Сообщение Re[10]: понимание ООП Алана Кея от 23.03.2023 15:11
Изменено 23.03.2023 15:21 vdimas
Re[10]: понимание ООП Алана Кея
Здравствуйте, Sinclair, Вы писали:
V>>Такие монстры как Голдберг служили неплохим противовесом этому, в общем-то, нубу-самоучке.
S>А что, Голдберг где-то заявляла, что язык Smalltalk был вдохновлён Фортом?
А что, Голдберг где-то заявляла, что язык Smalltalk был вдохновлён Лиспом?
Это ж чушь.
По официальной версии Smalltalk был вдохновлён Симулой, это повторяют участники разработки.
Из Форта взяли уже опробованные решения:
— шитый код, стековую машинку;
— возможность сохранения текущего состояния системы и повторной загрузки.
Последнее принципиально на медленной технике, это почему Форт порой был крайне удобен — каждый текущий момент времени ты компиллируешь/отлаживаешь только минимальный кусок кода.
Да, это была всего вторая в истории такая система после Форта.
Только в 3-й версии в Smalltalk-80 добавили вменяемую интроспекцию (а это уже языку 8 лет).
Отдалённо это можно сравнить с Лиспом и его расширением CLOS, потому что на деле нифига не так — в Лиспе хранится непосредственно AST в виде кортежей { функция, аргументы }.
А в Smalltalk код не хранится в таком виде.
Он хранится примерно как в Форте.
AST можно построить только обратной декомпиляцией, собсно, как это делается в Форт словом "see", куда я тебя уже отсылал, просто ты не понял — зачем. ))
Это примерно как обратная декомпиляция байткода CLI обратно в C#, только намного проще из-за простоты организации шитого кода.
Тебе же говорилось — ты слышал звон.
V>>Какой там в опу Лисп? ))
S>Да почитайте же уже The Early History of Smalltalk и перестаньте позориться.
Ты отвечай по-существу, не юли.
То, что сам Алан ретроспективно сравнивает свои решения с Лиспом и останавливается на отличиях — оно не делает ни тепло, ни холодно.
К тому же, он не единственный автор языка и его реализатор.
V>>Похоже, ты не трогал толком ни Смолтолк, ни Лисп, ни Форт, не понимаешь внутренней механики этих языков, но пытаешься фантазировать.
S>Вы всё время путаете дизайн языков с внутренней механикой компилятора и рантайма.
Наоборот, я утверждаю, что в общем случае это независимые вещи, упирающиеся в конкретные реализации.
Смолтолк конкретно мне интересен лишь в плане итории развития подходов программирования в IT.
Я хорошо понимаю принятые в процессе разработки языка (и затем системы разработки на его основе) решения, а так же, откуда они взялись, где были уже обкатаны и доказали свою полезность/эффективность.
V>>Т.е. в изначальном Лиспе никаких метаклассов не было, как и не было в Лиспе ООП, ес-но, были только ф-ии как первоклассные объекты (сам код) и данные в виде однонаправленно связанных встроенных в систему списков.
S>Конечно не было. Именно это Кей и реализовал — ему хотелось сделать систему, которая была построена на минимуме примитивов, как Лисп, но с ООП. Если бы в Лиспе было ООП, то Smalltalk бы и не понадобился.
Понадобился бы.
Смолтолк намного эффективнее Лиспа, хотя и уступал нейтивно-компиллируемым языкам.
Смолтолк выразительнее Лиспа при описании ООП.
И вообще при описании банальных арифметических и логических выражений и просто императивного кода.
Уже этих двух аргументов достаточно, чтобы не воспринимать Лисп как удовлетворительную ООП-систему, хотя с ООП там более-менее в CLOS.
Просто надо понимать, как именно тогда использовался LISP.
Он был что-то вроде современного Питона, т.е. языком, на котором было легко обкатывать концепции, экспериментировать и т.д.
Я бы еще понял, если бы ты сформулировал "Смолтолк был вдохновлён недовольством Лиспом", бо это близко к истине.
И не только Лиспом, ес-но, просто Лисп — удобный мальчик для битья. ))
V>>Курить, что есть шитый код.
S>Я знаю, что такое шитый код. Какое отношение он имеет к дизайну языка Smalltalk?
Прямое.
Во главу угла изначально ставилась простота реализации.
Шитый код давал в разы лучшую эффективность, чем машинка Лиспа, всё еще позволяя удобно манипулировать бинарным кодом, порождать его "на лету" и т.д.
Дизайн языка не был сформирован чисто теоретически.
Это была рекурсивная разработка, где особенности реализации нижнего уровня влияли на верхние и обратно тоже.
Т.е. никто не пытался разработать совсем абстрактный язык, как в случае с тем же Хаскелем.
Смолтолк — это изначально "реальный" язык. ))
V>>Пример развития Форта до переносимости м/у устройствами.
S>По-прежнему не понимаю, какое отношение Постскрипт с его переносимостью имеет к ООП Алана Кея.
Это уже юление.
Ты говорил про переносимость кода тут.
Хотя на самом деле имел ввиду не это.
(или же намеренно оставил как "последний аргумент", хотя я несколько раз явно дал понять, как понял твою задачу).
V>>Таки, самообразованием принято заниматься самостоятельно, не испытывая терпение коллег.
S>Ну так займитесь. Почему вы вместо того, чтобы почитать первоисточники, занимаетесь гаданием на МК-51?
Алан Кей с его столь громкими и столь же некорректными высказываниями не заслуживает достаточного доверия в кач-ве надёжного источника.
Над языком работали еще люди.
Пробуй аргументировать другими авторами, если сможешь.
— Аллан не изобрел ООП (хотя позиционирует себя как автор ООП).
— В его формулировке ООП неполно: http://www.rsdn.org/forum/flame.comp/8471966.1
— Он не изобрел ни одного принципиального решения, легшего в основу Смолтолка.
"Посылка сообщений" — это лишь взгляд на проблему, а не техническая концепция или ее реализация.
Он, по-сути, "интегратор-компилятор" — увидел возможность реализации полудинамического ООП-языка с достаточной эффективностью на основе имеющихся уже в IT на тот момент наработок.
До Смолтолка ООП-языки были только статическими (библиотечная эмуляция ООП на Лиспе не в счёт, бо эмулировать можно что угодно на чём угодно).
Он создать систему с такими св-вами, пообещав, что реализация должна получиться простой, всё.
Но работали они над языком аж 8 лет, прежде чем продукт стал коммерческим.
Т.е. не всё так просто, и тут очередная саечка Алану за шапкозакидательство.
Это что-то типа проекта Nemerle — ни одной новой концепции в языке не изобрели, просто попытка собрать удачные концепции на удачной платформе.
Но Nemerle реализовали достаточно быстро в первой версии и достаточно полно, в отличие от.
S>>>Попробуйте реализовать на Паскале, Си, и С++ функцию, которая бы передавала пользовательский предикат на сервер для исполнения.
V>>Не вижу технических проблем передать чистую ф-ию или чистое замыкание при наличии соотв. инфраструктуры.
S>Пример кода в студию. Хотя бы на одном из языков.
В предыдущем сообщении пример дан.
V>>Напомню, что MS компилятор С++ умеет компиллировать unamanaged C++ код (т.е. безо-всяких managed расширений) в чистый байт-код.
V>>(тип генерируемого образа для режима С++/CLI задаётся опциями компилятора)
S>Ну ок, если вам будет проще — попробуйте изобразить требуемую функциональность на unmanaged C++, скомпилированном в чистый байт-код.
Точную форулировку требуемой функциональности в студию.
V>>Ну вот попробуй на Лисп (или другом динамическом языке) без динамического исполнения текстовых исходников, а я поржу.
S>
Посмотрите на то, как устроены макросы Лиспа. Там нет ничего про динамическое исполнение текстовых исходников.
S>Всё построено на манипуляциях кодом в виде AST. Можете начинать ржать.
Это залёт, курсант! ))
Код макросов лиспа не манипулирует AST явно.
Макросы Лиспа подстановочные (шаблонные), как макросы Си/С++ или макроассемблера.
Заметное отличие лишь в том, что макросы Лиспа МОГУТ быть гигиеническими (если программист не забудет экранировать область видимости символов, бгг).
А вот макросы Форта устроены иначе — они получают на входе поток лексем и манипулируют с ним именно явно, порождая то самое AST.
Смотри, сколько каши приходится разгребать. ))
V>>Такая возможность связана с представлением исполняемого кода, а это представление перпендикулярно языку.
V>>Похоже, у тебя каша в голове из св-в языков и конкретных их компиляторов/интерпретаторов.
S>Всё ровно наоборот — это у вас каша.
У меня понимание, как оно устроено и работает.
А у тебя бесконечные "слышал звон" и передёргивания из разряда сказала-мазала.
V>>Язык, по-сути, тот же.
V>>Отличается представлением скомпиллированного кода, а значит, особенностями модели вычисления.
S>И самое замечательное, что эти особенности модели вычисления никак не влияют на то, о чём я говорю.
Еще как влияют.
Макросы Схемы живут только в момент компиляции, в отличии от макросов Лиспа, которые становятся частью текущего состояния "системы".
Макросы Схемы имеют другое ключевое слово и пара особенностей.
Но это по-прежнему подстановочные/позиционные макросы, без явного манипулирования AST.
S>Макросы в Схеме всё ещё есть, и это означает, что я могу решить обозначенную задачу и на схеме тоже.
Увы, увы.
Причём, тут я противоречу самому себе, вроде бы, ведь можно представить себе такую реализацию Схемы, которая ведёт себя как Лисп?
Представить такую реализацию можно, да вот только Схема — это именно компиллируемая версия Лиспа. ))
А динамическая версия — это сам Лисп.
Для целей эффективного конечного кода пришлось внести в Лисп несколько ограничений, наверно поэтому назвали другим языком и стандарты Схемы с тех пор развиваются независимо от Лиспа.
Вернее, впервые стандарты на семейство Лисп появились в Схеме — именно из-за вносимых ограничений.
Заметно позже сообщество стало формировать стандарты и на Лисп — CL.
Ну и, стандарты на эмуляцию ООП в Лиспе поверх CL — CLOS.
Хотя именно с точки зрения языка (а не подробностей его реализации) Схему можно считать диалектом Лиспа, конечно!
S>А всё потому, что решают тут свойства языка. Что там под капотом — дело десятое.
Кошмар
У языка два свойства — синтаксис и семантика.
Если тебе надо получить AST — это всего лишь синтаксис.
Никакой язык не запрещает получать синтаксис своих выражений.
И отправить на сервер ты хотел не код на исполнение, как выяснилось, а AST выражений на трансформацию.
Для исполнения отправляют более эффективный в исполнении код, обычно, поэтому я и показывал, как это делают в других технологиях.
Не берём пример браузеров и JS, бо это совсем кошмар — тянуть кода на исполнение.
V>>Не осенило еще? ))
S>Вижу, что вас не осенило. Причина, я думаю, именно в том, что вы не пробуете сделать то, о чём я говорю.
Сделать что именно?
Учись спрашивать.
V>>Например, MS Visual Basic for DOS компиллировал в неплохо оптимизированный код (я курочил дизассемблером что он там порождает — да там офигенно, на уровне их же компилятора Си и Паскаля).
S>Да видел конечно. Толку-то? Ни на одном из этих бейсиков я не могу отправить на сервер код пользовательского предиката.
Это был наглядный пример того, что язык тот же, а реализация разная.
В офисе он же хранится в виде VBA, и документ можно отослать и исполнить код в нём.
V>>В Лисп точно так же может сосуществовать сколько угодно много независимых ООП-подсистем библиотечного уровня.
S>Я в курсе. Синтаксис Лиспа настолько ужасен, что его ничем испортить нельзя. Поэтому всякие надстройки над ним выглядят не хуже оригинального лиспа.
S>И можно делать любое ООП, которое нравится — с наследованием интерфейсов и наследованием реализации, со множественным наследованием и без, с любыми наборами модификаторов "видимости" мемберов. Можно придумывать свойства и события; можно делать наследование экземпляров как в JS; можно обрабатывать неизвестные сообщения, как в Smalltalk.
S>Правда, всё это будет всё в том же ужасном стиле скобок поверх скобок. Но на фоне остального лисп-кода выделяться не будет.
В любом случае, это лишь эмуляция.
А эмулировать что угодно можно на люом Тьюринг-полном языке.
Объекты в Лиспе не являются первоклассными сущностями языка, вот в чём косяк.
Первоклассной сущностью там являются числа/символы, функции и пара CONS(car, cdr), где каждый элемент пары может быть числом, функцией или опять парой (ссылочная семантика для всего перечисленного).
S>В общем, Лисп считать ОО-языком бессмысленно.
Именно.
Зато Форт (бгг, сорри... Но Чарльз Мур был, таки, умнейшим челом) позволяет сделать первоклассной сущностью любую хрень.
Форт рассматривается опытным фортером как язык для порождения языков (из-за особенностей макросистемы, которая нифига не как в Лиспе), и именно так пишутся на ём программы — исключительно через определение слоёв DSL от самых низких до целевых. Не зря конструкции Форта называются словами. Программа в форте — это всегда описание новых слов. А с помощью них — других, более ёмких.
ничего более элегантного я не видел до сих пор, т.к. виденные другие языки навязывают синтаксис и философию.
Форт навязывает лишь способ мышления, не навязывая остального.
И при этом чудовищно прост в реализации.
И при этом чудовищно эффективен, в сравнении с Лиспом.
Порой и в сравнении с нейтивом из-за особенностей манипулирования стеком — в Форте обычно меньше паразитных манипуляций данными в стеках/регистрах, меньше ненужных копирований/преобразований данных — состояние стека на выходе одного слова часто является готовым состоянием стека для вызова другого. Писать программы на Форте — это как играть в Тетрис, натурально, все фигуры должны стыковаться, и тогда прога просто летает. ))
V>>Ты не понимаешь мотива принятия некоторых важных решений в IT в ретроспективе.
S>
Более того, ты зачем-то отмахиваешься от такой инфрмации, оперируя вещами, скорее, эмоциональными, чем рациональными.
V>>Проводимый ликбез тебя коробит, но это особенности твоего чванства и ничего более.
S>Скорее, это особенности вашего чванства.
За новую инфу я всегда благодарен, в отличие от.
А тебя аналогичный сценарий всегда бесит, что ты аж перестаёшь быть корректным в логике спора. ))
V>>Такие монстры как Голдберг служили неплохим противовесом этому, в общем-то, нубу-самоучке.
S>А что, Голдберг где-то заявляла, что язык Smalltalk был вдохновлён Фортом?
А что, Голдберг где-то заявляла, что язык Smalltalk был вдохновлён Лиспом?
Это ж чушь.
По официальной версии Smalltalk был вдохновлён Симулой, это повторяют участники разработки.
Из Форта взяли уже опробованные решения:
— шитый код, стековую машинку;
— возможность сохранения текущего состояния системы и повторной загрузки.
Последнее принципиально на медленной технике, это почему Форт порой был крайне удобен — каждый текущий момент времени ты компиллируешь/отлаживаешь только минимальный кусок кода.
Да, это была всего вторая в истории такая система после Форта.
Только в 3-й версии в Smalltalk-80 добавили вменяемую интроспекцию (а это уже языку 8 лет).
Отдалённо это можно сравнить с Лиспом и его расширением CLOS, потому что на деле нифига не так — в Лиспе хранится непосредственно AST в виде кортежей { функция, аргументы }.
А в Smalltalk код не хранится в таком виде.
Он хранится примерно как в Форте.
AST можно построить только обратной декомпиляцией, собсно, как это делается в Форт словом "see", куда я тебя уже отсылал, просто ты не понял — зачем. ))
Это примерно как обратная декомпиляция байткода CLI обратно в C#, только намного проще из-за простоты организации шитого кода.
Тебе же говорилось — ты слышал звон.
V>>Какой там в опу Лисп? ))
S>Да почитайте же уже The Early History of Smalltalk и перестаньте позориться.
Ты отвечай по-существу, не юли.
То, что сам Алан ретроспективно сравнивает свои решения с Лиспом и останавливается на отличиях — оно не делает ни тепло, ни холодно.
К тому же, он не единственный автор языка и его реализатор.
V>>Похоже, ты не трогал толком ни Смолтолк, ни Лисп, ни Форт, не понимаешь внутренней механики этих языков, но пытаешься фантазировать.
S>Вы всё время путаете дизайн языков с внутренней механикой компилятора и рантайма.
Наоборот, я утверждаю, что в общем случае это независимые вещи, упирающиеся в конкретные реализации.
Смолтолк конкретно мне интересен лишь в плане итории развития подходов программирования в IT.
Я хорошо понимаю принятые в процессе разработки языка (и затем системы разработки на его основе) решения, а так же, откуда они взялись, где были уже обкатаны и доказали свою полезность/эффективность.
V>>Т.е. в изначальном Лиспе никаких метаклассов не было, как и не было в Лиспе ООП, ес-но, были только ф-ии как первоклассные объекты (сам код) и данные в виде однонаправленно связанных встроенных в систему списков.
S>Конечно не было. Именно это Кей и реализовал — ему хотелось сделать систему, которая была построена на минимуме примитивов, как Лисп, но с ООП. Если бы в Лиспе было ООП, то Smalltalk бы и не понадобился.
Понадобился бы.
Смолтолк намного эффективнее Лиспа, хотя и уступал нейтивно-компиллируемым языкам.
Смолтолк выразительнее Лиспа при описании ООП.
И вообще при описании банальных арифметических и логических выражений и просто императивного кода.
Уже этих двух аргументов достаточно, чтобы не воспринимать Лисп как удовлетворительную ООП-систему, хотя с ООП там более-менее в CLOS.
Просто надо понимать, как именно тогда использовался LISP.
Он был что-то вроде современного Питона, т.е. языком, на котором было легко обкатывать концепции, экспериментировать и т.д.
Я бы еще понял, если бы ты сформулировал "Смолтолк был вдохновлён недовольством Лиспом", бо это близко к истине.
И не только Лиспом, ес-но, просто Лисп — удобный мальчик для битья. ))
V>>Курить, что есть шитый код.
S>Я знаю, что такое шитый код. Какое отношение он имеет к дизайну языка Smalltalk?
Прямое.
Во главу угла изначально ставилась простота реализации.
Шитый код давал в разы лучшую эффективность, чем машинка Лиспа, всё еще позволяя удобно манипулировать бинарным кодом, порождать его "на лету" и т.д.
Дизайн языка не был сформирован чисто теоретически.
Это была рекурсивная разработка, где особенности реализации нижнего уровня влияли на верхние и обратно тоже.
Т.е. никто не пытался разработать совсем абстрактный язык, как в случае с тем же Хаскелем.
Смолтолк — это изначально "реальный" язык. ))
V>>Пример развития Форта до переносимости м/у устройствами.
S>По-прежнему не понимаю, какое отношение Постскрипт с его переносимостью имеет к ООП Алана Кея.
Это уже юление.
Ты говорил про переносимость кода тут.
Хотя на самом деле имел ввиду не это.
(или же намеренно оставил как "последний аргумент", хотя я несколько раз явно дал понять, как понял твою задачу).
V>>Таки, самообразованием принято заниматься самостоятельно, не испытывая терпение коллег.
S>Ну так займитесь. Почему вы вместо того, чтобы почитать первоисточники, занимаетесь гаданием на МК-51?
Алан Кей с его столь громкими и столь же некорректными высказываниями не заслуживает достаточного доверия в кач-ве надёжного источника.
Над языком работали еще люди.
Пробуй аргументировать другими авторами, если сможешь.
— Аллан не изобрел ООП (хотя позиционирует себя как автор ООП).
— В его формулировке ООП неполно: http://www.rsdn.org/forum/flame.comp/8471966.1
— Он не изобрел ни одного принципиального решения, легшего в основу Смолтолка.
"Посылка сообщений" — это лишь взгляд на проблему, а не техническая концепция или ее реализация.
Он, по-сути, "интегратор-компилятор" — увидел возможность реализации полудинамического ООП-языка с достаточной эффективностью на основе имеющихся уже в IT на тот момент наработок.
До Смолтолка ООП-языки были только статическими (библиотечная эмуляция ООП на Лиспе не в счёт, бо эмулировать можно что угодно на чём угодно).
Он создать систему с такими св-вами, пообещав, что реализация должна получиться простой, всё.
Но работали они над языком аж 8 лет, прежде чем продукт стал коммерческим.
Т.е. не всё так просто, и тут очередная саечка Алану за шапкозакидательство.
Это что-то типа проекта Nemerle — ни одной новой концепции в языке не изобрели, просто попытка собрать удачные концепции на удачной платформе.
Но Nemerle реализовали достаточно быстро в первой версии и достаточно полно, в отличие от.
S>>>Попробуйте реализовать на Паскале, Си, и С++ функцию, которая бы передавала пользовательский предикат на сервер для исполнения.
V>>Не вижу технических проблем передать чистую ф-ию или чистое замыкание при наличии соотв. инфраструктуры.
S>Пример кода в студию. Хотя бы на одном из языков.
В предыдущем сообщении пример дан.
V>>Напомню, что MS компилятор С++ умеет компиллировать unamanaged C++ код (т.е. безо-всяких managed расширений) в чистый байт-код.
V>>(тип генерируемого образа для режима С++/CLI задаётся опциями компилятора)
S>Ну ок, если вам будет проще — попробуйте изобразить требуемую функциональность на unmanaged C++, скомпилированном в чистый байт-код.
Точную форулировку требуемой функциональности в студию.
V>>Ну вот попробуй на Лисп (или другом динамическом языке) без динамического исполнения текстовых исходников, а я поржу.
S>
Посмотрите на то, как устроены макросы Лиспа. Там нет ничего про динамическое исполнение текстовых исходников. S>Всё построено на манипуляциях кодом в виде AST. Можете начинать ржать.
Это залёт, курсант! ))
Код макросов лиспа не манипулирует AST явно.
Макросы Лиспа подстановочные (шаблонные), как макросы Си/С++ или макроассемблера.
Заметное отличие лишь в том, что макросы Лиспа МОГУТ быть гигиеническими (если программист не забудет экранировать область видимости символов, бгг).
А вот макросы Форта устроены иначе — они получают на входе поток лексем и манипулируют с ним именно явно, порождая то самое AST.
Смотри, сколько каши приходится разгребать. ))
V>>Такая возможность связана с представлением исполняемого кода, а это представление перпендикулярно языку.
V>>Похоже, у тебя каша в голове из св-в языков и конкретных их компиляторов/интерпретаторов.
S>Всё ровно наоборот — это у вас каша.
У меня понимание, как оно устроено и работает.
А у тебя бесконечные "слышал звон" и передёргивания из разряда сказала-мазала.
V>>Язык, по-сути, тот же.
V>>Отличается представлением скомпиллированного кода, а значит, особенностями модели вычисления.
S>И самое замечательное, что эти особенности модели вычисления никак не влияют на то, о чём я говорю.
Еще как влияют.
Макросы Схемы живут только в момент компиляции, в отличии от макросов Лиспа, которые становятся частью текущего состояния "системы".
Макросы Схемы имеют другое ключевое слово и пара особенностей.
Но это по-прежнему подстановочные/позиционные макросы, без явного манипулирования AST.
S>Макросы в Схеме всё ещё есть, и это означает, что я могу решить обозначенную задачу и на схеме тоже.
Увы, увы.
Причём, тут я противоречу самому себе, вроде бы, ведь можно представить себе такую реализацию Схемы, которая ведёт себя как Лисп?
Представить такую реализацию можно, да вот только Схема — это именно компиллируемая версия Лиспа. ))
А динамическая версия — это сам Лисп.
Для целей эффективного конечного кода пришлось внести в Лисп несколько ограничений, наверно поэтому назвали другим языком и стандарты Схемы с тех пор развиваются независимо от Лиспа.
Вернее, впервые стандарты на семейство Лисп появились в Схеме — именно из-за вносимых ограничений.
Заметно позже сообщество стало формировать стандарты и на Лисп — CL.
Ну и, стандарты на эмуляцию ООП в Лиспе поверх CL — CLOS.
Хотя именно с точки зрения языка (а не подробностей его реализации) Схему можно считать диалектом Лиспа, конечно!
S>А всё потому, что решают тут свойства языка. Что там под капотом — дело десятое.
Кошмар
У языка два свойства — синтаксис и семантика.
Если тебе надо получить AST — это всего лишь синтаксис.
Никакой язык не запрещает получать синтаксис своих выражений.
И отправить на сервер ты хотел не код на исполнение, как выяснилось, а AST выражений на трансформацию.
Для исполнения отправляют более эффективный в исполнении код, обычно, поэтому я и показывал, как это делают в других технологиях.
Не берём пример браузеров и JS, бо это совсем кошмар — тянуть кода на исполнение.
V>>Не осенило еще? ))
S>Вижу, что вас не осенило. Причина, я думаю, именно в том, что вы не пробуете сделать то, о чём я говорю.
Сделать что именно?
Учись спрашивать.
V>>Например, MS Visual Basic for DOS компиллировал в неплохо оптимизированный код (я курочил дизассемблером что он там порождает — да там офигенно, на уровне их же компилятора Си и Паскаля).
S>Да видел конечно. Толку-то? Ни на одном из этих бейсиков я не могу отправить на сервер код пользовательского предиката.
Это был наглядный пример того, что язык тот же, а реализация разная.
В офисе он же хранится в виде VBA, и документ можно отослать и исполнить код в нём.
V>>В Лисп точно так же может сосуществовать сколько угодно много независимых ООП-подсистем библиотечного уровня.
S>Я в курсе. Синтаксис Лиспа настолько ужасен, что его ничем испортить нельзя. Поэтому всякие надстройки над ним выглядят не хуже оригинального лиспа.
S>И можно делать любое ООП, которое нравится — с наследованием интерфейсов и наследованием реализации, со множественным наследованием и без, с любыми наборами модификаторов "видимости" мемберов. Можно придумывать свойства и события; можно делать наследование экземпляров как в JS; можно обрабатывать неизвестные сообщения, как в Smalltalk.
S>Правда, всё это будет всё в том же ужасном стиле скобок поверх скобок. Но на фоне остального лисп-кода выделяться не будет.
В любом случае, это лишь эмуляция.
А эмулировать что угодно можно на люом Тьюринг-полном языке.
Объекты в Лиспе не являются первоклассными сущностями языка, вот в чём косяк.
Первоклассной сущностью там являются числа/символы, функции и пара CONS(car, cdr), где каждый элемент пары может быть числом, функцией или опять парой (ссылочная семантика для всего перечисленного).
S>В общем, Лисп считать ОО-языком бессмысленно.
Именно.
Зато Форт (бгг, сорри... Но Чарльз Мур был, таки, умнейшим челом) позволяет сделать первоклассной сущностью любую хрень.
Форт рассматривается опытным фортером как язык для порождения языков (из-за особенностей макросистемы, которая нифига не как в Лиспе), и именно так пишутся на ём программы — исключительно через определение слоёв DSL от самых низких до целевых. Не зря конструкции Форта называются словами. Программа в форте — это всегда описание новых слов. А с помощью них — других, более ёмких.
ничего более элегантного я не видел до сих пор, т.к. виденные другие языки навязывают синтаксис и философию.
Форт навязывает лишь способ мышления, не навязывая остального.
И при этом чудовищно прост в реализации.
И при этом чудовищно эффективен, в сравнении с Лиспом.
Порой и в сравнении с нейтивом из-за особенностей манипулирования стеком — в Форте обычно меньше паразитных манипуляций данными в стеках/регистрах, меньше ненужных копирований/преобразований данных — состояние стека на выходе одного слова часто является готовым состоянием стека для вызова другого. Писать программы на Форте — это как играть в Тетрис, натурально, все фигуры должны стыковаться, и тогда прога просто летает. ))
V>>Ты не понимаешь мотива принятия некоторых важных решений в IT в ретроспективе.
S>
Более того, ты зачем-то отмахиваешься от такой инфрмации, оперируя вещами, скорее, эмоциональными, чем рациональными.
V>>Проводимый ликбез тебя коробит, но это особенности твоего чванства и ничего более.
S>Скорее, это особенности вашего чванства.
За новую инфу я всегда благодарен, в отличие от.
А тебя аналогичный сценарий всегда бесит, что ты аж перестаёшь быть корректным в логике спора. ))
Re[10]: понимание ООП Алана Кея
Здравствуйте, Sinclair, Вы писали:
V>>Такие монстры как Голдберг служили неплохим противовесом этому, в общем-то, нубу-самоучке.
S>А что, Голдберг где-то заявляла, что язык Smalltalk был вдохновлён Фортом?
А что, Голдберг где-то заявляла, что язык Smalltalk был вдохновлён Лиспом?
Это ж чушь.
По официальной версии Smalltalk был вдохновлён Симулой, это повторяют участники разработки.
Из Форта взяли уже опробованные решения:
— шитый код, стековую машинку;
— возможность сохранения текущего состояния системы и повторной загрузки.
Последнее принципиально на медленной технике, это почему Форт порой был крайне удобен — каждый текущий момент времени ты компиллируешь/отлаживаешь только минимальный кусок кода.
Да, это была всего вторая в истории такая система после Форта.
Только в 3-й версии в Smalltalk-80 добавили вменяемую интроспекцию (а это уже языку 8 лет).
Отдалённо это можно сравнить с Лиспом и его расширением CLOS, потому что на деле нифига не так — в Лиспе хранится непосредственно AST в виде кортежей { функция, аргументы }.
А в Smalltalk код не хранится в таком виде.
Он хранится примерно как в Форте.
AST можно построить только обратной декомпиляцией, собсно, как это делается в Форт словом "see", куда я тебя уже отсылал, просто ты не понял — зачем. ))
Это примерно как обратная декомпиляция байткода CLI обратно в C#, только намного проще из-за простоты организации шитого кода.
Тебе же говорилось — ты слышал звон.
V>>Какой там в опу Лисп? ))
S>Да почитайте же уже The Early History of Smalltalk и перестаньте позориться.
Ты отвечай по-существу, не юли.
То, что сам Алан ретроспективно сравнивает свои решения с Лиспом и останавливается на отличиях — оно не делает ни тепло, ни холодно.
К тому же, он не единственный автор языка и его реализатор.
V>>Похоже, ты не трогал толком ни Смолтолк, ни Лисп, ни Форт, не понимаешь внутренней механики этих языков, но пытаешься фантазировать.
S>Вы всё время путаете дизайн языков с внутренней механикой компилятора и рантайма.
Наоборот, я утверждаю, что в общем случае это независимые вещи, упирающиеся в конкретные реализации.
Смолтолк конкретно мне интересен лишь в плане итории развития подходов программирования в IT.
Я хорошо понимаю принятые в процессе разработки языка (и затем системы разработки на его основе) решения, а так же, откуда они взялись, где были уже обкатаны и доказали свою полезность/эффективность.
V>>Т.е. в изначальном Лиспе никаких метаклассов не было, как и не было в Лиспе ООП, ес-но, были только ф-ии как первоклассные объекты (сам код) и данные в виде однонаправленно связанных встроенных в систему списков.
S>Конечно не было. Именно это Кей и реализовал — ему хотелось сделать систему, которая была построена на минимуме примитивов, как Лисп, но с ООП. Если бы в Лиспе было ООП, то Smalltalk бы и не понадобился.
Понадобился бы.
Смолтолк намного эффективнее Лиспа, хотя и уступал нейтивно-компиллируемым языкам.
Смолтолк выразительнее Лиспа при описании ООП.
И вообще при описании банальных арифметических и логических выражений и просто императивного кода.
Уже этих двух аргументов достаточно, чтобы не воспринимать Лисп как удовлетворительную ООП-систему, хотя с ООП там более-менее в CLOS.
Просто надо понимать, как именно тогда использовался LISP.
Он был что-то вроде современного Питона, т.е. языком, на котором было легко обкатывать концепции, экспериментировать и т.д.
Я бы еще понял, если бы ты сформулировал "Смолтолк был вдохновлён недовольством Лиспом", бо это близко к истине.
И не только Лиспом, ес-но, просто Лисп — удобный мальчик для битья. ))
V>>Курить, что есть шитый код.
S>Я знаю, что такое шитый код. Какое отношение он имеет к дизайну языка Smalltalk?
Прямое.
Во главу угла изначально ставилась простота реализации.
Шитый код давал в разы лучшую эффективность, чем машинка Лиспа, всё еще позволяя удобно манипулировать бинарным кодом, порождать его "на лету" и т.д.
Дизайн языка не был сформирован чисто теоретически.
Это была рекурсивная разработка, где особенности реализации нижнего уровня влияли на верхние и обратно тоже.
Т.е. никто не пытался разработать совсем абстрактный язык, как в случае с тем же Хаскелем.
Смолтолк — это изначально "реальный" язык. ))
V>>Пример развития Форта до переносимости м/у устройствами.
S>По-прежнему не понимаю, какое отношение Постскрипт с его переносимостью имеет к ООП Алана Кея.
Это уже юление.
Ты говорил про переносимость кода тут.
Хотя на самом деле имел ввиду не это.
(или же намеренно оставил как "последний аргумент", хотя я несколько раз явно дал понять, как понял твою задачу).
V>>Таки, самообразованием принято заниматься самостоятельно, не испытывая терпение коллег.
S>Ну так займитесь. Почему вы вместо того, чтобы почитать первоисточники, занимаетесь гаданием на МК-51?
Алан Кей с его столь громкими и столь же некорректными высказываниями не заслуживает достаточного доверия в кач-ве надёжного источника.
Над языком работали еще люди.
Пробуй аргументировать другими авторами, если сможешь.
— Аллан не изобрел ООП (хотя позиционирует себя как автор ООП).
— В его формулировке ООП неполно: http://www.rsdn.org/forum/flame.comp/8471966.1
— Он не изобрел ни одного принципиального решения, легшего в основу Смолтолка.
"Посылка сообщений" — это лишь взгляд на проблему, а не техническая концепция или ее реализация.
Он, по-сути, "интегратор-компилятор" — увидел возможность реализации полудинамического ООП-языка с достаточной эффективностью на основе имеющихся уже в IT на тот момент наработок.
До Смолтолка ООП-языки были только статическими (библиотечная эмуляция ООП на Лиспе не в счёт, бо эмулировать можно что угодно на чём угодно).
Он предложил создать систему с такими св-вами, пообещав, что реализация должна получиться простой, всё.
Но работали они над языком аж 8 лет, прежде чем продукт стал коммерческим.
Т.е. не всё так просто, и тут очередная саечка Алану за шапкозакидательство.
(я вообще терпеть не могу поверхностных людей, особенно в инженерии)
Это что-то типа проекта Nemerle — ни одной новой концепции в языке не изобрели, просто попытка собрать удачные концепции на удачной платформе.
Но! Nemerle реализовали достаточно быстро в первой версии и достаточно полно, в отличие от.
И описание концепций Nemerle удивительно точное и полное.
Я не могу на полном серьёзе сравнивать болтовню Алана уровня болтовни бабушек у подъезда с подачей материала другими авторами.
Есть еще один такой же прихлебатель от IT — Мартин Фаулер, с Аланом два сапога пара.
Якающие нубы, за которых сплошной испанский стыд. ))
S>>>Попробуйте реализовать на Паскале, Си, и С++ функцию, которая бы передавала пользовательский предикат на сервер для исполнения.
V>>Не вижу технических проблем передать чистую ф-ию или чистое замыкание при наличии соотв. инфраструктуры.
S>Пример кода в студию. Хотя бы на одном из языков.
В предыдущем сообщении пример дан.
V>>Напомню, что MS компилятор С++ умеет компиллировать unamanaged C++ код (т.е. безо-всяких managed расширений) в чистый байт-код.
V>>(тип генерируемого образа для режима С++/CLI задаётся опциями компилятора)
S>Ну ок, если вам будет проще — попробуйте изобразить требуемую функциональность на unmanaged C++, скомпилированном в чистый байт-код.
Точную форулировку требуемой функциональности в студию.
V>>Ну вот попробуй на Лисп (или другом динамическом языке) без динамического исполнения текстовых исходников, а я поржу.
S> Посмотрите на то, как устроены макросы Лиспа. Там нет ничего про динамическое исполнение текстовых исходников.
S>Всё построено на манипуляциях кодом в виде AST. Можете начинать ржать.
Это залёт, курсант! ))
Код макросов лиспа не манипулирует AST явно.
Макросы Лиспа подстановочные (шаблонные), как макросы Си/С++ или макроассемблера.
Заметное отличие лишь в том, что макросы Лиспа МОГУТ быть гигиеническими (если программист не забудет экранировать область видимости символов, бгг).
А вот макросы Форта устроены иначе — они получают на входе поток лексем и манипулируют с ним именно явно, порождая то самое AST.
Смотри, сколько каши приходится разгребать. ))
V>>Такая возможность связана с представлением исполняемого кода, а это представление перпендикулярно языку.
V>>Похоже, у тебя каша в голове из св-в языков и конкретных их компиляторов/интерпретаторов.
S>Всё ровно наоборот — это у вас каша.
У меня понимание, как оно устроено и работает.
А у тебя бесконечные "слышал звон" и передёргивания из разряда сказала-мазала.
V>>Язык, по-сути, тот же.
V>>Отличается представлением скомпиллированного кода, а значит, особенностями модели вычисления.
S>И самое замечательное, что эти особенности модели вычисления никак не влияют на то, о чём я говорю.
Еще как влияют.
Макросы Схемы живут только в момент компиляции, в отличии от макросов Лиспа, которые становятся частью текущего состояния "системы".
Макросы Схемы имеют другое ключевое слово и пара особенностей.
Но это по-прежнему подстановочные/позиционные макросы, без явного манипулирования AST.
S>Макросы в Схеме всё ещё есть, и это означает, что я могу решить обозначенную задачу и на схеме тоже.
Увы, увы.
Причём, тут я противоречу самому себе, вроде бы, ведь можно представить себе такую реализацию Схемы, которая ведёт себя как Лисп?
Представить такую реализацию можно, да вот только Схема — это именно компиллируемая версия Лиспа. ))
А динамическая версия — это сам Лисп.
Для целей эффективного конечного кода пришлось внести в Лисп несколько ограничений, наверно поэтому назвали другим языком и стандарты Схемы с тех пор развиваются независимо от Лиспа.
Вернее, впервые стандарты на семейство Лисп появились в Схеме — именно из-за вносимых ограничений.
Заметно позже сообщество стало формировать стандарты и на Лисп — CL.
Ну и, стандарты на эмуляцию ООП в Лиспе поверх CL — CLOS.
Хотя именно с точки зрения языка (а не подробностей его реализации) Схему можно считать диалектом Лиспа, конечно!
S>А всё потому, что решают тут свойства языка. Что там под капотом — дело десятое.
Кошмар
У языка два свойства — синтаксис и семантика.
Если тебе надо получить AST — это всего лишь синтаксис.
Никакой язык не запрещает получать синтаксис своих выражений.
И отправить на сервер ты хотел не код на исполнение, как выяснилось, а AST выражений на трансформацию.
Для исполнения отправляют более эффективный в исполнении код, обычно, поэтому я и показывал, как это делают в других технологиях.
Не берём пример браузеров и JS, бо это совсем кошмар — тянуть кода на исполнение.
V>>Не осенило еще? ))
S>Вижу, что вас не осенило. Причина, я думаю, именно в том, что вы не пробуете сделать то, о чём я говорю.
Сделать что именно?
Учись спрашивать.
V>>Например, MS Visual Basic for DOS компиллировал в неплохо оптимизированный код (я курочил дизассемблером что он там порождает — да там офигенно, на уровне их же компилятора Си и Паскаля).
S>Да видел конечно. Толку-то? Ни на одном из этих бейсиков я не могу отправить на сервер код пользовательского предиката.
Это был наглядный пример того, что язык тот же, а реализация разная.
В офисе он же хранится в виде VBA, и документ можно отослать и исполнить код в нём.
V>>В Лисп точно так же может сосуществовать сколько угодно много независимых ООП-подсистем библиотечного уровня.
S>Я в курсе. Синтаксис Лиспа настолько ужасен, что его ничем испортить нельзя. Поэтому всякие надстройки над ним выглядят не хуже оригинального лиспа.
S>И можно делать любое ООП, которое нравится — с наследованием интерфейсов и наследованием реализации, со множественным наследованием и без, с любыми наборами модификаторов "видимости" мемберов. Можно придумывать свойства и события; можно делать наследование экземпляров как в JS; можно обрабатывать неизвестные сообщения, как в Smalltalk.
S>Правда, всё это будет всё в том же ужасном стиле скобок поверх скобок. Но на фоне остального лисп-кода выделяться не будет.
В любом случае, это лишь эмуляция.
А эмулировать что угодно можно на люом Тьюринг-полном языке.
Объекты в Лиспе не являются первоклассными сущностями языка, вот в чём косяк.
Первоклассной сущностью там являются числа/символы, функции и пара CONS(car, cdr), где каждый элемент пары может быть числом, функцией или опять парой (ссылочная семантика для всего перечисленного).
S>В общем, Лисп считать ОО-языком бессмысленно.
Именно.
Зато Форт (бгг, сорри... Но Чарльз Мур был, таки, умнейшим челом) позволяет сделать первоклассной сущностью любую хрень.
Форт рассматривается опытным фортером как язык для порождения языков (из-за особенностей макросистемы, которая нифига не как в Лиспе), и именно так пишутся на ём программы — исключительно через определение слоёв DSL от самых низких до целевых. Не зря конструкции Форта называются словами. Программа в форте — это всегда описание новых слов. А с помощью них — других, более ёмких.
ничего более элегантного я не видел до сих пор, т.к. виденные другие языки навязывают синтаксис и философию.
Форт навязывает лишь способ мышления, не навязывая остального.
И при этом чудовищно прост в реализации.
И при этом чудовищно эффективен, в сравнении с Лиспом.
Порой и в сравнении с нейтивом из-за особенностей манипулирования стеком — в Форте обычно меньше паразитных манипуляций данными в стеках/регистрах, меньше ненужных копирований/преобразований данных — состояние стека на выходе одного слова часто является готовым состоянием стека для вызова другого. Писать программы на Форте — это как играть в Тетрис, натурально, все фигуры должны стыковаться, и тогда прога просто летает. ))
V>>Ты не понимаешь мотива принятия некоторых важных решений в IT в ретроспективе.
S>
Более того, ты зачем-то отмахиваешься от такой инфрмации, оперируя вещами, скорее, эмоциональными, чем рациональными.
V>>Проводимый ликбез тебя коробит, но это особенности твоего чванства и ничего более.
S>Скорее, это особенности вашего чванства.
За новую инфу я всегда благодарен, в отличие от.
А тебя аналогичный сценарий всегда бесит, что ты аж перестаёшь быть корректным в логике спора. ))
V>>Такие монстры как Голдберг служили неплохим противовесом этому, в общем-то, нубу-самоучке.
S>А что, Голдберг где-то заявляла, что язык Smalltalk был вдохновлён Фортом?
А что, Голдберг где-то заявляла, что язык Smalltalk был вдохновлён Лиспом?
Это ж чушь.
По официальной версии Smalltalk был вдохновлён Симулой, это повторяют участники разработки.
Из Форта взяли уже опробованные решения:
— шитый код, стековую машинку;
— возможность сохранения текущего состояния системы и повторной загрузки.
Последнее принципиально на медленной технике, это почему Форт порой был крайне удобен — каждый текущий момент времени ты компиллируешь/отлаживаешь только минимальный кусок кода.
Да, это была всего вторая в истории такая система после Форта.
Только в 3-й версии в Smalltalk-80 добавили вменяемую интроспекцию (а это уже языку 8 лет).
Отдалённо это можно сравнить с Лиспом и его расширением CLOS, потому что на деле нифига не так — в Лиспе хранится непосредственно AST в виде кортежей { функция, аргументы }.
А в Smalltalk код не хранится в таком виде.
Он хранится примерно как в Форте.
AST можно построить только обратной декомпиляцией, собсно, как это делается в Форт словом "see", куда я тебя уже отсылал, просто ты не понял — зачем. ))
Это примерно как обратная декомпиляция байткода CLI обратно в C#, только намного проще из-за простоты организации шитого кода.
Тебе же говорилось — ты слышал звон.
V>>Какой там в опу Лисп? ))
S>Да почитайте же уже The Early History of Smalltalk и перестаньте позориться.
Ты отвечай по-существу, не юли.
То, что сам Алан ретроспективно сравнивает свои решения с Лиспом и останавливается на отличиях — оно не делает ни тепло, ни холодно.
К тому же, он не единственный автор языка и его реализатор.
V>>Похоже, ты не трогал толком ни Смолтолк, ни Лисп, ни Форт, не понимаешь внутренней механики этих языков, но пытаешься фантазировать.
S>Вы всё время путаете дизайн языков с внутренней механикой компилятора и рантайма.
Наоборот, я утверждаю, что в общем случае это независимые вещи, упирающиеся в конкретные реализации.
Смолтолк конкретно мне интересен лишь в плане итории развития подходов программирования в IT.
Я хорошо понимаю принятые в процессе разработки языка (и затем системы разработки на его основе) решения, а так же, откуда они взялись, где были уже обкатаны и доказали свою полезность/эффективность.
V>>Т.е. в изначальном Лиспе никаких метаклассов не было, как и не было в Лиспе ООП, ес-но, были только ф-ии как первоклассные объекты (сам код) и данные в виде однонаправленно связанных встроенных в систему списков.
S>Конечно не было. Именно это Кей и реализовал — ему хотелось сделать систему, которая была построена на минимуме примитивов, как Лисп, но с ООП. Если бы в Лиспе было ООП, то Smalltalk бы и не понадобился.
Понадобился бы.
Смолтолк намного эффективнее Лиспа, хотя и уступал нейтивно-компиллируемым языкам.
Смолтолк выразительнее Лиспа при описании ООП.
И вообще при описании банальных арифметических и логических выражений и просто императивного кода.
Уже этих двух аргументов достаточно, чтобы не воспринимать Лисп как удовлетворительную ООП-систему, хотя с ООП там более-менее в CLOS.
Просто надо понимать, как именно тогда использовался LISP.
Он был что-то вроде современного Питона, т.е. языком, на котором было легко обкатывать концепции, экспериментировать и т.д.
Я бы еще понял, если бы ты сформулировал "Смолтолк был вдохновлён недовольством Лиспом", бо это близко к истине.
И не только Лиспом, ес-но, просто Лисп — удобный мальчик для битья. ))
V>>Курить, что есть шитый код.
S>Я знаю, что такое шитый код. Какое отношение он имеет к дизайну языка Smalltalk?
Прямое.
Во главу угла изначально ставилась простота реализации.
Шитый код давал в разы лучшую эффективность, чем машинка Лиспа, всё еще позволяя удобно манипулировать бинарным кодом, порождать его "на лету" и т.д.
Дизайн языка не был сформирован чисто теоретически.
Это была рекурсивная разработка, где особенности реализации нижнего уровня влияли на верхние и обратно тоже.
Т.е. никто не пытался разработать совсем абстрактный язык, как в случае с тем же Хаскелем.
Смолтолк — это изначально "реальный" язык. ))
V>>Пример развития Форта до переносимости м/у устройствами.
S>По-прежнему не понимаю, какое отношение Постскрипт с его переносимостью имеет к ООП Алана Кея.
Это уже юление.
Ты говорил про переносимость кода тут.
Хотя на самом деле имел ввиду не это.
(или же намеренно оставил как "последний аргумент", хотя я несколько раз явно дал понять, как понял твою задачу).
V>>Таки, самообразованием принято заниматься самостоятельно, не испытывая терпение коллег.
S>Ну так займитесь. Почему вы вместо того, чтобы почитать первоисточники, занимаетесь гаданием на МК-51?
Алан Кей с его столь громкими и столь же некорректными высказываниями не заслуживает достаточного доверия в кач-ве надёжного источника.
Над языком работали еще люди.
Пробуй аргументировать другими авторами, если сможешь.
— Аллан не изобрел ООП (хотя позиционирует себя как автор ООП).
— В его формулировке ООП неполно: http://www.rsdn.org/forum/flame.comp/8471966.1
— Он не изобрел ни одного принципиального решения, легшего в основу Смолтолка.
"Посылка сообщений" — это лишь взгляд на проблему, а не техническая концепция или ее реализация.
Он, по-сути, "интегратор-компилятор" — увидел возможность реализации полудинамического ООП-языка с достаточной эффективностью на основе имеющихся уже в IT на тот момент наработок.
До Смолтолка ООП-языки были только статическими (библиотечная эмуляция ООП на Лиспе не в счёт, бо эмулировать можно что угодно на чём угодно).
Он предложил создать систему с такими св-вами, пообещав, что реализация должна получиться простой, всё.
Но работали они над языком аж 8 лет, прежде чем продукт стал коммерческим.
Т.е. не всё так просто, и тут очередная саечка Алану за шапкозакидательство.
(я вообще терпеть не могу поверхностных людей, особенно в инженерии)
Это что-то типа проекта Nemerle — ни одной новой концепции в языке не изобрели, просто попытка собрать удачные концепции на удачной платформе.
Но! Nemerle реализовали достаточно быстро в первой версии и достаточно полно, в отличие от.
И описание концепций Nemerle удивительно точное и полное.
Я не могу на полном серьёзе сравнивать болтовню Алана уровня болтовни бабушек у подъезда с подачей материала другими авторами.
Есть еще один такой же прихлебатель от IT — Мартин Фаулер, с Аланом два сапога пара.
Якающие нубы, за которых сплошной испанский стыд. ))
S>>>Попробуйте реализовать на Паскале, Си, и С++ функцию, которая бы передавала пользовательский предикат на сервер для исполнения.
V>>Не вижу технических проблем передать чистую ф-ию или чистое замыкание при наличии соотв. инфраструктуры.
S>Пример кода в студию. Хотя бы на одном из языков.
В предыдущем сообщении пример дан.
V>>Напомню, что MS компилятор С++ умеет компиллировать unamanaged C++ код (т.е. безо-всяких managed расширений) в чистый байт-код.
V>>(тип генерируемого образа для режима С++/CLI задаётся опциями компилятора)
S>Ну ок, если вам будет проще — попробуйте изобразить требуемую функциональность на unmanaged C++, скомпилированном в чистый байт-код.
Точную форулировку требуемой функциональности в студию.
V>>Ну вот попробуй на Лисп (или другом динамическом языке) без динамического исполнения текстовых исходников, а я поржу.
S>
Посмотрите на то, как устроены макросы Лиспа. Там нет ничего про динамическое исполнение текстовых исходников. S>Всё построено на манипуляциях кодом в виде AST. Можете начинать ржать.
Это залёт, курсант! ))
Код макросов лиспа не манипулирует AST явно.
Макросы Лиспа подстановочные (шаблонные), как макросы Си/С++ или макроассемблера.
Заметное отличие лишь в том, что макросы Лиспа МОГУТ быть гигиеническими (если программист не забудет экранировать область видимости символов, бгг).
А вот макросы Форта устроены иначе — они получают на входе поток лексем и манипулируют с ним именно явно, порождая то самое AST.
Смотри, сколько каши приходится разгребать. ))
V>>Такая возможность связана с представлением исполняемого кода, а это представление перпендикулярно языку.
V>>Похоже, у тебя каша в голове из св-в языков и конкретных их компиляторов/интерпретаторов.
S>Всё ровно наоборот — это у вас каша.
У меня понимание, как оно устроено и работает.
А у тебя бесконечные "слышал звон" и передёргивания из разряда сказала-мазала.
V>>Язык, по-сути, тот же.
V>>Отличается представлением скомпиллированного кода, а значит, особенностями модели вычисления.
S>И самое замечательное, что эти особенности модели вычисления никак не влияют на то, о чём я говорю.
Еще как влияют.
Макросы Схемы живут только в момент компиляции, в отличии от макросов Лиспа, которые становятся частью текущего состояния "системы".
Макросы Схемы имеют другое ключевое слово и пара особенностей.
Но это по-прежнему подстановочные/позиционные макросы, без явного манипулирования AST.
S>Макросы в Схеме всё ещё есть, и это означает, что я могу решить обозначенную задачу и на схеме тоже.
Увы, увы.
Причём, тут я противоречу самому себе, вроде бы, ведь можно представить себе такую реализацию Схемы, которая ведёт себя как Лисп?
Представить такую реализацию можно, да вот только Схема — это именно компиллируемая версия Лиспа. ))
А динамическая версия — это сам Лисп.
Для целей эффективного конечного кода пришлось внести в Лисп несколько ограничений, наверно поэтому назвали другим языком и стандарты Схемы с тех пор развиваются независимо от Лиспа.
Вернее, впервые стандарты на семейство Лисп появились в Схеме — именно из-за вносимых ограничений.
Заметно позже сообщество стало формировать стандарты и на Лисп — CL.
Ну и, стандарты на эмуляцию ООП в Лиспе поверх CL — CLOS.
Хотя именно с точки зрения языка (а не подробностей его реализации) Схему можно считать диалектом Лиспа, конечно!
S>А всё потому, что решают тут свойства языка. Что там под капотом — дело десятое.
Кошмар
У языка два свойства — синтаксис и семантика.
Если тебе надо получить AST — это всего лишь синтаксис.
Никакой язык не запрещает получать синтаксис своих выражений.
И отправить на сервер ты хотел не код на исполнение, как выяснилось, а AST выражений на трансформацию.
Для исполнения отправляют более эффективный в исполнении код, обычно, поэтому я и показывал, как это делают в других технологиях.
Не берём пример браузеров и JS, бо это совсем кошмар — тянуть кода на исполнение.
V>>Не осенило еще? ))
S>Вижу, что вас не осенило. Причина, я думаю, именно в том, что вы не пробуете сделать то, о чём я говорю.
Сделать что именно?
Учись спрашивать.
V>>Например, MS Visual Basic for DOS компиллировал в неплохо оптимизированный код (я курочил дизассемблером что он там порождает — да там офигенно, на уровне их же компилятора Си и Паскаля).
S>Да видел конечно. Толку-то? Ни на одном из этих бейсиков я не могу отправить на сервер код пользовательского предиката.
Это был наглядный пример того, что язык тот же, а реализация разная.
В офисе он же хранится в виде VBA, и документ можно отослать и исполнить код в нём.
V>>В Лисп точно так же может сосуществовать сколько угодно много независимых ООП-подсистем библиотечного уровня.
S>Я в курсе. Синтаксис Лиспа настолько ужасен, что его ничем испортить нельзя. Поэтому всякие надстройки над ним выглядят не хуже оригинального лиспа.
S>И можно делать любое ООП, которое нравится — с наследованием интерфейсов и наследованием реализации, со множественным наследованием и без, с любыми наборами модификаторов "видимости" мемберов. Можно придумывать свойства и события; можно делать наследование экземпляров как в JS; можно обрабатывать неизвестные сообщения, как в Smalltalk.
S>Правда, всё это будет всё в том же ужасном стиле скобок поверх скобок. Но на фоне остального лисп-кода выделяться не будет.
В любом случае, это лишь эмуляция.
А эмулировать что угодно можно на люом Тьюринг-полном языке.
Объекты в Лиспе не являются первоклассными сущностями языка, вот в чём косяк.
Первоклассной сущностью там являются числа/символы, функции и пара CONS(car, cdr), где каждый элемент пары может быть числом, функцией или опять парой (ссылочная семантика для всего перечисленного).
S>В общем, Лисп считать ОО-языком бессмысленно.
Именно.
Зато Форт (бгг, сорри... Но Чарльз Мур был, таки, умнейшим челом) позволяет сделать первоклассной сущностью любую хрень.
Форт рассматривается опытным фортером как язык для порождения языков (из-за особенностей макросистемы, которая нифига не как в Лиспе), и именно так пишутся на ём программы — исключительно через определение слоёв DSL от самых низких до целевых. Не зря конструкции Форта называются словами. Программа в форте — это всегда описание новых слов. А с помощью них — других, более ёмких.
ничего более элегантного я не видел до сих пор, т.к. виденные другие языки навязывают синтаксис и философию.
Форт навязывает лишь способ мышления, не навязывая остального.
И при этом чудовищно прост в реализации.
И при этом чудовищно эффективен, в сравнении с Лиспом.
Порой и в сравнении с нейтивом из-за особенностей манипулирования стеком — в Форте обычно меньше паразитных манипуляций данными в стеках/регистрах, меньше ненужных копирований/преобразований данных — состояние стека на выходе одного слова часто является готовым состоянием стека для вызова другого. Писать программы на Форте — это как играть в Тетрис, натурально, все фигуры должны стыковаться, и тогда прога просто летает. ))
V>>Ты не понимаешь мотива принятия некоторых важных решений в IT в ретроспективе.
S>
Более того, ты зачем-то отмахиваешься от такой инфрмации, оперируя вещами, скорее, эмоциональными, чем рациональными.
V>>Проводимый ликбез тебя коробит, но это особенности твоего чванства и ничего более.
S>Скорее, это особенности вашего чванства.
За новую инфу я всегда благодарен, в отличие от.
А тебя аналогичный сценарий всегда бесит, что ты аж перестаёшь быть корректным в логике спора. ))