Вползающий карго-культ

[metaclass]

Ждевелоп написал очередной пост из серии "как на самом деле все происходит в ИТ" с привлечением меня в качестве отрицательного примера: http://jdevelop.livejournal.com/2067575.html
Парадоксально, но факт - метаклассы аутисты, даже будь они сто тыщ раз основа основ компании - в результате замыкают все на себя, и если они на более-менее ключевой позиции - то разработка превращается в карго-культ правил, которые остальные не понимают, а глава секты не считает нужным пояснить/написать/обсудить.

В данном случае, он прав, потому что я не умею объяснить некоторые вещи коллегам и разработка кое-где превратилась в натуральный карго-культ. Причина в том, что в силу ограниченности ресурсов, меня хватает только на то, чтобы "натянуть кложурь/F# на firebird/postgresql/mssql" из-за чего некоторые архитектурные решения и их причины остаются задокументированными только в виде заметок в таск-трекере. Ну скажем, я сейчас одновременно делаю 4 проекта, из которых два коробочных, и единственный способ при этом не сойти с ума - это делать их на общей кодовой базе, что налагает на нее некоторые ограничения, которые не очевидны коллегам, не видящим всей картины в целом.

Второй аспект, который лично мне не совсем очевиден до сих пор - это степень моей личной вины в разного рода нетривиальной херне, накопившейся за 15 лет работы. Кое-где причина заведомо в том, что я не умел в общепринятые инструменты (один проект, существующий с 1997 года, использует совершенно невменяемый велосипедный фреймворк, разработанный в припадке идиотизма и только сейчас дошли руки это наконец-то заменить на нормальный код, благо с тех пор появились интернеты, нормальные сервера и сети у клиентов).
Но вот конкретно текущая ситуация с несколькими проектами на двух работах, использующими общую кодовую базу и разного рода нетривиальные кодогенераторы и F# с кложурью - с ней не очевидно. С какой стороны я на это не посмотрю, альтернатива была только одна - упростить все в несколько раз, отказаться от мысли запустить где-то кроме винды, использовать только Firebird, снизить количество проектов до одного, убрать кодогенераторы и отказаться от повторного использования кода. Из плохого для конторы и клиентов тут только снижение эффективности/скорости работы, т.к. F#/clojure/метапрограммирование с кодогенераторами все-таки сильно упрощают разработку.

Comments

[juan-gandhi.livejournal.com]

Альтернативой кодогенератору может быть только интерпретация. (Я ничего не предлагаю, просто философствую.)

[gds.livejournal.com]

пробовали, гадость редкостная. Именно поэтому я сейчас делаю что-то типа ruby on rails, но без руби, а с окамлом и кодогенерацией.

[ng67.livejournal.com]

Вы просто не умеете их готовить.
Поверьте...

[gds.livejournal.com]

умею, но не люблю.

[gds.livejournal.com]

хотя, учитывая "_их_ готовить", я мог слишком общо выразиться в каменте выше. Рельсы я люблю, концепции вполне грамотные, за некоторыми исключениями, да и детали реализации в большинстве случаев устраивают. А вот к руби отношусь с презрением, оттого и общее отношение к руби-рельсам, такое вот.

[permea-kra.livejournal.com]

*праздно*
yesod чем не подходит?

[gds.livejournal.com]

х-ем.

[permea-kra.livejournal.com]

Эм...
А чем плх х-ль? Он, имхо, более живой, чем *ml.

[gds.livejournal.com]

много чем плох, не буду вдаваться в подробности тут.

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

[permea-kra.livejournal.com]

Ну на *ML их и вовсе ни одной нет, если что.

[gds.livejournal.com]

https://github.com/camlunity/kamlo_wiki/blob/master/RealWorld.md#end-user-software
Недавно и 0install переписали на камло, грят малаца.
Ещё с десяток игрушек для мобил (не помню, яблоки или андроиды).
Вот это -- для пользователей. И оно бодро шевелится.

[berezovsky.livejournal.com]

Игрушки для мобил. Для пользователей.

[permea-kra.livejournal.com]

В сравнении с
www.haskell.org/haskellwiki/Haskell_in_industry
не впечатляет. Кроме того, компилятор х-ля живой, в отличии от дохлых *ml-ей

[gds.livejournal.com]

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

А про компилятор окамла -- changelog'и для того и придуманы, чтобы их читать, а не газировать лужу вместо этого.

[permea-kra.livejournal.com]

>Пользовательский софт -- гораздо более практичный критерий оценки того, подходит ли язык для написания чего-то реального.

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

[gds.livejournal.com]

я изначально предлагал оценивать по критерию "Предлагаю оценивать то, насколько живо работают реальные программы, сделанные для людей.", это уже потом мы перешли к обсуждению количества живых программ. Так вот, программы, сделанные для конечных пользователей, из этих трёх языков замечены только в питоне. Это мог бы быть приличный выбор, но "чтобы шевелилось" -- не единственный критерий.
Если же брать чуть шире, и рассматривать область, в которой я собираюсь применять окамл, то там эти языки шевелятся плохо. Например, рубисты часто хвалятся цифрами "100000 запросов в сутки" -- ну просто обосраться! А когда реальный RPS становится больше 50 -- так всё, хайлоад нах. Конечно, меня это не устроило.
Ещё одна проблема -- сейчас часто становится удобным и выгодным хостинг на виртуальных серверах, где платят за используемые память и процессор. Поэтому мне интересно сделать решение, оптимальное для этого применения. А х-ь тут неоптимален -- и памяти жрёт достаточно (причём утечки нередки, и попробуй отлови их в продакшоне -- это не эрланг, всё-таки, к которому можно на живую подключиться и посмотреть), и с использованием процессора не всё хорошо, если брать типично-ленивый подход к решению задач. Да, конечно, можно было бы это сначала написать, потом долго оптимизировать, обмазываться аннотациями строгости, но зачем, если можно сразу писать без лентяйки, и оно сразу будет работать весьма быстро? По критерию "чтобы шевелилось быстро" для задачи подходят разве что C, C++ и OCaml.

[permea-kra.livejournal.com]

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

Затем, что надо изобретать кучу библиотек с нуля, а нормальным людям это лень? Ну и кодовую базу самому поддерживать надо.

Конкретно в yesod из критических мест лентяйка уже убрана - там используются iteratee's в таких местах.

[gds.livejournal.com]

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

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

Ещё не понравилось, что в yesod, что в окамловском ocsigen -- ебанутость на типизации html, sql и прочего, до чего только руки дотянутся, причём средствами templatehaskell и camlp4 соответственно. Во-первых, там слишком строгая типизация не нужна, и уж точно не стоит описывать html прямо в исходниках, а sql конструировать из orm-подобных описаний. Во-вторых, синтаксические расширения, согласно моему опыту, гораздо сложнее отлаживать, если что-то идёт не так. А оно часто идёт.

[juan-gandhi.livejournal.com]

Пробовали, удобно.

[zelanton.livejournal.com]

какой-то велосипед?

[gds.livejournal.com]

ага, примерно такой же, как рельсы в 2003г.