Кажется, что правильный шаг уже проделан stack-ом, хотя и по рабоче-крестьянски:
попытка делиться "снэпшотом мирового стейта"

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

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

Да, я тоже оговорился, что проделан по рабоче-крестьянски.
Но кажется, правильный

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

Нет никакой луны в разработке. Тем более в билд системах. Вы даже задачу не сформулировали, и цель не поставили. Слова "хотим применить ТК/whatever" - не цель и не задача, а хотелки.

Нет никакой луны в разработке. Тем более в билд системах.

То же самое мне втирали упёртые скриптеры с бэкграундом bash/cmd, настаивая на своём говнокоде в powershell:
"Программирование это циклы и ветвления", а ты философ пустобрёх оторванный от практических задач

Слова "хотим применить ТК/whatever" - не цель и не задача, а хотелки.

Так и есть. Но чую, что "тепло"

Я прошел по ссылкам.

> The 'strongly typed' dev environment should drastically simplify dev tools, their confgurations and perhaps the build systems too

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

По существу могу сказать, что саму задачу сборки можно выразить хоть на статическом, хоть на динамическом языке, но это не решит магически основную проблему - essential complexity самой предметной области. Она никуда не исчезнет, поэтому в лучшем случае можно решать задачу упрощения статических проверок билд скриптов, когда там опечатки или неправильные параметры у вызовов. Билд скрипты - обычные программы, дергающие внешние сервисы, и к ним применимы те же принципы. А из программирования мы знаем, что статические системы типов хоть и помогают в написании программ, однако не убирают магическим способом природную сложность предметных областей.

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

Лично я пока даже базовый синтаксис хаскеля не освоил:
пару дней убил рефакторя пару трёхстрочных тестов трёхстрочных функций от использования error к Either

...Но "луну" наблюдаю.

У меня тоже часто возникает ощущение, что меня никто не понимает. Вот когда я говорю, например, об архитектуре ПО в ФП или о фри монадах. Но когда я что-то утверждаю, у меня за плечами уже куча PoC готова, написан код, показана работоспособность идей

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

Мне кажется, что в этом чатике меня наконец поняли.

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

Полезные каждому первому, инфильтрованные ТК тулзы могут быть созданы не обязательно на хаскеле, можно и более суровый матан притащить

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

Я тоже за DSL.
Но по причинам гуманитарным.
Хотя программеры за "код", языков много - и проблема вавилонской башни налицо

Потому необходимо избежать перетягивания каната, ощущения несправедливости и изобретения велосипедов

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

Кстати, к вопросу об инструментах с более суровым матаном.

В хаскеле плоская модульная система.
А вот в powershell - модули вложенные (мало кто до этого дочитывается, и почти никто не использует)
Разработчики в MS когда-то хотели вообще избавиться от глобальной scope в пользу рутового модуля - но не осилили впарить это майкам

Где-то ещё в ФП такое есть?

Что вы понимаете под плоскостью системы модулей в Хаскеле? Там вполне себе можно делать иерархию модулей

Модули не будут вложены друг в друга в смысле текста, но будут иерархичны в смысле подчиненности