Здравствуйте, Klapaucius, Вы писали:

K>Техника называется "static chain", изобрели ее около 1964-го года Рэндалл и Рассел, описана в Algol 60 Implementation — B.Randell & L.J.Russell, Academic Press, 1964.
K>А технику "замыкание" изобрел в том же году Ландин и реализовал впервые в SECD.

static chain всегда частный случай замыкания. То есть вложеные процедуры есть замыкания. Замыкания не обязательно вложеные процедуры. Можешь опровергнуть ?

Здравствуйте, Ikemefula, Вы писали:

I>Вот-вот. А отсутствие локальных функций означает количество кода примерно в 10 раз больше того, что ты показал.

Просто шедеврально!
Я ведь и написал пример в отсутствии локальных функций. Уууппссс??? ))


==============
Всё, закругляюсь. Ни ты, ни плюсующий тебе посетитель не в состоянии прочитать малюсенький отрывок кода из десятка строчек.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Ikemefula, Вы писали:

I>>Вот-вот. А отсутствие локальных функций означает количество кода примерно в 10 раз больше того, что ты показал.

V>Просто шедеврально!
V>Я ведь и написал пример в отсутствии локальных функций. Уууппссс??? ))

Написал, но твой код в принципе не компилируемый, похож больше на абстрактый псевдокод.

Здравствуйте, Ikemefula, Вы писали:

K>>Ну а причем тут смолток? Он более-менее оформился лет через 10 после "мейнстримной" разновидности ООП.
I>Это важно, потому что смолток более современный. По крайней мере это ООП четко указывает, где его можно применять, а где нет и в результате это ООП дало практически все известные ООП-артефакты. В симуловском лепи какие хочешь классы и все дела.

Как раз почти все известные ООП-артефакты произошли скорее от Симулы, зато вся ООП-идеология от Смолтока. Создатели Симулы никакого "ООП" не изобретали, они разработали необходимый им набор относительно низкоуровневых инструментов на основе которого они построили более высокоуровневые инструменты для дискретно-событийного моделирования. Никаких претензий на "парадигмы" и "философии" у них не было. Вот только современные мейнстримные ООЯ похожи на Симулу (типичный мейнстрим ООЯ отличается от симулы не больше, чем от другого типичного мейнстрим ООЯ), а не на Смолток.

Рассуждения о "естественности" ООП в свете этого достаточно забавны, ведь ООП — это философская база, подведенная постфактум под имеющийся инстумент, разрабатываемый без всякой философии.

K>>Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП,
I>То есть, старое неправильное это и есть симуловское ?

Да, симуловское, оно же и мейнстримное. Тут ирония, связанная с тем, что реформированное (мейнстрим-симулалайк ООП) пережило результат своей реформации (Смолток). Впрочем Кей вообще не считает ООП то, что в мейнстриме называется ООП-ом.

I>Если так, то все в порядке. В смолтоковском появились практически все что нужно — философич, методология, паттерны, юниттесты, это и есть true ООП. Вопрос кто древнее не стоит

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

Здравствуйте, Ikemefula, Вы писали:

I>static chain всегда частный случай замыкания.

Не частный случай. Static chain позволяет реализовывать функции со свободными переменными, используя стек, UFP не решает, функции первоклассными не делает. Замыкание — это техника реализации первоклассных функций, подразумевает размещение данных в куче и требует управления временем жизни этого блока в куче.

Техники разные, преимущества и недостатки — разные, результат использования — разный. Не вижу никаких бенефитов от проведения аналогий — наоборот, будут только путаница и пустопорожние флеймы. Аналогия очевидно вредна: использование вложенных функций как замыканий приводит к UB, а именование их замыканиями в разговоре с другим программистом приводит к недопониманию и проблемам с коммуникацией.

I>То есть вложеные процедуры есть замыкания.

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

I>Замыкания не обязательно вложеные процедуры.

И на что они "замыкаются", если никуда не вложены?

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Ikemefula, Вы писали:

K>>>Ну а причем тут смолток? Он более-менее оформился лет через 10 после "мейнстримной" разновидности ООП.
I>>Это важно, потому что смолток более современный. По крайней мере это ООП четко указывает, где его можно применять, а где нет и в результате это ООП дало практически все известные ООП-артефакты. В симуловском лепи какие хочешь классы и все дела.

