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

K>В чем-то типизация, конечно, уменьшает возможности, потому что она иногда (насколько редко — зависит от развитости системы типов) запрещает вполне осмысленный код. Но типизация и увеличивает возможности. А примеры можно всякие приводить. В том числе и такие

Автор: MigMit
Дата: 16.02.12

, где C++ пасует, а Java/C# — нет, не говоря уже о Хаскеле.

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

K>Я считаю, что интегрально, по совокупности плюсов и минусов, типизация лучше ее отсутствия.

Ну со вкусами конечно же спорить смысла нет — это личное дело каждого. )

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

_>Какое ещё метапрограммирование в C#?

Убогое, как и все остальное в C#.

K>>В данном случае разговор о том, что аналог написать нельзя — только и всего.

_>Ну да, конечно. Аналог написать нельзя, потому что в других языках нет контроля эффектов. А какая польза у нас тут от контроля эффектов? ) Никакой, но всё равно аналог написать нельзя. Угу.

Ну да, конечно. Бузина не является дядькой, потому что дядька человек разумный, а бузина — наоборот — двудольная и цветковая. А какая польза у нас тут от разумности и двудольности? ) Никакой, но все равно дядька не бузина. Угу.

_>Не стоит путать факультативную иммутабельность (есть почти во всех языках) и обязательную (типа как в Хаскеле). Так же как не стоит путать факультативную чистоту (как в D) и обязательную (как в Хаскеле).

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

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

_>Ну так я нигде и не возражал тому, что классический (вне монад) Хаскель является вполне симпатичным языком.

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

_>Только вот он как бы не для реального применения такой... )))

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

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

_>Нет, по ссылке как раз виден пример убогости реализации в Java/C#, которая не поддерживает рекурсивные типы.

А чего не проблема шаманизма сразу? Вообще заявка мощная, такого комментария я вроде в эпохальных обсуждениях примера тут и на лоре не еще видел.

_>Соответственно подобный Java/C# код по смыслу означает совершенно другое, чем он же, переведённый дословно на C++. А если переводить нормально, а не дословно, то всё будет нормально работать.

Это нужно обязательно развить. Объясните скорее, при чем тут "неподдержка рекурсивных типов в C#/Java" и как это нормально перевести на C++?

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

Это, вообще-то не дело вкуса, а технический вопрос.

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

_>>Какое ещё метапрограммирование в C#?
K>Убогое, как и все остальное в C#.

В C# версии 5+ вроде как должно появиться. Но здесь то текущая версия — где там конкретно обнаружилось метапрограммирование? )

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

Не, речь совсем не об этом. Поддержка — это обычно добавление каких-то возможностей. А в Хаскеле мы имеем скорее запрещение всего остального, кроме нашей парадигмы. Т.е. собственно говоря никто не мешал бы сделать язык со всеми возможностями Хаскеля и плюс нормальная поддержка других парадигм.

K>Да позиция понятна, все симпатичное для реального применения не годится по той же причине, по какой плац нужно подметать ломом.

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

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

K>Это нужно обязательно развить. Объясните скорее, при чем тут "неподдержка рекурсивных типов в C#/Java" и как это нормально перевести на C++?

Очевидно же, что одинаковая внешне запись на C++ и на Java/C# означают совершенно разные по реальному смыслу вещи. Так что тупое копирование кода из одного языка в другой не позволяет нам получать всегда работающий код, потому как он может просто означать другое. Как и в этом случае.

K>Это, вообще-то не дело вкуса, а технический вопрос.

Если бы так, то весь мир работал бы на 2-3 языка и всё. )

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

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

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

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

_>В C# версии 5+ вроде как должно появиться.

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

_> Но здесь то текущая версия — где там конкретно обнаружилось метапрограммирование? )

Конкретно здесь:

(S) typeof(S).GetConstructor(
                BindingFlags.Instance | BindingFlags.NonPublic,
                null,
                new Type[0],
                new ParameterModifier[0]).Invoke(null);

_>Не, речь совсем не об этом. Поддержка — это обычно добавление каких-то возможностей.

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

_>А в Хаскеле мы имеем скорее запрещение всего остального, кроме нашей парадигмы.

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

_>Т.е. собственно говоря никто не мешал бы сделать язык со всеми возможностями Хаскеля и плюс нормальная поддержка других парадигм.

И где же этот чудо-язык? Его, конечно, сделать нельзя. Какие есть плюсы у хаскеля?

1) Более-менее полноценная поддержка для комбинирования комбинаторов.
2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).

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

