Как стать автором
Обновить

Комментарии 20

Вот это норм пятничная статья! Увел меня в перезагрузку на пару минут.

%x = map {$_ => $$_} qw/& 1 ' `/;

При всей моей любви к Perl-у не очень восторгаюсь от подобного кода (хотя до настоящих перловых "угадай, что это делает" тут ещё далеко).

Что мешает написать несколько "лишних" строк, где объявить переменные с нормальными именами? зачем потом ломать голову над получившимися выражениями типа $x { '\'' } ?

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

Напомню, что perl создавался именно для быстрого написания программ. Поэтому у него так много "скороговорок" вроде x if y, do {} и т.п. Однако цена быстрого написания программ - дополнительные расходы на "соображалку". К тому же у perl-а - низкий порог вхождения и из-за этого меньше людей стремятся его освоить.

То есть для долгосрочных крупных проектов, поддерживать которые будет коллектив из 50 программистов с высокой текучкой кадров, выбирают python.

perl же будет уместен, например, на стартапах, которые, как известно "взлетают" 1 из 5, да и из взлетевших 4/5 закрываются в следующие 5 лет. Тут нужна скорость, чтобы успеть выпустить программу, которая начнёт приносить какой-никакой доход, пока закончатся средства вложенные в стартап.

Когда же стартап развернётся, то его пытаются переписать на python.

Так же perl идеален для написания одноразовых скриптов для парсинга логов или html-страниц сайтов.

Ну и я бы использовал не $x{'\''}, а $x{"'"}. Впрочем, я задавал вопрос "не знает ли кто-то аналога функций global() и local(), которые есть в python-е и возвращают хеш с глобальными или локальными переменными соответственно, для perl" (я тут перефразировал вопрос из статьи).

Ну, не знаю... Как по мне, так штуки типа x if yчитаемости не вредят, а вот $x{"'"} и даже исходный $' ещё как вредят. И квалификация поддерживающих программистов тут ни при чём, вопрос скорее в количестве времени, которое они на эту поддержку потратят. Ну и "тренировка мозга" эта не особо приятная. Если уж хочется потренировать мозг, то лучше специальную задачку-головоломку отыскать, а при поддержке программы просто тупо прочитать и исправить ошибку.

Мне часто приходится разбираться с кодом библиотек с метаспана...

Бегун тренируется в беге, а силач - в поднятии штанги. Но если их поменять местами...

Когда же стартап развернётся, то его пытаются переписать на python.

Вы живете в какой то своей уютненькой вселенной.

Кто то вообще в здравом уме сейчас пишет на перл ?

Я работал на двух стартапах с perl в 2011-12-м годах и в 2-х крупных фирмах с ERP и web-магазином на perl. И там насчитывалось от 3-х до 10 perl-программистов.
А так выбор языка программирования на стартапе зависит от руководителя проекта.

в 2011-12-м годах

Кто то вообще в здравом уме _сейчас_ пишет на перл ?

Как то вы знатно застряли на 10 лет.

Вы не поверите: даже не доплачиваю, чтобы на нём программировать. )

Для "хобби" почему нет. У меня питон такой. А я вообще php'шник )

низкий порог вхождения и из-за этого меньше людей стремятся его освоить.

Может наоборот, высокий? Потому и меньше.

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

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

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

Забавно, вам плюсуют за короткую память )

Так короткая память это и есть основной рабочий инструмент айтишника.

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

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

Это прекрасно для кода - большой объем сложного алгоритма просто виден и понятен как на ладони. При этом неразвитый джуниор просто не понимает как можно посмотреть на экран и СРАЗУ увидеть в нем какую-то проблему.

Но из этого выходят следующие проблемы, включая социальные:

  1. Мозг привык не просто держать в голове большой кусок данных в быстрой памяти, но и активно его обрабатывать и рассматривать. В результате ЛЮБОЙ вопрос мозг автоматически хочет поднять до такого же уровня сложности. И простые бытовые вопросы вызывают боль из-за недостатка аргументов которые хочется рассмотреть. Отсюда идет мем про замороченность айтишников ненужными мелочами, вниманием к некритичным мелочам, попытки в простых вещах найти какой-то сложный момент и к нему прицепиться

  2. Мозг привык оперировать большими объемами краткосрочной памяти. Поэтому переключиться с одной задачи на другую с возрастом становится все сложнее именно из-за объема. Не выходит загрузить кусочек другой задачки. Ты ковыряешь объект объемом 10-20 экранов а тебя спрашивают какой сорт колбасы купить. Надо выгрузить несколько экранов кода и загрузить список сортов колбасы или хотя бы выгрузить из мозга код, и поменять приоритет над чем сейчас думать. Это даже не ментальный вопрос. Это практически биохимический вопрос - память же не виртуальная, просто физически это занимает время и усилия. Даже наличие некоторого склероза не мешает тебе хорошо анализировать то, над чем ты сейчас работаешь благодаря развитой аналитике быстрой памяти.

Чем старше и сеньорнее разработчик, тем глубже эти проблемы. Да, они поддаются некоторому социальному контролю. Кто-то из-за них ругается в семье, кто-то создает правила, кто-то просто медленно и добродушно переключается. Кто-то выработал в себе привычку действительно бытовые проблемы решать не с таким же азартом, как писать код. Но в целом эти два момента явно прослеживаются практически у всех, кого я знаю из знакомых айтишников 30-40+.

P.S. Было бы интересно, если грамотный нейробиолог скажет насколько я реалистичную картинку себе нарисовал с точки зрения современной медицины.

как сохранить все эти переменные в хеш кратко

Достаточно сохранить %-, @- и @+, все остальные это производные от @- и @+:


$` is the same as substr($var, 0, $-[0])
$& is the same as substr($var, $-[0], $+[0] - $-[0])
$' is the same as substr($var, $+[0])
$1 is the same as substr($var, $-[1], $+[1] - $-[1])
$2 is the same as substr($var, $-[2], $+[2] - $-[2])
$3 is the same as substr($var, $-[3], $+[3] - $-[3])

В свою очередь %+ это производная от %-.


PS: Можно даже написать простой класс-обёртку вокруг этого, чтобы иметь результат как экземпляр класса, используя $re->post, $re[1] etc (если его ещё нет на metacpan). Чуть-чуть пострадает производительность, конечно, но сохранение тоже не бесплатно.

Производные более краткие.

Ну а ещё один уровень абстракци конечно не помешает, если никуда не спешить. Обычно хочется успеть побольше.
)

Вы пишите абстракцию один раз (тут дел-то на полчаса максимум) — а используете потом вечно (если она не сильно убивает производительность или если это неважно).


А краткость в Perl… как выше уже упоминалось — для себя или таких же — да, вполне, одноразовый или просто write-only код — тоже, но не забывайте — код лучше писать с расчётом на то что сопровождать и поддерживать его будет склонный к насилию психопат, который знает, где вы живёте — вполне возможно что вы им станете если посмотрите на свой код лет через 10-15.

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

И все так пишут думая что это шутка

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации