The bad, the good and the Haskell

[kika]

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

ifp5 пишет:
Реально проблема есть только одна единственная (и она та же самая что препятствует использованию OCaml, Haskell, LISP и пр) - что решение выбора языка принимают люди (такие бывают толстые и важные начальники), которые уже решили, что проект будет на жабе. Никаких других проблем в использовании шарпа (или хаскеля) нет.

Ну это на самом деле далеко не так. Это черезвычайно распространенное мнение, которое на самом деле базируется на такой красивой гиковской картине мира, в которой есть good programmers and evil managers. И все плохое проистекает из менеджеров, а все хорошее пишется умными программистами, которые вникают в проблему с полувзгляда и выбирают идеальный инструмент.
Попробуйте написать полезную программу на лиспе и продать ее пользователям (продать в широком, хорошем, смысле - пусть даже и забесплатно). Чтобы она была как программа на С++/Win32 или там на сишарпе/дотнете. Чтобы у нее был гуй, какой модно в этом сезоне (совершенно необязательно, кстати, чтобы он был один в один стянут с последнего оффиса), чтобы у нее был нетворкинг, чтобы она работала с трехмерной графикой под DX9/10 и использовала многоядерные процессоры. По-моему я описал гамез, сам того не желая, ну да ладно. Пусть это будет не гамез, а САПР.

Ровно та же самая проблема у всех на свете "скриптовых языков, лучших чем Перл". Они все безусловно лучше чем Перл (трудно быть хуже с точки зрения среднего программиста), но у перла есть CPAN. End of story here.

P.S. Всех, кто напишет что у Автокада в пузе как раз лисп - сразу забаню. Настолько short minded тут не нужны :-)

Comments

в порядке флэйма :-)

[alexott.livejournal.com]

А как же Грэхэм?!!! :-)
Пользователи бывают разные - конечным пользователям наплевать на то, чем программа написана, корпоративным, обычно тоже не особо интересно.
почтовый Дозор-Джет, написанный на scheme, приносит достаточно хорошую прибыль соответствующей компании, сумма продаж - несколько миллионов зеленых рублей в год.
а с первым абзацем твоего утверждения с полностью согласен, это хорошая теория заговора против программистов :-)

Re: в порядке флэйма :-)

[kika.livejournal.com]

Вопрос не в точке зрения конечного юзера, а в точке зрения разработчика, который выбирает инструмент. А у него уже "все пути прописаны", в отличие от ендюзера.
Простейший пример: разработчик принимает решение писать на сишарпе/дотнете и естественно выбирает дотнет 3.0 ибо рулез и он его скачал через 1.5 часа после анонса, а до этого сидел на ворованных из мелкософта бетах.
Для конечного юзера же (которому, indeed, совершенно насрать какой это дотнет, 3.0, 33.0, 2.0 или вообще не дотнет) это выливается в сколько там, 30 мегабайт даунлоада или 20? Я думаю что консервативная оценка потери клиентов в этот момент это порядка 50%. А реалистичная - 70%.

Re: в порядке флэйма :-)

[alexott.livejournal.com]

а, ну это да, несомненно. инструмент должен быть адекватен требованиям

Re: в порядке флэйма :-)

[109.livejournal.com]

о да, инсталляционный дивидюк скачать, а за 20 мегабайт дотнета удавиться - это по-нашему. be real, что такое 20 мег в век web 2.0? (а если иррационально мыслящие клиенты таки планируются, бандлить донет вместе с продуктом, да и всё).

Re: в порядке флэйма :-)

[kika.livejournal.com]

Тем не менее это научно установленный факт, спросите любого шароварщика. Есть психологическая готовность клиента - если он качает условный фотошоп, то его 20-ю мегами не испугаешь. А когда записную книжку или инстант мессенджер, то он говорит "Еб твою маааать!" и жмет на Cancel.

[dottedmag.livejournal.com]

[зевая] А у питона есть CheeseShop. И?

[kika.livejournal.com]

s/CPAN/CheeseShop/g
s/Perl/Python/g

И?

[kika.livejournal.com]

Впрочем сырная лавка пока послабее сипана, но это и понятно и простительно с учетом возраста.

Re: Reply to your comment...

[dottedmag.livejournal.com]

Я к тому что не end of story, как это было лет пять назад (когда действительно, на уродском перле приходилось писать из-за отсутствия альтернатив), а можно уже выбирать.

[rblaze.livejournal.com]

Меня от использования даже Python останавливает простой факт: если людей с C++ даже на средненьком уровне хрен найдешь, то что же будет с менее популярными языками? А брать людей, для которых решающим фактором при выборе работы является "там пишут на плохом C/C++, а тут на хорошем oCalm" как-то страшно.

[grundik.livejournal.com]

Имхо это как раз основная причина выбора C++, а не OCaml :)
Когда задача позволяет брать не сильных программеров, то не имеет смысла брать сильных программеров.
А большинство задач позволяет-таки брать не сильных программеров.

PS: немного поясню, если непонятно моё мнение - для сильного программера язык важен чисто эстетически, но не практически. Питон изучается за месяц, а работают люди годами. Сам код (набор классов/функций/etc) является языком, изучить который в случае C++ может быть сложнее, чем весь питон как язык. Когда же сложность ещё и на уровне концепций/алгоритмов, то собственно язык вообще отходит на пятый план.

