Комментарии 101
К тому же, «современные стеки» имеют свойство устаревать очень быстро и часто несовместимы между своими мажорными версиями, и то что супер-пупер-круто сейчас, может стать несовременным уже через три-четыре года, а Perl как был так и будет есть ещё лет 30.
Разумеется, у Perl есть свои недостатки, но они есть у любого языка и любого фреймворка, но тот факт что Perl создан не один десяток лет назад не делает его устаревшим (к тому же он развивался всё это время), а наличие просто невероятного количества модулей и фреймворков действительно делает его вполне жизнеспособным и в наше время, и действительно для любых задач (кроме, разве что, чисто вычислительных, а также требующих нативной многопоточности).
Что «современный стек» умеет из того, чего не умеет Perl? И какой смысл портировать то что и так прекрасно работает — просто «чтобы было»?
Находить разработчиков под него
PHP всего на 7 лет младше Perl, но ведь ещё актуален? И это несмотря на то что его ругают все кому не лень (причём за дело).
Си вообще почти древний (аж на 15 лет старше Perl) — и что, он уже неактуален?
Что касается «не пойдёт на вакансию» — это зависит от задачи и оплаты. Уверен, что если будет выбор между «CMS для порносайта» на C# за $50/час или «AI для робомобиля» на Perl за $75/час — то вряд ли многие выберут порносайты, даже если не знают Perl. Хотя, если это простые банальные кодеры — то да, выберут. А хорошие разработчики все же выберут второе.
Хотя вообще-то хороший разработчик должен знать (т.е. уметь практически применять) несколько языков, и понимать намного больше (хотя бы со словарём), а также легко осваивать новые, иначе он просто узкоспециализированный кодер.
К несчастью, многие современные разработчики знают только один, любой другой (даже похожий) идёт с трудом, и шаг влево или вправо выбивает их из колеи. Печально.
Я также не сомневаюсь, что на Perl написано много полезных модулей и, возможно, даже качественных приложений. Авторы обычно отвечают — «просто нужно писать аккуратно, не использовать всякий сомнительный функционал, и все получится». Однако это говорит лишь о силе воли и навыке разработчика, а не о пригодности технологии.
Java и C++ существуют уже не меньше лет, устаревать не собираются, и о кардинальных несовместимостях между версиями я также не слышал. Сообщества крупнее и активнее, сил и денег вкладывается на порядок больше, сотрудников искать легче, инструменты совершеннее. Разве это не достаточная мотивация?
как правило он не является решающим.
Серьезно? Кому нужен язык Go и микросервисы — OH, MY CODE #18
А что вы скрываете за понятием "современный стек"? Вот конкретно? JavaScript/Python? Приложения на Electron нынче с успехом питаются гигабайтами RAM, простой скрипт на Python легко заставляет свою виртуальную машину съесть до 70МиБ "с порога", а рядовой Perl-процесс укладывается до 10МиБ, стартует быстрее, и это при том, что выразительность языка гораздо выше, чем у тех обоих вместе взятых.
Я вот прямо сейчас на коленке провёл эксперимент:
perl -E 'say "foo" while 1'
— 508КиБ`python2 -c 'while True: print("foo")'
— 2.5МиБpython3 -c 'while True: print("foo")'
— 3.6МиБnode -e 'while (1) {console.log("foo")}'
— В секунду течёт где-то по 100МиБ, за несколько секунд дошло до 1ГиБ и я решил убить процесс, этого достаточно (node --version
= 8.12.0)
И эти объёмы потребляемой RAM растут пропорционально. Основные его конкуренты (если я правильно интерпретировал ваш "современный стек") дают ощутимо менее выразительный синтаксис и при этом ощутимо расточительнее по отношению к ресурсам.
Итак, вопрос: зачем вообще портировать проекты на "современный стек"?
Подозреваю, что вы не прочитали остальной тред, прежде чем писать комментарий, поэтому резюмирую одной строкой: поддерживаемость важнее потребления ресурсов. Под поддерживаемостью подразумевается
- В языке должны быть гарантии надежности (строгая статическая типизация)
- IDE для языка должна предоставлять умные рефакторинг и автодополнение
- На рынке должно быть достаточно специалистов
Perl, к сожалению, не удовлетворяет ни одному из данных пунктов, поэтому его производительность и выразительность ничего не значат. JS и Python — только пункт 3 (пункт 2 под вопросом). Примеры языков, удовлетворяющих всем трем пунктам — Java, C# или Go.
Ну я и отвечал на конкретное верхнее сообщение, а не на ветку треда.
поддерживаемость важнее потребления ресурсов
Только если ты большая компания — у которой неограниченные железные ресурсы, на которые в любой момент всегда есть деньги. Для конечного пользователя такой подход заканчивается печально и уныло (см. Electron-приложения, и всякие веб-сайтики, которые едят как не в себя, да ещё обвешаны кучей счётчиков, рекламных сетей и прочими зондами).
Пт. 1 удовлетворяет Haskell лучше всех перечисленных вместе взятых.
Пт. 2: JS и Python могут удовлетворять в отдельных случаях только если код очень "тупой", если не используются никакие хелперы для генерации функций, исключений, а всё развёрнуто набито копипастой/руками.
С пт. 3 вообще интересная ситуация. Есть хорошие инструменты, но изучать которые и работать с которыми люди не берутся в свободное время, т.к. им непонятны перспективы с точки зрения последующего поиска работы, т.к. вакансий не предлагают. А вакансий не предлагают, т.к. сложно найти таких специалистов на рынке, а специалистов мало, потому что им не предлагают вакансий, мотивации недостаточно для выделения большего кол-ва времени/сил на обучение. Ну вы поняли рекурсию.
Только если ты большая компания — у которой неограниченные железные ресурсы, на которые в любой момент всегда есть деньги. Для конечного пользователя такой подход заканчивается печально и уныло (см. Electron-приложения, и всякие веб-сайтики, которые едят как не в себя, да ещё обвешаны кучей счётчиков, рекламных сетей и прочими зондами).
И пользователя выбирают эти сайты и приложение и рассказывают друг другу, какие они офигенные. Так что пользователям поддерживаемость тоже важнее.
Эти поделки терпят либо от незнания что можно лучше, либо по причине отсутствия альтернатив.
Вот именно. Альтернатив нет, потому что их не смогли написать, а то, что по вашим критериям лучше либо не пилит модные фичи, либо пилит их очень медленно.
ruby -e 'while true; puts "foo" end' — 12.1МиБ
Если убрать Node.JS, — т.к. это вообще что-то невменяемое, и использовать это для скриптинга нельзя, если не хотите случайно запнуться об гигабайтную течь по памяти, то Ruby — пока чемпион по жиру.
Отдельная проблема — настройка окружения (интерпретатор, ide, кодировки и пр.) надеюсь, в новом курсе уделили этому внимание. У меня, например, возникла странная проблема с кавычками, которая проявлялась только в винде, и только в консоли. Гуглил с полчаса — без толку. Как раз таким вещам стоит посвятить часик во вводной лекции, а не лить воду про историю и философию.
Курс на Stepik, который анонсирован в этом посте, и «предыдущий курс» из Вашей ссылки действительно имеют общие корни. Изначально был создан живой курс для обучения студентов в рамках образовательных проектов mail.ru (Технопарк и другие). Фрагментарная видеозапись одного из первых выпусков этого материала и была выложена на youtube с достаточно прагматической целью: чтобы дать возможность студентам пересматривать лекционный материал в процессе работы над домашками. Видео достаточно сильно сокращено, там нет ответов на вопросы студентов и многих других вещей, и стартовать, имея только это видео, действительно может быть достаточно тяжело. Впрочем, «живой» курс не оставался неизменным и видоизменялся от семестра к семестру, учитывая успехи и неудачи предыдущих прогонов, так что есть надежда, что мы сумели с тех пор сделать его лучше. Из этого материала и родился курс для Stepik'а. В его названии есть слово «введение». Мы отобрали только те темы, которые действительно необходимы для знакомства с языком, и позволят изучить его синтаксис и начать писать на нем небольшие программы. Сложные разделы, требующие дополнительных знаний и опыта разработки, мы постарались в эту версию курса не включать. Получилось у нас сделать курс доступнее или нет — не знаю, время покажет. В том, что там найдется определенное количество косяков, которые придется исправлять — не сомневаюсь, но мы к этому готовы.
Исторический экскурс в новом видео предельно сокращен, на него отводится менее двух минут в стартовой лекции, и еще меньше приходится на философию. Второй видеофрагмент как раз касается работы под Windows: там предупреждение о том, что по мере закапывания вглубь проблем под виндами будет все больше и больше и в целом этот путь не рекомендуется. Кавычки не имеют прямого отношения к перлу, это связано с работой консоли, но об этом мы тоже предупреждаем. Чтобы облегчить старт и не собирать все эти грабли, можно, например, воспользоваться приготовленной для вас виртуалкой.
Некоторые считают, что язык Perl мертв, поэтому одной из задач курса является развенчание этого мифа.
Вот отсюда поподробнее можно пожалуйста?
Учитывая современные модули и функциональность языка, сегодня Perl способен решать любые задачи.
Наконец появился язык, на котором все можно писать! А то вечно как ни начнешь модуль ядра писать, так приходится с петона на си прыгать. Теперь муки позади.
Прошу обратить внимание на интересный факт: я получил гору минусов в карму и в сам коммент, но развенчание мифа не последовало.
Это говорит многое о «религиозности» отношения к языку. Не о логичном выборе, который есть чем защищать. Можно подвергнуть сомнению Аллаха, а можно подвергнуть сомнению статус Перла — отношение адептов будет одинаковым.
Вывод: вместо опровержения мифа сами же его и подтвердили, продемонстрировал отсутствие конструктива.
Выведение обещать не могу, но в офисе мейла есть Служба Вынимания. Приходите, если сможем — поможем :)
Ruby родился 23 февраля 1993 года. В тот день я беседовал со своим коллегой о возможности существования объектно-ориентированного сценарного языка. Я знал Perl (Perl4, а не Perl5), но он мне не нравился — был в нём некий привкус игрушечного языка (да и поныне есть). А объектно-ориентированный интерпретируемый язык казался многообещающим. В то время я знал Python. Но он мне не нравился потому, что я не считал его настоящим объектно-ориентированным языком. Его OO свойства казались надстройкой над языком. Мне, как языковому маньяку и фанату объектно-ориентированного программирования с пятнадцатилетним стажем, очень, очень хотелось, чтобы был истинно объектно-ориентированный, простой в использовании язык. Я пытался найти такой язык, но его не было.— это цитата автора по Википедии, именно по ней много лет назад я понял, что хочу знать Ruby и забыть Perl
Запустите обозреватель интернета версии 5.5 и введите в адресной строке адрес myspace.com/mail.ru…
На С# никогда не писали банковский софт, а на Basic его навалом, только никто уже не знает, как он работает?
Сравнил. В чём-то похожи.
А что у нас общего между perl и cobol? Ужасные языки программирования, на которых написаны куски старого кода, за сопровождение которого платят всё больше и больше умирающим от альцгеймера старикам. Да?
Насчёт «ужасного», цитирую:
Theorem: Parsing Perl 5 is Undecidable
We first establish Adam Kennedy's conjecture as a lemma. The proof will follow immediately from that and the Halting Theorem.
Kennedy's Lemma: If you can parse Perl, you can solve the Halting Problem.
To prove Kennedy's Lemma, we assume that we can parse Perl. In particular this means we can take the following devilish snippet of code, concocted by Randal Schwartz, and determine the correct parse for it:
whatever / 25 ; # / ; die "this dies!";
Schwartz's Snippet can parse two different ways: if whatever is nullary (that is, takes no arguments), the first statement is a division in void context, and the rest of the line is a comment. If whatever takes an argument, Schwartz's Snippet parses as a call to the whatever function with the result of a match operator, then a call to the die() function.
www.perlmonks.org/?node_id=663393
Да, Perl позволяет создавать малочитаемый код, но это выбор разработчика, а не особенность языка. Если я пишу скрипт для себя из серии «написал и забыл» — это не проблема, а для проекта который уйдёт в свет и с которым будет работать команда можно писать чисто и понятно. Для этого, кстати, и нужно адекватное обучение.
Другими словами, сам язык допускает конструкции на уровне парсера (!), которые невозможно разобрать не разобрав, что делает программа.
На этом месте его можно закапывать, потому что такого даже ассемблер (без полиморфизма) себе не позволяет.
Да, язык это позволяет (потому что это фича), но не навязывает — не вижу проблемы. Вы же не запрещаете производство кухонных ножей просто потому что ими можно кого-то убить или порезаться? Да и лицензий или курсов обучения для пользования бытовыми ножами я что-то не встречал — но вот удивительное дело, это не приводит к проблемам, кроме изолированных частных случаев.
Как я уже говорил раньше, никакой язык не обеспечит идеальности кода без желания разработчика (или его начальника) — на любом, даже самом идеальном и зарегулированном донельзя языке можно написать полную хрень, никем кроме автора не читаемую и непонимаемую (но вполне работоспособную), но это само по себе не делает язык плохим или хорошим.
Не надо ограничивать творчество на уровне языка — злые гении всё равно найдут выход, а добрые обидятся и не сделают чего-то великого в момент озарения.
Не надо ограничивать творчество на уровне языкаВ энтерпрайзной разработке не должно быть никакого «творчества на уровне языка». Вместо этого должны быть разумные ограничения, которые максимально усложняют жизнь «злым гениям», но не мешают нормальным разработчикам. А если язык заставляет человека вручную контролировать то, что компилятор мог бы сделать автоматически — это не фича, а огромный недостаток.
Любая благословленная ссылка в Perl'е — это объект. И привычных вещей(наследование, инкапсуляция и т.д.) туда не завезли. Поэтому сообщество напридумало хелперы Moose, Moo и т.д.
Тот же раст прекрасно живёт на структурах, функциях и типажах, без ООП, и его никто за это не ругает.
А насчет раста есть подозрения что он прекрасно живет из за хорошей системы типов.
В энтерпрайзной разработке не должно быть никакого «творчества на уровне языка».
Я вас сильно удивлю, если скажу что есть и другие виды разработок?
Ограничения должны быть административными — как и в ПДД. Представьте что автомобили физически ограничены двигаться не более 50 км/ч в городе, или принудительно останавливаются на знаке STOP — это нормально будет?
Есть языки которые позволяют делать operator overloading, а есть которые не позволяют — причиной называется то что это «может запутать» и «ухудшает читабельность» — хотя в ряде случаев как раз наоборот, то же самое относится к goto — это вопрос вкуса, если угодно.
Точно также и с Perl — может в ряде случаев это и ухудшит ситуацию, но может и улучшить. В конкретном проекте легко выставить условие — «никаких сомнительных конструкций» — и всё, вопрос закрыт, а для внутренних скриптов-однодневок, экспериментов или кода который ограничен по времени или памяти это может быть только плюсом.
Лучше иметь в баре бутылку виски и не пить его, чем не иметь и вдруг обнаружить что хочется выпить (опасность тут только для алкоголиков).
Для любого другого языка можно понять, что происходит, глядя в код. В перле его надо выполнять — в противном случае понять невозможно.
Для меня, к примеру, являются практически нечитаемыми (= невозможно понять) навороченные многоуровневые темплейты в C++, их явно понимает только автор, но это ведь не проблема языка.
Я посмотрел на codegolf для питона — там совершенно милые и забавные выкрутасы, которые заставляют задуматься «о как», но смысл которых понятен без исполнения кода.
Чтобы код был понятен всем, существуют style guide, никакой язык не заставит писать код который понятен всем (разве что там всего несколько строк).
Возьмите любой проект на js, пропустите через минимизатор (и оптимизатор) — и удачи в понимании его смысла, особенно если это библиотека типа jquery. И сейчас скажите что проблема в языке? Что примечательно, некоторые так пишут сами, на разных языках…
Никакие примеры «глупых сравнений» из js, или «wtf» для темплейтов с++ близко не подходят к необъятности ужаса языка, чей синтаксис является контекстно-зависимым.
UPD: Ближайшим аналогом могут быть макросы в Си, но они, всё-таки, не си, а препроцессор.
Мне лично гораздо более неприятно то что в C/C++ неопределен порядок вычисления аргументов функций (да и вообще выражений) — вот это действительно драма, по сравнению с динамическим парсингом, потому что, в отличие от динамического парсинга, это вообще непредсказуемо, но это никого не смущает:
(a++)+(++a)+(a--)+(--a)
Такое выражение даст разные результаты в зависимости от платформы, компилятора, его версии или настроек оптимизации — но почему-то допускается, несмотря на возможность статического парсинга.
Вы можете возразить — «не надо такое использовать» — так что же мешает не использовать особенности Perl, в таком случае?
Но я не хочу иметь ни с одним из этих языков ничего общего.
Я понимаю, ваши наезды на Си, и полностью их поддерживаю — такого минного поля трудно себе представить. Однако, наличие ужаса в Си оправдывает его системный статус. У перла такого статуса нет — во всех мейнстримовых дистрибутивах перл и python идут нос-в-нос.
Я могу назвать сходу с десяток WTF для питона, но ни одно из них даже близко не подходит к выразительности и многоэтажности высказываний об идиоматичности перла.
Для приведенного Вами фрагмента кода есть еще третий вариант: в дефолтном режиме whatever будет считаться просто строкой. Остальные два варианта, рассмотренные в цитате, полагаются на то, что где-то выше по коду есть объявление функции. Если дополнить фрагмент этим объявлением, неоднозначность исчезнет. Randal Schwartz был хитёр.
Да, на перле Сатану можно вызвать.
На Перле — Сатана появится мгновенно
На С — Сатана появится по частям
На Java чтобы призвать Сатану нужно прочитать длинную молитву
На Javascript Сатана появится, но возможно не тот…
На Перле — Сатана появится мгновенноnuff said
На С — Сатана появится по частямС простреленной ногой, точнее. А ещё и вам прострелит
На Java чтобы призвать Сатану нужно прочитать длинную молитвуС перерывами на уборку мусора (эта шутка, возможно, несколько устарела)
На Javascript Сатана появится, но возможно не тот…точно не тот
Я даже не шучу. www.youtube.com/watch?v=nc2q4OOK6K8
Без шуток, два года назад попалась мне задача, реализованная на перле, а я ни бум-бум. Пришлось учить питон и пилить свой велосипед.
В общем хорошая новость, может после этого курса я смогу понять что там было «накОдено»
Perl — хороший язык, мощный и выразительный, по-своему прекрасный, но он мало где нужен, если быть честным. Вот только уж если нужен, то за большую зарплату (и придется работать, как правило, с авгиевыми конюшнями легаси).
Есть такой Perl, который весьма похож на Golang (демоны на AnyEvent + Coro), только с удобной динамической типизацией и прочими удобствами скриптовых языков.
похож на Golang (демоны на AnyEvent + Coro)
В каком месте? AnyEvent построен на каллбеках. Соответственно привет callback hell.
callback hell, впрочем, следствие непонимания или неправильного использования асинхронных фич, но всё можно делать правильно.
Perl по-своему прекрасен, особенно в нише работы с текстовыми данными, сам несколько лет на нём писал. Но новые проекты сейчас на нем начинать бы ни за что не стал.
Пока вы будете учить Perl — нейронные сети под Python захватят весь мир.
AI::MXNet
Цикл статей:
Machine learning in Perl
Machine learning in Perl, Part2: a calculator, handwritten digits and roboshakespeare
Machine learning in Perl, Part3: Deep Convolutional Generative Adversarial network
Machine learning in Perl: Kyuubi goes to a (Model)Zoo during The Starry Night
А теперь попробуем найти вакансии ML с Perl...
TIOBE Index for November 2018
Хотя вот начинающим я бы его не советовал. Объяснений мало, в задачах приходится разбираться копаясь в дополнительных материалах ибо решать надо используя то, чему еще не научили. В общем для начинающих будет слишком туго, а для тех, кто разбирается наверное слишком просто? В итоге казалось бы интересный курс, но непонятно на кого рассчитанный.
Курс «Введение в Perl» от Mail.Ru Group