Всем привет. Как поживаешь, /development/ ЛОРа? Давно не писал, но мое внимание привлекла одна проблема (присущая, вообще говоря, не только ЛОРу, но на ЛОРе проявляющаяся ярче всего). Речь пойдет о пресловутом «enterprise» (иногда в юмористическом написании «enterpriZe», «ынтырпрайз» и так далее).
В том, что «enterprise» стал на ЛОРе эдаким жупелом, смоляным чучелом — ничего странного и страшного нет. У неспециалистов это слово в первую очередь ассоциируется с корпоративным, капиталистическим, пиджачно-галстучно-кофеварочным. А отрицание корпоративного — очень в духе современной молодежи, чей природный нонконформизм требует реализации. Но это не есть предмет сегодняшней беседы; оставим юношеский нонконформизм социологам и психологам.
Проблема в том, что сам технический термин «enterprise-технологии» часто трактуется неверно. Распространено множество дилетантских интерпретаций (например, «ынтерпрайз ≡ copy-paste» и так далее). Как человеку, не один десяток лет проведшему в пресловутом «enteprise», мне хотелось бы расставить точки над «i».
Итак, ПО и технологии уровня предприятия («enterprise software») характеризуются в первую очередь повышенными нефункциональными требованиями (non-functional requirements, NFR). Что это означает? NFR относятся к работе системы, а не к её специфическому поведению (которое описывается функциональными требованиями). Рассмотрим типичные NFR:
- производительность (performance);
- масштабируемость (scalability);
- доступность (availability);
- надежность (reliability);
- безопасность (security);
- расширяемость (extensibility);
- управляемость кода (maintainability);
- управляемость системы (manageability)
и так далее. По этим признакам определенные технологии и языки программирования могут быть отнесены к «enterprise» или «non-enterprise». Например:
- Java-технологии специально разрабатывались как enterprise и максимально удовлетворяют перечисленным NFR;
- у языка Си отличная производительность, но отсутствует ООП, отсюда проблемы с абстракциями, управляемостью и расширяемостью. Плюс прямая работа с памятью и проблемы безопасности;
- C++ предоставляет ООП, но не решает проблем с безопасностью;
- Python и Ruby обладают хорошим ООП, но, не имея качественных JIT-компиляторов, сильно проигрывают по производительности. См. историю с Твиттером и Ruby vs. Scala;
- Haskell имеет немасштабирующийся GC; функциональный подход не дает таких возможностей для decoupling'а и модуляризации, как ООП. Следствие — неуправляемый и плохо расширяемый код;
- Лиспы имеют целый букет проблем, начиная от производительности, проходя через масштабируемость и заканчивая управляемостью.
Разумеется, такое деление «enterprise / non-enterprise» в известной степени условно. Например, можно и на Java нагородить неуправляемой, немасштабируемой и дырявой лапши. С другой стороны, наверное, можно и в рамках лиспа придерживаться строгой модуляризации, а коммерческие реализации дадут хорошую производительность и масштабируемость. Однако, такой подход не принят в лисп-среде (там приняты шестиуровневые квазицитирования), и подобный код будет считаться «non-lispy crap».
Более подробно эту тему я собираюсь осветить в своем блоге. А засим желаю всем быть точными в терминах, а технологии выбирать по их объективным достоинствам/недостаткам, а не руководствуясь нонконформизмом или модными трендами.
С пламенным приветом,
ваш Кукинштейн
