Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Perl: Общие вопросы > Критический анализ Perl, статья


Автор: Zuzu 15.1.2007, 18:04
Глубокоуважаемые!

Нашел такую вот статейку на просторах Интернета.

"Критический анализ языка PERL"

http://www.stanislaw.ru/rus/research/perl.asp

Статейка старая, но забавная.

Кто что скажет по этому поводу - хочется услышать компетентное мнение специалистов, для которых Perl - повседневный рабочий инструмент smile

Автор: Nab 15.1.2007, 19:17
Все не осилил, возможно позже дочитаю....
Автор говорит все верно, все что он описал, действительно присутствует в языке.
Просто то что он считает недостатком, я считаю достоинствами smile

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

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

Автор: tishaishii 15.1.2007, 23:05
А мне по-барабану, лишь бы результат был.
С Perl для меня всё проще.

Автор: nitr 16.1.2007, 01:34
Думаю много говорят по этой теме...
Что добавлю smile 
1) http://golovinov.moikrug.ru/ не впечатлил
2) Perl - это Perl
3) Работу над ошибками необходимо сделать...
4) Язык не выбирает свой путь, не выбирает программистов, всё наоборот ;)
5) А что если анализ др. нетипиз. языков сделать? smile
6) Идеалов нет smile 
7) Программируя на Perl, необходимо программировать на Perl (имхо - истина)

з.ы.: читаем perldoc smile)))

Автор: korob2001 16.1.2007, 09:58
use strict - и большая половина проблем отлетит сама собой.

Давайте теперь, попробуем проанализировать пример кода, который приводит автор этой статьи. Т.е. код который писал он лично. Вот цитата:
Цитата

Но и это ещё куда ни шло по сравнению с тем обстоятельством, что в PERL вообще невозможно различать строки и числа. Дело в том, что PERL всегда представляет числа как строки, а неявные преобразования происходят по мере необходимости при вычислениях выражений и присваиваниях. Возможно, что с точки зрения автора данного языка это "круто", да вот с точки зрения практического программирования это совсем не круто, поскольку чревато такими трудноуловимыми "глюками" (иначе и не назовёшь), о каких Larry Wall, наверное, и не догадывался. Вот реальный пример из собственной практики автора.

Итак, есть модуль, реализующий набор функций для обработки дат. Функции этого модуля, манипулирующие с датами, принимают значения дат в виде упорядоченных троек чисел, обозначающих, соответственно, год, месяц и день. Кроме того, модуль реализует пару функций, одна из которых для переданного строкового представления даты в виде "YYYY-MM-DD" (а если более точно, то в виде ^\d{1, 4}-\d{1, 2}-\d{1, 2}$; такая форма представления дат используется, например, сервером БД MySQL) возвращает соответствующую упорядоченную тройку чисел, которую затем можно использовать с функциями обработки дат, а вторая выполняет обратное преобразование, формируя из переданной упорядоченной тройки чисел строковое представление даты точно в виде "YYYY-MM-DD", которое затем можно использовать, например, при конструировании SQL-запроса. Вот их текст:
Код

sub ToString {
     my ($Year, $Month, $Day) = @_;
 
     return
        (
           $Year < 10 ? "000" : (
              $Year < 100 ? "00" : ($Year < 1000 ? "0" : "")
           )
        ).$Year."-".
        ($Month < 10 ? "0" : "").$Month."-".
       ($Day < 10 ? "0" : "").$Day;
 }

sub ToNumberList {
    my $Date = $_[0];
    my ($Year, $Month, $Day) =
       $Date =~ /^(\d{1, 4})-(\d{1, 2})-(\d{1, 2})$/;

    if (!(defined($Year) && defined($Month) && defined($Day))) {
       ($Year, $Month, $Day) = (0, 0, 0);
    }

    return ($Year, $Month, $Day);
}


Проблема была в том, что при попытке выполнить вот такой вызов с совершенно правильным аргументом

ToString(ToNumberList("0800-01-01"));

возвращалась неправильная строка "00800-001-001", которая потом приводила к ошибке там, где она использовалась далее. Причина на самом деле в том, что PERL хранит числа в виде строк, а при вычислениях автоматически преобразует строки в числа и наоборот. Поэтому для того, чтобы решить данную проблему и сделать модуль "пуленепробиваемым", пришлось строку 1 заменить на следующие:

