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

_>Да легко. Вот к примеру периодически возникает потребность в написание различных скриптов (к примеру не тривиального построения проектов и т.п.). Сейчас это пишется на Питоне
И сколько там строк?

_>(кстати тоже в своеобразном DSL).
И чего в питоне ДСЛного?

_>На каком из статически типизированных языков ты предлагаешь мне сделать эту работу?
На любом с выводом типов.

_> И чем это будет удобнее?
Будешь получать по рукам не через час работы скрипта, а до запуска.

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

ARK>Я тоже не отношусь к сторонникам динамики, но преимущества в определенных случаях, по-моему, очевидны: можно писать код БЫСТРО.
Статическая типизация этому не мешает.

ARK>Можно абстрагироваться от типа переменной вообще.
Вывод типов.

ARK>Можно вызывать функции, которые еще не написаны.
1)Любая нормальная ИДЕ одним нажатием кнопки может сделать заглушку бросающую исключение.
2)Ничто не мешает компилятору генерировать такие заглушки.
Те выставил флаг компилятору, а он вместо ошибки начал давать предупреждение и выкидывать исключение при вызове метода.

ARK>Ну и так далее.
Что-то пока у тебя не задалось.

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

DE>Знаешь что забавно? Что люди выступающие против макросов/ДСЛ тоже считают твои аргументы не убедительными.
Разница существенна.
Я знаю про динамическую типизацию больше чем они.
Они про макросы не знают ничего.

DE>Вот только мейнстримовых (статически типизированных) языков с "выводом типов и метапрограммированием" (практически?) нет. А динамика вполне доступна и "пропихнуть в продакшен", наверное, легче чем немерле.
Пихать динамику в продакшен глупо. Всегда.

DE>Ну и опять же про "миллионы мух": любители динамики ведь и решения принимают. Да и найти готовых специалистов проще.
К сожалению нельзя запретить принимать решения мухам.
Вот они и тащат в продакшен всякое говно. То динамически типизированный язык притащат. То NoSQL в качестве основного хранилища.

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

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

N>>Я, кстати, не проповедую "каждому языку — свою IDE". Имхо есть места, где это просто не нужно/не оправданно. Но там где нужно, стоит думать про нее с первого дня.
WH>Тут главное не забывать, что нет таких задач, для которых нужно было бы калечить язык, так чтобы для него было трудно сделать ИДЕ.

Это само собой.

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

ARK>Если это не является секретной информацией, не могли бы вы описать чуть подробнее? Или какой-нибудь документ выложить.
ARK>Просто интересно, ничего кроме этого.

Через пару месяцев наверное могу вообще подробно рассказать. ) А пока могу только уточнить, что описанный DSL не является самоцелью или чем-то подобным, а выступает всего лишь в роли одного из инструментов реализации (в данном случае кастомизации) некого интересного прикладного решения.

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

LP>Пытаетесь объять необъятное?
Нет.

LP>Да ну?
Компилятор может написать любой профильный студент. И даже некоторые школьники.
Нормальных ИДЕ раз, два и обчёлся.

LP>Это сомнительно хотя бы потому, что универсальные генераторы IDE есть уже давно (https://eclipse.org/Xtext/),
Крайне ограниченная штука с кучей закатов солнца вручную.

LP>а вот действительно универсальные генераторы компиляторов — такого история не знает. Каков должен быть алгоритм, который лишь из одного метаописания языка С++ может комплировать С++ код, а из метаописания языка Prolog-a — Prolog-код?
https://en.wikipedia.org/wiki/Graph_rewriting закрывает процентов 90.

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

_>>Да легко. Вот к примеру периодически возникает потребность в написание различных скриптов (к примеру не тривиального построения проектов и т.п.). Сейчас это пишется на Питоне
WH>И сколько там строк?

Обычно 1-2 экрана. ) Ну точнее я то уже привык использовать данный инструмент вообще во всех случаях, так что частенько встречаются скрипты и в несколько строк. Однако их теоретически можно было бы заменить всякими там make/bat и т.п. файлами. В отличие от сложных случаев, которые писать без помощи специализированных инструментов очень неприятно.

_>>(кстати тоже в своеобразном DSL).
WH>И чего в питоне ДСЛного?

DSL там реализует не сам Питон, а соответствующие библиотечки для него. Например типа таких: http://docs.fabfile.org/en/1.10/tutorial.html

_>>На каком из статически типизированных языков ты предлагаешь мне сделать эту работу?
WH>На любом с выводом типов.

Ну так назови хотя бы один. В чём проблема? )))