K>Как раз почти все известные ООП-артефакты произошли скорее от Симулы, зато вся ООП-идеология от Смолтока. Создатели Симулы никакого "ООП" не изобретали, они разработали необходимый им набор относительно низкоуровневых инструментов на основе которого они построили более высокоуровневые инструменты для дискретно-событийного моделирования. Никаких претензий на "парадигмы" и "философии" у них не было. Вот только современные мейнстримные ООЯ похожи на Симулу (типичный мейнстрим ООЯ отличается от симулы не больше, чем от другого типичного мейнстрим ООЯ), а не на Смолток.

"вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали" Мне кажется тут надо определиться.

JS, питон и руби это хоришие примеры мейнстримных языков ?

K>Рассуждения о "естественности" ООП в свете этого достаточно забавны, ведь ООП — это философская база, подведенная постфактум под имеющийся инстумент, разрабатываемый без всякой философии.

Это неважно. Любая теория развивается до тех пор пока пригодня для решения насущных задач.

K>>>Смолток — это не "изначальное древнее ООП", а возрождение умирающего старого и реформация неправильного ООП,
I>>То есть, старое неправильное это и есть симуловское ?

K>Да, симуловское, оно же и мейнстримное. Тут ирония, связанная с тем, что реформированное (мейнстрим-симулалайк ООП) пережило результат своей реформации (Смолток). Впрочем Кей вообще не считает ООП то, что в мейнстриме называется ООП-ом.

I>>Если так, то все в порядке. В смолтоковском появились практически все что нужно — философич, методология, паттерны, юниттесты, это и есть true ООП. Вопрос кто древнее не стоит

K>Имеет место быть адаптация, когда ритуал требует пальмовые ветви, но за неимением пальм используются ветви вербы, а наряжают елки.

Здравствуйте, Klapaucius, Вы писали:

K>Да, симуловское, оно же и мейнстримное. Тут ирония, связанная с тем, что реформированное (мейнстрим-симулалайк ООП) пережило результат своей реформации (Смолток). Впрочем Кей вообще не считает ООП то, что в мейнстриме называется ООП-ом.

Правильно, потому что там симуловская модель которую ты сам назвал старым и неправильным Мне только непонятно, почему в одном случае ты за ООП считаешь язык, а в другом целую пачку языков Смалтолк сдох, зато есть JS, питон, руби, objective c и тд. Симула тоже сдохла, вместо неё С++, С#, Java и прочий мусор.

Здравствуйте, Klapaucius, Вы писали:

I>>static chain всегда частный случай замыкания.

K>Не частный случай. Static chain позволяет реализовывать функции со свободными переменными, используя стек, UFP не решает, функции первоклассными не делает. Замыкание — это техника реализации первоклассных функций, подразумевает размещение данных в куче и требует управления временем жизни этого блока в куче.

А если язык не умеет ПФ, то отличить замыкание от static chain как минимум невозможно.

K>Техники разные, преимущества и недостатки — разные, результат использования — разный. Не вижу никаких бенефитов от проведения аналогий — наоборот, будут только путаница и пустопорожние флеймы. Аналогия очевидно вредна: использование вложенных функций как замыканий приводит к UB, а именование их замыканиями в разговоре с другим программистом приводит к недопониманию и проблемам с коммуникацией.

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

I>>То есть вложеные процедуры есть замыкания.

K>Замыкания — это либо пара из блока данных в куче и кода функции (техника), либо лямбда со свободными переменными (в противоположность комбинатору, у которого все переменные связаны), паскалевско-алголовские вложенные функции ни тем ни другим не являются.

Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.

I>>Замыкания не обязательно вложеные процедуры.

K>И на что они "замыкаются", если никуда не вложены?

На пустой контекст.

Здравствуйте, Ikemefula, Вы писали:

I>А если язык не умеет ПФ, то отличить замыкание от static chain как минимум невозможно.

Не нужно ставить телегу впереди лошади — неумение ПФ — это и есть наблюдаемое отличие мужду техниками. Другое отличие — одна техника использует только стек, а второй нужна куча и автоматическое управление памятью: GC, счетчики ссылок, регионы и т.д.

I>UB это следствие хака, обход возможностей языка.

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

I>Проблемы с коммуникацией это сомнительный аргумент, как пример здесь три человека высказалось за тз отличную от твоей, а в поддержку высказалось тоже целых три человека