my $Year = $_[0] + 0;
my $Month = $_[1] + 0;
my $Day = $_[2] + 0;

а строку 22 на вот это:

return ($Year + 0, $Month + 0, $Day + 0);

что хоть и выглядит очень глупо, зато работает справно.

Об именах переменных и подпрограмм, я даже говорить не хочу. Этот стиль врядле кто-то одобрит.

Зачем для получения даты в формате yyyy-mm-dd или каком-нить подобном, создавать подрограмму в модуле?
Можно же было бы написать и такой код:
Код

my $str_date = sprintf("%04d-%02d-%02d", 2006,8,5);

Эта строка кода избавляет автора от следующего гемороя:
Код

sub ToString {
     my ($Year, $Month, $Day) = @_;
 
     return
        (
           $Year < 10 ? "000" : (
              $Year < 100 ? "00" : ($Year < 1000 ? "0" : "")
           )
        ).$Year."-".
        ($Month < 10 ? "0" : "").$Month."-".
       ($Day < 10 ? "0" : "").$Day;
 }

Плюс от того, решения к которому он пришёл. Я имею ввиду это:
Цитата

my $Year = $_[0] + 0;
my $Month = $_[1] + 0;
my $Day = $_[2] + 0;

а строку 22 на вот это:

return ($Year + 0, $Month + 0, $Day + 0);

что хоть и выглядит очень глупо, зато работает справно.

Выглядит действительно очень глупо.
Короче таких косяков там довольно много. Автор сильно далёк от понимания контекста. Очень важно понимать его и о этом написано практически во всех учебниках по Perl.
Например его сильно удивляет, как это можно присвоить список скаляру или наоборот.  smile 
Именно это и сводит его с ума.

Автор: DENNN 16.1.2007, 11:49
+1

Автор: Shaggie 16.1.2007, 12:51
Цитата

$i = 1;
$s = "Number ".i;
print($s); # печать строки "Number i" вместо ожидаемой "Number 1"

Да! Это аргумент! Я бросаю Перл навсегда! Автору респект, не ожидал такой сильной хохмы. А ведь перед этим он скромно упомянул, что знает около десяти ЯП но не собирается этим хвалиться...

А если серьезно, автор мало того что пишет в предвзято негативном стиле (в "Programming Perl", кстати, минусы и опасные места описаны наравне с плюсами), так еще и нагло издевается над самим языком и его создателем, а в статье, ориентированной якобы на "аналитическую критику", подобные выпады смотрятся просто дико!
Интересно, он только над Перлом так издевался, или в С тоже пытался этакие шутки пошутить? Неужели нет никакой необходимости учитывать контекст самого ЯП, выполняемых им задач? А следить за тем, что пишешь, тоже нужды нет?
Такую статью можно написать о любом языке программирования, было бы желание. К сожалению, пишут и похлеще... зашел давеча на linuxsuxx.org... Сколько ж в людях агрессии и ненависти!

Автор: Shaggie 16.1.2007, 13:32
Цитата

Наличие своей области видимости для каждого блока – излишество, вполне достаточно двух областей видимости: область видимости модуля и область видимости подпрограммы.

Да-да, в PHP так и есть, только вот при работе с большим проектом мне удобства это никогда не добавляло, а как бы даже и наоборот... все имхо, разумеется. smile 

Автор: amg 16.1.2007, 16:04
Необъективная статья. Достоинства перла перевернуты с ног на голову и объявлены недостатками. Конечно, если использовать аргументы типа "порядок лучше, чем анархия", то легко можно доказать, что тоталитаризм лучше, чем демократия. 
Конкретный пример:
Код

Так, например, для выделения TLD (top level domain) из полного доменного
имени вполне можно использовать простые функции обработки строк rindex и
substr, как показано в следующем фрагменте исходного кода:

$TLD = "";
$p = rindex($DomainName, ".");
# Если символ "." не найден, то доменное имя не верно,
# и TLD не может быть выделен, в противном случае выделяем TLD функцией
# substr
if ($p != -1) {
   $TLD = substr($DomainName, $p + 1);
}

