Oberon space
General Category => Общий раздел => Тема начата: Geniepro от Сентябрь 20, 2013, 12:19:06 pm
-
Haskell в продакте: Отчёт менеджера проекта (http://habrahabr.ru/post/193722/)
...
Продакт в коммерческом проекте — это не в маленькая песочница «для себя», не в академический эксперимент в области Computer Science. Это бесконечная борьба за «линию партии», когда вокруг ад, ужас и погибель, а оно всё равно должно рабоать. Int64 в XML-RPC кодируется строкой (потому что int'ы в XML-RPC signed int32), openssl при чтении нескольких сертификатов из файла читает только первый из них, в bool надо писать либо «1», либо «0», но иногда — «2», ибо только так придумали закодировать третий режим — и т.д. и т.п. В этих условиях требования к языку постепенно перерастают в требования к его экосистеме, инфраструктуре, готовности адаптироваться к реальному миру.
Я буду писать о Haskell с позиций product owner'а, менджера проекта, системного администратора, но никак не программиста. Так что не ожидайте от меня задушевных восторгов о том, как изящно через монадки можно сделать семигрупоид и как здорово выводить типы через типы с помощью типов.
С точки зрения менеджера проекта язык программирования оценивается по нескольким метрикам, совершенно отличными от программистских. Для программиста язык и его особенности — едва ли не самая важная вещь, так как именно с ним он проводит большую часть времени. Для остальных членов команды куда важнее происходящее за пределами исходного текста. Сначала это поиск библиотек и подходящих технологий, потом задачи сопровождения, мониторинга, внедрения и отладки.
...
-
Любимая цитата из текста:
Питон, как и любой другой динамически типизированный язык — это сплошная мина замедленного действия.
-
факт: пол-часа на сборку проекта. На весьма нехилом железе с кучей ядер и сверхбыстрой СХД снизу.
Привет С++! :-D
-
А мне эта цитата понравилась:
Это бесконечная борьба за «линию партии», когда вокруг ад, ужас и погибель, а оно всё равно должно работать.
-
А мне эта цитата понравилась:
Это бесконечная борьба за «линию партии», когда вокруг ад, ужас и погибель, а оно всё равно должно работать.
Ну, это стандартно в реальных проектах же. Оно должно заработать, даже если оно не может работать даже теоретически :-)
-
Haskell в продакте: Отчёт менеджера проекта (http://habrahabr.ru/post/193722/)
.....
ИМХО, как то не очень (убедительно и предметно)....
-
и еще , довольно вульгарный стиль изложения... я понимаю еще когда здесь в таком стиле "пиндосит" Логопет (от него другого и не ждешь), но писать подобным образом публикацию даже в харбр - не уважать себя.
-
факт: пол-часа на сборку проекта. На весьма нехилом железе с кучей ядер и сверхбыстрой СХД снизу.
Привет С++! :-D
Это у них была полная сборка проекта. У разработчиков быстрее компилировалось (не всё перекомпилировалось, и оптимизацию отключали).
Но действительно, GHC весьма нешустро компилирует, до оберонов или до дельф далеко...
-
и еще , довольно вульгарный стиль изложения... я понимаю еще когда здесь в таком стиле "пиндосит" Логопет (от него другого и не ждешь), но писать подобным образом публикацию даже в харбр - не уважать себя.
Не заметил явных вульгаризмов. Да на хабре так все кому не лень пишут, по-моему...
-
и еще , довольно вульгарный стиль изложения... я понимаю еще когда здесь в таком стиле "пиндосит" Логопет (от него другого и не ждешь), но писать подобным образом публикацию даже в харбр - не уважать себя.
Не заметил явных вульгаризмов. Да на хабре так все кому не лень пишут, по-моему...
плохо (что не заметили). По этому и его сравнивают с сборищем желающих самоутвердиться щеглов. Одно могу сказать - что в конторе в которой работает этот "менеджер" неплохие программеры.. коль скоро удалось перевести проект на Хаскель (тут, конечно, интересна подоплека этого решения), а вот о менеджерах этого я сказать не могу.
-
Одно могу сказать - что в конторе в которой работает этот "менеджер" неплохие программеры.. коль скоро удалось перевести проект на Хаскель (тут, конечно, интересна подоплека этого решения), а вот о менеджерах этого я сказать не могу.
Ну а на чём им ещё было решать свои низкоуровневые задачи?
Си/С++ не устроил из-за низкой надёжности.
JVM-языки -- из-за JVM.
Питон -- так же как и Си + JVM -- ненадёжность + виртуальная машина (хотя вроде есть же компилятор CPython), да ещё и многопоточности в питоне нет.
Всякие D они не стали рассматривать из-за их нестабильности.
Единственный конкурент -- Окамл, на котором, кстати, и был написан Xen, который они использовали в своём продукте. Непонятно, почему его не выбрали...
-
Про обероны они, возможно и не слышали, а почему не выбрали паскаль или аду -- тоже непонятно...
Просто были у них два программахера, хотевших кодить на хаскелле, вот и выбрали хаскель )))
-
Ну а на чём им ещё было решать свои низкоуровневые задачи?
а я (из статьи) ничего и не узнал про их проект...
-
факт: пол-часа на сборку проекта. На весьма нехилом железе с кучей ядер и сверхбыстрой СХД снизу.
Привет С++! :-D
Это у них была полная сборка проекта. У разработчиков быстрее компилировалось (не всё перекомпилировалось, и оптимизацию отключали).
Но действительно, GHC весьма нешустро компилирует, до оберонов или до дельф далеко...
Дык, вывод типов что в плюсах что в хаскеле - та самая штука которая сильно замедляет процесс компиляции. Поэтому тот же boost так ме-едленно компилится. И тут выпиливание препроцессора и переход на "модули" ну никак не поможет.
-
Просто были у них два программахера, хотевших кодить на хаскелле, вот и выбрали хаскель )))
если это верно + проект маленький, то верно с большой вероятностью мое предположение о фуфельности их менеджмента.
-
Одно могу сказать - что в конторе в которой работает этот "менеджер" неплохие программеры.. коль скоро удалось перевести проект на Хаскель (тут, конечно, интересна подоплека этого решения), а вот о менеджерах этого я сказать не могу.
Ну а на чём им ещё было решать свои низкоуровневые задачи?
Задачи у них были, насколько я понял, вполне высокоуровневые. Впрочем, я вообще слабо понимаю различие между высокоуровневой и низкоуровневой задачей. А вот решение одной и той же задачи, вполне может быть как низкоуровневым, так и высокоуровневым (первая в терминах машины (не важно что это за машина - реальная, или виртуальная, имеративная или функциональная), вторая - в терминах задачи).
Да, а выбрали хаскель не потому, что все остальное такое кривое и не надежное (тот же С++), а просто потому, что программерам хаскеля захотелось :-)
И да, ощущения от хаскеля мои личные вполне соответствуют тому что описано в статье. Поэтому я от него отказался в пользу С++ и некоторых других языков.
-
Но действительно, GHC весьма нешустро компилирует, до оберонов или до дельф далеко...
Дык, вывод типов что в плюсах что в хаскеле - та самая штука которая сильно замедляет процесс компиляции. Поэтому тот же boost так ме-едленно компилится. И тут выпиливание препроцессора и переход на "модули" ну никак не поможет.
Вывод типов тут ни причём. Там в комментах уточнялось, что половину времени занимает компиляция одного модуля с шаблонами Template Haskell, а это в GHC нешустро работает.
Остальное время, видимо, занимает оптимизация сгенерированного кода, анализ строгости и всё такое.
Типы же выводятся (кроме случая с шаблонами) практически мгновенно. Ну, если не увлекаться зависимыми типами с вычислениями на типах. Но это уже не стандартный хаскелл (как и шаблоны)...
-
Ну а на чём им ещё было решать свои низкоуровневые задачи?
а я (из статьи) ничего и не узнал про их проект...
Как я понял, что-то связанное с виртуальными машинами для серверов приложений, какие-то облачные сервера:
http://cloud.selectel.ru/
http://habrahabr.ru/company/selectel/
Не знаю насчёт размеров их приложений, но в одной из предыдущих статей (http://habrahabr.ru/post/189530/) этого amarao упоминалось про 300 модулей на хаскелле и ещё 300 файлов на coffee-script, хотя, может, это и не этот проект...