Это и есть проблема с коммуникацией. Если бы одного мнения придерживался один человек, а другого — 100, то у сообщества не было бы проблемы с коммуникацией. Проблемы были бы только у этого одного.

K>>Замыкания — это либо пара из блока данных в куче и кода функции (техника), либо лямбда со свободными переменными (в противоположность комбинатору, у которого все переменные связаны), паскалевско-алголовские вложенные функции ни тем ни другим не являются.
I>Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.

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

K>>И на что они "замыкаются", если никуда не вложены?
I>На пустой контекст.

Теперь еще и пустой контекст какой-то появился. Что такое "пустой контекст"?

Здравствуйте, Ikemefula, Вы писали:

I>"вся философия и методология ООП, паттерны и юнит-тесты и т.д., придуманные смолтокерами не пропали" Мне кажется тут надо определиться.

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

I>JS, питон и руби это хоришие примеры мейнстримных языков ?

JS — мейнстрим и в каком-то смысле испытал влиание self. Питон и Руби не мейнстрим. В случае Руби влияние smalltalk есть, в случае питона я его в упор не вижу.

K>>Рассуждения о "естественности" ООП в свете этого достаточно забавны, ведь ООП — это философская база, подведенная постфактум под имеющийся инстумент, разрабатываемый без всякой философии.
I>Это неважно. Любая теория развивается до тех пор пока пригодня для решения насущных задач.

Речь идет о направлении развития. Если бы философия и "естественность" было первичным — появилась бы сначала идея, а потом реализация. И были бы сложности с реализацией. Но первична была реализация — а идея подведена в качестве базы позднее. Мой пойнт в том, что нет вопроса об естественности, если по факту идея произошла из особенностей реализации фреймворка для дискретно-событийного моделирования. И именно это направление — причина успешного распространения симулалайк-ООП и главное его конкурентное преимущество.

I>Правильно, потому что там симуловская модель которую ты сам назвал старым и неправильным

Справедливости ради, неправильным его назвал Кей, а я не считаю, что одно из них правильнее другого.

I>Мне только непонятно, почему в одном случае ты за ООП считаешь язык, а в другом целую пачку языков Смалтолк сдох, зато есть JS, питон, руби, objective c и тд. Симула тоже сдохла, вместо неё С++, С#, Java и прочий мусор.

Смолток — тоже целая куча языков с кучей последователей. И objective c еще один язык действительно испытавший влияние смолтока. Только в случае "кучи смолтоков" мы не имеем "плотного кластера" — это языки, мягко говоря, друг на друга не похожие, варьирующиеся от обджектив-си, до эрланга. И в мейнстриме из них один два и все. В случае мейнстрим-ООП языки похожи, они практически "клоны" симулы, особенно по состоянию на конец 90-х и начала 2000-х, когда всякие ФП-фичи типа лямбд, параметрического полиморфизма и иммутабельных "объектов" не стало модно в такие языки добавлять.

Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Ikemefula, Вы писали:

I>>А если язык не умеет ПФ, то отличить замыкание от static chain как минимум невозможно.

K>Не нужно ставить телегу впереди лошади — неумение ПФ — это и есть наблюдаемое отличие мужду техниками.

И давно замыкания определяются через ПФ ? Если понимать замыкания как способ реализации языковых фич, то все понятно — есть ПФ, значит должен быть реализован общий случай. Нет ПФ — достаточно и частного, т.е. оптимизируем как угодно.

>Другое отличие — одна техника использует только стек, а второй нужна куча и автоматическое управление памятью: GC, счетчики ссылок, регионы и т.д.

не важно, это особенности реализации и оптимизации.

I>>UB это следствие хака, обход возможностей языка.

K>Ошибочная аналогия с замыканием — это и есть мотивация для хака. Из аналогии следует некоторая возможность, которую "хакер" и пытается реализовать.

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

I>>Проблемы с коммуникацией это сомнительный аргумент, как пример здесь три человека высказалось за тз отличную от твоей, а в поддержку высказалось тоже целых три человека

K>Это и есть проблема с коммуникацией. Если бы одного мнения придерживался один человек, а другого — 100, то у сообщества не было бы проблемы с коммуникацией. Проблемы были бы только у этого одного.

То есть, если моего мнения будут придерживаться все, то проблемы в коммуникации будут. А если твоего — то нет. Так что ли ?

I>>Можно рассматривать просто как оптимизацию, поскольку язык запрещает передавать функции наверх.

