Фреймы Минского и ООП - что раньше?

[nondeterminism]

arseniiv в сообщении #1013008 писал(а):

nondeterminism в сообщении #1012975 писал(а):

тогда уж текст программы, а не программу.

Как раз-таки программу. Программа может быть деревом, например. Деревом разбора λ-терма хотя бы.

Ваше замечание, как всегда, ни о чем. Любой текст программы при грамматическом разборе может быть разбит (и как правло разбивается) на дерево, однако, он не перестает быть текстом от этого.

[arseniiv]

nondeterminism в сообщении #1013010 писал(а):

Любой текст программы при грамматическом разборе может быть разбит (и как правло разбивается) на дерево, однако, он не перестает быть текстом от этого.

А какая разница, получили мы дерево из текста или каким-то иным способом? Вот макросы в лиспе конструируют сразу списки (и если перед нами не компилятор, списками всё и ограничится), не являющиеся текстом.

nondeterminism в сообщении #1013010 писал(а):

Ваше замечание, как всегда, ни о чем.

Скажите это себе.

[AlexDem]

nondeterminism в сообщении #1012975 писал(а):

AlexDem в сообщении #1012970 писал(а):

Машина может выполнять только программу, записанную на некотором языке.

тогда уж текст программы, а не программу.

Не представляю, как можно выполнить текст. Можно выполнить только то, что написано в тексте.

nondeterminism в сообщении #1012975 писал(а):

Если Вы придумали язык, значит Вы придумали машину для этого языка. Физическая реализация не важна в данном случае. Придумав язык вы автоматически придумываете правила интерпретации этого языка.

Нет, язык определяет правила образования текстовых цепочек, интерпретировать написанное можно множеством разных способов, не обязательно даже понимать это как программу.

[arseniiv]

В принципе, под языками программирования понимают обычно язык вместе с семантикой (хоть небольшой — например, что означает +). Но что этого достаточно для фиксации какого-то из трансляторов языка — спору нет, не.

[iifat]

nondeterminism в сообщении #1012947 писал(а):

iifat в сообщении #1012922 писал(а):

К языкам программирования — совершенно точно отдалённое.

Да, за исключением того, что основной инструмент реализации данных систем -- языки программирования

Вы забыли упомянуть, что программы вводятся в компьютер руками. Да, к анатомии тоже весьма непосредственно относятся.

[aa_dav]

А вот у меня стойкое ощущение, что ООП "назрел" когда стали в структуры добавлять указатели на функции. И увидели что это хорошо.
Тут для меня даже удивительно, что Симула прошла совершенно бесследно, хотя позднее мейнстрим вернулся именно к такому порядку вещей, а тяглом начального развития и популяризации концепции стал Смоллтолк.

[arseniiv]

Указатель на функцию как поле структуры — это ещё кому ООП, а кому и не ООП. Метод — это всё-таки штука одна на все экземпляры класса, тогда как поле экземпляра может иметь разное значение у каждого. В тех языках, где можно трактовать классы как просто особенные объекты, бывает, методы можно считать полями класса.

[aa_dav]

arseniiv в сообщении #1013392 писал(а):

Метод — это всё-таки штука одна на все экземпляры класса, тогда как поле экземпляра может иметь разное значение у каждого.

Это вопрос реализации. Главное как раз не то как будет реализовано, а то, что можно создать код который работает с широким спектром передаваемых ему сущностей единообразным способом. Буквально - глядя на код нельзя заранее сказать какое именно у него будет поведение. Кармак в Quake 1 GUI писал в сущности в ООП-нутом стиле на голой сишечке примерно следующим кодом:

struct element
{
    ...
    void (*on_draw)( element *self, ... );
    void (*on_activate)( element *self, ... );
};
...
struct button
{
     struct element parent; // наследование
};
...
void button_on_activate( element *self, ... );
{
      button *this = (button *) self;
      ...
};

Конечно это было много позднее обозначенных революций. Но что-то мне не верится, что революции произошли спонтанно, а не по итогу рассматривания подобного кода, ведь даже WinAPI по части HWND и WndProc это по сути механизм динамической диспетчеризации, где даже наследование можно углядеть тоже.
Но чёрт его знает, бывает то что сейчас кажется очевидным на ранней заре как раз никому очевидным не казалось.

[arseniiv]

aa_dav в сообщении #1013421 писал(а):

Главное как раз не то как будет реализовано, а то, что можно создать код который работает с широким спектром передаваемых ему сущностей единообразным способом. Буквально - глядя на код нельзя заранее сказать какое именно у него будет поведение.

Давайте не будем путать делегаты и методы. Да, они тоже добавляют полиморфизму, но используются чуть иначе. В библиотеках UI они поголовно используются для обработки событий, и примерно то же в остальных случаях — позволить не обязательно относящемуся к объекту коду (иначе, если есть наследование, используют и виртуальные методы) обработать какое-то «изменение» в состоянии этого объекта. А присваивать каждому объекту одинаковый набор значений полей и потом не трогать — это, как минимум, бессмысленная трата ресурсов. Когда нет классов и есть глобальные функции, в качестве методов используются (как в старые давние времена) именно они.

-- Пн май 11, 2015 19:46:27 --

Грубо говоря, делегат/поле-функция — это лишняя степень свободы экземпляра, когда метод — нет.

[aa_dav]

arseniiv в сообщении #1013571 писал(а):

Грубо говоря, делегат/поле-функция — это лишняя степень свободы экземпляра, когда метод — нет.

Грубо говоря вас с вашим пониманием концепции ООП создатель языка Смоллтол слал на известные буквы.
Если для вас ООП это С++ то вы невероятно и глубоко ошибаетесь.

-- 11.05.2015, 19:49 --