Если под "нормальной поддержкой других парадигм" вы понимаете именно отказ от контроля за эффектами — то с рассуждениями о коде, нормальной ленивостью и оптимизациями можно распрощаться, а значит и с полноценным комбинированием комбинаторов. Т.е. остается у нас только более-менее полноценная система типов и мы попадаем в мертвую зону между хаскелем и так называемыми "гибридами", забитую мертвыми ML-ями и дышащим на ладан окамлом. Это вечные девяностые — прогресс отсюда никуда не двинуть. От гибридов языки мертвой зоны выгодно отличаются полноценными системами типов и модулей, которыми гибриды жертвуют ради использования библиотек и рантаймов популярных мейнстримовых языков, но — по всей видимости — этого недостаточно.
Т.е. язык вашей мечты это, скажем так, предыдущее поколение ФЯП, после середины 2000-х либо вовсе умерших, либо влачащих жалкое существование и имеющих популярность малую даже в сравнении с хаскелем и успешными "гибридами", которые сами большой популярностью похвастать не могут.
Если под другой парадигмой понимать ООП, причем мейнстримовое, с сабтайпингом, а не марсианское-структурное, какое возможно в хаскеле и некоторых "негибридных" мл-ях, то оно наносит такой удар по системе типов, что о хоть сколько нибудь полноценной поддержке ФП говорить уже не приходится. Это так называемые "гибриды", которые любят декларировать "мультипарадигменность", но ФП там, как колбаса при коммунизме: чего не спроси — отвечают, что потребности нет.

_>К сожалению не годится. Вот я например не считаю тот же C++ идеалом (у меня к нему есть гора претензий) и с удовольствием заменил бы его на что-то лучшее, но не выходит по разным причинам. Ну в случае Хаскеля сам кривой дизайн языка не подходит. А вот например D (который является большим шагом вперёд в верном направление) не подходит из-за слабого развития инфраструктуры (собственно у Хаскеля есть и эта проблема, но там это уже не важно).

Ну, то есть, нужен язык в точности как C++, но с перламутровыми пуговицами? Тут, как мне кажется, надеяться не на что. Перламутровых пуговиц никогда не будет достаточно, чтоб перевесить инфраструктуру плюсов, в которую человеколет вложено чуть ли не больше, чем во все остальные языки вместе взятые.

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

_>Очевидно же, что одинаковая внешне запись на C++ и на Java/C# означают совершенно разные по реальному смыслу вещи.

Это, конечно, верно. Собственно, это как раз пример, написанный для того, чтоб это продемонстрировать.

_>Так что тупое копирование кода из одного языка в другой не позволяет нам получать всегда работающий код, потому как он может просто означать другое. Как и в этом случае.

Ну так я и спрашиваю — а как это перевести на C++ нормально?
И при чем тут "неподдержка рекурсивных типов в C#/Java"?

K>>Это, вообще-то не дело вкуса, а технический вопрос.
_>Если бы так, то весь мир работал бы на 2-3 языка и всё. )

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

Здравствуйте, D. Mon, Вы писали:
DM>Хотел намекнуть, что в языках вроде питона можно вызвать некоторый специальный метод вместо несуществующего, но нельзя вызвать сам несуществующий, ему взяться неоткуда. Кстати, в D тоже есть такая фишка. А в С++ "вы не должны этого хотеть", там это ошибка времени компиляции, как и было сказано выше.
Ну вот поэтому С++ и нравится не всем. В частности, для банальной вещи — реализация proxy в какой-нибудь RPC инфраструктуре — плюсы предлагают пользоваться компиляторами IDL. А современные динамические языки просто проксируют всё, что пришло.

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

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

Так это ты предложил пообсуждать фичи отсутствующие в языках, но при этом имеющие множественные реализации в виде библиотек. Хотя лично я не особо представляю что тут собственно обсуждать — тут просто есть факт возможности/невозможности реализации данной фичи на данном языке. Ну и ещё можно добавить факт наличия/отсутствия уже готовой библиотеки. По поводу мультиметодов для C++ и Питона в этом смысле разницы нет.

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

K>Рефлексия и рантайм кодогенерация были всегда. Некоторые улучшения в кодогенерации во второй версии, убогое цитирование в третьей, несколько улучшенное в четвертой.

Ааа ну рантайм кодогенерация безусловно есть. В таком смысле метапрограммирование есть и в javascript и в bash. ))) Да и на ассемблере можно. )

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