Причём обрати внимание... Это я ещё не потребовал наличия в языке готовых инструментов типа http://www.scons.org или https://waf.io, без которых написание подобных скриптов является сомнительным развлечением. А ты уже и без этого не смог назвать ни одного языка...

_>> И чем это будет удобнее?
WH>Будешь получать по рукам не через час работы скрипта, а до запуска.

Это конечно же очень хорошо, но только при выполнение трёх условий:

1. Чтобы писалось не сложнее чем сейчас. Т.е. чтобы синтаксис языка был не тяжелее Питона и были в наличие нужные предметные библиотеки.
2. Чтобы запускалось не сложнее чем сейчас. Т.е. никаких там отдельных компиляторов, а просто некий универсальный исполнитель скриптов, который прописываем в path.
3. Чтобы можно было увидеть ссылку на скачивание описанного чуда, а не утверждение, что это всё теоретически возможно (против этого никто и не возражал). ))))

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

ARK>>Я тоже не отношусь к сторонникам динамики, но преимущества в определенных случаях, по-моему, очевидны: можно писать код БЫСТРО.
WH>Статическая типизация этому не мешает.

Иногда мешает.

ARK>>Можно абстрагироваться от типа переменной вообще.
WH>Вывод типов.

Вывод типов имеет дело с каким-то конкретным типом, а я имею дело с типом, который, возможно, вообще еще не объявлен.

ARK>>Можно вызывать функции, которые еще не написаны.
WH>1)Любая нормальная ИДЕ одним нажатием кнопки может сделать заглушку бросающую исключение.
WH>2)Ничто не мешает компилятору генерировать такие заглушки.
WH>Те выставил флаг компилятору, а он вместо ошибки начал давать предупреждение и выкидывать исключение при вызове метода.

1) Не все используют IDE.
2) Не все используют IDE, генерящие такие заглушки.
3) Это лишние телодвижения и, возможно, неиспользуемый мусор в коде.

ARK>>Ну и так далее.
WH>Что-то пока у тебя не задалось.

Вполне объективные наблюдения.

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

ARK>>Если это не является секретной информацией, не могли бы вы описать чуть подробнее? Или какой-нибудь документ выложить.
ARK>>Просто интересно, ничего кроме этого.

_>Через пару месяцев наверное могу вообще подробно рассказать. ) А пока могу только уточнить, что описанный DSL не является самоцелью или чем-то подобным, а выступает всего лишь в роли одного из инструментов реализации (в данном случае кастомизации) некого интересного прикладного решения.

Спасибо, будем ждать.

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

N>Если мы можем его менять, то никаких вопросов, конечно, нет. А если уже написаны горы кода?

Пока не нужно поддерживать обратную совместимость, то в общем-то тоже больших проблем у нас, например, на практике не возникает с внесением изменений в DSL, когда есть способы трансформирования AST.

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

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

N>>Если мы можем его менять, то никаких вопросов, конечно, нет. А если уже написаны горы кода?

_DA>Пока не нужно поддерживать обратную совместимость, то в общем-то тоже больших проблем у нас, например, на практике не возникает с внесением изменений в DSL, когда есть способы трансформирования AST.

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

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

_DA>>Пока не нужно поддерживать обратную совместимость, то в общем-то тоже больших проблем у нас, например, на практике не возникает с внесением изменений в DSL, когда есть способы трансформирования AST.

N>И у клиентов? Впрочем, с синтаксисом при таких возможностях проблем действительно немного.
Я как раз и имел ввиду, что пока клиенты сами код не пишут на DSL, то можно его безболезненно изменять, так как он весь хранится у нас. (На самом деле один клиент есть такой, но там совсем по мелочи, ему можно и персонально исходники поправить).

N>А если вы решили что-то автоматизировать и обнаружили, что не можете до исполнения программы понять нужные свойства, т.к. это просто не предусмотрено? Хотя тяжело, конечно, без общего конкретного примера рассуждать.
Эмм, это вопрос уже конкретно по нашему проекту? Могу в приватных сообщениях рассказать, если интересно )

WH>Единственный объективный аргумент в пользу динамической типизации: Нужно писать меньше кода.

Но это очень сильный аргумент.

Вообще, отвечая сразу и на вопрос выше о задачах, где динамика может выиграть перед статикой, попробую собрать все в кучу:

1) Динамика удобнее при интеграции с другими динамическими системами или сервисами, о типизации которых на этапе компиляции ничего не известно.
Примеры — работа с удаленным rpc-сервером без схемы, чтение данных из базы если схема заранее неизвестна, стык с другими динамическими системами, в общем все юзкейсы для которых ms ввел dynamic.
Статическая типизация здесь никаких гарантий не даст, а под ногами мешаться будет.

