Про ёжика в тумане, зазнайство, языки программирования и вериги

[vit_r]

Там были авгиевы конюшни на 5 строк.

nponeccop тут

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

Comments

Про ФП

[livejournal.livejournal.com]

User gineer referenced to your post from Про ФП (http://gineer.livejournal.com/1651163.html) saying: [...] Originally posted by at Про ёжика в тумане, зазнайство, языки программирования и вериги [...]

[alll]

Ну а потом кто-то будет эти пять строк поддерживать под бодрые стимуляции со стороны менеджмента "да ты чо так долго, там кода всего ничего". :)

[vit-r.livejournal.com]

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

Если почитать описание, хорошо видно, что написано оно не на человеческом языке, и перевести его язык, понятный людям, нет никакой возможности.

[mehanizator.livejournal.com]

отлично!

[cross-join.livejournal.com]

Верните Пролог, гады!

[thedeemon.livejournal.com]

http://lambda-the-ultimate.org/node/112

[metaclass.livejournal.com]

Аналогичная хрень в каком-нибудь GCC или csc будет занимать десяток файлов по 100-1000 строк, густо пересыпанных нечитабельными комментариями в стиле "2+2=4".
Лучше уж авгиевы конюшни на хаскеле - они на экран и в голову помещаются, хотя бы.

[vit-r.livejournal.com]

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

[vit-r.livejournal.com]

густо пересыпанных нечитабельными комментариями в стиле "2+2=4".

Ну сказки-то не надо рассказывать.

Лучше уж авгиевы конюшни на хаскеле - они на экран и в голову помещаются, хотя бы.

Правило номер ноль: ничего не должно помещаться в голове. Всё должно быть на бумаге. А с Хаскеля надо не просто раззиповывать запись, но ещё и расшифровывать код.

[rdia.livejournal.com]

Звучит хорошо. Сразу вспоминается "программа на перле" и прочие творения сумрачного гения обфускации.

[vit-r.livejournal.com]

На Перле есть пути писать хорошо, красиво и понятно. А тут - нет.

[binf.livejournal.com]

== ничего не должно помещаться в голове

не надо думать. надо КОДИТЬ. вот это я понимаю, грамотное управление разработкой!

[vit-r.livejournal.com]

Думать надо тогда, когда надо думать. А не решать головоломки вместо работы.

Чтобы уж совсем понятно. Сейчас на три страницы кода до пяти имён, обозначающих одно и то же.

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

[binf.livejournal.com]

"на три страницы кода до пяти имён, обозначающих одно и то же" - это какая то особенность хаскеля?? если да, то это косяк. В хаскеле для дублирования имён принято просто добавлять символ ' к имени

[binf.livejournal.com]

Это проблема, да. в основном потому, что мало менеджеров, знающих хаскель и умеющих вычислить говнокод как они это делают в джаве. Некому пнуть головастика, вот он и изгаляется. На хаскеле очень легко писать ясный и простой код, без уродства

[ext_1684112 (from livejournal.com)]

>менеджеры ходят на цыпочках и говорят шёпотом.

Какая хорошая практика.

[vit-r.livejournal.com]

Если бы было легко, все бы давым-давно на нём писали.

[vit-r.livejournal.com]

Это про реальный рабочий проект и зрелый код. То есть тот, который в работе уже лет двадцать.

Хаскель - это для развлечений. Лучше всего, индивидуальных.

[rdia.livejournal.com]

Всегда есть путь писать хорошо, красиво и понятно. Даже на Хаскелле.

[vit-r.livejournal.com]

Нет, конечно.

Чтобы писать в промышленном стиле на Хаскеле, надо выкинуть Хаскель и взять другой язык.

[deadzay4ik.livejournal.com]

Так за 20 лет хаскель стал другим. Надо свежий код смотреть.
Например Зефирова. Ну и он вроде на C# соскочил, видимо в хаскеле типизация еще не дошла до уровня "продакшен" языков.

[binf.livejournal.com]

На c++ или джаве что ли легко? но на них пишут

[binf.livejournal.com]

вас не правильно информировали (http://dimchansky.github.io/posts/2014/11/05/haskell-real-life-use/)

[vit-r.livejournal.com]

Эту ссылку мне кидают уже раз сотый. Да и выглядит он убого.

Там принципиальные проблемы для промышленного использования, которые я объяснять не буду. А систему рабочую можно написать хоть на ассемблере, хоть на Бейсике, если есть бюджет.

[vit-r.livejournal.com]

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

[binf.livejournal.com]

Паттерны ООп проще чем теория категорий (про с++ я вообще молчу)? ну ок, не буду спорить

== для Жабы, правда, пришлось создавать толпу тулов и библиотек

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

[vit-r.livejournal.com]

Паттерны ООп проще чем теория категорий

Скажу прямо, для меня сама постановка вопроса звучит как бред.

когда нам надо было распарсить на джаве грамматику,

Для каждой задачи надо брать подходящий инструмент, а не забивать отвёрткой гвозди.

[pappadeux.livejournal.com]

ANTLR?

[binf.livejournal.com]

Хорошо для компиляторов или организации протоколов например, там где нужна эффективность. Мне не нужна, у меня язык описания трейдерских триггеров. Но нужна простота, гибкость и статический контроль выражений. Это как раз особенность Parsec - комбинация микропарсеров, проще этого нет ничего.