Про недостатки перла как языка и платформы сказано многое, например, про то, что нет спецификации языка, про то, что странный синтаксис к которому нужно долго привыкать и т.д.
Достаточно того, что авторы языка, задумывая новые версию, по сути создали новый язык мало похожий на исходный (Perl 6), тем самым признали что текущий перл вышел не очень удачным, что в принципе понятно т.к. язык создавался как замена shell'у, а потом оброс фичами.
Я бы хотел сказать о своих личных наблюдениях, которые привели меня к тому, что работать на перле я пойду только в крайнем случае, несмотря на то, что этой мой основной язык.
Кто-то может сказать, что это мелочи, мол можно привыкнуть и писать рабочий код, да, я долгое время писал, но со временем понимаешь, что нет никаких причин привыкать к плохому, надо выбирать лучшие решения, а не какие-нибудь.
Помимо этого, раньше у перла было преимущество в количестве модулей, но сейчас оно утеряно, уже несколько раз приходилось из перла использовать питонные модули, спасибо автору Inline::Python за такую возможность.
Достаточно того, что авторы языка, задумывая новые версию, по сути создали новый язык мало похожий на исходный (Perl 6), тем самым признали что текущий перл вышел не очень удачным, что в принципе понятно т.к. язык создавался как замена shell'у, а потом оброс фичами.
Я бы хотел сказать о своих личных наблюдениях, которые привели меня к тому, что работать на перле я пойду только в крайнем случае, несмотря на то, что этой мой основной язык.
- Обратная совместимость — перл старается её поддерживать, с одной стороны это хорошо, с другой стороны для того чтобы писать на современном перле надо явно включать прагмы использования новых фич т.е. написав код по умолчанию в 21 веке вы можете получить код в котором компилятор не отлавливает даже опечатки и именах переменных и не поддерживает никаких новых конструкций. Мне кажется те, кто хотят обратной совместимости должны включать прагмы таковой, а по умолчанию язык должны быть актуальным.
- Параллельное программирование — с тредами в перле изначально было плохо, их как-то всегда не рекомендовали использовать, форкать процессы можно, но до определённого порога, а потом люди начинают думать как это оптимизировать и конечно перл не исключение — история этого вопроса примерно такая, сначала был POE, потом его заменил Coro, а потом пришёл и всех победил AnyEvent. И долгое время я не понимал суть проблемы, но когда узнал как эти вопросы решаются в Erlang или Haskell понял что асинхронное программирование на коллбэках это низкий уровень, по сути шаг назад. Перл когда-то выстрелил именно как высокоуровневый язык, а тут получилось наоборот.
- Глобальные переменные — грамотные программисты конечно используют use strict и my, но многие конструкции языка, такие как регулярные выражения или eval, используют глобальные переменные для возвращения результата, это уродство о котором нужно всегда помнить, например в $1 может оказаться результат предыдущего матчинга, поэтому надо проверять не наличие значения, а результат матчинга. В питоне, в том числе для регексов, обошлись без глобальных переменных и всё получилось нормально.
- eval — это пример странности в синтаксисе, на самом деле eval в перл, если передать ему строку, ведёт себя как ожидается от функции с таким именем, а вот если ему передать блок кода, то он по сути реализует оператор try, хотя и убого (поэтому на cpan есть много «фиксов» try).
- Передача параметров в функцию — опять же, предлагается какой-то низкоуровневый механизм, параметры приходят виде массива и нужно его явно превращать в что-то удобочитаемое, некоторые варианты в принципе невозможно реализовать, например нельзя передать два хеша по значению, только по ссылке. Есть конечно костыли вроде этого, но костыли есть костыли, достаточно посмотреть на то как реализована передача параметров в Python, чтобы понять как должен выглядеть продуманные высокоуровневый синтаксис передачи параметров.
- Оператор in — стандартная задача — проверить входит ли элемент в массив, в питоне это делается единственно правильным способом
element in array
, в перле такого нет, одно время вводили smart matching, но наворотили там такого, что быстро решили его выпилить, а остальные варианты выглядят просто жутко.
- Работа с датами — к сожалению почти все книги по перлу рекомендуют модуль Datetime, автор которого смешал в один модуль, то что должно быть двумя (арифметика дат и календарь) и ещё и рассказывает всем как это оказывается сложно делать такую ерунду, а ещё у этого модуля жуткий объектный синтаксис. Относительно нормальный в перле это Class::Date, но почему-то его мало кто знает, а эталон снова в питоне, почему-то там люди понимают, что максимальная единица в арифметике дат это неделя, а месяц это уже понятие календаря. Кому интересны подробности может почитать переписку тут.
- И это можно продолжать бесконечно, вот ещё пример, когда вместо одной нормальной функции, есть куча непонятно чего.
- Но главная проблема в том, что сообщество не замечает этих проблем — «мы всегда так делали».
Кто-то может сказать, что это мелочи, мол можно привыкнуть и писать рабочий код, да, я долгое время писал, но со временем понимаешь, что нет никаких причин привыкать к плохому, надо выбирать лучшие решения, а не какие-нибудь.
Помимо этого, раньше у перла было преимущество в количестве модулей, но сейчас оно утеряно, уже несколько раз приходилось из перла использовать питонные модули, спасибо автору Inline::Python за такую возможность.