Однако в мире программистов на PERL такой простой, ясный и эффективный
подход, по-видимому, не приветствуется, поскольку нужно слишком много писать
и слишком много думать. Ещё бы! Ведь если верить словам автора PERL, то "   
the three great virtues of a programmer: laziness, impatience, and hubris"1 
[1]. С их точки зрения, гораздо удобнее написать всё, по возможности, в одну
строку, например так:

($TLD) = $DomainName =~ m/.*\.(.*)/; # $TLD необходимо заключить в круглые  
                                     # скобки, указав тем списковый контекст

Однако несмотря на то, что в первом варианте в пять раз больше строк
исходного кода, чем во втором, последний менее эффективен, что легко
установить, выполнив приведённые примеры в цикле с контролем времени
выполнения при помощи функции time. Автор неоднократно повторил данный
эксперимент на компьютере с поцессором Intel Pentium 100 MHz и 32 Mb  
оперативной памяти, причём в одной версии шаблон, по которому велось  
выделение во втором фрагменте, был предварительно откомпилирован вне тела
цикла при помощи qr, а в другой  этот шаблон был указан непосредственно в
выражении вместе с опцией o (compile only once). Длина строки $DomainName
составляла 78000 символов. Первый фрагмент в цикле из 10000 итераций
потребовал для выполнения всего 1-2 секунды, а второй (в обеих версиях)
167-168 секунд. Таким образом, пропаганда повсеместного использования  
операций с шаблонами фактически стимулирует применение их не по назначению,
в то время как можно было бы обойтись более простыми и более эффективными  
средствами.
Действительно, мире, выдуманном автором, в котором доменные имена состоят из 78000 символов, первый вариант много эффективнее. Но в реальном то мире, с доменными именами типа "www.yandex.ru", для которого и был предложен 2-й вариант, он примерно столь же эффективен. И уж если эта самая эффективность столь важна (хотя непонятно, зачем она в данном случае: мой  очень средний компьютер обрабатывает 1e6 имен за 1 с), то можно было
подумать немного и придумать что-то типа 
Код

$TLD = $' if $DomainName =~ m/.*\./;
 Это выражение хоть и использует столь нелюбимые автором шаблоны, но тем не менее в реальности работает быстрее обеих его вариантов.

Автор: amg 16.1.2007, 16:32
Автору должно быть стыдно за незнание критикуемого им предмета.
Примеры:
Код

Если использованный способ обозначения строки допускает выполнение подстановки, то перед 
преобразованием PERL, рассматривая подстроки, следующие после символов "$" и "@", 
встречающихся в строке, как идентификаторы соответствующих скаляров и массивов, вставляет 
их значения, которые автоматически преобразуются к строковому типу, в строку, как если бы 
они были указаны непосредственно, причём значения элементов массива сливаются в одну 
сплошную подстроку.
 Значения элементов массива при этом не сливаются в одну сплошную подстроку, а разделяются значениями переменной $" (по умолчанию пробел).
Код

[Для улучшения производительности?] шаблон [m/.*\.(.*)/] был указан ... с опцией o (compile only once) [а лучше не стало].
(В квадратных скобках - мои подходящие по смыслу добавления) Опция o и не должна действовать на шаблон, не содержащий переменных.

Автор: Zuzu 16.1.2007, 16:48
amg, меня, собственно, тоже из всего изложенного в статье поразила попытка переложить на perl проблемы, которые возникли в результате элементарного непонимания вещи, которая, по большому счету, "сама по себе" и к перлу отношения не имеет. Я, собственно, про регулярные выражения. И о том, что неэффективным регулярным выражением можно "положить" любую машину, честно написано в Mastering Regular Expression.

Кстати, попробуй мой вариант по стравнению с твоим на предмет сравнения производительности. Он, ИМХО, болле читабелен для пресловутого, упоминаемого в статье, программиста-читателя.

Код


$TLD = $1 if $DomainName =~ /\.([^.]*)$/;

Автор: korob2001 17.1.2007, 02:05
Меня тоже поразила вот эта часть.
Цитата

# Если символ "." не найден, то доменное имя не верно,
# и TLD не может быть выделен, в противном случае выделяем TLD функцией
# substr
if ($p != -1) {
   $TLD = substr($DomainName, $p + 1);
}

.......

