аминь

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

хочется встать и помоится духу зависимых типов после такой тирады))

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

Тем более что это никакая не функциональная чистота, а банальная ошибка дизайна авторв языка, будем честны. Кложура и erlang самые что ни на есть функциональные языки, успешно используют дин. типизацию. Все (!) сат. типизированные js- заменители, подобные elm (typescript, scalajs, reasonml, gopherjs), успешно используют дин. типизацию для интеропа с js. Ни кому бы и в голову не пришло там городить огород с портами.

А чего опять так эмоционально? "Гореть в аду"... давайте дышать глубже и высказываться мягче, пожалуйста.

))

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

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

Я так понимаю, что ты как раз про JS, про коллбеки и белиберду отложенных вызовов. Интероп как раз складывает всё в корзину функции update и, собственно, список портов, поэтому аргумент про десятки мест для Elm не валиден.

Где я писал что технология не решает проблему? Можно спросить у зала, решает ли она их проблемы.

нет. если есть доступный js-объект в окружении, то я хочу иметь возможность вызывать его функции и дёргать свойства напрямую, а не через эффекты. Под белибердой я имел  ввиду последнее - мне нужно объявить порт, прописать для него Msg, изменить update и  subscribe. Я не хочу этого делать там, где в других языках можно обойтись одной строчкой loc.

== Где я писал что технология не решает проблему?

вот здесь - "А крахи JS-приложений Elm решать никогда и не вписывался."

Здесь уже был недовольный Elm-ом и его решениями человек, вбрасывающий ради того чтобы вбросить. Истина важна безусловно, но я теряюсь в логике твоих утверждений. Языки сделаны разными, Elm наиболее строгий из перечисленных (Хаскель строже, как я понимаю). И строгий он по определению, поэтому _насколько возможно_ JS изолирован, потому что его использование приводит к непредсказуемым последствиям в логике программы. Крах программы означает, что логика уже не работает.

я смотрю на хорошее, а полохое предпочитаю обходить стороной. поэтому использую elm  там, где он помогает, а не мешает.

Где он помогает в твоём случае? Поделись.

- маленькие изолированные компоненты react с вводом от UI и websocket-ом, который  в elm очень хорош.  

- WebGL -   Elm понимает текст шейдеров на GLSL и проверяет согласованность используемых типов между шейдерами и основной программой - уникальная и очень ценная опция.  Библиотека для  WebGL более высокоуровневая, чем в js

- vdom на гуманном языке (после jsx это особонно ценишь)

ну и просто elm помогает как-то развиваться и пощупать светлое будущее, в котормо нет webpack, npm и JS, а есть иммутабельность и чистые функции

== _насколько возможно_ JS изолирован

проясни пожалуйста что ты понимаешь под изолированностью в данном случае, если сам признал, что вызов js может привести к краху. Что -то вроде мешка с обезьяной с грантами?

Когда у тебя крашится приложение, в котором есть и elm, и js, ты с 99% уверенностью знаешь, что дело не в Elm

emacs