Вот никаких вы не можете понять простейшую вещь. Для данной фичи (например чистоты/ленивости) в языке могут быть не только режимы "не имеем поддержки" (как в большинстве языков) и "обязательно к использованию" (как в Хаскеле). Вполне возможен вариант "есть полноценная поддержка, но использовать фичу не обязательно" (как в D относительно чистоты).

K>И где же этот чудо-язык? Его, конечно, сделать нельзя. Какие есть плюсы у хаскеля?

K>1) Более-менее полноценная поддержка для комбинирования комбинаторов.
K>2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).

Это всё скорее следствия.

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

Так пускай будет даже по умолчанию такой режим, но должен быть спокойный способ не использовать данную фичу. Я уже приводил пример. Что в одних языках переменные по умолчанию мутабельные и есть слово const. Можно сделать наоборот и сделать иммутабельные по умолчанию и добавить ключевое слово mut (как в том же Rust) — это будет ближе к функциональному, но при этом не отметает поддержку классического. А в Хаскеле у нас его фичи не просто по умолчанию, а обязательны! В этом и есть ключевой минус.

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

Не отказ, а опциональность. Кстати, OCaml очень даже не плохой язык, но сейчас несколько устарел уже.

K>Т.е. язык вашей мечты это, скажем так, предыдущее поколение ФЯП, после середины 2000-х либо вовсе умерших, либо влачащих жалкое существование и имеющих популярность малую даже в сравнении с хаскелем и успешными "гибридами", которые сами большой популярностью похвастать не могут.

Языка моей мечты я пока не видел. Но это будет скорее в том направление, что задают D, Rust с одной стороны и Python, Ruby и т.п. с другой.

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

K>Это, конечно, верно. Собственно, это как раз пример, написанный для того, чтоб это продемонстрировать.

И в чём смысл демонстрировать такую очевидную вещь? )

K>Ну так я и спрашиваю — а как это перевести на C++ нормально?
K>И при чем тут "неподдержка рекурсивных типов в C#/Java"?

На C++ подобные вещи вообще по другому записывают. Точнее то, что записано на C#/Java. Вот на Хаскеле (как я понял из обсуждения там) у нас совсем другой расклад с этим примером...

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

_>Ааа ну рантайм кодогенерация безусловно есть. В таком смысле метапрограммирование есть и в javascript и в bash. ))) Да и на ассемблере можно. )

Ваши ассоциативные ряды, конечно, интересны, но для тех, кто интересуется вашим внутренним миром, в отрыве от данного разговора. Давайте в это углубляться не будем и вернемся к тому, о чем мы говорили. Вы упомянули паттерны проектирования, как код на языке, а не некие неформальные концепции. Я попросил пояснить, имеется ли в виду метапрограммирование. Вы ответили, что нет, не имеется, но привели пример с использованием метапрограммирования. Вы тут противоречия не замечаете?

_>Вот никаких вы не можете понять простейшую вещь. Для данной фичи (например чистоты/ленивости) в языке могут быть не только режимы "не имеем поддержки" (как в большинстве языков) и "обязательно к использованию" (как в Хаскеле). Вполне возможен вариант "есть полноценная поддержка, но использовать фичу не обязательно" (как в D относительно чистоты).

Если данную фичу — контроль за эффектами "использовать не обязательно", то это означает, что таких фич как:
1) Полноценная ленивость
2) Возможность рассуждать о коде
3) Оптимизации, существенно меняющие код
4) Полноценное комбинирование комбинаторов
у нас нет. Т.е. если использовать контроль за эффектами не обязательно, то используете вы контроль за эффектами или нет уже не важно: он бесполезен.

K>>1) Более-менее полноценная поддержка для комбинирования комбинаторов.
K>>2) Возможность рассуждать об этих комбинаторах как о математических объектах (с оговорками).

_>Это всё скорее следствия.

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

_>Так пускай будет даже по умолчанию такой режим, но должен быть спокойный способ не использовать данную фичу. Я уже приводил пример. Что в одних языках переменные по умолчанию мутабельные и есть слово const. Можно сделать наоборот и сделать иммутабельные по умолчанию и добавить ключевое слово mut (как в том же Rust) — это будет ближе к функциональному, но при этом не отметает поддержку классического. А в Хаскеле у нас его фичи не просто по умолчанию, а обязательны! В этом и есть ключевой минус.