ООП это ООП.
Не надо мешать в кучу с vtbl и _proto_.
Это просто _техники_.
А суть в целом одна. Просто обогащается.
И никаких "интерфейсов" в духе Java/C# тоже нет в вики или прочих "банальных риторик", это просто _техники_.
Вопрос только в том что эти техники имеют целью. Сделать что-то чтобы пролазило в аргументы других методов имея под собой в случае типизированных языков собственно типы и их порождения... всего лишь...

[arseniiv]

aa_dav в сообщении #1013595 писал(а):

Если для вас ООП это С++ то вы невероятно и глубоко ошибаетесь.

Как можно было вывести C++, не понимаю. Где я его упоминал? Я вообще на нём практически не пишу.

aa_dav в сообщении #1013595 писал(а):

ООП это ООП.

Под ООП разные люди и языки понимают разное, это как бы не я придумал.

aa_dav в сообщении #1013595 писал(а):

А суть в целом одна.

А суть в целом из-за разнообразия языков уже не получается «одна» — всё это вместе уже не сводится.

aa_dav в сообщении #1013595 писал(а):

всего лишь...

Абстракция от всех деталей порождает бессмысленные определения без применения.

[Toucan]

aa_dav в сообщении #1013595 писал(а):

Грубо говоря вас с вашим пониманием концепции ООП создатель языка Смоллтол слал на известные буквы.

aa_dav, предупреждение за недопустимые формы ведения дискуссии.

[aa_dav]

arseniiv в сообщении #1013611 писал(а):

Как можно было вывести C++, не понимаю. Где я его упоминал?

arseniiv в сообщении #1013611 писал(а):

Под ООП разные люди и языки понимают разное, это как бы не я придумал.

Именно поэтому я вспомнил про Алана Кэя, собственно создателя Smalltalk и человека внедрившего вообще сам термин ООП. Цитаты:

Цитата:

Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++
...
Я жалею, что придумал термин «объекты» много лет назад, потому что он заставляет людей концентрироваться на мелких идеях. По-настоящему большая идея — это сообщения
...
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

Зауживать понятие "сообщения" методами и "не методами" - это неправильно. Тут скорее наоборот чем больше свободы тем круче сообщение.
P.S.
Более того, тот же C++, имхо, сильно страдает от отсутствия built-in делегатов, потому что делегаты это _просто отличный_ способ послать сообщение. Более чем естественное для _ООП_ callback-сообщение.

[arseniiv]

aa_dav в сообщении #1013758 писал(а):

Более того, тот же C++, имхо, сильно страдает от отсутствия built-in делегатов

Только что вы сами говорили об указателях на функции. Это ровно то же самое, если только не multi-cast, но тогда можно сделать список однотипных указателей, и делов.

aa_dav в сообщении #1013758 писал(а):

Зауживать понятие "сообщения" методами и "не методами" - это неправильно.

Долго думал и так и не сообразил, каким образом надо перепрыгнуть с одной мысли на другую.

В любом случае,

aa_dav в сообщении #1013758 писал(а):

потому что делегаты это _просто отличный_ способ послать сообщение

надеюсь, вы не считаете, что вам должны верить на слово.

[aa_dav]

arseniiv в сообщении #1013762 писал(а):

Только что вы сами говорили об указателях на функции. Это ровно то же самое

Касаемо С++ есть сильная разница между указателями на функции и указателями на методы, которые есть в языке, а делегаты вообще отсутствуют в том смысле в котором в них возникает потребность и их пилят и велосипедят десятками, включая std::function в С++11. Если бы они были в языке, к примеру, можно было бы написать такое:

vector<point> points;
circle c;
...
auto it = find_if( points.begin(), points.end(), c.is_inside );

Но это немного другая тема.

arseniiv в сообщении #1013762 писал(а):

надеюсь, вы не считаете, что вам должны верить на слово.

Мне не верьте, Алану Кэю поверьте. =)
Есть такая концепция "объекты обмениваются сообщениями". Так вот не надо пытаться зауживать картинку какими то конкретными реализациями. Что есть "метод" а что не есть.
Т.е. выше мне возразили что указатели на функции в структурах это не ООП, потому что не методы, а что-то другое. Делегаты типа. С классом какие то не такие соотношения.
Так вот - это может и не _метод_класса_ в смысле С++. Но это всё такой же способ отправки сообщения.
Еще раз - если процедурную парадигму можно сформулировать как "пишем код который может работать с известной (конкретной) сущностью и переиспользуем его многократно" (вызов процедур). То ООП это "пишем код который может работать с заранее неизвестной сущностью и переиспользуем его многократно". Коренное отличие именно в том, что сущность заранее неизвестна, от неё ожидается что она "сама знает" что и как ей сделать чтобы продвинуть процесс вперед. Ессесно мы не можем при этом полагаться на её конкретное внутренее устройство (без инкапсуляции таким образом это не взлетит) и естественно что нам нужна какая то техника чтобы передать поток управления этой сущности. В целом это называется динамическая диспетчеризация. И реализована она может быть массой способов. От лукапов по таблицам идентификаторов, до указателей на функции (привет WndProc) и там до делегатов. Это всё разные способы, но смысл их один - "послать объекту сообщение".
Поэтому неправильно говорить что WndProc это не ООП. Делая ГУИ ты всегда делаешь ООП.

-- 12.05.2015, 08:19 --

Собственно потому что есть действительно ряд задач которые кто бы не брался реализовывать, Кармак там или Microsoft, а в итоге получаются объекты обменивающиеся сообщениями - ООП - я и глубоко сомневаюсь что идея всплыла "неожиданно как озарение". Тут пахнет лишь последовательной эволюцией мысли.