Эрланг-шытсторм

[metaclass]

http://jamhed.livejournal.com/237948.html
http://jamhed.livejournal.com/239564.html
http://jamhed.livejournal.com/240154.html

http://maxim.livejournal.com/468313.html

Знаете, что самое раздражающее в этих срачах? Что инженерных/технических и прочих строгих методов различить кто прав и кто не прав в этом - нету.
Я уверен, что при достаточных скиллах будут работать оба решения - что горы велосипедов марки NIH, что усиленная ебля с чужим "готовым" кодом в заставлении его работать как положено.

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

Comments

[jamhed.livejournal.com]

Вот erlang как язык провоцирующий конкурентность определяет структурирование программы определенным образом. За долгие годы эти определенные образы были выписаны отдельно и получили название OTP. Почему надо пользоваться OTP а не изобретать собственные реализации gen_fsm, gen_event и message queue? Потому что за те же долгие годы абстракции OTP были неоднократно отлажены и документированы. Однако вне всякого сомнения склонность изобрести такие велосипеды есть и будет, т.к. с виду всё выглядит просто: PID ! MSG, и не надо gen_server. После чего начнется отладка, хождение по граблям и самодельная кривая реализация gen_server. Понятно что работать будут оба решения, in the long run. Вопрос в том зачем заказчику оплачивать самодельные реализации стандартных библиотек?

[tzirechnoy.livejournal.com]

>эти определенные образы были выписаны отдельно и получили название OTP.

Что Вы несёте?

[jamhed.livejournal.com]

Вопрос несколько не понятен.

[raydac.livejournal.com]

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

[blackyblack.livejournal.com]

Тут вопрос скорее стоит так: зачем заказчику оплачивать переделку на стандартные библиотеки, если in the long run будет работать и так?
Надо в общем от денежных затрат плясать, а не от перфекционизма отдельно взятых товарищей. Если Максим врёт, что он всё сделал за месяц и сэкономил тучу денег, то его косяк. Если заказчик врёт, что потратили тучу бабла и человеко-лет, то косяк заказчика.

[jamhed.livejournal.com]

> зачем заказчику оплачивать переделку на стандартные библиотеки,

Потому что стандартные библиотеки:
1. документированы
2. отлажены
3. не захламляют логику приложения

От чего in the long run стоимость поддержки, отладки и внесения изменений сокращается.

> Если заказчик врёт, что потратили тучу бабла и человеко-лет, то косяк заказчика.

То, что этот проект "развивается" с 2010 года -- объективная реальность, равно как и то что Максим непосредственно там участвовал в период с начала 2012 года (может и раньше, у меня данных нет) по середину 2014. Могут 3 года ужаться до одного человеко-месяца? В принципе могут.

[gineer.livejournal.com]

\\Могут 3 года ужаться до одного человеко-месяца? В принципе могут.

Really? %))

[jamhed.livejournal.com]

Ну а что такого. Объективных оценок производительности программиста не существует же. Тем более если OTP переписывать.

[gineer.livejournal.com]

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

Что особо прикольно, в корреляции с недавней похвальбой Максима про 30 млн. пользователей и 20 млрд. $ транзакций (получается меньше 1000 на лоб)... %)))

[bydlorus.livejournal.com]

У меня только один вопрос, 6 лет для онлайн-покера не многовато ли? И если да, то кто тут виноват - заказчик или erlang?

[porter333.livejournal.com]

заказчик, вестимо. Слишком богатый

[jamhed.livejournal.com]

Я бы сказал организация процесса. Ну плюс попытки запроектировать scalability и concurrency сильно до того, как это вообще могло бы понадобиться.

[thedeemon.livejournal.com]

Это ж было про другой проект - в банке.

[porter333.livejournal.com]

> Если Максим врёт, что он всё сделал за месяц

мнээ, ну сотрудничество с турками не один год продолжалось. У них даже на какой-то момент деньги кончились.

[anonim-legion.livejournal.com]

> будет работать и так?

Не будет. Есть стоимость поддержки, и она ниже для стандартных решений (в офисе - Винда), чем для самодеятельности (в офисе - Линуксы, см. анекдот про секретаршу-линуксоида, "отмонтировать забыла!").

[blackyblack.livejournal.com]

Замена gen_server на gen_fsm - это капля в море стоимости поддержки. В 99% случаев достаточно изолировать проблемный модуль за фиксированным API и не тратить время и деньги (и не сраться с предыдущими кодерами, никто не совершенен).

[vit-r.livejournal.com]

Насколько понимаю, до недавнего времени с документацией OTP были дикие проблемы в смысле ответа на вопрос "зачем"?

[volodymir-k.livejournal.com]

В 90-х практически вся документация так писалась
"для старта кракрумблям-сервера вызывайте следующий вызов с такими параметрами: ...", а зачем -- читайте IRC / NNTP

[vit-r.livejournal.com]

Вот потому мы и находимся там, где находимся.

[gineer.livejournal.com]

+1

И в этом контексте интересны признания людей в том сто они не любят онтологии. ;)
http://ivan-gandhi.livejournal.com/3481184.html?thread=56884832#t56884832

[anonim-legion.livejournal.com]

Я очень редко встречал документацию, где на этот вопрос имелся бы ответ.

[vit-r.livejournal.com]

Сейчас по OTP есть приличная книжка.

[dmitriid.livejournal.com]

В документации с незапамятных времен шел OTP Design Principles User Guide, где пусть и кратко, но описано, что и зачем

[vit-r.livejournal.com]

Хреново там было описано, когда я это читал. Сейчас - не знаю.

[cottidianus.livejournal.com]

отлично написано