Глубокоуважаемые!

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

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

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

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

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

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

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

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

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

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

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

use strict - и большая половина проблем отлетит сама собой.

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

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

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

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

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

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

+1

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

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

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

Необъективная статья. Достоинства перла перевернуты с ног на голову и объявлены недостатками. Конечно, если использовать аргументы типа "порядок лучше, чем анархия", то легко можно доказать, что тоталитаризм лучше, чем демократия. 
Конкретный пример:
Действительно, мире, выдуманном автором, в котором доменные имена состоят из 78000 символов, первый вариант много эффективнее. Но в реальном то мире, с доменными именами типа "www.yandex.ru", для которого и был предложен 2-й вариант, он примерно столь же эффективен. И уж если эта самая эффективность столь важна (хотя непонятно, зачем она в данном случае: мой  очень средний компьютер обрабатывает 1e6 имен за 1 с), то можно было
подумать немного и придумать что-то типа  Это выражение хоть и использует столь нелюбимые автором шаблоны, но тем не менее в реальности работает быстрее обеих его вариантов.

Автору должно быть стыдно за незнание критикуемого им предмета.
Примеры:
 Значения элементов массива при этом не сливаются в одну сплошную подстроку, а разделяются значениями переменной $" (по умолчанию пробел).
(В квадратных скобках - мои подходящие по смыслу добавления) Опция o и не должна действовать на шаблон, не содержащий переменных.

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

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

Меня тоже поразила вот эта часть.

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

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

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

Это сообщение отредактировал(а) korob2001 - 17.1.2007, 02:39

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

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

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

Это сообщение отредактировал(а) Shaggie - 17.1.2007, 07:11

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

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

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

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

Это сообщение отредактировал(а) nitr - 17.1.2007, 11:42

Про регулярные выражения.


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

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

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

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

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

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

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

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

Читаю статью. Она производит довольно смешанное впечатление.

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это сообщение отредактировал(а) korob2001 - 30.1.2007, 16:12

ППКС