Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 90
Теги, конечно, впечатляют!
Как бывший перловщик со стажем (сейчас пишу на питоне) позволю себе несколько замечаний:
1. Использование регулярок вместо простых функций типа split и т.п. Далеко не правда. Справедливо разве что про разработчиков которые только вошли во вкус регулярок и пытаются решить с их помощью все проблемы (все мы помним про «теперь у вас две проблемы»).
2. Короткие имена переменных. Во-первых, практически во всех программах на всех языках программирования будут всякие $, $j, $k будут применятся для прохода по циклу, а $dx и $dy для смещения каких-либо данных. Ну так реально удобно. Во-вторых, для действительно используемых переменных (не как вышеприведенные ijk) существуют стандарты и соглашения о кодировании. Да, до этого нужно дорасти, но к этому рано или поздно приходешь. Сам или путем воздействия на твою целостность остальных разработчиков :)
3. Постфиксные if/unless. На мой взгляд это очень и очень хороший функционал (которого мне не хватает на питоне, приходится изворачиваться с A if B else C), НО в том случае если ВСЯ строка помещается на экране и легко читается/воспринимается. К примеру: die if $error;
Что касается конкретной приведенной программы: ну отписался линуксоид рабочей программой. Вам шашечки или ехать? Как поставить перл можно нагуглить. Если надо понять КАК программа работает, а не просто запустить и получить результат, ну напишите разработчику. Уверен, что он расскажет, а подобная форма написания программы была выбрана из-за того, что так просто быстрее.
1. Использование регулярок вместо простых функций типа split и т.п. Далеко не правда. Справедливо разве что про разработчиков которые только вошли во вкус регулярок и пытаются решить с их помощью все проблемы (все мы помним про «теперь у вас две проблемы»).
2. Короткие имена переменных. Во-первых, практически во всех программах на всех языках программирования будут всякие $, $j, $k будут применятся для прохода по циклу, а $dx и $dy для смещения каких-либо данных. Ну так реально удобно. Во-вторых, для действительно используемых переменных (не как вышеприведенные ijk) существуют стандарты и соглашения о кодировании. Да, до этого нужно дорасти, но к этому рано или поздно приходешь. Сам или путем воздействия на твою целостность остальных разработчиков :)
3. Постфиксные if/unless. На мой взгляд это очень и очень хороший функционал (которого мне не хватает на питоне, приходится изворачиваться с A if B else C), НО в том случае если ВСЯ строка помещается на экране и легко читается/воспринимается. К примеру: die if $error;
Что касается конкретной приведенной программы: ну отписался линуксоид рабочей программой. Вам шашечки или ехать? Как поставить перл можно нагуглить. Если надо понять КАК программа работает, а не просто запустить и получить результат, ну напишите разработчику. Уверен, что он расскажет, а подобная форма написания программы была выбрана из-за того, что так просто быстрее.
> Что касается конкретной приведенной программы: ну отписался линуксоид рабочей программой. Вам шашечки или ехать?
Вот-вот. Если б автору для решения конкретной проблемы предложили готовый экзешник, он бы тоже жаловался, что его невозможно понять (и да, работает не на всех операционках), а значит те, кто компилирует в .exe, извращенцы?
Сам писал года три на перле, теперь столько же на джаве пишу. Считаю, что пишу на джаве в соответствии с джавовскими концепциями, а на перле — в соответствии с перловыми. На перле можно писать красиво и правильно, он имеет хорошую выразительную силу. К примеру, цепочки с замыканиями типа map {...} grep {...} split /\t/ читаются гораздо легче и быстрее, чем код с аналогичным функционалом, написанный на Java (нормальных лямбд так пока и не вставили). В общем, каждый язык хорош по-своему, а в плохой программе зачастую виноват программист, а не язык.
Вот-вот. Если б автору для решения конкретной проблемы предложили готовый экзешник, он бы тоже жаловался, что его невозможно понять (и да, работает не на всех операционках), а значит те, кто компилирует в .exe, извращенцы?
Сам писал года три на перле, теперь столько же на джаве пишу. Считаю, что пишу на джаве в соответствии с джавовскими концепциями, а на перле — в соответствии с перловыми. На перле можно писать красиво и правильно, он имеет хорошую выразительную силу. К примеру, цепочки с замыканиями типа map {...} grep {...} split /\t/ читаются гораздо легче и быстрее, чем код с аналогичным функционалом, написанный на Java (нормальных лямбд так пока и не вставили). В общем, каждый язык хорош по-своему, а в плохой программе зачастую виноват программист, а не язык.
Ну конкретно этот человек тут присутствует на правах местного деревенского дурачка, профессионально оставшегося где-то в середине 90-х, которому позволительно тыкать в окружающих пальцем.
Этот пост может напомнить разработчику о том, что его приложение живет не по отдельности, а в рамках среды рабочей станции, и навязывание экстренных оповещений может сложиться в крайне неприятную для пользователя картину, хотя отдельно взятое сообщение при этом может казаться достаточно безобидным.
О чем может рассказать пост с пыльными лулзами из древней фидошной эхи, посвященными умирающему языку я не знаю. Ну разве что программисты бывают хорошие и бывают плохие. Неожиданно.
О чем может рассказать пост с пыльными лулзами из древней фидошной эхи, посвященными умирающему языку я не знаю. Ну разве что программисты бывают хорошие и бывают плохие. Неожиданно.
Во-первых, делаются далеко идущие выводы по частному случаю. Во-вторых, такие программеры есть на любом языке программирования.
Системные администраторы использующие Perl для скриптования задач и программисты на Perl по хорошему должны быть РАЗНЫМИ людьми. То что вы тут написали касается первых.
У перла таже самая проблема как и у пхп — не было четкого вектора развития, вот и результат.
Вполне себе четкий вектор развития: Practical Extraction and Report Language, а потом полетели в веб и администрирование.
Четкий вектор развития не генерирует такого (например классы в перле и помойка функций в глобальном неймспейсе в пхп)
А что с классами в перле не так? Их просто нет.
Они как бы есть, но в целом вы правы, их фактически нет. В php, классы тоже как бы есть, но сбоку. К примеру массив остался совсем не классом, расширения — кто во что горазд: одни засирают кучей функций глобальную область видимости, другие один мегакласс напишут с кучей членов, третьи вообще извратятся — одна процедура и дергайте коллбеки через неё. Все эти мешанины подходов и демонстрируют отсутствие этого самого четкого вектора развития.
я гдето говорил что «хочу в перле ооп»? я сказал лишь об отсутствии вектора. А ваш PS скорее не про то «куда» перл двигается а, про то «как»
Развёрнуто это было бы отдельная статья, а не комментарий. Так как я не умею обтекаемо выражаться, то боюсь «батхёрт» вызванный такой статьей выльется в минус тыще к карме :) Посмотрите на современные языки, что в них есть и как они развиваются. Сравните со «старичками», сделайте выводы.
perldoc perlobj?
Ну согласитесь же, что ISA и bless ну никак нельзя назвать реализацией классов в общем смысле. Это залепа, превращающая модуль в некий объект.
Нет, не соглашусь ни в коем разе, что isa и bless — это нормальная реализация. Это недоклассы, превращение модулей в классы это совсем не типичная реализация. Вот в 6 перле рассово-верные классы. Равно как в руби, сях и иже с ними. А в перле это синтетическая штука, не позволяющая реализовать обычный функционал классов. Намучался с ней весьма не мало в свое время. Moose да, хорош. Но это всё равно расширение языка, а не базовый функционал.
Объектный механизм perl минимален в плане ограничений, поэтому можно реализовать всё что угодно. Даже в базовом виде легко реализуются такие ооп-понятия как класс, объект, методы/аттрибуты, наследование (в т.ч. множественное), полиморфизм, инкапсуляция (см. perldoc perlootut)
Рассматривать perl отдельно от CPAN — это практически нонсенс ) timtowtdi — берите любую понравившуюся реализацию ооп на cpan'e. Если затрудняетесь с выбором, то возможно поможет perlootut#perl-oo-systems или книжка Modern Perl Book
Рассматривать perl отдельно от CPAN — это практически нонсенс ) timtowtdi — берите любую понравившуюся реализацию ооп на cpan'e. Если затрудняетесь с выбором, то возможно поможет perlootut#perl-oo-systems или книжка Modern Perl Book
я думаю, что Ларри не решил создавать отдельно классы, а решил создать функцию bless, которая доводит модуль до класса,
чтобы не плодить лишнего.
чтобы не плодить лишнего.
Да уж, пример кода на перле действительно веселый, особенно на первый взгляд!
Mithgol, пример, который вы привели, называется one liner. Его специально пишут так, чтобы он поместился в одну короткую строку. И вы правы, это write-only. Написал, запустил, забыл — вся жизнь oneliner-а. Его даже не сохраняют.
Когда пишут обычные скрипты или программы на перле, пишут нормально. Не зачёт.
Когда пишут обычные скрипты или программы на перле, пишут нормально. Не зачёт.
>запись управляющих конструкций в противоестественном порядке
Сей порядок вовсе не противоестественен, а очень даже наоборот, наиболее приближен к натуральным языкам.
Ибо я могу сказать как «Ежели вам не трудно, Мицгол, не несите чушь», так и «Мицгол, не несите чушь, ежели вам не трудно».
Сей порядок вовсе не противоестественен, а очень даже наоборот, наиболее приближен к натуральным языкам.
Ибо я могу сказать как «Ежели вам не трудно, Мицгол, не несите чушь», так и «Мицгол, не несите чушь, ежели вам не трудно».
Язык это инструмент. Умение правильно им пользоваться, писать простой, понятный, читабельный, эффективный код это и есть показатель професионализма разработчика. Как программист с опытов в 7 лет могу сказать, что писать write-only можно на любом языке. Не раз в этом убеждался.
В последний год работаю в комманде разработчиков высокого уровня над крупным проектом основным языком, которого является Perl. Код никак нельзя назвать write-only.
То, что описано в статье, как правило, пишут либо начинающие, либо одиночки, кроме которых этот код никто читать не будет.
В последний год работаю в комманде разработчиков высокого уровня над крупным проектом основным языком, которого является Perl. Код никак нельзя назвать write-only.
То, что описано в статье, как правило, пишут либо начинающие, либо одиночки, кроме которых этот код никто читать не будет.
Программиста никто не заставляет писать write-only код.
Наоборот, в man perlstyle написано, как надо правильно оформлять перловый код.
Наоборот, в man perlstyle написано, как надо правильно оформлять перловый код.
Порция гомофобия в конце убила желание плюсануть. Впрочем, потом я дочитал до имени автора.
А я догадался об авторстве, как только дочитал до фразы «в терминах православного христианства можно называть гордынею, а в терминах люркморского жидокащенизма можно называть ЧСВ (чувством собственного величия).»
ЧСВ кстати — чувство собственной важности.
Когда-то очень давно я использовал перл для парсинга разных текстовых файлов, скачанных из инета сайтов (тогда интернет был по dial-up, помню на ночь ставил на закачку интересные сайты с технической документацией, а потом вырезал из них баннеры). Язык своеобразный, но он мне нравился именно за эту своеобразность, «хакерский дух» если можно так выразиться. И регулярные выражения очень нравились, я поначалу жалел что в Си такой возможности нету:)
ЧСВ кстати — чувство собственной важности.
Когда-то очень давно я использовал перл для парсинга разных текстовых файлов, скачанных из инета сайтов (тогда интернет был по dial-up, помню на ночь ставил на закачку интересные сайты с технической документацией, а потом вырезал из них баннеры). Язык своеобразный, но он мне нравился именно за эту своеобразность, «хакерский дух» если можно так выразиться. И регулярные выражения очень нравились, я поначалу жалел что в Си такой возможности нету:)
В-третьих, Perl допускает запись управляющих конструкций в противоестественном порядке «код оператор условие» (например, «код unless условие» или «код if условие»).
Ничего противоестественного в этом нет. Более того, это вполне привычный порядок для обыденной речи: «отослать сообщение, если книги кончились».
Более подробно можно прочитать в книге «DSLs in Boo» (Ayende Rahien, Manning, 2010), которая не имеет никакого отношения к Perl.
Порядок все-таки противоестественный. Сначала должна быть проверка условия, а затем код — именно так происходит при выполнении кода, именно так человек читает программу и воспринимает ее, именно так устроено синтаксическое дерево. Зачем ставить все с ног на голову?
Кстати, похожая пробема — когда в некоторых языках при объявлении переменных сначала перечисляются имена, а затем объявляется что это такое (тип, модификаторы). Типа «i, j, k: integer». Сейчас такой стиль объявления почему-то возвращается в Scala, Go и некоторых других новых языках.
Кстати, похожая пробема — когда в некоторых языках при объявлении переменных сначала перечисляются имена, а затем объявляется что это такое (тип, модификаторы). Типа «i, j, k: integer». Сейчас такой стиль объявления почему-то возвращается в Scala, Go и некоторых других новых языках.
В естественных языках такое встречается. Значит, порядок можно признать естественным.
P. S. Если кто не в курсе, Ларри Уолл, автор перла — лингвист.
P. S. Если кто не в курсе, Ларри Уолл, автор перла — лингвист.
А, ну если естественность понимать в этом смысле, то тогда в Викицитатнике нетрудно разыскать ещё одну цитату из Дейкстры к этому случаю:
— Проекты, предлагающие программирование на естественном языке, гибельны по своей сути.
— Проекты, предлагающие программирование на естественном языке, гибельны по своей сути.
Во многих языках тип указывается после имени переменной.
Такой порядок логичен по трем причинам:
1) Название переменной зачастую несет больше информации, чем ее тип. Мне, как программисту, тип чаще всего не важен. Мне важно как (логически) использовать переменную, а это определяется далеко не ее типом.
2) Имена типов бывают длинными как песьня с припевом. Искать глазами название переменной после этого типа, который кроме важной информации несет много служебной, зачастую неудобно.
3) В scala имена переменных начинаются на одном уровне (ппятый символ с начала строки) не зависимо от того, указан ли тип или используется выведение типов. Это облегчает чтение кода.
Такой порядок логичен по трем причинам:
1) Название переменной зачастую несет больше информации, чем ее тип. Мне, как программисту, тип чаще всего не важен. Мне важно как (логически) использовать переменную, а это определяется далеко не ее типом.
2) Имена типов бывают длинными как песьня с припевом. Искать глазами название переменной после этого типа, который кроме важной информации несет много служебной, зачастую неудобно.
3) В scala имена переменных начинаются на одном уровне (ппятый символ с начала строки) не зависимо от того, указан ли тип или используется выведение типов. Это облегчает чтение кода.
именно так человек читает программу
Вы замените «человек» на «программист», и ваше утверждение может быть верным. Я не зря дал ссылку на книжку, там эта ситуация разбирается, в том числе и с точки зрения читабельности кода.
Я бы сказал, что такой способ появился и в C++. Во всяком случае для функций (auto f() -> int). Данный способ удобен в шаблонном программировании для выведения типа. Думаю с такой же целью это сделано и в Go.
Новый синтаксис объявления функций в C++ как раз не противоречит принципу «сначала известное, потом неизвестное». Сначала мы пишем «auto» — декларируем объявление (здесь было бы уместнее новое ключевое слово типа «func», но увы, на такое по понятным причинам никогда не пойдут), затем само объявление. И внутри него — сначала то, что на входе (список параметров), затем то что на выходе (возвращаемое значение).
Почти любой код можно признать абракадаброй если написать его в одну строку.
Всё это х**ня, а автор полнейший мудак!
use Perl or die;
use Perl or die;
>… постепенно развивают в программисте довольно неприятное качество презрения к окружающим непрограммистам…
Да! Мы такие! :-DDD
Да! Мы такие! :-DDD
Вот кстати, да, я прочитал по перлу три книги, и нигде не видел, чтобы длинный регексповый паравоз был бы разбит на строки, комментирующие каждую часть. Между тем, для нормального чтения сторонним человеком это, имхо, единственное подходящее форматирование.
Человек специально написал однострочник на perl и сделал его коротким, чтобы другим людям было проще его запустить. Но за это был почти предан анафеме. Однако.
Противоестесвенные порядок есть не только в perl, занчит пора писать статью и про проф. деформацию и ruby программистов.
Противоестесвенные порядок есть не только в perl, занчит пора писать статью и про проф. деформацию и ruby программистов.
Хватит уже мусолить тему о том, что perl — это write-only и вообще нечитаемая ересь. Да, написать можно так, что никто ничего не поймет без бутылки водки, а то и двух. НО! Никто же не заставляет так писать.
А вообще некоторые конструкции весьма удобны и логичны — тот же code if условие. Просто надо набраться опыта и проникнуться философией.
Не лезет? Значит язык не для вас. Никто же не жалуется, что Brainfuck практически нечитаем.
А вообще некоторые конструкции весьма удобны и логичны — тот же code if условие. Просто надо набраться опыта и проникнуться философией.
Не лезет? Значит язык не для вас. Никто же не жалуется, что Brainfuck практически нечитаем.
Бггггг
Если бы меня попросили что-то написать для ФИДО, я бы завернул что-нибудь еще менее читаемое и максимально трудно запускаемое, чтобы оно гармонировало с остальным так называемым программным обеспечением фидонета.
И там бы обязательно была бы регекспа s/H/Н/g %) Если вы понимаете, о чем я :)
Если бы меня попросили что-то написать для ФИДО, я бы завернул что-нибудь еще менее читаемое и максимально трудно запускаемое, чтобы оно гармонировало с остальным так называемым программным обеспечением фидонета.
И там бы обязательно была бы регекспа s/H/Н/g %) Если вы понимаете, о чем я :)
С++ тоже изрядно write-only…
значит, он и свои собственные переменные со временем начнёт называть однобуквенно (наподобие $l, $f, $u),
Я так не делаю, и мои коллеги по работе тоже.
Язык языком, а голова на плечах не зависит от него.
Я так не делаю, и мои коллеги по работе тоже.
Язык языком, а голова на плечах не зависит от него.
А если так? Что тут может быть непонятного?
next unless /(([^,]*,){6,})U(.*)/;
($l, $u) = ($1, $3);
while ($u =~ /^(.*,)?(T[A-Xa-x]{2}),?(.*)/) {
$l .= "$2,";
$u = "$1$3"
};
$_ = "${l}U$u\n";
s/,U?,?\s*$/\n/
next unless /(([^,]*,){6,})U(.*)/;
($l, $u) = ($1, $3);
while ($u =~ /^(.*,)?(T[A-Xa-x]{2}),?(.*)/) {
$l .= "$2,";
$u = "$1$3"
};
$_ = "${l}U$u\n";
s/,U?,?\s*$/\n/
Я ужé сформулировал во блогозаписи пару недостатков этого кода:
Что было непонятно?
Почему в комментариях читатели постепенно пришли к выводу, что на самом деле мне не нравится запись кода в одну строку без разбиения на несколько строк?
- Чрезмерное употребление регулярных выражений (которые читаются медленно и с трудом) вместо библиотечных функций строкового анализа (смысл которых мгновенно явствует по их названию).
- Употребление однобуквенных переменных (смысл которых осознаётся медленно и с трудом) вместо осмысленных имён переменных (смысл которых мгновенно явствует по их названию).
Что было непонятно?
Почему в комментариях читатели постепенно пришли к выводу, что на самом деле мне не нравится запись кода в одну строку без разбиения на несколько строк?
Вообще этот one-liner не может сходу прочитать человек который а) не знает Perl; б) не знает синтаксис регулярных выражений.
Я на Питоне пишу, но всё равно худо-бедно-приблизительно сообразил что здесь к чему :)
А вообще не в языке проблема, а в кривых рученьках.
И на Бейсик с Коболом Дийкстра зря гнал: нормальные языки, каждый для своих целей.
Пишите программы, любите друг друга :)
Я на Питоне пишу, но всё равно худо-бедно-приблизительно сообразил что здесь к чему :)
А вообще не в языке проблема, а в кривых рученьках.
И на Бейсик с Коболом Дийкстра зря гнал: нормальные языки, каждый для своих целей.
Пишите программы, любите друг друга :)
Подвергшиеся этой деформации программисты либо искреннейше забывают, что не все вокруг программируют на Perl под Linux, либо совершенно плевать хотели на судьбу тех лиц, которые не программируют на Perl под Linux, либо проявляют деятельное желание как-нибудь наказать тех, кто не программирует на Perl под Linux.Хотелось бы отметить, что автоматически обычно говорят со своей колокольни. Дело не в ЧСВ, просто есть проблема, есть решение. Им поделились. Не подошло, ну и ладно. И пользователи Windows в равной степени на задумываясь отвечали бы о своей системе. «Нажмите кнопку Пуск», «На диске Цэ»…
Все унылое — и телега автора на язык (хоть сам с перла на CoffeeScript прехожу), и его выводы и приведенный однострочник.
/(([^,]*,){6,})U(.*)/
Вам, мелким людишкам, не способным прочитать простую регулярку, не понять :) ХА-ХА-ХА
Хм, не программировал на Perl более 2-х лет, но фраза «подпадает под определение write-only» неверная, ибо я с легкостью его прочитал, чуть подумал над регулярками и понял их.
И ещё один комментарий по поводу постфиксных
Это не полноценные операторы, это модификаторы. И в
по-моему, гораздо выразительнее, чем
или не дай бог
if/while/for....Это не полноценные операторы, это модификаторы. И в
perlstyle (если не ошибаюсь) очень чётко обозначено их предназначение: поставить акцент не на условии, а на выполняемом действии. В других случаях — не использовать.die if $anything > 100500 && check_anything_else ($anything, $anything2);
по-моему, гораздо выразительнее, чем
if ($anything > 100500 && check_anything_else ($anything, $anything2))
{
die;
}
или не дай бог
if ($anything > 100500 && check_anything_else ($anything, $anything2)) { die; }
Когда-то читал весьма полезную статью с названием что-то типа «как побеждать в споре». Что существенно — не в дискуссии с аргументацией, а именно в споре, с переходом на личности и уклонением от темы etc… ). И очень похоже, что автор поста не преминул воспользоваться некоторыми не особо щепетильными приемчиками )). Впрочем, по пунктам:
1. Мощность имплементации регулярок в перле, на голову превышающую оную в других языках. Очевидное достоинство, но нет, автор твердо считает что это недостаток, ибо от недостатка ума на мощном языке можно написать некрасивую программу. То что в других языках приходится писать простыни кода для кратких действий — этот факт автором сознательно (а сознательно ли?) игнорируется.
2. Из факта использования технических встроенных в спецификацию нескольких (их весьма немного) переменных $1, $2.., $_, которые в принципе невозможно переименовать каким либо семантическим образом, автор делает (логически совершенно необоснованный) вывод, что программист будет использовать только короткие имена для собственных переменных. Что ж, прием действительно может сработать против тех, кто не знает что такое перл, но зачем вводить читателей в заблуждение?
3. Да, допускает. Перл много чего допускает, ассемблер с фортраном куда меньше, и что теперь? Сравним-ка:
if(flag_A == 1) {
use_A ++;
}
if(flag_B == 1) {
use_B ++;
}
и
$use_A ++ if $flag_A == 1;
$use_B ++ if $flag_B == 1;
Для программиста, получающего оклад за кол-во строк кода, очевидно, первый вариант в три раза предпочтительнее. Но я вот предпочитаю лаконичный (но стуктурированный и красивый код), когда не надо листать десятки екранов, чтобы увидеть ход выполнения кода.
Автор может справедливо возразить — но ведь можно ж таки написать нечитаемый код с помощью всяких хитрых перловых конструкций! Разумеется нечитаемый код на перле написать можно, как и в ЛЮБОМ другом языке, и что с того??? Упомянутые конструкции позволяют также создавать и лаконичный красивый код (собственно, именно для этого они и введены в язык), этот фактор автором опять сознательно (ли?) игнорируется.
4. Ну тут и возразить не знаю что. Раз программист на перле умеет разбираться в перловом коде, а другие нет — значит он мудак, без вариантов. Я правильно выразил посыл автора?
Ну и ещё несколько замечаний.
Во первых, перловый скрипт в примере — однострочный. Он может выглядить двустрочным, трехстрочным, n-строчным — но он принадлежит к специальному классу скриптов — однострочные рецепты. И кстати, они не обязаны легко читаться, парсить все варианты входов и выводить на все ошибки вразумительные диагностические сообщения. Скорее наоборот даже. Суть таких скриптов — сделать работу в конкретном окружении (поэтому для винды такие скрипты надо адаптировать), на конкретном материале, когда заранее известно что данные такого-то формата, когда запускающий знает места и памяти хватает, и вообще — нечего заниматься проверкой тех ошибок, которые все равно никогда не возникнут. А ещё такие скрипты очень удобно использовать в качестве примера того, каким нечитаемым может быть код на том языке, на котором они написаны :)
Во вторых, посмотрел бы я как автор решил бы указанную в посте проблему с ноделистами )) Прислал бы uu-аттач с С-кодом, к нему makefile, список либ-зависимостей и ман по запуску? Что-то сомнительно. Или может структурированный самодокументированный php-файл. Впрочем, с чего бы это специалисту по php использовать фишку перла (pod-самодокументацию). А, и ещё не забыть указать какие модули в php надо что-бы были вкомпилены (это ж не перл с явным указанием используемых модулей).
Что ещё добавить? man perl ;)
1. Мощность имплементации регулярок в перле, на голову превышающую оную в других языках. Очевидное достоинство, но нет, автор твердо считает что это недостаток, ибо от недостатка ума на мощном языке можно написать некрасивую программу. То что в других языках приходится писать простыни кода для кратких действий — этот факт автором сознательно (а сознательно ли?) игнорируется.
2. Из факта использования технических встроенных в спецификацию нескольких (их весьма немного) переменных $1, $2.., $_, которые в принципе невозможно переименовать каким либо семантическим образом, автор делает (логически совершенно необоснованный) вывод, что программист будет использовать только короткие имена для собственных переменных. Что ж, прием действительно может сработать против тех, кто не знает что такое перл, но зачем вводить читателей в заблуждение?
3. Да, допускает. Перл много чего допускает, ассемблер с фортраном куда меньше, и что теперь? Сравним-ка:
if(flag_A == 1) {
use_A ++;
}
if(flag_B == 1) {
use_B ++;
}
и
$use_A ++ if $flag_A == 1;
$use_B ++ if $flag_B == 1;
Для программиста, получающего оклад за кол-во строк кода, очевидно, первый вариант в три раза предпочтительнее. Но я вот предпочитаю лаконичный (но стуктурированный и красивый код), когда не надо листать десятки екранов, чтобы увидеть ход выполнения кода.
Автор может справедливо возразить — но ведь можно ж таки написать нечитаемый код с помощью всяких хитрых перловых конструкций! Разумеется нечитаемый код на перле написать можно, как и в ЛЮБОМ другом языке, и что с того??? Упомянутые конструкции позволяют также создавать и лаконичный красивый код (собственно, именно для этого они и введены в язык), этот фактор автором опять сознательно (ли?) игнорируется.
4. Ну тут и возразить не знаю что. Раз программист на перле умеет разбираться в перловом коде, а другие нет — значит он мудак, без вариантов. Я правильно выразил посыл автора?
Ну и ещё несколько замечаний.
Во первых, перловый скрипт в примере — однострочный. Он может выглядить двустрочным, трехстрочным, n-строчным — но он принадлежит к специальному классу скриптов — однострочные рецепты. И кстати, они не обязаны легко читаться, парсить все варианты входов и выводить на все ошибки вразумительные диагностические сообщения. Скорее наоборот даже. Суть таких скриптов — сделать работу в конкретном окружении (поэтому для винды такие скрипты надо адаптировать), на конкретном материале, когда заранее известно что данные такого-то формата, когда запускающий знает места и памяти хватает, и вообще — нечего заниматься проверкой тех ошибок, которые все равно никогда не возникнут. А ещё такие скрипты очень удобно использовать в качестве примера того, каким нечитаемым может быть код на том языке, на котором они написаны :)
Во вторых, посмотрел бы я как автор решил бы указанную в посте проблему с ноделистами )) Прислал бы uu-аттач с С-кодом, к нему makefile, список либ-зависимостей и ман по запуску? Что-то сомнительно. Или может структурированный самодокументированный php-файл. Впрочем, с чего бы это специалисту по php использовать фишку перла (pod-самодокументацию). А, и ещё не забыть указать какие модули в php надо что-бы были вкомпилены (это ж не перл с явным указанием используемых модулей).
Что ещё добавить? man perl ;)
а нет ли у автора поста каких либо примеров деформаций на почве bash или awk или sed…
не трогайте святое своими немытыми руками.
не трогайте святое своими немытыми руками.
чем больше возможностей, тем больше вероятность напороться на товарища, который использует максимум неочевидных вариантов в одном месте и хорошо, если там не будет ошибок.
— однострочник
— написанный программистом для программистов (или nodelist'ы в фидо обсуждали домохозяйки, которые впервые услышали про перл?)
— var = 42 if somevar is not None else 33 — это питон, да.
А тот факт, что программист на любом языке обязан уметь читать регулярки, я вообще оставлю за кадром.
— написанный программистом для программистов (или nodelist'ы в фидо обсуждали домохозяйки, которые впервые услышали про перл?)
— var = 42 if somevar is not None else 33 — это питон, да.
А тот факт, что программист на любом языке обязан уметь читать регулярки, я вообще оставлю за кадром.
Случайно наткнулся на статью. Почитал каменты.
Интересно, почему никто не видит главное упоминание, что пользователь работает под windows, где эта регулярка даже при установленном perl работать не будет из-за особенностей экранирования символов и раскрытия мета-символов?
Регулярка как регулярка, вполне даже читабельная. Но главное-то, что эта регулярка бесполезна пользователю винды. А под рукой в то время не у каждого был линукс, а виртуалок в те годы на обычных десктопах еще не было. То есть прислали «соверешнно верный и бесполезный ответ».
Интересно, почему никто не видит главное упоминание, что пользователь работает под windows, где эта регулярка даже при установленном perl работать не будет из-за особенностей экранирования символов и раскрытия мета-символов?
Регулярка как регулярка, вполне даже читабельная. Но главное-то, что эта регулярка бесполезна пользователю винды. А под рукой в то время не у каждого был линукс, а виртуалок в те годы на обычных десктопах еще не было. То есть прислали «соверешнно верный и бесполезный ответ».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Четыре профессиональные деформации программистов на языке Perl, демонстрируемые на живом примере