2) Динамика удобнее, когда статическая типизация в имеющихся альтернативах недостаточно гибка. Например когда нужно объединение типов — вот в Nemerle есть variant, но что делать если одна переменная имеет тип A | B | C | D, а другая — A | C | E | F? Один variant-тип неудобно по многим причинам (ну например он должен быть объявлен в одной сборке) да и нужные нам статические проверки он не обеспечит, а если два — то проблема в том, что значения A1 и A2 будут разными, и вот мы уже пишем кучу ненужного затрудняющего понимание кода. Ну а если в языке даже неуклюжего variant/pm нет, то вообще туши свет — мысль, которая могла быть выражена лаконично, растекается. Да что там, в большинстве языков даже тип со значениями ( T | null (значение отсутствует) | undefined (значение не определено) ) уже страшная проблема.

3) Системы с горячей заменой кода. Наверное, удачно совместить ее со статической типизацией в принципе возможно, но пока на этом поле играет динамика.

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

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

WH>1)Медленное исполнение.
WH>2)Большое потребление памяти.
WH>3)Серьёзные проблемы с поддержкой кода, если его больше 100 строк.
WH>4)Плохая поддержка ИДЕ.

Как и все трюизмы, эти, верные в целом (если, конечно, опустить "100 строк"), могут не соответствовать действительности в конкретных условиях.

Например, почему-то поддержка того же Эрланга со стороны ИДЕ намного лучше, чем существующая на данный момент поддержка Nemerle.

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

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

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

N>>А если вы решили что-то автоматизировать и обнаружили, что не можете до исполнения программы понять нужные свойства, т.к. это просто не предусмотрено? Хотя тяжело, конечно, без общего конкретного примера рассуждать.
_DA>Эмм, это вопрос уже конкретно по нашему проекту? Могу в приватных сообщениях рассказать, если интересно )

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

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

и сильно ли это повлияло на существующий код.

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

_>1) Динамика удобнее при интеграции с другими динамическими системами или сервисами, о типизации которых на этапе компиляции ничего не известно.
Ничего не сможешь с этим сервисом сделать. Даже обратится к нему не сможешь.
Либо тебе известен контракт. А если есть контракт, то уже есть типы.

_>Примеры — работа с удаленным rpc-сервером без схемы, чтение данных из базы если схема заранее неизвестна, стык с другими динамическими системами, в общем все юзкейсы для которых ms ввел dynamic.
И что ты будешь дальше делать?
Максимум что ты можешь сделать, это распечатать то, что ты получил.
Это при условии, что ты вообще смог к нему обратиться.

А вот если ты хочешь сделать что-то осмысленное, то тебе нужно знать что там лежит
Вот тут уже и появляются статическая типизация.

_>2) Динамика удобнее, когда статическая типизация в имеющихся альтернативах недостаточно гибка. Например когда нужно объединение типов — вот в Nemerle есть variant, но что делать если одна переменная имеет тип A | B | C | D, а другая — A | C | E | F?
Это легко делается.
Просто это нужно настолько редко что никто это не делает.
Но если тебе так хочется, к немерле 2 я это прикручу.

_>Ну а если в языке даже неуклюжего variant/pm нет, то вообще туши свет — мысль, которая могла быть выражена лаконично, растекается.
Так в большинстве динамически типизированных языков этого тоже нет.

_>Да что там, в большинстве языков даже тип со значениями ( T | null (значение отсутствует) | undefined (значение не определено) ) уже страшная проблема.
Мы всё ещё говорим про динамическую типизацию, где в переменной может быть любое говно?

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

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

_>Как и все трюизмы, эти, верные в целом (если, конечно, опустить "100 строк"), могут не соответствовать действительности в конкретных условиях.
Когда конкретно они не соответствуют действительности?

_>Например, почему-то поддержка того же Эрланга со стороны ИДЕ намного лучше, чем существующая на данный момент поддержка Nemerle.
Я ещё не видел ни одной ИДЕ для динамически типизированных языков, которую не мог бы запутать десятком строк кода.

_>Резюмируя — чтобы тащить динамику в продакшн действительно нужны веские причины, но при их наличии динамика не табу.
Пока что таких причин так и не назвали.

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

WH>>Статическая типизация этому не мешает.
ARK>Иногда мешает.
Ни разу не замечал. Единственное что мешает быстро писать код это непонимание того что нужно писать.