K>Еще раз. Либо это конкретная техника — тогда проверяем наличие блоков данных в куче. Их нет — след. не замыкание.

Это детали реализации. Есть какая жОсткая спецификация, как должны реализовываться замыкания ?

K>Если имеется в виду лямбда со свободными переменными — проверяем, является ли вложенная функция "засахаренной" лямбдой. Передавать "наверх" нельзя — значит не является. Итого не является замыканием в обоих смыслах.

Передавать вверх == фича языка. У нас любой язык это минимальный набор фич (эффектов) которые нас интересуют. Нет фичи — нет и её поддержки. Это нормально.

K>>>И на что они "замыкаются", если никуда не вложены?
I>>На пустой контекст.

K>Теперь еще и пустой контекст какой-то появился. Что такое "пустой контекст"?

"environment for the non-local variables" — т.е. количество variables == 0

Здравствуйте, Klapaucius, Вы писали:

I>>JS, питон и руби это хоришие примеры мейнстримных языков ?

K>JS — мейнстрим и в каком-то смысле испытал влиание self. Питон и Руби не мейнстрим. В случае Руби влияние smalltalk есть, в случае питона я его в упор не вижу.

Это почему питон и руби не мейнстрим ? В питоне ровно то же ООП что и в смалтоке, разная только реализация

K>>>Рассуждения о "естественности" ООП в свете этого достаточно забавны, ведь ООП — это философская база, подведенная постфактум под имеющийся инстумент, разрабатываемый без всякой философии.
I>>Это неважно. Любая теория развивается до тех пор пока пригодня для решения насущных задач.

K>Речь идет о направлении развития. Если бы философия и "естественность" было первичным — появилась бы сначала идея, а потом реализация. И были бы сложности с реализацией. Но первична была реализация — а идея подведена в качестве базы позднее.

Так вообще везде, в физике например и вобще где угодно. Заметили эффект, изучили свойства, подобрали модель, нашли применение.

>Мой пойнт в том, что нет вопроса об естественности, если по факту идея произошла из особенностей реализации фреймворка для дискретно-событийного моделирования. И именно это направление — причина успешного распространения симулалайк-ООП и главное его конкурентное преимущество.

Распрострение языков что я перечислил вообще говоря показывает сильную ограниченность этого ООП. А проблемы с дизайном у людей которые исповедуют это ООП как общий тренд показывает что преимущество когда то бло, но пропало

I>>Правильно, потому что там симуловская модель которую ты сам назвал старым и неправильным

K>Справедливости ради, неправильным его назвал Кей, а я не считаю, что одно из них правильнее другого.

Одно ты назвал старым и неправильным, другое — его реформацией То есть, все что ты хочешь сказать, что неправильное, и реформация неправильного суть одинаково неправильны ? Тогда выходит тебе не нравится ООП вообще, какое они ни было

I>>Мне только непонятно, почему в одном случае ты за ООП считаешь язык, а в другом целую пачку языков Смалтолк сдох, зато есть JS, питон, руби, objective c и тд. Симула тоже сдохла, вместо неё С++, С#, Java и прочий мусор.

K>Смолток — тоже целая куча языков с кучей последователей. И objective c еще один язык действительно испытавший влияние смолтока. Только в случае "кучи смолтоков" мы не имеем "плотного кластера" — это языки, мягко говоря, друг на друга не похожие, варьирующиеся от обджектив-си, до эрланга. И в мейнстриме из них один два и все.

А для чего тебе "плотный кластер", на что это влияет ?

>В случае мейнстрим-ООП языки похожи, они практически "клоны" симулы, особенно по состоянию на конец 90-х и начала 2000-х, когда всякие ФП-фичи типа лямбд, параметрического полиморфизма и иммутабельных "объектов" не стало модно в такие языки добавлять.

Меня интересует как сейчас, а не как было. С динамиками в C# вообще все шоколадно — чисто по смалтоковски можно высекать.

Здравствуйте, Ikemefula, Вы писали:

I>Если понимать замыкания как способ реализации языковых фич, то все понятно — есть ПФ, значит должен быть реализован общий случай. Нет ПФ — достаточно и частного, т.е. оптимизируем как угодно.

На колу мочало — начинай сказку сначала:

Не нужно ставить телегу впереди лошади — неумение ПФ — это и есть наблюдаемое отличие мужду техниками.

