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

А чего не хватает Julia, чтобы это был GPL, а не eDSL?    Ведь не о реализации же идёт речь, а о теоретических каких-то проблемах?

Нет, не нотацию. Я вот не считаю, что Julia от машины Тьюринга нотацией отличается.

ммм, окей, а можно тогда уточнить значение слова "нотация", и/или аргументировать утверждение "нотация Julia не отличается от нотации для МТ? не понимаю

Я вообще слово "нотация" не употреблял, поэтому не пойму, о чём спрашивается.

Я считаю, что есть отдельно представление программы как AST, и отдельно какое-то её выражение в тексте. Наверное, правила соответствия текста и AST и называется "нотация".

В Julia есть доступ к AST, и если нужно подхакивать что-то для eDSL, то это делается не столько в части парсинга текста исходного кода, сколько в части процессинга какой-то части AST.

Ну, и там даже большая детальность (два уровня): https://pkg.julialang.org/docs/julia/THl1k/1.1.1/devdocs/ast.html

Для справки: про типы в Julia документация вот — https://pkg.julialang.org/docs/julia/THl1k/1.1.1/devdocs/types.html

Подробности и теория в части subtyping приаттачены в paper.

Пример eDSL (аналог Modelica, для инженерного моделирования) на макросе model в Julia — https://github.com/ModiaSim/Modia.jl

Что сразу неудобно в Julia:
1. Отсутствие ООП-методов. Функции с dynamic dispatch это иной, отличающийся от мейнстримного modeling approach, менее надёжный (в случае импорта функций с одинаковыми именами из разных модулей) и создающий лишнюю когнитивную нагрузку в тех domains, которые уже промоделированы в методах (работа со сторонними объектными API).
2. Массивы "с единицы", как принято в математических DSL. Также лишняя когнитивная нагрузка и источник ошибок.

Что ненадёжно в Julia: динамическая типизация. Для exploratory в REPL или разработки продуктов силами двух-трёх экспертов с совпадающим культурным бэкграундом это приемлемо. Однако, для более крупных и разнородных команд динамическая типизация является гарантией вечного бардака.

Ну, массивы с единицы - это уже просто bikeshedding! 😂

И главная проблема - отсутствие каких-либо преимуществ. Ради чего брать Julia вне "фортрановской" ниши? Ок, на ней можно писать EDSL вроде Modia. Но такие же EDSL можно писать на C#, например.

На нормальном языке с существующей экосистемой и развитыми инструментами.

Так а Вы, простите, какими языками кроме C# владеете? 😊

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

1. В сообществе Julia считают, что multiple dispatch и впрямь отличается от ООП — но тем, что это лучше.

If you're familiar with Julia and its ecosystem, you may have noticed something lovely but a bit puzzling: there seems to be an unusually large amount of code reuse between packages compared to other seemingly similar languages. This sharing of code comes in two forms:

1. Sharing basic types among a wide variety of packages providing disparate functionality;
2. Sharing generic algorithms that work on various implementations of common abstractions.

Why does generic code in Julia "just work"? Why do Julia packages seem to share types with so little friction? Both kinds of reuse are supposed to be natural benefits of class-based object-oriented languages. After all, inheritance and encapsulation are two of the four pillars of OOP. Even more puzzling is that Julia has no encapsulation and doesn't allow inheriting from concrete types at all. Yet both kinds of code reuse are rampant. What is going on? In this talk, I make the case that both of kinds sharing stem directly from Julia's multiple dispatch programming paradigm.

https://www.youtube.com/watch?v=kc9HwsxE1OY

2. Всегда можно включить проверку для тех переменных, типы которых ты считаешь, что не должны меняться. А остальные пусть будут динамических типов. Это не считается серьёзной проблемой. Вот типичный пример текста: "Adding static type checking to Julia in 100 lines of code"
https://nextjournal.com/jbieler/adding-static-type-checking-to-julia-in-100-lines-of-code/
Но для меня нестатичность типов явно не стоп-фактор.

3. Я лично предпочитаю массивы с единицы (и терпеть не могу массивы с нуля — я питон так и не полюбил из-за этих вот нулей в нумерации). Но в Julia есть custom indexing, хоть с -3 делай эти массивы — https://docs.julialang.org/en/latest/devdocs/offset-arrays/

Хаять multiple dispatch только из-за того, что "на ООП не похоже" как-то э.

@ailevenchuk В Clojure-экосистеме тоже от multiple dispatch (сделан так же, как в Julia) большая польза сообществом наблюдается.

Вот пример, как комбинация типов и multiple dispatch приводит к простому программированию сложных машин состояний — https://www.youtube.com/watch?v=WGT9_cEImAk

Как раз пример того, как эффективна работа с типами при multiple dispatch.

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

@ailevenchuk Удобно, но немного органичено. Ограничено тем, что каждый кусочек данных имеет выделенный тип. Для сравнения, пусть у нас есть набор данных {:sex :male :name "Пупкин, Васиуалий" :age 42}. Если диспетчер может для аргумента вместо фиксированной функции "взять обработчик с наиболее близким по иерархии типом" выполнить произвольный код, то такой набор данных может участвовать в разных "иерархиях" для пола, возраста etc.

Смотря что вы имеете в виду под словом "владеете". В коммерческой разработке в основном использовал C, C++, Python, Lua, JavaScript, Java, C#, SQL, SPARQL, разные DSL, "баши" и ассемблеры, для себя экспериментировал с альтернативными парадигмами (Haskell, OCaml, Prolog, etc) в начале века, а в плане "читал по языку документацию, стандарты или какие-то primers" - после первой сотни считать перестал.