http://www.rusdoc.ru/articles/pochemu_korporatsii_nenavidjat_perl/17636/
---
Дейв Кросс, разработчик и журналист на технологические темы, всю жизнь создавал корпоративные системы на Perl, посетил вышеупомянутую конференцию, где побеседовал с представителями компаний. Он пишет в блоге O’Reilly ONLamp, что и сам мог бы заявиться на следующий год с докладом на тему «Почему корпорации ненавидят Perl». Это действительно несправедливо, считает Кросс.
Дейв Кросс не волнуется за своё собственное будущее как программиста, потому что до самой пенсии может быть обеспечен работой, поддерживая множество уже созданных систем. Однако факт в том, что многие крупные компании сейчас отказываются от Perl’а и собираются переписывать всё на Java + PHP.
В настоящее время сами разработчики веб-систем явно начинают относиться к Perl’у как к некому технологически устаревшему артефакту и в целом говорят о нём пренебрежительно. Такое настроение передаётся заказчикам, которые не разбираются в технологиях, однако теперь сразу начинают беспокоиться, едва услышав слово “perl”. Им не нужны «устаревшие» решения, они хотят красивые системы на новых технологиях.
Дейв Кросс признаёт, что за десять лет у компаний скопилось очень много некачественно написанного кода на Perl. Но его низкое качество не объясняется технологическим несовершенством самого Perl’а, а совершенно иными причинами. На самом деле разработчики трудились в условиях, когда качество не являлось главным приоритетом. Многие проекты были первыми шагами компаний в области веб-разработки. Естественно, что качество проектов не было на высоте. Созданные отдельными подразделениями, эти системы часто даже не могли обмениваться информацией друг с другом. Неудивительно, что поддержка этого кода сейчас представляет собой трудную задачу.
С другой стороны, есть множество примеров, когда современная система создаётся на Perl, и она отлично проявляет себя: её легко поддерживать и дорабатывать. Здесь Perl не уступает ни одному новомодному языку.
Определённо, у компаний скопилось много кода, который нужно переписать в течение ближайших нескольких лет. Однако переход при этом на новые языки — это уж слишком радикальная мера. Руководители обвиняют Perl в тех проблемах, которые на самом деле объясняются ошибками менеджмента и неправильным подходом к разработке.
Десять-двенадцать лет назад почти все мы создавали приложения на Perl и все мы делали ошибки. Теперь нам приходится исправлять эти ошибки. Но за эти годы мы стали более опытными и теперь можем переписать системы с учётом всего того чему научились за эти годы, пишет Дейв Кросс.
---
Конечно, я не
Конечно, я не Дейв Кросс, но свое мнение на этот счет имею. Компании, особенно сверху, совершенно все равно, на чем будет написано приложение. Важен результат. Вы можете сложить его из кубиков Lego, если знаете волшебные слова, позволяющие заставить их работать. Решение об использовании того или иного языка принимает не коммерческий директор или акционеры, ничего не понимающие в IT. Есть тех отдел. И тут уже возможны варианты.
Если люди сидят грамотные, они взвесят все pro и contra и примут решение об использовании того или иного языка программирования. В зависимости от решаемых задач это может быть и не Perl:)(об этом дальше)
Вторая категория людей - узколобые выскочки, обладающие узкими или крайне небольшими познаниями в предметной области. Если человек знает только что-то одно, он и будет насаждать данную технологию для решения всех вопросов. А подходит она или нет - это уже дело десятое.
С точки зрения технологий. Далеко не все задачи можно решить на Perl. Знаете почему? Думаю, знаете:) Потому что нет соответствующих библиотек. Конечно, есть проблемы, куда втыкать Perl не стоит(например, писать драйвера, наверное, на нем не надо:)). Что касается задач уровня корпораций... Приступая к разработке приложения, нужно оценить, а есть ли уже поддержка протокола, сервера(и т.д.) со стороны Perl. Часто так бывает, что поддержки нет. Писать с нуля? Увольте, нет времени.
Из личного опыта - мы часть проектов перебросили на Java исключительно потому, что не смогли найти необходимых(достаточно сложных) библиотек на Perl. Пример номер два - один из весьма масштабных проектов, изначально созданный на Perl, собирается с течением времени переходить на что-то другое.
Люди приходят в программирование, начинают что-то изучать. Их первоначальные задачи не сложны, однако по мере роста опыта становятся все более и более ответственными и если профессионал видит, что язык, на котором он работает, не может справиться с задачей, он, вероятнее всего, выполнит задачу на другом языке, Это, как говориться, +1. Из большого числа таких вот +1 создается mainstream. Новички зелены, они готовы доверчиво смотреть в глаза гуру и брать пример с уже чего-то работающего. Что сейчас популярно? Java и глобальный и надежный. Почему? Да потому что многие пишут на них, под них такими же энтузиастами создаются зачастую корявые и плохо работающие библиотеки. Но они есть! Часть умрет, как говорил Дарвин, но часть будет развиваться.
По моему мнению, Perl-у не хватает как раз поддержи широкого спектра серверов и протоколов. Я тут недавно размещал новость о том, что требуются волонтеры для написания клиентских библиотек на Perl для RabbitMQ. Кто откликнулся? Я молчу про полноценные FIX и FAST сервера(ну, у кого что болит, тот о том и говорит:)) Думаю, дальше список каждый может продолжить сам.
Наболело:)
Можно
Можно поконкретнее, каких библиотек не хватило именно вам?
Вобщем я
Вобщем я убежден, что проблема та же что и у работодателей с поиском специалистов - просто нет нормального контакта между работодателями и потенциальными работниками, в результате, что одни, что другие, тратят слишком много времени на отсев плохих предложений, и все равно не находят отличных предложений, а только удовлетворительные.
Не хватает
Взаимодействие по протоколу FIX. Любой из существующих версия. FIX engine-ов на Perl нет.
В каких
В каких минимальных пределах должен быть реализован протокол?
Какое может быть ваше участие?
Я имел в виду,
Я имел в виду, что FIX все-таки очень специфический протокол, чтобы рассчитывать на его реализацию в духе FOSS, а для корпораций Perl сейчас "немодный".
Поэтому, если есть желание чтобы такая реализация появилась, нужно приложить некоторые усилия - как минимум, помочь в постановке задачи и в организации тестирования (предметная область уж очень специфична).