>>Другое отличие — одна техника использует только стек, а второй нужна куча и автоматическое управление памятью: GC, счетчики ссылок, регионы и т.д.
I>не важно, это особенности реализации и оптимизации.

Оптимизация тут не при чем, а реализация важна, потому что она и обсуждается.

I>То есть, если моего мнения будут придерживаться все, то проблемы в коммуникации будут. А если твоего — то нет. Так что ли ?

Если определение общепринято — проблем с коммуникацией нет, в противном случае проблемы есть. От того какое именно определение общепринято это никак не зависит.

I>Это детали реализации.

Обсуждаемое значение слова "замыкание" — это название детали реализации.

I>Передавать вверх == фича языка. У нас любой язык это минимальный набор фич (эффектов) которые нас интересуют. Нет фичи — нет и её поддержки. Это нормально.

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

K>>>>И на что они "замыкаются", если никуда не вложены?
I>>>На пустой контекст.
K>>Теперь еще и пустой контекст какой-то появился. Что такое "пустой контекст"?
I>"environment for the non-local variables" — т.е. количество variables == 0

Да, а каждый лысый — волосатый, просто с "пустой прической".

Здравствуйте, Ikemefula, Вы писали:

I>Это почему питон и руби не мейнстрим ?

По факту.

I>В питоне ровно то же ООП что и в смалтоке, разная только реализация

В смолтоке объекты — основной строительный блок языка. В питоне — они просто "припарка" к структурному языку — ядру. Как в симуле и в яве.

I>Так вообще везде, в физике например и вобще где угодно. Заметили эффект, изучили свойства, подобрали модель, нашли применение.

В физике "и везде" бывает и наоборот — по подобранной модели предсказали эффект — обнаружили его, сопоставили свойства с предсказанными, не опровергли модель. Но аналогия с физикой ложная. Физика изучает реальный мир, а ООП — инженерная методика (это в лучшем случае), она ничего кроме себя самой не изучает.

I>Распрострение языков что я перечислил вообще говоря показывает сильную ограниченность этого ООП.

Эта "сильная ограниченность" и является конкурентным преимуществом.

I>А проблемы с дизайном у людей которые исповедуют это ООП как общий тренд показывает что преимущество когда то бло, но пропало

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

I>Одно ты назвал старым и неправильным, другое — его реформацией То есть, все что ты хочешь сказать, что неправильное, и реформация неправильного суть одинаково неправильны ?

Да. И я иронизирую над "правильным реформированным ООП" смолтокеров потому, что оно не решило проблем ООП, но создало новые проблемы как раз с тем, с чем у ООП первоначально было все хорошо — простотой реализации. Формально, конечно, реализовать смолток проще — наивная реализация чуть ли не на один экран поместится. Вот только практически полезная реализация — это настоящий рокет сайенс.

I>Тогда выходит тебе не нравится ООП вообще, какое они ни было

Мне вообще все не нравится, а ООП — побольше среднего прочего.

I>А для чего тебе "плотный кластер", на что это влияет ?

Это показатель жизнеспособности идеи, если можно и через 50 лет "продавать" то же самое, но с перламутровыми пуговицами.

I>Меня интересует как сейчас, а не как было. С динамиками в C# вообще все шоколадно — чисто по смалтоковски можно высекать.

До смолтока C#-у как до Луны. И это, кстати, не недостаток.

Здравствуйте, Klapaucius, Вы писали:

K>На колу мочало — начинай сказку сначала:
K>

K>Не нужно ставить телегу впереди лошади — неумение ПФ — это и есть наблюдаемое отличие мужду техниками.

Замыкания есть реализация ПФ, а неумение ПФ есть наблюдаемый эффект без замыканий. Очень познавательно, спасибо, это называется порочный круг и смысла не имеет, повторяй ты эхто сколько хочешь раз.

K>В реальном мире языки имеют не "набор фич (эффектов) которые нас интересуют", а некоторое его подмножество, из-за ограничений, накладываемых проблемами реализации. Другими словами, мы имеем не те фичи, которые нам нужны, а те из них, что можем себе позволить. Поэтому все наоборот: нет поддержки — нет и фичи. Вот это — нормально. А то что вы описали — это какой-то платоновский идеализм, в котором реализация — это тень фичи.

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

