[prog.flame] И вот для этого стоило осваивать Хаскелл?

Люди сообщают с мест:

Компания называется Restaumatic, Польша. Пишем сервисы для ресторанов: заказ еды, системы скидок, сайты, вот это вот все. Обычный web, CRUD, фронтенд на PureScript, бэкенд на Haskell. На самом деле, переписываем потихоньку эту функциональность с RoR и добавляем новую.

Цинк: cpp_stm_free: монадическая STM библиотека для параллельного программирования.

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

Мне, например, нравится использовать C++ в вещах, связанных с низким или более-менее низким уровнем. Протоколы какие-нибудь реализовывать, устройствами какими-нибудь управлять, писать ядра СУБД или MQ-брокеров, ресурсы экономить (выжимать тактики из битиков, как кто-то когда-то хорошо сказал). Но это прежде всего потому, что сами эти задачи мне нравятся. А C++ оказался весьма хорошо приспособлен для таких задач.

Но вот формошлепство, складской учет и пр. скучные для меня самого задачи, не нравятся мне в принципе. Заниматься такими вещами, конечно, можно. И что-то подобное бывало в прошлом, когда времена были трудными и аутсорсеры в наших местах еще только-только начинали появляться, а внутренний рынок разработки ПО стремительно схлопывался. Но это не от хорошей жизни. И заманить меня на разработку подобного рода софта в нормальных условиях вряд ли возможно. Тем более обещанием того, что в проекте будет использоваться любимый язык программирования.

А тут Web-приложение с бэкэндом на Хаскелле, которое суть складской учет, который во времена оные отлично покрывали dBase-ами и Clipper-ами... Нужно, наверное, очень сильно любить Хаскелл ;)

PS. Интересно было бы лет через 5-10 узнать, чем все закончилось. А то вспоминается пример Sociomantic-а, в котором когда-то выбрали в качестве языка реализации D1, а потом столкнулись с тем, что есть большая и работающая кодовая база на D1, который уже никому не нужен, и есть совсем другой D2, который с D1 не совместим ни на уровне языка, ни на уровне библиотек. Но там хотя бы выбор шустрого D был оправдан требованиями к скорости реакции. Ради чего выбирать Хаскелл для рядового Web-приложения -- это вопрос.