Comments 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-программистов.
А так выбор языка программирования на стартапе зависит от руководителя проекта.
низкий порог вхождения и из-за этого меньше людей стремятся его освоить.
Может наоборот, высокий? Потому и меньше.
perl был прекрасен из-за очень низкого порога входа и при этом отличной работе с переменными, массивами и всем, что надо для парсинга прямо здесь.
Я вот читаю лекции по bash, и в загашнике есть несколько достаточно больших скриптов, но если месяц ничего серьезного не пишу, то уже подглядываю синтаксис обычных массивов в справке. А помнить в перле все нюансы спец-символов, если пишешь не каждый день - мрачновато.
Поэтому злоупотреблять чем-то подобным, неважно стартап или ентерпрайз. Ведь все это - продакшен, который теоретически может в будущем поддерживаться кем-то еще.
Забавно, вам плюсуют за короткую память )
Так короткая память это и есть основной рабочий инструмент айтишника.
Профессиональную деформацию я понимаю примерно так - в процессе разработки, программисту необходимо проанализировать текущий кусок кода (объект со всеми его методами и данными). Анализировать вещи, которые лежат в долгосрочной памяти невозможно - долго, неточно и так далее. Поэтому программист привыкает загружать в быструю память некий объем и уже с ним работает. Прогоняет мысленно алгоритм, видит как его воплотить в виде кода и так далее.
Со временем такая постоянная работа приучает мозг к тому, что в быструю память можно загружать куски побольше и активно их анализировать.
Это прекрасно для кода - большой объем сложного алгоритма просто виден и понятен как на ладони. При этом неразвитый джуниор просто не понимает как можно посмотреть на экран и СРАЗУ увидеть в нем какую-то проблему.
Но из этого выходят следующие проблемы, включая социальные:
Мозг привык не просто держать в голове большой кусок данных в быстрой памяти, но и активно его обрабатывать и рассматривать. В результате ЛЮБОЙ вопрос мозг автоматически хочет поднять до такого же уровня сложности. И простые бытовые вопросы вызывают боль из-за недостатка аргументов которые хочется рассмотреть. Отсюда идет мем про замороченность айтишников ненужными мелочами, вниманием к некритичным мелочам, попытки в простых вещах найти какой-то сложный момент и к нему прицепиться
Мозг привык оперировать большими объемами краткосрочной памяти. Поэтому переключиться с одной задачи на другую с возрастом становится все сложнее именно из-за объема. Не выходит загрузить кусочек другой задачки. Ты ковыряешь объект объемом 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.
Перезапись специальных переменных Perl регулярными выражениями