PPS: при прочих равных я выберу контору, в которой пишут на лиспе, просто мне так приятнее. Также я выберу контору, офис которой ближе к моему дому - мне тоже так приятнее. Почему меня страшно брать на работу?

[rblaze.livejournal.com]

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

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

[gaus.livejournal.com]

Питон изучается за месяц, а работают люди годами

...А лиспы изучаются за пару часов.

Боюсь, что это популярное заблуждение. У каждого языка свой набор идиом, cвой стиль, cвой way-of-doing-things. И он изучается постепенно, годами разработки. Правила шахмат можно объяснить за пару минут, научится играть умно - нужно очень долгое время (это не я придумал эту аналогию, я её стащил из sicp-a). Это косвенно связано с проблемой в заглавном посте. Найти гика, который за ночь зафанател от Хаскелла - нет проблем, найти человека, который глубоко понимает идиоматику Хаскелла - крайне сложная задача. И её решение имеет больше накладных раходов, чем предоставляет преимуществ более короткий код какого-нибудь квиксорта :)

[pzz.livejournal.com]

Когда задача позволяет брать не сильных программеров, то не имеет смысла брать сильных программеров.
А большинство задач позволяет-таки брать не сильных программеров

Как будто-бы есть выбор. Взать сильного программиста - удача. Набрать команду сильных программистов - большая удача.

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

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

[dmzlj.livejournal.com]

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

[grundik.livejournal.com]

Я пишу на scheme.
При этом у меня есть проекты и на питоне, и на C#, и на java, и на C++, и на PHP (о Боже!), и на perl, и на bash даже один :)

На каком языке решена проблема - пользователю глубоко насрать.

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

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


PS: http://www.franz.com/success/ - вот тут примеров есть.
PPS: не совсем САПР, но близко - http://www.izware.com/mirai/index.htm, также пример игрушки: http://en.wikipedia.org/wiki/Jak_and_Daxter. Что-то ищё искать лень, взял первое попавшееся.

[kika.livejournal.com]

Я знаю все эти ссылки, именно потому что на одной из своих предедущих работ втюхал народу лисп как язык реализации ядра системы (народ немного охуел по началу, но особо не сопротивлялся). И был бы у нас хороший лисповод, мы бы всерьез рассмотрели лисп в качестве языка для одного из ключевых компонентов нашего текущего проекта, больно уж он туда хорошо ложится.
Но как вы будете на лиспе писать гуй, который я пишу на Qt? И что мы будем делать, если вы таки напишете, а потом уйдете?
Гуманитарные вопросы...

[pzz.livejournal.com]

Но как вы будете на лиспе писать гуй, который я пишу на Qt? И что мы будем делать, если вы таки напишете, а потом уйдете?

Ну это, как раз, простой вопрос. Не надо писать гуй на лиспе, надо написать его на C++ (из-за Qt, а не ради самого C++), и соеденить с содержательной частью, написанной на лиспе. И постараться при этом, чтобы как можно меньше содержания просочилось в C++.

[grundik.livejournal.com]

Ну тут несколько вариантов:
* не писать гуй на лиспе, писать на другом языке
* сделать биндинги к qt и писать на лиспе
* писать не на qt, а на ltk (или что там есть - я тут не в курсе)
* не писать гуй вообще :)
* писать WebUI (на лиспе или не на лиспе)

По поводу "потом уйдёте".

Насколько я знаю, в теории PM-ства считается, что ключевых людей вообще не должно быть. На практике я не видел, чтобы ключевых людей не было (и я сам как PM не могу так построить процесс), но зато видел, как уход ключевого человека был безболезненный. Из моей команды уже уходили двое ключевых людей (причём одновременно) - ничего, не умерли (конечно, была просадка, но не смертельная).

Если я уйду, то у меня тут есть кадидаты на замену меня как схемера (на полную мою замену кандидатов нет, и быть не может - каждый ресурс уникален).


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

А хороших девелоперов сложно найти независимо от языка.

[lenik-terenin.livejournal.com]

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

[msh.livejournal.com]

Все хаскели и окамлы отпадают на этапе feasibility study. У нас есть проект, проживет он, скажем, 5 лет. В среднем программист работает 3 года, нам нужно за 5 лет значит нанять, скажем, 10 программистов на хаскеле, каждый с опытом коммерческого программирования хотя бы год, по цене близкой к средней по рынку.
Это возможно только если я университет или, скажем, IBM. Или вокруг 5 лет глухой рецессии

[xfyre.livejournal.com]

согласен, вопрос "кем это сопровождать даже если это взлетит" является ключевым при принятии решения :)

[dmzlj.livejournal.com]

у петона есть cheeseshop

Perl CPAN

[max-posedon.livejournal.com]

http://search.cpan.org/search?query=smtp&mode=all
Results 1 - 10 of 281 Found

Хвастать CPAN-ом, который есть следствие отсутвия нормального stdlib у языка - маразм. И ваши категоричные "End of story here" смешны.

Re: Perl CPAN

[kika.livejournal.com]

Это специально чтобы Вас повеселить. У меня развлекательный блог.