Про недостатки перла как языка и платформы сказано многое, например, про то, что нет спецификации языка, про то, что странный синтаксис к которому нужно долго привыкать и т.д.
Достаточно того, что авторы языка, задумывая новые версию, по сути создали новый язык мало похожий на исходный (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 за такую возможность.
ссылка на оригинал статьи https://habrahabr.ru/post/327408/
Добавить комментарий