($TLD) = $DomainName =~ m/.*\.(.*)/; # $TLD необходимо заключить в круглые  
                                     # скобки, указав тем списковый контекст

О  как чел проверяет доменные имена.  smile Получается такая строка "......................." или даже "         .           " тоже являются корректными доменными именемами. Регулярное выражение для такого определения доменного имени конечно же не требуется. Оно потребуется в том случае, если будет необходимость действительно отловить доменное имя, вместо произвольной строки.

Добавлено @ 02:15 
Вернусь к прошлой теме, о форматах дат:
Код

# Преобразуем дату в формат yyyy-mm-dd
my $str_date = sprintf("%04d-%02d-%02d", 2006,8,5);
# Получаем дату в виде списка $year, $month, $day
my($year,$month,$day) = split(/-/, $str_date);

Вот собственно эти строки и заменяют собой "модуль" автора.  smile 

Автор: Shaggie 17.1.2007, 07:09
Сошлись на том, что автор пытается совершить простые действия сложными способами.

И если гвоздь никак не хочет забиваться в доску, то во всем оказывается виноват молоток. smile 

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

Автор: GoodBoy 17.1.2007, 09:55
Вообще, конечно, весьма бредовая статья... :-)))  Предлагаю считать это юмором! :-)))

Автор: amg 17.1.2007, 10:00
Цитата(Zuzu @ 16.1.2007,  16:48)
Кстати, попробуй мой вариант по стравнению с твоим на предмет сравнения производительности. Он, ИМХО, болле читабелен для пресловутого, упоминаемого в статье, программиста-читателя.
Код


$TLD = $1 if $DomainName =~ /\.([^.]*)$/;


Этот вариант на коротких строках работает примерно так же, как и другие упоминавшиеся шаблоны, а вот на длинных строках почему то очень сильно тормозит, причем тем сильнее, чем длиннее строки. Интересно, почему? 
Код

                                       Длина строки х кол-во циклов   
             Выражение                   |  10x1e6  | 1e6x1e2
-----------------------------------------|----------|---------       
($TLD) = $DomainName =~ m/^.*\.(.*)$/;   |  2.30 с  |  0.47 с 
$TLD = $' if $DomainName =~ m/.*\./;     |  1.10 с  |  0.45 с
$TLD = $1 if $DomainName =~ /\.([^.]*)$/;|  2.26 с  | 15.82 с

Автор: Materium 17.1.2007, 10:53
Автор просто ни*** (простите) не разбирается в Перл. ))) И ему кажется не приходит в голову что любую задачу на ЯП можно сделать всегда способом больше, чем одним. Через Ж можно на любом языке писать.

Автор: nitr 17.1.2007, 11:39
GoodBoy, согласен smile
korob привёл многочисленные доказательства ;) , хотя статья тоже ими является smile)

Автор: Zuzu 17.1.2007, 12:43
Про регулярные выражения.


amg, большое спасибо. Заставляет задуматься и дальше вдумчиво читать документацию. Могу предположить, что .* в первых regexp сразу проходит до конца строки, а затем происходит возврат. В моем случае \. (точка) сравнивается с каждым символом строки (слева направо), что и привело к существенному увеличению времени выполнения. Я надеялся на то, что оптимизатор regexp Perl, увидев символ $ (конец строки) сразу "начнет с хвоста" строки. Надежды мои не оправлдались.

Это здесь offtopic. Если интересно, можно создать отдельную тему и там все это попытаться выяснять вопрос  более подробно.

Автор: Shaggie 17.1.2007, 12:53
Zuzu, вопрос - почему так происходит? По идее, в ([^.]*)$ звездочка без вопроса должна диктовать жадный режим чтения строки. Возможно, виноваты квадратные скобки...
Врубился! (кажется smile ). Причина в том, что перл действительно читает все до конца, а потом возвращается назад и проверяет каждый символ в строке на неравенство точке, оттого и тормоза. В остальных примерах проверка не производится.

Автор: Materium 17.1.2007, 16:43
Ну, Perl является одним из самых трудно-читаемых языков. ничего с этим не поделаешь. За силу языка приходится этим расплачиваться )))
В остальном, занимаясь своей задачей - а это практический язык для извлечения отчётов, - работа с текстом - Perl является лучшим языком в мире. Об этом пишет сам Ларри.