Ну так "иммутабельность по умолчанию" вроде let и let mutable против var const и var — это никакая не полноценная поддержка иммутабельности. Это только некоторый способ простимулировать написание "хорошего" кода и штрафовать "плохой", наподобие обсуждаемой (и осуждаемой мной) тут раньше системы карательных наименований. Упомянутую мной здесь пользу (специфические оптимизации, возможность рассуждать о коде и полноценная ленивость) на такой базе не построить, такая "поддержка" во всех ml-ях есть, а вот нормальной поддержки, без кавычек, там как раз и нет.

_>Не отказ, а опциональность.

В данном случае практически значимой разницы между "опциональность" и "отказ" нет.

_>Кстати, OCaml очень даже не плохой язык, но сейчас несколько устарел уже.

OCaml, конечно, лучше подавляющего большинства языков, и устаревший по сравнению с языками, которые можно по пальцам если не одной, то двух рук точно пересчитать (причем подавляющее большинство помимо авторов никто не знает). Это, однако, больше говорит не о качествах окамла, а о плачевном положении в области разработки языков и об удручающей неграмотности и узком кругозоре типичного автора языка программирования.

_>Языка моей мечты я пока не видел. Но это будет скорее в том направление, что задают D, Rust с одной стороны и Python, Ruby и т.п. с другой.

Могу вам только позавидовать, потому что такого добра будет еще немало сделано: это как раз те автоматы калашникова, которые всегда получаются у типичного автора ЯП.

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

_>И в чём смысл демонстрировать такую очевидную вещь? )

Я видел (и сам вел) несколько дискуссий длиной в бразиллион постов с теми, для кого это вовсе не очевидная вещь. Правда, демонстрировать ее действительно бесполезно: участники дискуссий остаются при своих заблуждениях.

K>>Ну так я и спрашиваю — а как это перевести на C++ нормально?
K>>И при чем тут "неподдержка рекурсивных типов в C#/Java"?

_>На C++ подобные вещи вообще по другому записывают.

Это вы уже говорили. Я и спрашиваю: по другому — как?

_>Точнее то, что записано на C#/Java. Вот на Хаскеле (как я понял из обсуждения там) у нас совсем другой расклад с этим примером...

Как раз сходство между хаскельным, C# и Java кодом вполне прослеживается, потому что параметрический полиморфизм в этих языках в некоторой степени схожий, про C++ этого, конечно, не скажешь.

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

_>Так это ты предложил пообсуждать фичи отсутствующие в языках, но при этом имеющие множественные реализации в виде библиотек. Хотя лично я не особо представляю что тут собственно обсуждать — тут просто есть факт возможности/невозможности реализации данной фичи на данном языке.

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

>Ну и ещё можно добавить факт наличия/отсутствия уже готовой библиотеки. По поводу мультиметодов для C++ и Питона в этом смысле разницы нет.

Разница есть. В С++ надо пахать и пахать, а в питоне на порядок меньше кода.

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

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

Лушче говорить 'паттерны', особенно если в контексте слово шаблон используется как template.

Не совсем понятно, что значит "шаблона нет, но есть результат его применения". Чтото навроде "слова 'жопа' нет, но есть и результат и обозначаемое этим словом место"

Паттерн программирования это просто какая то фича, которая поддерживается на уровне библиотеки или соглашения.

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

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

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

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

Сделать это очень просто — придумай и опубликуй хорошую игру или открой новый бизнес. Как только оформится более-менее внятное коммюнити, сразу увидишь и паттерны и всё остальное. Часть будет новых, в зависимости от новизны твоей идеи, часть будет заинствованых, так же в зависимости от новизны идеи. Часть появится быстро, часть появится через некоторое время. Паттерны программирования ничем от этих паттернов не отличаются, абсолютно ничем.

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

K>Ваши ассоциативные ряды, конечно, интересны, но для тех, кто интересуется вашим внутренним миром, в отрыве от данного разговора. Давайте в это углубляться не будем и вернемся к тому, о чем мы говорили. Вы упомянули паттерны проектирования, как код на языке, а не некие неформальные концепции. Я попросил пояснить, имеется ли в виду метапрограммирование. Вы ответили, что нет, не имеется, но привели пример с использованием метапрограммирования. Вы тут противоречия не замечаете?

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

А что у нас с паттернами проектирования в функциональном стиле? ) Или с инструментами типа UML для функциональной парадигмы? )

K>Если данную фичу — контроль за эффектами "использовать не обязательно", то это означает, что таких фич как:
K>1) Полноценная ленивость
K>2) Возможность рассуждать о коде
K>3) Оптимизации, существенно меняющие код
K>4) Полноценное комбинирование комбинаторов
K>у нас нет. Т.е. если использовать контроль за эффектами не обязательно, то используете вы контроль за эффектами или нет уже не важно: он бесполезен.

