Pull to refresh

Почему я больше не хочу програмировать на Perl

Reading time 3 min
Views 13K
Про недостатки перла как языка и платформы сказано многое, например, про то, что нет спецификации языка, про то, что странный синтаксис к которому нужно долго привыкать и т.д.

Достаточно того, что авторы языка, задумывая новые версию, по сути создали новый язык мало похожий на исходный (Perl 6), тем самым признали что текущий перл вышел не очень удачным, что в принципе понятно т.к. язык создавался как замена shell'у, а потом оброс фичами.

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

  1. Обратная совместимость — перл старается её поддерживать, с одной стороны это хорошо, с другой стороны для того чтобы писать на современном перле надо явно включать прагмы использования новых фич т.е. написав код по умолчанию в 21 веке вы можете получить код в котором компилятор не отлавливает даже опечатки и именах переменных и не поддерживает никаких новых конструкций. Мне кажется те, кто хотят обратной совместимости должны включать прагмы таковой, а по умолчанию язык должны быть актуальным.

  2. Параллельное программирование — с тредами в перле изначально было плохо, их как-то всегда не рекомендовали использовать, форкать процессы можно, но до определённого порога, а потом люди начинают думать как это оптимизировать и конечно перл не исключение — история этого вопроса примерно такая, сначала был POE, потом его заменил Coro, а потом пришёл и всех победил AnyEvent. И долгое время я не понимал суть проблемы, но когда узнал как эти вопросы решаются в Erlang или Haskell понял что асинхронное программирование на коллбэках это низкий уровень, по сути шаг назад. Перл когда-то выстрелил именно как высокоуровневый язык, а тут получилось наоборот.

  3. Глобальные переменные — грамотные программисты конечно используют use strict и my, но многие конструкции языка, такие как регулярные выражения или eval, используют глобальные переменные для возвращения результата, это уродство о котором нужно всегда помнить, например в $1 может оказаться результат предыдущего матчинга, поэтому надо проверять не наличие значения, а результат матчинга. В питоне, в том числе для регексов, обошлись без глобальных переменных и всё получилось нормально.

  4. eval — это пример странности в синтаксисе, на самом деле eval в перл, если передать ему строку, ведёт себя как ожидается от функции с таким именем, а вот если ему передать блок кода, то он по сути реализует оператор try, хотя и убого (поэтому на cpan есть много «фиксов» try).

  5. Передача параметров в функцию — опять же, предлагается какой-то низкоуровневый механизм, параметры приходят виде массива и нужно его явно превращать в что-то удобочитаемое, некоторые варианты в принципе невозможно реализовать, например нельзя передать два хеша по значению, только по ссылке. Есть конечно костыли вроде этого, но костыли есть костыли, достаточно посмотреть на то как реализована передача параметров в Python, чтобы понять как должен выглядеть продуманные высокоуровневый синтаксис передачи параметров.

  6. Оператор in — стандартная задача — проверить входит ли элемент в массив, в питоне это делается единственно правильным способом element in array, в перле такого нет, одно время вводили smart matching, но наворотили там такого, что быстро решили его выпилить, а остальные варианты выглядят просто жутко.

  7. Работа с датами — к сожалению почти все книги по перлу рекомендуют модуль Datetime, автор которого смешал в один модуль, то что должно быть двумя (арифметика дат и календарь) и ещё и рассказывает всем как это оказывается сложно делать такую ерунду, а ещё у этого модуля жуткий объектный синтаксис. Относительно нормальный в перле это Class::Date, но почему-то его мало кто знает, а эталон снова в питоне, почему-то там люди понимают, что максимальная единица в арифметике дат это неделя, а месяц это уже понятие календаря. Кому интересны подробности может почитать переписку тут.

  8. И это можно продолжать бесконечно, вот ещё пример, когда вместо одной нормальной функции, есть куча непонятно чего.

  9. Но главная проблема в том, что сообщество не замечает этих проблем — «мы всегда так делали».

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

Помимо этого, раньше у перла было преимущество в количестве модулей, но сейчас оно утеряно, уже несколько раз приходилось из перла использовать питонные модули, спасибо автору Inline::Python за такую возможность.
Tags:
Hubs:
+1
Comments 227
Comments Comments 227

Articles