Ещё одно разочарование.

[thesz]

Для Хаскеля нет простых веб-фреймворков.

Вообще нет, совсем, никаких.

Это связано с тем, что все (ВСЕ!) веб-фреймворки используют WAI. WAI, Web Application Interface, представляет из себя библиотеку в 18 (примерно) каталогов, каждый из которых содержит по несколько исходных файлов

Comments

[highway99]

Ну вот нахера пытаться писать вебморды на Хаскеле? Когда-то бэкенды писали на С++ через CGI, но это не значит, что надо продолжать убиваться ап стену. Чем JS устраивает? Ну, или, там, Руби, Скала, Го, наконец. Да мало ли.

[thesz]

Прав буду я, конечно же. У меня ж опыта больше. Плюс, мы говорим о конкретном программисте - обо мне. Мой замер времени говорит, что типы и компилятор экономят время, по сравнению с тестами и отсутствием компилятора.

[mudasobwa]

С чего это вы решили, что у вас опыта больше?

[thesz]

Потому, что с высокой вероятностью у меня его больше.

Я старше большинства людей (мне 44), профессионально программирую с 18 лет, у меня опыт распространяется от микроконтроллеров на ассемблере до кластеров с CUDA, включая хранилище БД и документооборот на Оракле и захватывая компьютерное железо и разработку поддержки языков для описания этого железа.

[mudasobwa]

Ну ладно, меряние ж опытами показало примерное равенство (у меня нет железа, но зато есть всякие VAX/VMS, COBOL, embedded scripting, собственный алгоритм индексации поиска, медицинский софт и так далее.)

А анализ ж опыта показывает, что у вас его больше с жесткой типизацией, а у меня ровно наоборот. Поэтому нам удобно по-разному. Так что аргумент «я говорил про себя» рулит :)

[thesz]

Дорогой друг.

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

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

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

Вы это делаете?

[mudasobwa]

Разумеется. Любой более-менее опытный человек это делает. Причем, в любой профессии.

Я не записывал точную дату, но убежден, что начал так поступать задолго до 1998 года (ну, года на два раньше - точно). Мои ошибки (и, как следствие, критерии) могут:

а) отличаться от ваших, и
  б) приводить к иным практикам.

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

У нас аксиоматика разная, это просто понять, попробуйте.

[thesz]

Стоимость исправления ошибки пропорциональна времени между её внесением и обнаружением.

Это вывод, лежащий за практиками PSP/TSP и исследованиями, которые привели к этому выводу. Все они направлены на уменьшение этого времени.

Поэтому мои "аксиомы" стоят на выводах из многолетних научных исследований.

На чём стоят ваши?

[mudasobwa]

В реальном проекте стоимость исправления одной ошибки - критерий бессмысленный. Имеет смысл считать стоимость исправления всех ошибок.

Этот параметр, внезапно, пропорционален не только усредненному времени исправления ошибки, но и их количеству.

Далее. Как говаривал капитан Врунгель, всякая селедка - рыба, но не каждая рыба - селедка. Поэтому из верного тезиса «стоимость исправления ошибки пропорциональна времени между её внесением и обнаружением» никак не следует, что это ключевой параметр.

Вот простой пример. При создании автомобиля была допущена ошибка: на все деньги заказали квадратные колеса. Обнаружили мгновенно: не едет, гадина. Исправить невозможно.

Мои аксиомы высосаны из пальца.

[thesz]

"...количеству..."

И тут снова интересное - типы-то количество ошибок снижают! Количество тех ошибок, конечно, что вырвались за пределы рабочего времени разработчика. Для которых стоимость исправления становится резко выше.

"...из пальца..."

В общем, это видно. "Что-то такое" делали, но как-то не до конца, с другими практиками не сводили и так далее.

Можно ли вас попросить покинуть обсуждение?

[highway99]

Я же писал: "тру-JS программеры прекрасно обходятся без типов"
console.log(100 + "100") - говнокод, так индусы пишут, которые про cohesion не в курсе.
Тру программеры перепишут это так: console.log(100 + (+"100"))
Вообще, любая public-facing функция должна делать а) проверку/валидацию/трансформацию входных параметров и б) уже потом делать что-то полезное. Perl помните? Принцип tainted переменных? Вот я в точности про это говорю, только чуть шире.

[binf]

для ноды можно писать на TS со статической типизацией

[develop7]

typescript? это тот, в котором члены енумов успешно приравниваются к чиселкам?

[binf]

это который единственная замена js в не игрушечном продуктиве

[nivanych]

Для JavaScript/Node имеет смысл писать на PureScript.