Автор: Materium 17.1.2007, 17:08
И вообще читал статью. Может кто помнит показывали по телеку как четыре японских робота играют в футбол.
С интересом узнал, что:
1)Основное программирование: С++
2)Второстепенное (часть высокоуровневых задач): Perl

Так что не надо автором ля-ля что Перл плохой!  smile 

Автор: korob2001 23.1.2007, 23:21

Модератор: Всё что касалось ООП вынес в отдельную тему:

http://forum.vingrad.ru/topic-133547.html

Автор: regis 25.1.2007, 15:50
Читаю статью. Она производит довольно смешанное впечатление.

С одной стороны многое верно: анахронизмов в Perl, ведущих родословную и UNIX shell-ов и AWK действительно слишком много. Имена переменных с сигилами, например, или интерполяция строк.
Кое-где вполне разделяю недоумение автора: например, применение инкремента к символьным строкам -- это просто песня (при том, что обратной операции, т.е. декремента, в этом случае вообще не предусмотрено. ;)  )

С другой стороны: многие из анахронизмов вполне официально depreciated, и в современных версиях Perl есть предупреждение об их использовании. Одно только use strict (о котором автор, похоже, и не слышал) отлавливает и недекларированные переменные и barewords.

А кое-какие замечания автора вообще тянут на придирки!

А что мешало определить стандартную функцию, которая бы возвращала текущий размер или границы диапазонов индексов массива, как это сделано, например, в языках Java Script (функция length) и Visual Basic (функции LBound и UBound)?

А что мешает определить ее вам? smile

Код

sub a_length { return scalar @_; }


-- так, по моему, будет вполне достаточно.

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

Уж с этим совершенно не согласен: ИМХО, отсутствие возведения в степень во многих языках -- явный минус.

В общем, впечатление неоднозначное. Однако, буду дальше читать. ;)

Автор: tishaishii 26.1.2007, 12:53
А что, скалярный контекст для массивов для узнать длинну массива не подходит, или $#_ есть тоже, а такого в JavaScript нету.
Возводить в степень можно по-разному. В некоторых случаях можно оптимизировать, например 10e3=10**3 или 2**4 в бинарном виде 100000, 1**3=1.

Автор: GoodBoy 30.1.2007, 13:07
korob2001, вот это видел??
http://forum.vingrad.ru/topic-134327/unread-1.html
:-)))

Автор: Danissimo 30.1.2007, 15:19
В общем-то, если отбросить шелуху в виде никому не нужных эмоций автора, я с ним согласен. Честно говоря, когда пишу код, то никогда до конца не уверен, как меня поймет перл. Сильно удручает.

Многие ставят в плюс, что одно и то же можно сделать разными способами. Я бы вообще не говорил об этом как о плюсе или минусе: разве есть язык, про который нельзя сказать того же? что на нем можно сделать одно и то же разными способами? Я таких не знаю.

Что мне действительно не нравится в перле -- его неоднозначность. Программируя на других языках, я привык к тому, что используя декларативные средства языка, можно сильно упростить себе жизнь, так как синтаксис и семантика (!) проверяется компилятором, что очень помогает быстро устранять банальные ошибки. Да, даже для таких языков можно написать программу, которая будет неправильно работать, и компилятор ничего не скажет. Но нету неоднозначности.

Правда, пока писал, вспомнил С/С++. Надо признать, что в этих языках неоднозначности тоже хватает. Но не на столько...

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

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

Вот такие мысли.

Автор: stan777 30.1.2007, 15:39
Да строгость в перле потеряна, но согласитесь зато халявный язык на котором можно быстро что-то своять, в отличии от Си

Автор: korob2001 30.1.2007, 16:10
Цитата

korob2001, вот это видел??

Сейчас увидел.  smile
Я просто не люблю спорить в таких бестолковых топиках. Никто и никому ничего не докажет. Мнения как гвозди, чем больше по ним бъёшь, тем глубже они вбиваются.

Автор: Danissimo 30.1.2007, 16:11
Цитата(stan777 @ 30.1.2007,  15:39)
Да строгость в перле потеряна, но согласитесь зато халявный язык на котором можно быстро что-то своять, в отличии от Си

ППКС

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)