LINUX.ORG.RU

Чего мне не хватает в Perl?

 ,


1

12

Пишу на языке давно и успешно, отношусь к нему сугубо положительно, но есть конечно моменты, которые, мягко говоря не устраивают.

Итак, претензии к Perl от человека, который его осилил и знает особенности языка не по наслышке:

1) Не хватает собственно скорости. Скорость исполнения кода, т.е. его непосредственной интерпретации - Ахиллесова пята не только Perl, но и Ruby, и Python, и PHP. Но если интерпретаторы PHP и Python становятся быстрее с каждым годом, то интерпретатор Perl застрял в своём развитии - и при этом язык не имеет LLVM-компиляторов, как тот же Crystal, реализующий очень быстрый диалект Ruby. Для Perl есть RPerl, который непонятно как работает и работает ли у кого-то, кроме самого Вина Бразвелла. Ну и да, RPerl - это всё-таки не вполне Perl, по сути это какой-то «perl'оподобный диалект языка Си»

2) Не хватает адекватной проверки входных параметров. Есть куча сторонних модулей для этого: MooseX::Method::Signatures, Params::Validate и ещё тысячи их, но все они добавляют дикий оверхед к и без того не быстрой работе интерпретатора

3) Отсутствует как класс нормальный параллелизм: без пула потоков работать с потоками невозможно (создание потока - крайне медленная операция), с пулом потоков в принципе удобно, но всё одно памяти они жрут как не в себя. На Perl в 100 раз всё лучше с процессами, в том числе есть неплохие модули для работы с shared memory (правда, Redis для того же самого намного удобнее).

4) CPAN конечно замечательный репозиторий пакетов, но выкладывать что-то туда - это лишняя трата времени, да и все эти инструкции по правильному выкладыванию немного бесят: мне что, заняться больше нечем? ИМХО подход того же Crystal'а с его shards'ами намного удобнее.

5) Отсутствие макрогенерации кода. Есть конечно eval, но это, мягко говоря, всё равно что бульдозером шпалы укладывать: неудобно, анахронично, работает в рантайме (что просто ппц на самом деле), чревато ошибками. Учитывая стоимость вызова процедур в Perl5 отсутствие макрогенерации негативно влияет на потенциальную производительность

Относительно удобства ООП претензий не имею - те, у кого они есть, просто пришли из других языков и пытаются применять к совершенно иначе устроенному Perl'у свои «обобщённые» знания.

★★★★★

Последнее исправление: DRVTiny (всего исправлений: 2)

Ответ на: комментарий от level1

Вы сами знаете, куда можете засунуть своё мнение. Оно очень ценно для меня, оставайтесь на линии.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от mythCreator

Или то, что распихать всю бизнес логику в Entity и контроллеры это нормально(то есть отсутствие слоя бизнес логики в принципе).

А в итоге получается сайтик возмужавших торгашей-челночников, освоивших «высокие технологии»? Даже Reg.ru - ну чем он торгует? Воздухом торгует, ни больше - ни меньше.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Не заметил сразу реально полезную особенность такого таймера: $id, будучи захваченной в замыкание after-таймера, будет переопределена как id задания recurring-таймер'а.

Я, правда, сделал всё-таки с учётом того, что реальному пользователю гораздо чаще нужен recurring-таймер, нежели просто after-таймер, посему каждый из параметров может быть 0/undef.

Но конечно это не меняет того факта, что в AnyEvent было просто сразу по-человечески реализовано, да ещё с альтернативным вариантом написания «для ленивых» (AE).

Ну и да, по существу я бы ещё добавил в первый пост как существенный недостаток perl'а - отсутствие как класса поддержки переключения конкурентных потоков исполнения через собственный perl'овый рантайм. Например, в Ruby, в fiber'ах, это есть

DRVTiny ★★★★★
() автор топика
Ответ на: N от Casus

1) Про это уже говорили. Да, не хватает. На практике это редко критично.

Это офигеть как критично, потому, что можно передать не тот тип и получить в рантайме ошибку, которую можно было бы заметить на этапе компиляции. Про отправить войну и мир в место флажка уже написали. Добавлю еще, что JSON::XS может вернуть один и тот же скаляр и как строку и как число в зависимости от контекста в котором он использовался в прошлый раз. Например если мы его прямо в код посчитали это будет число, а если вынули из базы то уже строка. При этом swift приложение на iOS просто упадет если кто-то из нас не поставит костыль.

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

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

5) Технологий хоть отбавляй. Если не знаешь что взять — спроси у тех, кто знает. Не надо приводить мне в пример джаву, там свои заморочки.