ARK>Вывод типов имеет дело с каким-то конкретным типом, а я имею дело с типом, который, возможно, вообще еще не объявлен.
Ну, где то ты заполняешь этот тип.

ARK>1) Не все используют IDE.
ARK>2) Не все используют IDE, генерящие такие заглушки.
Это их проблемы.

ARK>3) Это лишние телодвижения и, возможно, неиспользуемый мусор в коде.
Вот это ты проигнорировал.

WH>>2)Ничто не мешает компилятору генерировать такие заглушки.
WH>>Те выставил флаг компилятору, а он вместо ошибки начал давать предупреждение и выкидывать исключение при вызове метода.

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

_>Обычно 1-2 экрана. )
Те до 100 строк.
На таких объёмах динамика ещё не успевает превратиться в ад.

_>DSL там реализует не сам Питон, а соответствующие библиотечки для него. Например типа таких: http://docs.fabfile.org/en/1.10/tutorial.html
Для любого статически типизированного языка такое пишется примерно за день.

_>Ну так назови хотя бы один. В чём проблема? )))
10 секунд гугления.
http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html

_>1. Чтобы писалось не сложнее чем сейчас. Т.е. чтобы синтаксис языка был не тяжелее Питона и были в наличие нужные предметные библиотеки.

main = do
    cd "/tmp"
    mkdir "test"
    output "test/foo" "Hello, world!"  -- Write "Hello, world!" to "test/foo"
    stdout (input "test/foo")          -- Stream "test/foo" to stdout
    rm "test/foo"
    rmdir "test"
    sleep 1
    die "Urk!"

_>2. Чтобы запускалось не сложнее чем сейчас. Т.е. никаких там отдельных компиляторов, а просто некий универсальный исполнитель скриптов, который прописываем в path.
Либо есть либо пишется за пару часов.

_>3. Чтобы можно было увидеть ссылку на скачивание описанного чуда, а не утверждение, что это всё теоретически возможно (против этого никто и не возражал). ))))
Ещё 30 секунд гугления и ты найдёшь ещё много чего интересного.

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

ARK>>Вывод типов имеет дело с каким-то конкретным типом, а я имею дело с типом, который, возможно, вообще еще не объявлен.
WH>Ну, где то ты заполняешь этот тип.

Я могу просто вызвать метод "Process" у параметра метода. А потом позвать дополнительно еще IsValid. При этом никакого типа с этими Process/IsValid у меня пока нет (и, возможно, и не будет никогда), я просто набрасываю общую структуру. Может я, быстро найдя лучший вариант алгоритма, вообще удалю этот метод, не успев даже объявить нужный тип.

ARK>>3) Это лишние телодвижения и, возможно, неиспользуемый мусор в коде.
WH>Вот это ты проигнорировал.
WH>

WH>>>2)Ничто не мешает компилятору генерировать такие заглушки.
WH>>>Те выставил флаг компилятору, а он вместо ошибки начал давать предупреждение и выкидывать исключение при вызове метода.

Пардон, это я как-то пропустил. Ну да, с таким флагом будет то же самое. Но это и есть уже динамика по сути.

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

ARK>Я могу просто вызвать метод "Process" у параметра метода. А потом позвать дополнительно еще IsValid. При этом никакого типа с этими Process/IsValid у меня пока нет (и, возможно, и не будет никогда), я просто набрасываю общую структуру. Может я, быстро найдя лучший вариант алгоритма, вообще удалю этот метод, не успев даже объявить нужный тип.
Так в чём проблема то?
Или ты хочешь обязательно запустить недописанный код?

ARK>Пардон, это я как-то пропустил. Ну да, с таким флагом будет то же самое. Но это и есть уже динамика по сути.
Нет. Это только для прототипа. Для релиза это нужно отключать.
И тогда компилятор всё отловит.

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

ARK>>Я могу просто вызвать метод "Process" у параметра метода. А потом позвать дополнительно еще IsValid. При этом никакого типа с этими Process/IsValid у меня пока нет (и, возможно, и не будет никогда), я просто набрасываю общую структуру. Может я, быстро найдя лучший вариант алгоритма, вообще удалю этот метод, не успев даже объявить нужный тип.
WH>Так в чём проблема то?
WH>Или ты хочешь обязательно запустить недописанный код?

Ну да, что-то быстренько набросать и запустить недописанное, посмотреть на работу какого-то куска.

ARK>>Пардон, это я как-то пропустил. Ну да, с таким флагом будет то же самое. Но это и есть уже динамика по сути.
WH>Нет. Это только для прототипа. Для релиза это нужно отключать.
WH>И тогда компилятор всё отловит.

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

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