Просуммирую опыт.
Современное состояние дел с программированием на Haskell чрезвычайно и требует скорейшего вмешательства высших сил.
Наличие cabal файлов и составление проектов из них, вкупе с текущей реализацией самого cabal, делает невозможным программирование с исследованием (exploratory programming). Потому, что вы, сделав cabal (new-)repl в текущем проекте, не можете простым образом загрузить файл из проекта, который использован в зависимостях вашего проекта.
В переводе на русский, если ваш проект содержит ссылку на проект abanamat с Control.Abanamat, который использует Funck.Russian из проекта funcking-i18n, то вы не можете выполнить ":m Funck.Russian" напрямую - надо переходить в другой проект. Таким образом, для понимания работы требуется больше движений, чем надо.
Так же, cabal местами чрезвычайно "последовательный". Из недавнего - я ждал порядка 15 минут окончания выполнения тестов happy, а ещё через некоторое время - окончание тестов alex, тоже заметные минуты. В это время ничего не собиралось. Ну, и даже на ноутбуке с 16Г памяти надо ограничивать параллельность оного кабала - иначе вы в обязательном порядке напоритесь на работу нескольких сборщиков (ld - он долгий!) одновременно, что вызовет откачку памяти и неработоспособность системы в целом. Приятная такая вишенка на торте.
Теперь перейдём к определению зависимостей внутри пакетов. На самом деле никого не интересует, какая версия у пакета. Интересна функциональность. Есть ли у функции sdL из пакета butic второй параметр с типом Zefirity, или нет? А что, если в версии 0.1 он был, потом, в версиях с 0.2.3 до 183.7.15.144 включительно его не было, а в версии 192.6 он снова появился? Надо ли мне ограничивать версии пакетов с помощью связей вида butic >= 192.6 || butic < 0.2.3? Или мне надо указать, что в sdL второй параметр должен иметь тип Zefirity? Или, вообще, "вот такой тест должен выполняться".
Я очень странно себя чувствую. Вроде бы, по всем ощущениям не Хаскель начала 2000-х, но, почему-то, я всё равно продуктивен. Но от ощущения "я мог бы и больше" избавиться не удаётся.
Наличие cabal файлов и составление проектов из них, вкупе с текущей реализацией самого cabal, делает невозможным программирование с исследованием (exploratory programming). Потому, что вы, сделав cabal (new-)repl в текущем проекте, не можете простым образом загрузить файл из проекта, который использован в зависимостях вашего проекта.
В переводе на русский, если ваш проект содержит ссылку на проект abanamat с Control.Abanamat, который использует Funck.Russian из проекта funcking-i18n, то вы не можете выполнить ":m Funck.Russian" напрямую - надо переходить в другой проект. Таким образом, для понимания работы требуется больше движений, чем надо.
Так же, cabal местами чрезвычайно "последовательный". Из недавнего - я ждал порядка 15 минут окончания выполнения тестов happy, а ещё через некоторое время - окончание тестов alex, тоже заметные минуты. В это время ничего не собиралось. Ну, и даже на ноутбуке с 16Г памяти надо ограничивать параллельность оного кабала - иначе вы в обязательном порядке напоритесь на работу нескольких сборщиков (ld - он долгий!) одновременно, что вызовет откачку памяти и неработоспособность системы в целом. Приятная такая вишенка на торте.
Теперь перейдём к определению зависимостей внутри пакетов. На самом деле никого не интересует, какая версия у пакета. Интересна функциональность. Есть ли у функции sdL из пакета butic второй параметр с типом Zefirity, или нет? А что, если в версии 0.1 он был, потом, в версиях с 0.2.3 до 183.7.15.144 включительно его не было, а в версии 192.6 он снова появился? Надо ли мне ограничивать версии пакетов с помощью связей вида butic >= 192.6 || butic < 0.2.3? Или мне надо указать, что в sdL второй параметр должен иметь тип Zefirity? Или, вообще, "вот такой тест должен выполняться".
Я очень странно себя чувствую. Вроде бы, по всем ощущениям не Хаскель начала 2000-х, но, почему-то, я всё равно продуктивен. Но от ощущения "я мог бы и больше" избавиться не удаётся.