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

> * Нечитабельный, особенно когда количество кода возрастает. Язык поощряет написание нечитабельного кода.

Докажите. Когда я последний раз взаимодействовал с Perl в CPAN был довольно-таки читаемый код. Сомневаюсь, что что-то изменилось. Вот то ли дело стандартные библиотеки Python. Вот уж где хочется пройтись асфальтоукладчиком. =)

> * Ужасные $, @ и % префиксы переменных.

Ужаааасные, ну конеееечно. Ведь это так плохо, по имени символа понять, что он относится к скаляру, списку или хэшу. Суффиксные нотации в стиле Microsoft куда лучше, конечно же. =)

> * Невозможность описать параметры функции в заголовке функции.

Когда я в последний раз писал на перле (а это было целую вечность тому назад), вроде бы уже было можно. Нафиг надо, конечно, но можно.

> Надо смотреть в тело функции чтоб узнать, какие аргументы есть и как они используются. Или верить на слово документации, если она есть и не устарела. Удачной отладки.

Ё-моё, надо читать документацию. В топку такой язык! В топку! =)

> * Чтение аргументов функции из массива @_. Какое-то тяжёлое наследие шелл-программирования походу, где аргументы в $@ хранятся.

О ужас, функции по умолчанию принимают массив, который потом надо разбирать. Во многих языках это -- отдельный элемент синтаксиса, имеющий специальную нотацию. А тут -- из коробки, ну как же так-то. =)

> * Нет типизации скаляров. Одна переменная - это тебе и строка, и число. Можно запросто сложить число со строкой, "и тебе за это ничего не будет". Тоже похоже на тяжёлое наследие шеллов.

Ну вообще-то есть. Это тебе не шелл, где всё обращается в строку. Другое дело, в перле присутствует элемент тяжёлого наследия от Си, с этим его неявным преобразованием типов.

> * Ужасно реализованное ООП.

Перевожу на человеческий язык: "Модель ООП в языке Perl отличается от той, к которой привык автор в любом другом языке". Что собственно не мудрено: каждый ООП-ориентированный язык создаёт какую-то свою модель ООП, отличную от предыдущих. Этих моделей уже целый вагон, и каждая несёт в себе свои достоинства и недостатки. Эталонной модели нет. Смысла спорить о том, какая из моделей лучше -- тоже. Я вот скажу, что лучшая модель ООП представлена в языке OCaml, а вы продолжите дальше мучаться со Scala, но то, что у ООП есть проблемы с теоретической базой, и что это уже давно религиозный культ -- к языку Perl никак не относится.

> * Практически не реализованное ФП. Никаких тебе filter, map или flatmap.

Лол. Вы уверены? =)

> * Сложность рефакторинга, обусловленная вышепереречисленными трудностями.

Вот тут ничего не смогу сказать. Я не занимался рефакторингом на перле. Но при прочих равных, я спокойно читал чужой код, и он вызывал куда меньше вопросов, чем, к примеру, код на си, на крестах, на яве или скале.

> В 90-х, когда не было выбора, Perl был хорошим выбором, на безрыбье. Но сейчас Python и особенно Ruby на голову удобнее.

Я не хочу представлять себе ментальное состояние людей, на полном серьёзе утверждающих, что между Perl 5 и Python 3 -- они сделают выбор в пользу Python 3. Больные ублюдки. =)