I>>>>На пустой контекст.
K>>>Теперь еще и пустой контекст какой-то появился. Что такое "пустой контекст"?
I>>"environment for the non-local variables" — т.е. количество variables == 0

K>Да, а каждый лысый — волосатый, просто с "пустой прической".

лысый это человек у котрого растительность на голове удовлетворяет определенному критерию. Ничего смешного, это математика.

Здравствуйте, Klapaucius, Вы писали:

I>>Это почему питон и руби не мейнстрим ?

K>По факту.

Так и запишем, что у тебя нет даже минимального объяснения а только "по факту" и твои рассуждения на счет мейнтсримности и популярности можно игнорировать.

I>>В питоне ровно то же ООП что и в смалтоке, разная только реализация

K>В смолтоке объекты — основной строительный блок языка. В питоне — они просто "припарка" к структурному языку — ядру. Как в симуле и в яве.

Если смотреть внутрь реализации, то окажется что все мы пишем на ассемблере.

I>>Так вообще везде, в физике например и вобще где угодно. Заметили эффект, изучили свойства, подобрали модель, нашли применение.

K>В физике "и везде" бывает и наоборот — по подобранной модели предсказали эффект — обнаружили его, сопоставили свойства с предсказанными, не опровергли модель. Но аналогия с физикой ложная. Физика изучает реальный мир, а ООП — инженерная методика (это в лучшем случае), она ничего кроме себя самой не изучает.

Здесь тож самое — изучение модели позволяет предсказывать эффекты. Есть модель — можно и эффекты предсказывать.

I>>Распрострение языков что я перечислил вообще говоря показывает сильную ограниченность этого ООП.

K>Эта "сильная ограниченность" и является конкурентным преимуществом.

Ты почему то ничего не говоришь про задачи у тебя популярность растет сама по себе, как будто является свойством семейства языков.
ЯП появились как инструмент решения задач. раньше это в основном обработка данных, отсюда неудивительно что популярная парадигма будет data-centric, что вобщем то и есть симуловское ООП.
С ростом сложности софта, которая ка известно растет нелинейно, data-centric себя исчерпал. Появились сложные задачи не ориентированые на обработку данных. Отсюда понятно, что популярными будут языки ориентированые на новые задачи, например — взаимодействие, вычисления самой разной природы и тд и тд.

Смалтоковское ООП оно полностью завязано на поведение и взаимодействие. В data-centriс это тоже можно, но в смалтоковской парадигме это намного проще. При чем весь data-centric полностью укладывается в смалтоковскую парадигму.

I>>А проблемы с дизайном у людей которые исповедуют это ООП как общий тренд показывает что преимущество когда то бло, но пропало
K>А проблемы с дизайном прямое следствие идеологии, которая от смолтока идет.

Это разница между парадигмами. Симуловское ООП ориентировано на обработку данных. Смалтоковское — на поведение и взаимодействие. Отсюда понятны причины косяков в дизайне — описывая взаимодействие в духе симуловского ООП неизбежно будут рождаться монстры.
В то время как смалтоковское позволяет вполне сносно обрабатывать данные, максимум — незначительно в ущерб перформансу.

I>>Одно ты назвал старым и неправильным, другое — его реформацией То есть, все что ты хочешь сказать, что неправильное, и реформация неправильного суть одинаково неправильны ?

K>Да. И я иронизирую над "правильным реформированным ООП" смолтокеров потому, что оно не решило проблем ООП, но создало новые проблемы как раз с тем, с чем у ООП первоначально было все хорошо — простотой реализации.

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

>Формально, конечно, реализовать смолток проще — наивная реализация чуть ли не на один экран поместится. Вот только практически полезная реализация — это настоящий рокет сайенс.

Формально языки были направлены на самые разные задачи. Обработка данных со сцены не девается, это объясняет популярность С++, более того, никуда и не денется, отсюда ясно, что С++ потеснит только более производительный аналог в симуловской концепции.

Сложность поведения и взаимодействия компонентов только растет, а это значт что смалтоковская концепция популярности тоже не теряет, что видно на примере JS, питона, руби.

Вычислительные задачи самой разной природы дают результат в виде популярности функциональных языков.

I>>Тогда выходит тебе не нравится ООП вообще, какое они ни было
K>Мне вообще все не нравится, а ООП — побольше среднего прочего.

