Исправление wall_jvm, (текущая версия) :
Джулия очень универсальная, считай почти что это Лисп с его лозунгом «Лучше иметь 100 функций, которые работают с одной структурой данных, чем 10 функций работающих с 10 структурами».
Главное – это именно multiple dispatch в сочетании с опциональной типизацией и выводом типов. Это позволяет решить expression problem (https://en.wikipedia.org/wiki/Expression_problem – The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)) – отдельно пополнять алгоритмы и структуры данных, причём не теряя в производительности и не залезая внутрь уже имеющегося кода. Это ключ к модульности, платформенности, созданию библиотек. Пополнить код новыми типами данных и процедурами можно без перекомпиляции уже имеющихся библиотек и потери в производительности, в этом фишка. И не путайте multiple dispatch с перегруженными операторами, это не про синтаксис вообще!
Это типа засунуть концепт базы данных внутрь языка: позволить писать алгоритмы, которые не нужно потом менять по мере постепенного раскучерявливания структур данных. Особенности обработки новых структур данных можно просто добавлять, как программы обработки данных в базах данных. С другой стороны, можно добавлять процедуры – это как засунуть базу процедур внутрь языка, симметричная базам данных идея, которая должна бы использоваться при распухании не данных, а кода.
https://ailev.livejournal.com/1218155.html
Я не знаю ни одного языка, который бы так близко приблизился к решению проблемы Expression problem.
Исходная версия wall_jvm, :
Джулия очень универсальная, считай почти что это Лисп с его лозунгом «Лучше иметь 100 функций, которые работают с одной структурой данных, чем 10 функций работающих с 10 структурами».
Главное – это именно multiple dispatch в сочетании с опциональной типизацией и выводом типов. Это позволяет решить expression problem (https://en.wikipedia.org/wiki/Expression_problem – The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)) – отдельно пополнять алгоритмы и структуры данных, причём не теряя в производительности и не залезая внутрь уже имеющегося кода. Это ключ к модульности, платформенности, созданию библиотек. Пополнить код новыми типами данных и процедурами можно без перекомпиляции уже имеющихся библиотек и потери в производительности, в этом фишка. И не путайте multiple dispatch с перегруженными операторами, это не про синтаксис вообще!
Это типа засунуть концепт базы данных внутрь языка: позволить писать алгоритмы, которые не нужно потом менять по мере постепенного раскучерявливания структур данных. Особенности обработки новых структур данных можно просто добавлять, как программы обработки данных в базах данных. С другой стороны, можно добавлять процедуры – это как засунуть базу процедур внутрь языка, симметричная базам данных идея, которая должна бы использоваться при распухании не данных, а кода.
Я не знаю ни одного языка, который бы так близко приблизился к решению проблемы Expression problem.