С чего бы это?

K>Ну так "иммутабельность по умолчанию" вроде let и let mutable против var const и var — это никакая не полноценная поддержка иммутабельности. Это только некоторый способ простимулировать написание "хорошего" кода и штрафовать "плохой", наподобие обсуждаемой (и осуждаемой мной) тут раньше системы карательных наименований. Упомянутую мной здесь пользу (специфические оптимизации, возможность рассуждать о коде и полноценная ленивость) на такой базе не построить, такая "поддержка" во всех ml-ях есть, а вот нормальной поддержки, без кавычек, там как раз и нет.

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

K>В данном случае практически значимой разницы между "опциональность" и "отказ" нет.

Опять же с чего бы это? ) Тот же пример чистоты в D говорит об обратном... )

K>Могу вам только позавидовать, потому что такого добра будет еще немало сделано: это как раз те автоматы калашникова, которые всегда получаются у типичного автора ЯП.

Кстати, хочу интересный нюанс отметить в этом смысле. В последнее время становятся нормой гетерогенные системы — очень многие успешные проекты используют несколько разных языков в связке. Казалось бы самое оно взять для такой связки языки с разными парадигмами. Ну например какой-нибудь там Фортран для вычислительной части и хаскель (или что-то скриптовое похожего вида, кстати а такое вообще есть?) для остального и т.п. Однако, если мы посмотрим в реальность, то увидим что среди современных сложных проектов лидирует связка C++/Python. Т.е. два мультипарадигменных языка! Более того, на мой взгляд, при всех своих различиях, они очень похожи одним базовым принципом: в них напихано множество различных парадигм и концепций, но при этом ни одна не является обязательной для использования. И судя по индустрии в данный момент, именно этот принцип и оказывается "побеждающим". При этом работа в такой связке оказывается очень похожа на обоих уровнях, а добавка Питона к C++ по сути позволяет повысить скорость разработки без потери эффективности и защищённости продукта. Думаю это и есть текущий вектор в будущее...

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

K>Я видел (и сам вел) несколько дискуссий длиной в бразиллион постов с теми, для кого это вовсе не очевидная вещь. Правда, демонстрировать ее действительно бесполезно: участники дискуссий остаются при своих заблуждениях.

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

K>Это вы уже говорили. Я и спрашиваю: по другому — как?

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

#define cint struct{const int value;}
template<typename T> class Cons{
    vector<int> data;
    Cons()=default;
    template<typename S, typename F> friend Cons<S> MakeCons(S s, F f);
    template<typename S> friend int ScalarProduct(const Cons<S>& c1, const Cons<S>& c2);
};
template<typename S, typename F> Cons<S> MakeCons(S s, F f)
{
    Cons<S> r;
    for(int i=0; i<s.value; i++) r.data.push_back(f(i));
    return r;
}
template<typename S> int ScalarProduct(const Cons<S>& c1, const Cons<S>& c2)
{return inner_product(c1.data.cbegin(), c1.data.cend(), c2.data.cbegin(), 0);}
int main()
{
    int n;
    cin>>n;
    cint size{n};
    auto cons1=MakeCons(size, [](int i){return i;});
    auto cons2=MakeCons(size, [](int i){return i+1;});
    //cint size1{n+1};
    //auto cons2=MakeCons(size1, [](int i){return i;});//а такое не будет компилироваться
    cout<<ScalarProduct(cons1, cons2)<<endl;
}

Получается аналогичная защита. Но при этом позволяет спокойно создавать компоненты для произведения не обязательно внутри одной функции, как в примерах C#/Java. Ну а про расход памяти и быстродействие думаю можно даже не упоминать — они тут получаются вообще не сравнимыми... )

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

>>Ну и ещё можно добавить факт наличия/отсутствия уже готовой библиотеки. По поводу мультиметодов для C++ и Питона в этом смысле разницы нет.

I>Разница есть. В С++ надо пахать и пахать, а в питоне на порядок меньше кода.

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

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

I>>Разница есть. В С++ надо пахать и пахать, а в питоне на порядок меньше кода.

_>При использование готовой библиотеки? ) Не думаю. ) Если конечно не иметь в виду обычную разницу между динамическими и статическими языками в объявлениях типов и т.п.

Ну то есть библиотеки писать не надо, правильно ?