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

[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++.

[kika.livejournal.com]

Слово "соединить" выглядит очень дешевым только когда в ЖЖ трепешься :-) Как и "постараться".

[pzz.livejournal.com]

Жить вообще трудно :-)

[grundik.livejournal.com]

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

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

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

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


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

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

[kika.livejournal.com]

Меня не конкретно гуй на лиспе интересует, а вообще иллюстрация того что писание на немейнстримовых языках это luxury. Что стоит денег. Которые в той модели мира, из корневого поста, существуют только в виде зарплаты в кассе.

Изучение же языка может быть не таким сложным как изучение парадигмы. Тут уже кто-то писал на эту тему.

[grundik.livejournal.com]

> писание на немейнстримовых языках это luxury

В каких-то случаях - да, в других - это возможность решить задачу дешевле. Зависит от задачи.

> Изучение же языка может быть не таким сложным как изучение парадигмы

Чо это за программист такой, которому парадигмы сложно даются?

[kika.livejournal.com]

Кстати, писать игрушку на лиспе - самое милое дело. В типичной трехмерной игрушке есть два места приложения интеллекта в больших количествах - трехмерный движок (то есть собственно код, ответственный за отображение моделей на экране со всеми bells and whistles) и игровая логика, начиная от физической модели поведения объектов до имитации наличия интеллекта у NPC. И вот вся вторая часть пишется на лиспе только так. Прям как родная.

[grundik.livejournal.com]

Насколько я знаю геймдев, там голимый С++ с редкими вставками lua и python.
Почему ситуация именно такая - мне лично непонятно. По идее AI на лиспе писать удобнее, работу с деревьями - тем более. Однако ж C++.

[kika.livejournal.com]

Потому что мейнстрим. Потому же почему Viaweb был на лиспе, а Yahoo! Stores стал на перле и С++.
С плохо подходящим под задачу мейнстримовым языком есть шанс сильно не уложиться по срокам. А с хорошо подходящим немейнстримовым - не сделать никогда, завязнув в писании всяких обвязок и заполнении дыр, которые в мейстриме уже давно заполнены, причем зачастую самими вендорами средств разработки.

[grundik.livejournal.com]

Ситуации очень разные. silver bullet-ов не существует.

Повторюсь, что в моём случае если бы я выбрал не scheme а php (как меня пытались заставить), то я всё бы ещё не релизнул первую версию, а после релиза умер бы с поддержкой. И то, что сейчас для развития надо писать обвязки к c++-сным либам (ну вот неудачно я выбрал реализацию scheme, выбрал бы PLT или вообще common lisp - не было бы проблем) - это всё равно дешевле, чем могло бы быть в случае выбора чего-то другого мейнстримового (пусть даже java).

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

В реальности у коммерческих лиспов с библиотеками очень хорошо, и ffi там лёгкий и приятный (то есть позвать C++ из лиспа довольно легко).

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

[kika.livejournal.com]

"Я выбрал" - сколько вас там было в этом "Я"? Один человек? Я в одно рыло и на SSE2 ассемблере пишу.

FFI-то приятный, а вот как позвать лисп из С? Как включить модуль на лиспе в билд всего проекта?
Ну и кроме того, не в одном ffi дело, а дело больше именно в сдвиге парадигмы на границе двух миров. Разная работа с памятью, разное представление объектов, все разное. И реально на самом деле, при интеграции дешевле оставить их отдельно, связав каким-то протоколом, предполагающим явную сериализацию-десериализацию в приемлемый для всех формат. А это далеко не всегда feasible, как это по русски-то сказать.

[grundik.livejournal.com]

> "Я выбрал" - сколько вас там было в этом "Я"? Один человек?

Выбирал и писал framework - я один, сейчас на этом всём пишут порядка десяти, на момент выбора планировалось (и сейчас планируется) чтобы писали порядка сорока человек.

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

Ну а вообще насколько я знаю можно включить lisp в си, только я не знаю, как там с сигнатурами и прочей лебедой. Для guile есть неплохой мануал на эту тему. Также есть компиляторы из лиспа в си (или там в java, байткод jvm, байткод .Net и так далее).

[pzz.livejournal.com]

Насколько я знаю, в теории PM-ства считается, что ключевых людей вообще не должно быть

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

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

[grundik.livejournal.com]

> оно, правда, не всегда и требуется

Я бы даже сказал "почти никогда не требуется".

[lenik-terenin.livejournal.com]

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