Дело не в наличии, а хаотичном развитии, в java две библиотеки подчиняющиеся одной JSR спецификации можно заменить, т.к. у них один интерфейс. В perl без дополнительного слоя абстракции типа адаптера или фасада это так просто сделать не выйдет.

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

Да, я тоже писал, что не все подходят для perl. Если есть хороший линк по паттернам на perl или в принципе на динамических языках поделитесь. И про то как писать на perl сложные приложения с многослойной архитектурой.

7) «Очень многие представители» — громкое заявление без какого либо обоснования, кроме «личного мнения», которое используется в следующем пункте.

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

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

8) Джун должен участвовать в проекте, который ведёт сведущий в теме тимлид. Тогда он многому научится. Поощряется участие в перл-тусовках, типа телеграммовской.

Джуну сложно оценить насколько его тим лид сведущий. Коллеги с предыдущего проекта кстати тоже участвовали в perl тусовках типа yapc.

mythCreator
()
Ответ на: комментарий от DRVTiny

Мне доводилось при работе с панелью рег.ру видеть, как перл дампы падали прямо в браузер.

mythCreator
()
Ответ на: комментарий от mythCreator

Это офигеть как критично, потому, что можно передать не тот тип и получить в рантайме ошибку, которую можно было бы заметить на этапе компиляции. Про отправить войну и мир в место флажка уже написали. Добавлю еще, что JSON::XS может вернуть один и тот же скаляр и как строку и как число в зависимости от контекста в котором он использовался в прошлый раз. Например если мы его прямо в код посчитали это будет число, а если вынули из базы то уже строка. При этом swift приложение на iOS просто упадет если кто-то из нас не поставит костыль.

Про базу странно, я не замечал изменения типа только от выборки значения. Для валидации типов и приведения их к нужным - средства есть. Речь изначально была о некотором жёстком наборе типов на уровне компилятора, этого нет. Но для валидации по схеме средства есть. Так же как и способ приведения типов к ожидаемым «на той стороне» тоже есть. На счёт JSON::XS — не виноватый он, у него нет контекста. Он должен применяться к структуре, которая уже прошла приведение данных к требуемой схеме.

Casus ★★★★★
()
Ответ на: комментарий от DRVTiny

Ну и да, по существу я бы ещё добавил в первый пост как существенный недостаток perl'а - отсутствие как класса поддержки переключения конкурентных потоков исполнения через собственный perl'овый рантайм. Например, в Ruby, в fiber'ах, это есть

Модуль Coro, который именно этим занимается, на CPAN со времён выпуска 5.10. Да, средство прямо в языке было бы, конечно, лучше. Но, раз Coro уже есть, то вроде как и незачем (было) лезть в ядро Perl, да и при случае проблемы можно свалить на Леманна :)

Casus ★★★★★
()
Ответ на: комментарий от Casus

Насчет базы я не совсем верно выразился там была выборка объекта с помощью самописной orm. Возможно на чистом DBI этой проблемы нет.

mythCreator
()
Ответ на: комментарий от Casus

Модуль Coro не заменяет рантайм, в этом беда. В fiber'е Ruby или Crystal'а можно просто вызвать read и понимать при этом, что в действительности никакого блокирующего ожидания не будет: в действительности read передаст управление планировщику, который запомнит, что для данного файлового дескриптора нужно делать периодический select - и как только данные в ответ на read придут, можно будет передать управление обратно. Перловая реализация, будучи реализованной сбоку, предлагает каждую потенциаально блокирующую операцию в коде заменять на специальный аналог «для Coro», «для AnyEvent». А на Ruby можно с минимальным оверхедом сделать обычное приложение асинхронным - вообще ничего не переписывая.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от Casus

По-моему паттерн не такой уж и сложный

sub {
 state $first_run=0;
 on->('event' => __SUB__) unless $first_run++;
 do_something();
}->()
Зато не нужно никаких передач коллбеков: замыкание само себя добавляет в планировщик. Проблема может быть разве что с переполнением счётчика. Тогда я бы предложил делать так:

sub {
 state $first_run;
 on->('event' => __SUB__) unless ($first_run+0)==($first_run|=1);
 do_something();
}

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

Модуль Coro не заменяет рантайм

Тем не менее, содержит весьма интересные части, например, Coro::Handle, с которым почти ничего не надо менять в синхронном коде.

А на Ruby можно с минимальным оверхедом сделать обычное приложение асинхронным

Да, это полезно, удобно и хотелось бы иметь в Perl. Есть, видимо, в Perl6.

Casus ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.