Сообщение Re[7]: понимание ООП Алана Кея от 22.03.2023 12:36
Изменено 22.03.2023 12:37 Sinclair
Re[7]: понимание ООП Алана Кея
Здравствуйте, vdimas, Вы писали:
V>Такой Паскаль лично я в руках не держал, держал Турбо-Паскаль, потом объектный, потом Дельфи.
RTFM: https://ru.wikipedia.org/wiki/P-%D0%BA%D0%BE%D0%B4
V>В любом случае, если даже такой Паскаль существовал (с возможностью сохранять и оперировать этим P-представлением), тогда и возможность соответствующая была.
V>Аргумент из разряда "было или нет реализовано" опять немного перпендикулярный.
Простите, но это бред.
V>Аналогично в VB — компиляция происходит в нейтив, но для отладки используется P-код в памяти, без сброса образа на диск.
Ну, так как мне воспользоваться этим кодом изнутри VB?
V>Что не требуется уже на уровне переносимых объектных файлов.
При чём тут "не требуется"?
Речь о том, как что устроено, и с чем связаны какие возможности.
V>Я уже говорил — из Форта, скорее, который являлся чем-то вроде бинарной версии Лиспа.
Продолжаете безудержно вантазировать.
V>Натяжка Смолтолка на Лисп, таки, слишком смелая.
При чём тут натяжка? Это прямая речь Алана Кея.
V>Зато на Форт прямая — под капотом была стековая VM с двумя стеками из Форта и такой же шитый код по результату работы JIT.
Какой "такой же"?
V>Это почему к эффективности Смолтолка были вопросы, из-за недостаточно умного JIT.
Опять пошёл какой-то бред.
V>Зато PostScript, который является развитием Форта, вполне себе ездит с устройства на устройство и прекрасно исполняется.
А пост-скрипт то тут при чём?
V>Повторюсь, любой объектный файл (или архив их в объектной библиотеке) над переносимой платформой (например, llvm) представляет из себя то же самое.
V>Даже в Паскале, Си и С++.
V>К языку это перпендикулярно.
Сколько бы раз вы ни повторяли, это не перестанет быть заблуждением.
Попробуйте реализовать на Паскале, Си, и С++ функцию, которая бы передавала пользовательский предикат на сервер для исполнения.
А потом для сравнения попробуйте реализовать то же самое на Lisp или SmallTalk.
Может быть, тогда до вас дойдёт, как такая возможность связана с языком.
V>Сходство с Лиспом там в общей схеме работы интерпретатора, который двухфазный:
V>1. компиляция во внутренее представление;
V>2. исполнение этого внутреннего представления.
С этой точки зрения более-менее похожи все языки, включая basic.
V>Еще отличие Форта в том, что в коде хранится адрес исполняемой процедуры слова, в то время как в Лиспе хранился адрес метаинформации символа, т.е. Чарльз Мур убрал лишний уровень косвенности в процессе работы программы. Однако же, обратным поиском адреса в Форте запросто памятся на "слова". Т.е. Мур сделал размен эффективности оперирования метаинформацией на эффективность исполнения.
Короче, общего примерно столько же, сколько у вороны с роялем.
V>Да и, до первых виденных ЭВМ прилично упражнялся на программируемом калькуляторе MK-61, это тот же Форт, вид сборку.
V>Поэтому, программирование на Форте чуть позже зашло как к себе домой. ))
Простите, но рассуждения про Форт не очень интересны в контексте ООП. А ваше очередное самолюбование не интересно совсем.
V>Оперирование динамической памятью явное.
V>Это самые базовые слова:
V>- "," — выделить ячейку в динамической памяти и скопировать туда значение с вершины стека;
V>- "@" — читать из памяти число адресу на вершине стека;
V>- "!" — писать число из второй ячейки стека по адресу на вершине стека.
Это, мягко говоря, совсем не то, что применяется в Лиспе или Смоллтоке.
V>В Форте можно описать произвольные структуры данных в памяти.
В ассемблере тоже. Это не делает ассемблер лиспоподобным языком.
V>Сборка мусора в Лиспе, опять же, реализована по-разному.
Это подробности. Она является неотъемлемой частью языка.
V>В некоторых реализация сборка мусора вызывается каждый раз при исчерпании текущих свободных ячеек в предвыделенном пуле их, что может провоцировать (и провоцировала) сборку мусора даже когда потребности в этом не было, т.е. не было "забытых" объектов.
V>В других реализациях сборка мусора вызывается явно в рамках борьбы такими с холостыми срабатываниями.
Чегось?
V>В любом случае, с многопоточной сборкой мусора в современных VM этот подход имел мало общего.
Это вообще иррелевантно к данному обсуждению. Речь о языке, а не о реализации.
V>Да и сборщик мусора консервативный, а не точный, как в Java или .Net.
V>Т.е. не перемещает данные (не уплотняет память).
Чегось? Продолжается безудержный бред, да?
V>Т.е., не помогла особо метаинформация.
Прекрасно помогла.
V>Второй вариант без проблем может быть реализован в Форте на библиотечном уровне.
V>В Лиспе на библиотечном уровне никак, т.к. отсутствуют встроенные примитивы прямой работы с памятью и соотв. доступ ко внутренним кишкам интерпретатора.
V>(в кое-каких реализациях присутствуют, но это уже намного более поздние эксперименты в попытках привнести в Лисп свойства полее поздних ЯВУ общего назначения)
В лиспе сборка мусора является частью языка. Отсутствие примитивов прямой работы с памятью — это скорее плюс, чем минус.
V>С выходом объектного Паскаля и первых версий VB от MS, скорее.
Это в (бывшем) СССР. А в мире объектные версии Паскаля прошли практически незамеченными массовой публикой.
Попробуйте найти литературу по ООП с примерами на Паскале или VB.
V>Java изначально ограничила саму ООП-парадигму и .Net совершила ту же ошибку в первоначальном дизайне.
Мне даже интересно, какие именно аспекты ООП-парадигмы проигнорировала Java.
V>Помнишь обсуждение хотя бы новых управляемых указателей на методы в .Net?
V>А обсуждение типов-делегатов все нулевые года?
V>Надо ж было умудриться описать делегаты как объекты, что делегаты с одинаковой сигнатурой стали несовместимы. ))
Это, собственно, и есть попытки выйти за пределы ООП-парадигмы. В чистом ООП никаких делегатов нет. Есть интерфейсы с определёнными сигнатурами.
А несовместимость делегатов с одинаковой сигнатурой в рамках ООП не является самостоятельной особенностью. Она скорее связана с выбором между утиной типизацией и номинативной типизацией.
V>Это серьёзный косяк, как ни крути.
V>C++ эту ошибку не совершал.
Скажем, в С++ два одноимённых типа с "одинаковой сигнатурой" ничуть не более совместимы между собой, чем в дотнете.
Это в ФП подобные проблемы возникнуть не могут, т.к. там совместимость любых функций с одинаковой сигнатурой ставится во главу угла. А в лиспе так и вообще, одинаковость сигнатуры не является критерием.
V>Повторяю в сотый раз — "чисто ФП-шные" штуки были в ООП чуть не в первых ООП-языках.
V>Например, в том же Алголе-68.
V>Т.е. функциональный тип как первоклассный в языке, лямбды.
Мне кажется, вы слишком смело называете Алгол ООП-языком. Никакого ООП в нём не было.
V>Симула, кстате, была тоже лишь попыткой объектного расширения Алгола.
Как так — взяли ООП-шный алгол и попробовали привинтить к нему "объектное расширения"?
V>Да и Смолтолк приобрёл свои характерные черты не в первой версии 72, и даже не в 76, а только в 80.
:sigh:
http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
V>Для этого значение должно быть const в контексте внешнего кода.
Не-не-не, Дэвид Блейн. Вот я пишу свой код. И в нём мне бы хотелось полагаться на то, что его вызывают не с чем попало, а с неизменяемым объектом.
V>Т.е. значение может быть const по всей иерархии "внешности", вплоть до объявления.
Внешний код ещё не написан — каким образом я смогу потребовать от него const на этом значении "по всей иерархии внешности"?
V>Это на выбор программиста.
V>Что будет лишь малой частью всех возможных сценариев по слишком очевидной причине (тут уже сложно не материться) — ввиду наиболее сильного наложенного на сценарий ограничения.
Ок, как видим, вы так и не поняли, что такое иммутабельность, и почему она ортогональна const.
V>Странно, что мы вообще спорили тогда и сейчас вокруг подобной элементарщины...
Да ничего странного — у вас отсутствует обучаемость. Годы идут, а вы так и не вышли за пределы своих заблуждений.
В качестве упражнения можете попробовать спроектировать на С++ пару абстрактных классов — изменяемый вектор и immutable вектор. В терминах дотнета это были бы IImmutableList<T> и IList<T>. И посмотрите, можно ли их отнаследовать друг от друга; можно ли получить один из другого при помощи модификатора const; понадобится ли вообще модификатор const при проектировании этих классов или при их использовании.
V>Такой Паскаль лично я в руках не держал, держал Турбо-Паскаль, потом объектный, потом Дельфи.
RTFM: https://ru.wikipedia.org/wiki/P-%D0%BA%D0%BE%D0%B4
V>В любом случае, если даже такой Паскаль существовал (с возможностью сохранять и оперировать этим P-представлением), тогда и возможность соответствующая была.
V>Аргумент из разряда "было или нет реализовано" опять немного перпендикулярный.
Простите, но это бред.
V>Аналогично в VB — компиляция происходит в нейтив, но для отладки используется P-код в памяти, без сброса образа на диск.
Ну, так как мне воспользоваться этим кодом изнутри VB?
V>Что не требуется уже на уровне переносимых объектных файлов.
При чём тут "не требуется"?
Речь о том, как что устроено, и с чем связаны какие возможности.
V>Я уже говорил — из Форта, скорее, который являлся чем-то вроде бинарной версии Лиспа.
Продолжаете безудержно вантазировать.
V>Натяжка Смолтолка на Лисп, таки, слишком смелая.
При чём тут натяжка? Это прямая речь Алана Кея.
V>Зато на Форт прямая — под капотом была стековая VM с двумя стеками из Форта и такой же шитый код по результату работы JIT.
Какой "такой же"?
V>Это почему к эффективности Смолтолка были вопросы, из-за недостаточно умного JIT.
Опять пошёл какой-то бред.
V>Зато PostScript, который является развитием Форта, вполне себе ездит с устройства на устройство и прекрасно исполняется.
А пост-скрипт то тут при чём?
V>Повторюсь, любой объектный файл (или архив их в объектной библиотеке) над переносимой платформой (например, llvm) представляет из себя то же самое.
V>Даже в Паскале, Си и С++.
V>К языку это перпендикулярно.
Сколько бы раз вы ни повторяли, это не перестанет быть заблуждением.
Попробуйте реализовать на Паскале, Си, и С++ функцию, которая бы передавала пользовательский предикат на сервер для исполнения.
А потом для сравнения попробуйте реализовать то же самое на Lisp или SmallTalk.
Может быть, тогда до вас дойдёт, как такая возможность связана с языком.
V>Сходство с Лиспом там в общей схеме работы интерпретатора, который двухфазный:
V>1. компиляция во внутренее представление;
V>2. исполнение этого внутреннего представления.
С этой точки зрения более-менее похожи все языки, включая basic.
V>Еще отличие Форта в том, что в коде хранится адрес исполняемой процедуры слова, в то время как в Лиспе хранился адрес метаинформации символа, т.е. Чарльз Мур убрал лишний уровень косвенности в процессе работы программы. Однако же, обратным поиском адреса в Форте запросто памятся на "слова". Т.е. Мур сделал размен эффективности оперирования метаинформацией на эффективность исполнения.
Короче, общего примерно столько же, сколько у вороны с роялем.
V>Да и, до первых виденных ЭВМ прилично упражнялся на программируемом калькуляторе MK-61, это тот же Форт, вид сборку.
V>Поэтому, программирование на Форте чуть позже зашло как к себе домой. ))
Простите, но рассуждения про Форт не очень интересны в контексте ООП. А ваше очередное самолюбование не интересно совсем.
V>Оперирование динамической памятью явное.
V>Это самые базовые слова:
V>- "," — выделить ячейку в динамической памяти и скопировать туда значение с вершины стека;
V>- "@" — читать из памяти число адресу на вершине стека;
V>- "!" — писать число из второй ячейки стека по адресу на вершине стека.
Это, мягко говоря, совсем не то, что применяется в Лиспе или Смоллтоке.
V>В Форте можно описать произвольные структуры данных в памяти.
В ассемблере тоже. Это не делает ассемблер лиспоподобным языком.
V>Сборка мусора в Лиспе, опять же, реализована по-разному.
Это подробности. Она является неотъемлемой частью языка.
V>В некоторых реализация сборка мусора вызывается каждый раз при исчерпании текущих свободных ячеек в предвыделенном пуле их, что может провоцировать (и провоцировала) сборку мусора даже когда потребности в этом не было, т.е. не было "забытых" объектов.
V>В других реализациях сборка мусора вызывается явно в рамках борьбы такими с холостыми срабатываниями.
Чегось?
V>В любом случае, с многопоточной сборкой мусора в современных VM этот подход имел мало общего.
Это вообще иррелевантно к данному обсуждению. Речь о языке, а не о реализации.
V>Да и сборщик мусора консервативный, а не точный, как в Java или .Net.
V>Т.е. не перемещает данные (не уплотняет память).
Чегось? Продолжается безудержный бред, да?
V>Т.е., не помогла особо метаинформация.
Прекрасно помогла.
V>Второй вариант без проблем может быть реализован в Форте на библиотечном уровне.
V>В Лиспе на библиотечном уровне никак, т.к. отсутствуют встроенные примитивы прямой работы с памятью и соотв. доступ ко внутренним кишкам интерпретатора.
V>(в кое-каких реализациях присутствуют, но это уже намного более поздние эксперименты в попытках привнести в Лисп свойства полее поздних ЯВУ общего назначения)
В лиспе сборка мусора является частью языка. Отсутствие примитивов прямой работы с памятью — это скорее плюс, чем минус.
V>С выходом объектного Паскаля и первых версий VB от MS, скорее.
Это в (бывшем) СССР. А в мире объектные версии Паскаля прошли практически незамеченными массовой публикой.
Попробуйте найти литературу по ООП с примерами на Паскале или VB.
V>Java изначально ограничила саму ООП-парадигму и .Net совершила ту же ошибку в первоначальном дизайне.
Мне даже интересно, какие именно аспекты ООП-парадигмы проигнорировала Java.
V>Помнишь обсуждение хотя бы новых управляемых указателей на методы в .Net?
V>А обсуждение типов-делегатов все нулевые года?
V>Надо ж было умудриться описать делегаты как объекты, что делегаты с одинаковой сигнатурой стали несовместимы. ))
Это, собственно, и есть попытки выйти за пределы ООП-парадигмы. В чистом ООП никаких делегатов нет. Есть интерфейсы с определёнными сигнатурами.А несовместимость делегатов с одинаковой сигнатурой в рамках ООП не является самостоятельной особенностью. Она скорее связана с выбором между утиной типизацией и номинативной типизацией.
V>Это серьёзный косяк, как ни крути.
V>C++ эту ошибку не совершал.
Скажем, в С++ два одноимённых типа с "одинаковой сигнатурой" ничуть не более совместимы между собой, чем в дотнете.
Это в ФП подобные проблемы возникнуть не могут, т.к. там совместимость любых функций с одинаковой сигнатурой ставится во главу угла. А в лиспе так и вообще, одинаковость сигнатуры не является критерием.
V>Повторяю в сотый раз — "чисто ФП-шные" штуки были в ООП чуть не в первых ООП-языках.
V>Например, в том же Алголе-68.
V>Т.е. функциональный тип как первоклассный в языке, лямбды.
Мне кажется, вы слишком смело называете Алгол ООП-языком. Никакого ООП в нём не было.
V>Симула, кстате, была тоже лишь попыткой объектного расширения Алгола.
Как так — взяли ООП-шный алгол и попробовали привинтить к нему "объектное расширения"?
V>Да и Смолтолк приобрёл свои характерные черты не в первой версии 72, и даже не в 76, а только в 80.
:sigh:
http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
V>Для этого значение должно быть const в контексте внешнего кода.
Не-не-не, Дэвид Блейн. Вот я пишу свой код. И в нём мне бы хотелось полагаться на то, что его вызывают не с чем попало, а с неизменяемым объектом.
V>Т.е. значение может быть const по всей иерархии "внешности", вплоть до объявления.
Внешний код ещё не написан — каким образом я смогу потребовать от него const на этом значении "по всей иерархии внешности"?
V>Это на выбор программиста.
V>Что будет лишь малой частью всех возможных сценариев по слишком очевидной причине (тут уже сложно не материться) — ввиду наиболее сильного наложенного на сценарий ограничения.
Ок, как видим, вы так и не поняли, что такое иммутабельность, и почему она ортогональна const.
V>Странно, что мы вообще спорили тогда и сейчас вокруг подобной элементарщины...
Да ничего странного — у вас отсутствует обучаемость. Годы идут, а вы так и не вышли за пределы своих заблуждений.
В качестве упражнения можете попробовать спроектировать на С++ пару абстрактных классов — изменяемый вектор и immutable вектор. В терминах дотнета это были бы IImmutableList<T> и IList<T>. И посмотрите, можно ли их отнаследовать друг от друга; можно ли получить один из другого при помощи модификатора const; понадобится ли вообще модификатор const при проектировании этих классов или при их использовании.
Re[7]: понимание ООП Алана Кея
Здравствуйте, vdimas, Вы писали:
V>Такой Паскаль лично я в руках не держал, держал Турбо-Паскаль, потом объектный, потом Дельфи.
RTFM: https://ru.wikipedia.org/wiki/P-%D0%BA%D0%BE%D0%B4
V>В любом случае, если даже такой Паскаль существовал (с возможностью сохранять и оперировать этим P-представлением), тогда и возможность соответствующая была.
V>Аргумент из разряда "было или нет реализовано" опять немного перпендикулярный.
Простите, но это бред.
V>Аналогично в VB — компиляция происходит в нейтив, но для отладки используется P-код в памяти, без сброса образа на диск.
Ну, так как мне воспользоваться этим кодом изнутри VB?
V>Что не требуется уже на уровне переносимых объектных файлов.
При чём тут "не требуется"?
Речь о том, как что устроено, и с чем связаны какие возможности.
V>Я уже говорил — из Форта, скорее, который являлся чем-то вроде бинарной версии Лиспа.
Продолжаете безудержно фантазировать.
V>Натяжка Смолтолка на Лисп, таки, слишком смелая.
При чём тут натяжка? Это прямая речь Алана Кея.
V>Зато на Форт прямая — под капотом была стековая VM с двумя стеками из Форта и такой же шитый код по результату работы JIT.
Какой "такой же"?
V>Это почему к эффективности Смолтолка были вопросы, из-за недостаточно умного JIT.
Опять пошёл какой-то бред.
V>Зато PostScript, который является развитием Форта, вполне себе ездит с устройства на устройство и прекрасно исполняется.
А пост-скрипт то тут при чём?
V>Повторюсь, любой объектный файл (или архив их в объектной библиотеке) над переносимой платформой (например, llvm) представляет из себя то же самое.
V>Даже в Паскале, Си и С++.
V>К языку это перпендикулярно.
Сколько бы раз вы ни повторяли, это не перестанет быть заблуждением.
Попробуйте реализовать на Паскале, Си, и С++ функцию, которая бы передавала пользовательский предикат на сервер для исполнения.
А потом для сравнения попробуйте реализовать то же самое на Lisp или SmallTalk.
Может быть, тогда до вас дойдёт, как такая возможность связана с языком.
V>Сходство с Лиспом там в общей схеме работы интерпретатора, который двухфазный:
V>1. компиляция во внутренее представление;
V>2. исполнение этого внутреннего представления.
С этой точки зрения более-менее похожи все языки, включая basic.
V>Еще отличие Форта в том, что в коде хранится адрес исполняемой процедуры слова, в то время как в Лиспе хранился адрес метаинформации символа, т.е. Чарльз Мур убрал лишний уровень косвенности в процессе работы программы. Однако же, обратным поиском адреса в Форте запросто памятся на "слова". Т.е. Мур сделал размен эффективности оперирования метаинформацией на эффективность исполнения.
Короче, общего примерно столько же, сколько у вороны с роялем.
V>Да и, до первых виденных ЭВМ прилично упражнялся на программируемом калькуляторе MK-61, это тот же Форт, вид сборку.
V>Поэтому, программирование на Форте чуть позже зашло как к себе домой. ))
Простите, но рассуждения про Форт не очень интересны в контексте ООП. А ваше очередное самолюбование не интересно совсем.
V>Оперирование динамической памятью явное.
V>Это самые базовые слова:
V>- "," — выделить ячейку в динамической памяти и скопировать туда значение с вершины стека;
V>- "@" — читать из памяти число адресу на вершине стека;
V>- "!" — писать число из второй ячейки стека по адресу на вершине стека.
Это, мягко говоря, совсем не то, что применяется в Лиспе или Смоллтоке.
V>В Форте можно описать произвольные структуры данных в памяти.
В ассемблере тоже. Это не делает ассемблер лиспоподобным языком.
V>Сборка мусора в Лиспе, опять же, реализована по-разному.
Это подробности. Она является неотъемлемой частью языка.
V>В некоторых реализация сборка мусора вызывается каждый раз при исчерпании текущих свободных ячеек в предвыделенном пуле их, что может провоцировать (и провоцировала) сборку мусора даже когда потребности в этом не было, т.е. не было "забытых" объектов.
V>В других реализациях сборка мусора вызывается явно в рамках борьбы такими с холостыми срабатываниями.
Чегось?
V>В любом случае, с многопоточной сборкой мусора в современных VM этот подход имел мало общего.
Это вообще иррелевантно к данному обсуждению. Речь о языке, а не о реализации.
V>Да и сборщик мусора консервативный, а не точный, как в Java или .Net.
V>Т.е. не перемещает данные (не уплотняет память).
Чегось? Продолжается безудержный бред, да?
V>Т.е., не помогла особо метаинформация.
Прекрасно помогла.
V>Второй вариант без проблем может быть реализован в Форте на библиотечном уровне.
V>В Лиспе на библиотечном уровне никак, т.к. отсутствуют встроенные примитивы прямой работы с памятью и соотв. доступ ко внутренним кишкам интерпретатора.
V>(в кое-каких реализациях присутствуют, но это уже намного более поздние эксперименты в попытках привнести в Лисп свойства полее поздних ЯВУ общего назначения)
В лиспе сборка мусора является частью языка. Отсутствие примитивов прямой работы с памятью — это скорее плюс, чем минус.
V>С выходом объектного Паскаля и первых версий VB от MS, скорее.
Это в (бывшем) СССР. А в мире объектные версии Паскаля прошли практически незамеченными массовой публикой.
Попробуйте найти литературу по ООП с примерами на Паскале или VB.
V>Java изначально ограничила саму ООП-парадигму и .Net совершила ту же ошибку в первоначальном дизайне.
Мне даже интересно, какие именно аспекты ООП-парадигмы проигнорировала Java.
V>Помнишь обсуждение хотя бы новых управляемых указателей на методы в .Net?
V>А обсуждение типов-делегатов все нулевые года?
V>Надо ж было умудриться описать делегаты как объекты, что делегаты с одинаковой сигнатурой стали несовместимы. ))
Это, собственно, и есть попытки выйти за пределы ООП-парадигмы. В чистом ООП никаких делегатов нет. Есть интерфейсы с определёнными сигнатурами.
А несовместимость делегатов с одинаковой сигнатурой в рамках ООП не является самостоятельной особенностью. Она скорее связана с выбором между утиной типизацией и номинативной типизацией.
V>Это серьёзный косяк, как ни крути.
V>C++ эту ошибку не совершал.
Скажем, в С++ два одноимённых типа с "одинаковой сигнатурой" ничуть не более совместимы между собой, чем в дотнете.
Это в ФП подобные проблемы возникнуть не могут, т.к. там совместимость любых функций с одинаковой сигнатурой ставится во главу угла. А в лиспе так и вообще, одинаковость сигнатуры не является критерием.
V>Повторяю в сотый раз — "чисто ФП-шные" штуки были в ООП чуть не в первых ООП-языках.
V>Например, в том же Алголе-68.
V>Т.е. функциональный тип как первоклассный в языке, лямбды.
Мне кажется, вы слишком смело называете Алгол ООП-языком. Никакого ООП в нём не было.
V>Симула, кстате, была тоже лишь попыткой объектного расширения Алгола.
Как так — взяли ООП-шный алгол и попробовали привинтить к нему "объектное расширения"?
V>Да и Смолтолк приобрёл свои характерные черты не в первой версии 72, и даже не в 76, а только в 80.
:sigh:
http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
V>Для этого значение должно быть const в контексте внешнего кода.
Не-не-не, Дэвид Блейн. Вот я пишу свой код. И в нём мне бы хотелось полагаться на то, что его вызывают не с чем попало, а с неизменяемым объектом.
V>Т.е. значение может быть const по всей иерархии "внешности", вплоть до объявления.
Внешний код ещё не написан — каким образом я смогу потребовать от него const на этом значении "по всей иерархии внешности"?
V>Это на выбор программиста.
V>Что будет лишь малой частью всех возможных сценариев по слишком очевидной причине (тут уже сложно не материться) — ввиду наиболее сильного наложенного на сценарий ограничения.
Ок, как видим, вы так и не поняли, что такое иммутабельность, и почему она ортогональна const.
V>Странно, что мы вообще спорили тогда и сейчас вокруг подобной элементарщины...
Да ничего странного — у вас отсутствует обучаемость. Годы идут, а вы так и не вышли за пределы своих заблуждений.
В качестве упражнения можете попробовать спроектировать на С++ пару абстрактных классов — изменяемый вектор и immutable вектор. В терминах дотнета это были бы IImmutableList<T> и IList<T>. И посмотрите, можно ли их отнаследовать друг от друга; можно ли получить один из другого при помощи модификатора const; понадобится ли вообще модификатор const при проектировании этих классов или при их использовании.
V>Такой Паскаль лично я в руках не держал, держал Турбо-Паскаль, потом объектный, потом Дельфи.
RTFM: https://ru.wikipedia.org/wiki/P-%D0%BA%D0%BE%D0%B4
V>В любом случае, если даже такой Паскаль существовал (с возможностью сохранять и оперировать этим P-представлением), тогда и возможность соответствующая была.
V>Аргумент из разряда "было или нет реализовано" опять немного перпендикулярный.
Простите, но это бред.
V>Аналогично в VB — компиляция происходит в нейтив, но для отладки используется P-код в памяти, без сброса образа на диск.
Ну, так как мне воспользоваться этим кодом изнутри VB?
V>Что не требуется уже на уровне переносимых объектных файлов.
При чём тут "не требуется"?
Речь о том, как что устроено, и с чем связаны какие возможности.
V>Я уже говорил — из Форта, скорее, который являлся чем-то вроде бинарной версии Лиспа.
Продолжаете безудержно фантазировать.
V>Натяжка Смолтолка на Лисп, таки, слишком смелая.
При чём тут натяжка? Это прямая речь Алана Кея.
V>Зато на Форт прямая — под капотом была стековая VM с двумя стеками из Форта и такой же шитый код по результату работы JIT.
Какой "такой же"?
V>Это почему к эффективности Смолтолка были вопросы, из-за недостаточно умного JIT.
Опять пошёл какой-то бред.
V>Зато PostScript, который является развитием Форта, вполне себе ездит с устройства на устройство и прекрасно исполняется.
А пост-скрипт то тут при чём?
V>Повторюсь, любой объектный файл (или архив их в объектной библиотеке) над переносимой платформой (например, llvm) представляет из себя то же самое.
V>Даже в Паскале, Си и С++.
V>К языку это перпендикулярно.
Сколько бы раз вы ни повторяли, это не перестанет быть заблуждением.
Попробуйте реализовать на Паскале, Си, и С++ функцию, которая бы передавала пользовательский предикат на сервер для исполнения.
А потом для сравнения попробуйте реализовать то же самое на Lisp или SmallTalk.
Может быть, тогда до вас дойдёт, как такая возможность связана с языком.
V>Сходство с Лиспом там в общей схеме работы интерпретатора, который двухфазный:
V>1. компиляция во внутренее представление;
V>2. исполнение этого внутреннего представления.
С этой точки зрения более-менее похожи все языки, включая basic.
V>Еще отличие Форта в том, что в коде хранится адрес исполняемой процедуры слова, в то время как в Лиспе хранился адрес метаинформации символа, т.е. Чарльз Мур убрал лишний уровень косвенности в процессе работы программы. Однако же, обратным поиском адреса в Форте запросто памятся на "слова". Т.е. Мур сделал размен эффективности оперирования метаинформацией на эффективность исполнения.
Короче, общего примерно столько же, сколько у вороны с роялем.
V>Да и, до первых виденных ЭВМ прилично упражнялся на программируемом калькуляторе MK-61, это тот же Форт, вид сборку.
V>Поэтому, программирование на Форте чуть позже зашло как к себе домой. ))
Простите, но рассуждения про Форт не очень интересны в контексте ООП. А ваше очередное самолюбование не интересно совсем.
V>Оперирование динамической памятью явное.
V>Это самые базовые слова:
V>- "," — выделить ячейку в динамической памяти и скопировать туда значение с вершины стека;
V>- "@" — читать из памяти число адресу на вершине стека;
V>- "!" — писать число из второй ячейки стека по адресу на вершине стека.
Это, мягко говоря, совсем не то, что применяется в Лиспе или Смоллтоке.
V>В Форте можно описать произвольные структуры данных в памяти.
В ассемблере тоже. Это не делает ассемблер лиспоподобным языком.
V>Сборка мусора в Лиспе, опять же, реализована по-разному.
Это подробности. Она является неотъемлемой частью языка.
V>В некоторых реализация сборка мусора вызывается каждый раз при исчерпании текущих свободных ячеек в предвыделенном пуле их, что может провоцировать (и провоцировала) сборку мусора даже когда потребности в этом не было, т.е. не было "забытых" объектов.
V>В других реализациях сборка мусора вызывается явно в рамках борьбы такими с холостыми срабатываниями.
Чегось?
V>В любом случае, с многопоточной сборкой мусора в современных VM этот подход имел мало общего.
Это вообще иррелевантно к данному обсуждению. Речь о языке, а не о реализации.
V>Да и сборщик мусора консервативный, а не точный, как в Java или .Net.
V>Т.е. не перемещает данные (не уплотняет память).
Чегось? Продолжается безудержный бред, да?
V>Т.е., не помогла особо метаинформация.
Прекрасно помогла.
V>Второй вариант без проблем может быть реализован в Форте на библиотечном уровне.
V>В Лиспе на библиотечном уровне никак, т.к. отсутствуют встроенные примитивы прямой работы с памятью и соотв. доступ ко внутренним кишкам интерпретатора.
V>(в кое-каких реализациях присутствуют, но это уже намного более поздние эксперименты в попытках привнести в Лисп свойства полее поздних ЯВУ общего назначения)
В лиспе сборка мусора является частью языка. Отсутствие примитивов прямой работы с памятью — это скорее плюс, чем минус.
V>С выходом объектного Паскаля и первых версий VB от MS, скорее.
Это в (бывшем) СССР. А в мире объектные версии Паскаля прошли практически незамеченными массовой публикой.
Попробуйте найти литературу по ООП с примерами на Паскале или VB.
V>Java изначально ограничила саму ООП-парадигму и .Net совершила ту же ошибку в первоначальном дизайне.
Мне даже интересно, какие именно аспекты ООП-парадигмы проигнорировала Java.
V>Помнишь обсуждение хотя бы новых управляемых указателей на методы в .Net?
V>А обсуждение типов-делегатов все нулевые года?
V>Надо ж было умудриться описать делегаты как объекты, что делегаты с одинаковой сигнатурой стали несовместимы. ))
Это, собственно, и есть попытки выйти за пределы ООП-парадигмы. В чистом ООП никаких делегатов нет. Есть интерфейсы с определёнными сигнатурами.А несовместимость делегатов с одинаковой сигнатурой в рамках ООП не является самостоятельной особенностью. Она скорее связана с выбором между утиной типизацией и номинативной типизацией.
V>Это серьёзный косяк, как ни крути.
V>C++ эту ошибку не совершал.
Скажем, в С++ два одноимённых типа с "одинаковой сигнатурой" ничуть не более совместимы между собой, чем в дотнете.
Это в ФП подобные проблемы возникнуть не могут, т.к. там совместимость любых функций с одинаковой сигнатурой ставится во главу угла. А в лиспе так и вообще, одинаковость сигнатуры не является критерием.
V>Повторяю в сотый раз — "чисто ФП-шные" штуки были в ООП чуть не в первых ООП-языках.
V>Например, в том же Алголе-68.
V>Т.е. функциональный тип как первоклассный в языке, лямбды.
Мне кажется, вы слишком смело называете Алгол ООП-языком. Никакого ООП в нём не было.
V>Симула, кстате, была тоже лишь попыткой объектного расширения Алгола.
Как так — взяли ООП-шный алгол и попробовали привинтить к нему "объектное расширения"?
V>Да и Смолтолк приобрёл свои характерные черты не в первой версии 72, и даже не в 76, а только в 80.
:sigh:
http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
V>Для этого значение должно быть const в контексте внешнего кода.
Не-не-не, Дэвид Блейн. Вот я пишу свой код. И в нём мне бы хотелось полагаться на то, что его вызывают не с чем попало, а с неизменяемым объектом.
V>Т.е. значение может быть const по всей иерархии "внешности", вплоть до объявления.
Внешний код ещё не написан — каким образом я смогу потребовать от него const на этом значении "по всей иерархии внешности"?
V>Это на выбор программиста.
V>Что будет лишь малой частью всех возможных сценариев по слишком очевидной причине (тут уже сложно не материться) — ввиду наиболее сильного наложенного на сценарий ограничения.
Ок, как видим, вы так и не поняли, что такое иммутабельность, и почему она ортогональна const.
V>Странно, что мы вообще спорили тогда и сейчас вокруг подобной элементарщины...
Да ничего странного — у вас отсутствует обучаемость. Годы идут, а вы так и не вышли за пределы своих заблуждений.
В качестве упражнения можете попробовать спроектировать на С++ пару абстрактных классов — изменяемый вектор и immutable вектор. В терминах дотнета это были бы IImmutableList<T> и IList<T>. И посмотрите, можно ли их отнаследовать друг от друга; можно ли получить один из другого при помощи модификатора const; понадобится ли вообще модификатор const при проектировании этих классов или при их использовании.