Вероятно ты просто решаешь другие задачи, в которых ООП непригодно. Скажем начни ты в хаскеле поднимать xml, скорее всего умрёшь от натуги. А старый гнусный С++ рвёт здесь всех конкурентов, кроме специализированых под xml реализаций.

I>>А для чего тебе "плотный кластер", на что это влияет ?
K>Это показатель жизнеспособности идеи, если можно и через 50 лет "продавать" то же самое, но с перламутровыми пуговицами.

Чушь. Популярность не является свойством семейства, эта популярность зависит от актуальных задач а ты почему то нигде про это ни разу не сказал

I>>Меня интересует как сейчас, а не как было. С динамиками в C# вообще все шоколадно — чисто по смалтоковски можно высекать.
K>До смолтока C#-у как до Луны. И это, кстати, не недостаток.

Я и не говорил, что C# это смалток. Я говорю что в ём можно отлично реализовать концепцию смалтоковского ООП, естественно ,будет чуток многословно, побольше чем на питоне, но терпимо.

Здравствуйте, SV., Вы писали:

SV.>...и это невероятно печально.

SV.>Примеры. Допустим, некто спрашивает, зачем нужно наследование интерфейсов. Я привожу пример, когда оно нужно.

Думаю, что истинное понимание ООП приходит уже будучи ОО-проектировщиком. Хоть чисто в домашних условиях, например книга "Применение UML"-Лармана,
перевернуло мое представление о создании программ. У него описано, что истоки нужно искать в реальном мире, составляя так называемые use-case'ы. Реальные случаи использования системы.
А из них выделять существительные (классы) и глаголы (методы). Это само собой не все ООП, но суть такова.

Здравствуйте, Ikemefula, Вы писали:

I>>>Это почему питон и руби не мейнстрим ?
K>>По факту.
I>Так и запишем, что у тебя нет даже минимального объяснения а только "по факту" и твои рассуждения на счет мейнтсримности и популярности можно игнорировать.

А по-моему, можно игнорировать рассуждения о мейнстриме человека, который считает, что руби — это мейнстрим.

K>>В смолтоке объекты — основной строительный блок языка. В питоне — они просто "припарка" к структурному языку — ядру. Как в симуле и в яве.
I>Если смотреть внутрь реализации, то окажется что все мы пишем на ассемблере.

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

I>Здесь тож самое — изучение модели позволяет предсказывать эффекты. Есть модель — можно и эффекты предсказывать.

Это, скорее, в тему соседней ветки, где предсказывающий эффект по модели "замыкание" получает UB.

I>популярность зависит от актуальных задач а ты почему то нигде про это ни разу не сказал

Я об этом ниразу не сказал, потому что считаю это неправильным.
1) Не наблюдается никакой связи между тем, для чего язык разрабатывался и тем, для чего он применяется.
Мы живем в мире, в котором серверные приложения пишут на языках, которые разрабатывали например для программирования интерактивных телевизоров, "программирования" мигания текста на веб-страничке, скриптования обработки текстов.
Это объяснимо, конечно, потому что большинство языков, не смотря на заявляемую когда-то авторами "принадлежность", не имеют никакой специализации и являются языками общего назначения. Даже когда язык действительно специализирован — эта спецуиализация по мере развития разбавляется совершенно посторонними фичами. В SQL добавляют императивные конструкции, регулярные выражения перестают быть регулярными и т.д.
Подавляющее большинство языков не заточены под какую-то нишу.
2) Выбор языка определяется, в основном, возможностью нанять программиста на этом языке. Разумеется, имеющаяся в таком подходе положительная обратная связь раздувает любую флуктуацию до космических масштабов и делает популярность языка случайной. Невозможно предсказать какой из языков станет популярным, а какой канет в забвение: A или A', который от A отличается оттенком перламутровых пуговиц.
3) Если же язык выбирают по техническим причинам, то выбирают не языки, а реализации и инфраструктуру, причем набор неигрушечных реализаций для нужных платформ часто вообще отсутствует. Понятно, что и тут положительная обратная связь, выхватывающая из шума случайный кактус и заставляющая его есть десятилетиями.
4) Не смотря на все это, иногда таки можно выбрать кактус, который колется поменьше — это инициирует лавинообразный переход на новое семейство языков, как только мы можем себе это позволить, но не раньше.
Сдвиг парадигмы не происходит от изменения задач, а ппоисходит от развития техники, которая начиная с какого-то момента позволяет иметь новый уровень удобств. ООП стал популярен, когда его стало можно себе позволить. И ФП становится популярным в последнее время по этим же причинам. Смолток просто морально устарел раньше, чем его смогли себе позволить использовать значительное количество программистов — вот и все.

Здравствуйте, Ikemefula, Вы писали:

I>Ну вообще говоря язык проектируется под определенный набор фич, а точнее под определенные задачи

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

Про проектирование языков под определенные задачи, которого в реальности не существует ответил развернуто здесь

Автор: Klapaucius
Дата: 23.08.12

K>>Да, а каждый лысый — волосатый, просто с "пустой прической".
I>лысый это человек у котрого растительность на голове удовлетворяет определенному критерию. Ничего смешного, это математика.

Это смешно, потому, что критерий смешной и обобщение бесполезно. Нет никакого применения для обобщения замыканий и не замыканий введением "пустого контекста". Ну, кроме как насмешить собеседника в форумном диспуте.

Здравствуйте, Klapaucius, Вы писали:

I>>Так и запишем, что у тебя нет даже минимального объяснения а только "по факту" и твои рассуждения на счет мейнтсримности и популярности можно игнорировать.

K>А по-моему, можно игнорировать рассуждения о мейнстриме человека, который считает, что руби — это мейнстрим.

Мейнстрим это задачи, а не ЯП. ЯП это уже следствие.

I>>Здесь тож самое — изучение модели позволяет предсказывать эффекты. Есть модель — можно и эффекты предсказывать.
K>Это, скорее, в тему соседней ветки, где предсказывающий эффект по модели "замыкание" получает UB.

Так ты определись, можно ли модели предсказывать или нет

I>>популярность зависит от актуальных задач а ты почему то нигде про это ни разу не сказал

K>Я об этом ниразу не сказал, потому что считаю это неправильным.
K>1) Не наблюдается никакой связи между тем, для чего язык разрабатывался и тем, для чего он применяется.

Не важно для чего делали. Важно для чего он пригоден. Иногда это одно и то же, иногда — нет.

K>Это объяснимо, конечно, потому что большинство языков, не смотря на заявляемую когда-то авторами "принадлежность", не имеют никакой специализации и являются языками общего назначения. Даже когда язык действительно специализирован — эта спецуиализация по мере развития разбавляется совершенно посторонними фичами. В SQL добавляют императивные конструкции, регулярные выражения перестают быть регулярными и т.д.
K>Подавляющее большинство языков не заточены под какую-то нишу.

Это заблуждение. Проверяется очень легко — берешь одну и ту же задачу и пишешь на самых разных ЯП. В одних языка решения будут простые и работать будут очень эффективно, в других будет нагромождение кода и фатальное проседание производительности.

K>2) Выбор языка определяется, в основном, возможностью нанять программиста на этом языке. Разумеется, имеющаяся в таком подходе положительная обратная связь раздувает любую флуктуацию до космических масштабов и делает популярность языка случайной. Невозможно предсказать какой из языков станет популярным, а какой канет в забвение: A или A', который от A отличается оттенком перламутровых пуговиц.

Выбор языка вообще говоря определяется задачами, а не состоянием рынка труда. НАпример несмотря на то, что подавляющее большинство умеет JS + С# или Java или С++, есть целая куча вакансий по другим языкам.

K>3) Если же язык выбирают по техническим причинам, то выбирают не языки, а реализации и инфраструктуру, причем набор неигрушечных реализаций для нужных платформ часто вообще отсутствует. Понятно, что и тут положительная обратная связь, выхватывающая из шума случайный кактус и заставляющая его есть десятилетиями.

Правильно, я и говорю — язык это следствие. А главное это задачи.

K>4) Не смотря на все это, иногда таки можно выбрать кактус, который колется поменьше — это инициирует лавинообразный переход на новое семейство языков, как только мы можем себе это позволить, но не раньше.

Это непроверяемо и нефальсифицируемо, так шта...

K>Сдвиг парадигмы не происходит от изменения задач, а ппоисходит от развития техники, которая начиная с какого-то момента позволяет иметь новый уровень удобств. ООП стал популярен, когда его стало можно себе позволить. И ФП становится популярным в последнее время по этим же причинам. Смолток просто морально устарел раньше, чем его смогли себе позволить использовать значительное количество программистов — вот и все.

Предложи как это можно проверить и фальсифицировать, тогда можно и продолжить.