В преддверии выпуска Perl 5.12 разработчики обсуждают (http://use.perl.org/~Ovid/journal/38010) перспективы этой технологии. Так, в приведённой статистике (http://www.tiobe.com/index.php/content/paperinfo/tpci/index....) отмечено сокращение за год базы пользователей на 0.86%. И несмотря на ряд исторических примеров, когда побеждённые конкурентами проекты ПО восставали вследствие "почивания на лаврах" победителей, существуют причины, по которым Perl5 будет сложно это сделать: отсутствие маркетинга, привлечения молодых новичков, накопленный багаж кода и застарелость навыков (отсутствие стремления к восприятию изменений в современном Web ) пользователей Perl5.
С другой стороны, существует и другая статистика, которая показывает небольшой рост базы пользователей, но в абсолютном выражении. В целом участники дискуссии сходятся во мнении о том, что Perl испытывает серьёзную конкуренцию со стороны PHP, Python, Ruby.
Управленцы компаний и учреждений, использующих данную технологию, в ...URL: http://use.perl.org/~Ovid/journal/38010
Новость: http://www.opennet.me/opennews/art.shtml?num=19221
Криптосинтаксис Perl'а погубит его. На фоне его сложных правил с невероятным количество исключений PHP, Python, Ruby смотрятся гораздо выигрышней для новичков.
В итоге Perl запрограммирован на медленную агонию.
> Криптосинтаксис Perl'а погубит его.Синтаксис им, видите ли, не нравится. А Python'овский, видимо, верх совершенства.
> На фоне его сложных правил с невероятным количество исключений
Можно вот с этого места подробней, я записываю.
> PHP, Python, Ruby смотрятся гораздо выигрышней для новичков.
Ну, за ruby ничего не скажу, но вот php не пнул только ленивый: "ура! в пятой версии появилось то, что в других языках программирования есть уже десять лет!". И PDO, архитектурно повторяющий DBI, и никаких аналогов CGI, шаблоны через пень-колоду, которые функицонально не дотянут до HTML::Template, будь он не ладен. Во, сосед просит рассказать про CGI::Application. Ну, а про множественное наследование я не буду, и не просите.
А какие удобные в PHP конструкторы! В perl'е я могу их настрогать ровно столько, сколько vim выдержит. А в php... ну, попробуйте. Ещё советую попробовать один и тот же метод использовать как static и как метод объекта. А как получится, напишите сюда. Доступ к передаваемым функции параметрам, ежели они произвольного количества -- омг, расскажите им про @_.
После всех этих граблей у новичков будут напряги только с синтаксисом. Избавятся от нежной любви к синтаксису а-ля бейсик, и всё зашибётся. Можно методом от противного: показать им ook. :D
>Синтаксис им, видите ли, не нравится. А Python'овский, видимо, верх совершенства.Не верх совершенства, просто проще, и, следовательно, лучше perl-овского.
>А какие удобные в PHP конструкторы! В perl'е я могу их настрогать
>ровно столько, сколько vim выдержит. А в php... ну, попробуйте. ЕщёРасскажите, пожалуйста, о красоте и изяществе ООП в Perl, желательно с аналогиями с другими языками.
>советую попробовать один и тот же метод использовать как static и
>как метод объекта. А как получится, напишите сюда. Доступ к передаваемым
>функции параметрам, ежели они произвольного количества -- омг, расскажите им про
>@_.Не надо утверждать, что Perl лучше, потому что PHP хуже. Perl с его нечитаемым синтаксисом и сложной контекстно-зависимой семантикой агонизирует. Такие дела.
> Не верх совершенства, просто проще, и, следовательно, лучше perl-овского.И какие именно места вызывают затруднения?
Мне действительно интересно, как человеку выучившему perl по его родным man'ам.
> Расскажите, пожалуйста, о красоте и изяществе ООП в Perl, желательно с аналогиями с другими языками.
Непременно. Сразу после вашего рассказа об удобстве php.
> Не надо утверждать, что Perl лучше, потому что PHP хуже.
Как инструмент он таки удобнее. Пример: см. про конструкторы и static. Я б ещё чего написал, но пока не увидел вашей аргументации.
И, да, персонально чьё-то неприятие синтаксиса за аргумент не канает, увы. Мне вообще кажется, что проблемы восприятия синтаксиса perl'а вызван патологическим пристрастием к basic'оподобным языкам.
> Perl с его нечитаемым синтаксисом
Нечитаемым _вами_. У неполенившихся разобраться проблем не возникает. А со включенным syntax highlighting вообще праздник для глаз.
>И какие именно места вызывают затруднения?
>Мне действительно интересно, как человеку выучившему perl по его родным man'ам.Какие там затруднения у изучившего всю гору невнятной и разрозненной документации? Не спорю, Л. Уолл замечательный автор и лингвист, его книги просто интересны, но зачем такому интуитивному языку так много документации и книги в стиле "Как правильно программировать на Perl" и "Сборник рецептов"? Что ни правило - 40 исключений и 8 контекстов использования. О последовательности (concise) правил лучше умолчать.
>> Расскажите, пожалуйста, о красоте и изяществе ООП в Perl, желательно с аналогиями с другими языками.
>Непременно. Сразу после вашего рассказа об удобстве php.А я не адвокат РНР. Более того, я предпочитаю perl РНР, но тем не менее, не считаю, что у perl все в полном порядке.
>> Не надо утверждать, что Perl лучше, потому что PHP хуже.
>Как инструмент он таки удобнее. Пример: см. про конструкторы и static. Я
>б ещё чего написал, но пока не увидел вашей аргументации.Как инструмент чего? Может, расскажете про наследование в этом вашем perl-e? Или, например, про разделение прав доступа к полям класса?
>И, да, персонально чьё-то неприятие синтаксиса за аргумент не канает, увы. Мне
>вообще кажется, что проблемы восприятия синтаксиса perl'а вызван патологическим пристрастием к
>basic'оподобным языкам.Это не мое восприятие. Я свободно пишу и читаю на Perl.
>> Perl с его нечитаемым синтаксисом
>
>Нечитаемым _вами_. У неполенившихся разобраться проблем не возникает. А со включенным syntax
>highlighting вообще праздник для глаз.Замечательно. Включите, пожалуйста, подсветку кода и расскажите, что имелось ввиду здесь:
@isatype{@isatype} = (1) x @isatype;
>Какие там затруднения у изучившего всю гору невнятной и разрозненной документации?man perl и остальные man perl*, описанные, кстати, в предыдущем, -- это очень разрозненно и невнятно.
>Не
>спорю, Л. Уолл замечательный автор и лингвист, его книги просто интересны,
>но зачем такому интуитивному языку так много документации и книги в
>стиле "Как правильно программировать на Perl" и "Сборник рецептов"? Что ни
>правило - 40 исключений и 8 контекстов использования. О последовательности (concise)
>правил лучше умолчать.Так примеры будут или как всегда?
Я вот сейчас прочитал ещё раз, на всякий случай, man perlfunc и не обнаружил каких-либо исключений. Может, у меня не тот man perlfunc?
>>> Расскажите, пожалуйста, о красоте и изяществе ООП в Perl, желательно с аналогиями с другими языками.
>>Непременно. Сразу после вашего рассказа об удобстве php.
>А я не адвокат РНР. Более того, я предпочитаю perl РНР, но
>тем не менее, не считаю, что у perl все в полном
>порядке.Ну, если мы будем искать сферических коней в вакууме, то в итоге скатимся сначала к assembler'у, а потом опять вернёмся к c/c++, а всё остальное от лукавого.
>>> Не надо утверждать, что Perl лучше, потому что PHP хуже.
>>Как инструмент он таки удобнее. Пример: см. про конструкторы и static. Я
>>б ещё чего написал, но пока не увидел вашей аргументации.
>Как инструмент чего?Для раскалывания орехов, видимо.
>Может, расскажете про наследование в этом вашем perl-e? Или,
>например, про разделение прав доступа к полям класса?man perltoot
man perltoocА чтение man'ов вслух по-прежнему $50/час.
>>И, да, персонально чьё-то неприятие синтаксиса за аргумент не канает, увы. Мне
>>вообще кажется, что проблемы восприятия синтаксиса perl'а вызван патологическим пристрастием к
>>basic'оподобным языкам.
>
>Это не мое восприятие. Я свободно пишу и читаю на Perl.Дык о чём тогда спорим, и зачем спрашивать про наследование и доступ к свойствам? Чтобы убедиться, что я полномочен зачитывать маны по стандартным расценкам?
>>> Perl с его нечитаемым синтаксисом
>>
>>Нечитаемым _вами_. У неполенившихся разобраться проблем не возникает. А со включенным syntax
>>highlighting вообще праздник для глаз.
>Замечательно. Включите, пожалуйста, подсветку кода и расскажите, что имелось ввиду здесь:
>@isatype{@isatype} = (1) x @isatype;Ничего. Даже так: ничего хорошего. Пока не заменить фигурные скобки на квадратные. И даже если заменить, всё равно хорошего мало.
Но теперь вы можете смело начинать рассказывать про use strict, а также свести оный к тем самым исключениям.
>>Замечательно. Включите, пожалуйста, подсветку кода и расскажите, что имелось ввиду здесь:
>>@isatype{@isatype} = (1) x @isatype;
>
>Ничего. Даже так: ничего хорошего. Пока не заменить фигурные скобки на квадратные.
>И даже если заменить, всё равно хорошего мало.
>
>Но теперь вы можете смело начинать рассказывать про use strict, а также
>свести оный к тем самым исключениям.Я бы поспорил :) Тут каждому элементу среза хэша %isatype, ключи которого содержатся в массиве @isatype, присваивается единица.
Если хэш %isatype и массив @isatype были до этого объявлены, то use strict ничего плохого на это выражение не скажет.
Из соображений читабельности кода, я бы рекомендовал не называть хэш с массивом одинаковыми именами. А так всё ОК :)
>>Какие там затруднения у изучившего всю гору невнятной и разрозненной документации?
>
>man perl и остальные man perl*, описанные, кстати, в предыдущем, -- это
>очень разрозненно и невнятно.именно так. language reference в perl отсутствует де-факто.
>Так примеры будут или как всегда?
Пожалуйста.
perlsyn
"Every simple statement must be terminated with a semicolon, unless it is the final statement in a block, in which case the semicolon is optional."
Правило с исключением и исключением на исключение. Следом: "BLOCK if EXPR" и "if EXPR BLOCK". Короче, можно продолжать до бесконечности. Или и сейчас будем спорить, что все в perl-е однозначно, последовательно и логично?
>Я вот сейчас прочитал ещё раз, на всякий случай, man perlfunc и
>не обнаружил каких-либо исключений. Может, у меня не тот man perlfunc?Нет, просто вы фанатично отстаиваете свой язык, не замечая очевидных проблем.
>Ну, если мы будем искать сферических коней в вакууме, то в итоге
>скатимся сначала к assembler'у, а потом опять вернёмся к c/c++, а
>всё остальное от лукавого.Какие кони, какой вакуум? Perl далек от идеала, так что описывать его как идеальный газ крайне непрагматично.
>>Как инструмент чего?
>Для раскалывания орехов, видимо.Годится.
>>Может, расскажете про наследование в этом вашем perl-e? Или,
>>например, про разделение прав доступа к полям класса?
>man perltoot
>man perltooc"Some languages provide a formal syntactic interface to a class's methods, but Perl does not. It relies on you to read the documentation of each class."
То есть наследования в perl-е нет. Или начнете доказывать, что это хорошо и все ООП зиждется на знании реализации класса-родителя?
"it's generally considered rather poor form in most object modules. In an object module, you should set up a protective veil to separate interface from implementation. So provide a class method to access class data just as you provide object methods to access object data."
В 21 веке перл-программисты пишут геттеры\сеттеры для публичных членов класса, даже если никакой особой логики за этим нет. Правда, есть угрозы переписать это все в 6ой версии, которая все никак не родится.
>Дык о чём тогда спорим, и зачем спрашивать про наследование и доступ
>к свойствам?Спрашивать затем, чтобы натолкнуть вас на рассмотрение проблемных мест языка. На которые вы закрываете глаза.
>>Замечательно. Включите, пожалуйста, подсветку кода и расскажите, что имелось ввиду здесь:
>>@isatype{@isatype} = (1) x @isatype;
>
>Ничего. Даже так: ничего хорошего. Пока не заменить фигурные скобки на квадратные.
>И даже если заменить, всё равно хорошего мало.
>Но теперь вы можете смело начинать рассказывать про use strict, а также
>свести оный к тем самым исключениям.Лучше смело расскажу о том, что это строка из какого-то стандартного или CPAN-овского модуля. Но не об этом. Я хотел услышать объяснения по семантике этой строки.
>Правило с исключением и исключением на исключение.Это издержки парсера, в паскале было то же самое. Все ставят ; везде и не парятся, а вас оно вдруг смутило?
> Следом: "BLOCK if EXPR" и "if EXPR BLOCK". Короче, можно продолжать до бесконечности.
Ну и в C есть while{} и do{}while. Постусловия - очень удобная вещь, между прочим делает язык ближе к натуральному. А вот постциклы я лично не люблю.
>будем спорить, что все в perl-е однозначно, последовательно и логично?
Разумеется.
>>Я вот сейчас прочитал ещё раз, на всякий случай, man perlfunc и
>>не обнаружил каких-либо исключений. Может, у меня не тот man perlfunc?
>Нет, просто вы фанатично отстаиваете свой язык, не замечая очевидных проблем.Когда заканчиваются аргументы, остается только назвать собеседника фанатиком?
Проблем много и их никто не отрицает, но то, что вы приводите в качестве премеров - проблемы вас, а не языка.>То есть наследования в perl-е нет. Или начнете доказывать, что это хорошо
>и все ООП зиждется на знании реализации класса-родителя?А в Python duck typing. Покажите-ка мне реализацию ООП вообще без проблем.
>>Дык о чём тогда спорим, и зачем спрашивать про наследование и доступ
>>к свойствам?
>Спрашивать затем, чтобы натолкнуть вас на рассмотрение проблемных мест языка. На которые
>вы закрываете глаза.Напомню, что мы обсуждаем вашу реплику: `Perl с его нечитаемым синтаксисом и сложной контекстно-зависимой семантикой агонизирует'. Весомых аргументов в поддержку вы не привели, только из разряда `я не умею'. А на ООП переходить не надо, тут все проблемы известны и давно обсуждены. К слову, очень небольшому числу людей они _реально_ мешают.
>Это издержки парсера, в паскале было то же самое. Все ставят ;
>везде и не парятся, а вас оно вдруг смутило?Причем тут "смутило"? После пятой жены меня ничего не смущает. Был разговор "приведите список неоднозначностей и исключений". Вот они, или надо все, до копеечки?
>> Следом: "BLOCK if EXPR" и "if EXPR BLOCK". Короче, можно продолжать до бесконечности.
>Ну и в C есть while{} и do{}while. Постусловия - очень удобная
>вещь, между прочим делает язык ближе к натуральному. А вот постциклы
>я лично не люблю.Вы не различаете разницы между simple statements и compound statements? Если не понимаете, в чем противоречие, то не отсылайте больше к документации, вы сами ее невнимательно читали.
>>будем спорить, что все в perl-е однозначно, последовательно и логично?
>Разумеется.Из упрямства?
>Когда заканчиваются аргументы, остается только назвать собеседника фанатиком?
Собеседника следует называть фанатиком, как только он начинает отрицать очевидную аргументацию. Вы же не сослались на уточнения и пояснения в самой документации, верно? Кроме того, видимо, вы не знакомы с историей и целью создания языка, иначе знали бы, что Л.Уолл объяснял, почему именно он внес в язык большое количество контекстно-зависимых конструкций.
>>То есть наследования в perl-е нет. Или начнете доказывать, что это хорошо
>>и все ООП зиждется на знании реализации класса-родителя?
>А в Python duck typing. Покажите-ка мне реализацию ООП вообще без проблем.И что duck typing? Потрудитесь внятно объяснить значение этого понятия своими словами, заодно аргументируйте, почему это проблема.
>Напомню, что мы обсуждаем вашу реплику: `Perl с его нечитаемым синтаксисом и
>сложной контекстно-зависимой семантикой агонизирует'. Весомых аргументов в поддержку вы не привели,В сухом остатке: у Perla ужасный синтаксис и неразвитая ООП-парадигма. С остальными проблемами я готов смириться.
>только из разряда `я не умею'. А на ООП переходить не
>надо, тут все проблемы известны и давно обсуждены. К слову, очень
>небольшому числу людей они _реально_ мешают.Ну да. Миллион леммингов не может не ошибаться. Жду ваших аргументов в защиту тезиса "ООП - Вселенское Зло".
>Причем тут "смутило"?Потому что вы тут утверждаете какой у Perl ужасный синтаксис.
> После пятой жены меня ничего не смущает.
Да уж не скромничайте.
>Был разговор "приведите список неоднозначностей и исключений". Вот они, или надо все, до
>копеечки?Можно хотя бы пару каких-нибудь, которые реально портят жизнь?
Ну и пару реальных языков, где исключений и неоднозначностей нет.>>> Следом: "BLOCK if EXPR" и "if EXPR BLOCK". Короче, можно продолжать до бесконечности.
>>Ну и в C есть while{} и do{}while. Постусловия - очень удобная
>>вещь, между прочим делает язык ближе к натуральному. А вот постциклы
>>я лично не люблю.
>Вы не различаете разницы между simple statements и compound statements? Если не
>понимаете, в чем противоречие, то не отсылайте больше к документации, вы
>сами ее невнимательно читали.Что вам не нравится-то, объясните. Что перед if нельзя {}, а после надо обязательно?
>>>будем спорить, что все в perl-е однозначно, последовательно и логично?
>>Разумеется.
>Из упрямства?Потому что вы меня пока ни в чем не убедили. `У перл плохой синтаксис потому что мне он не нравится' - это все что вы пока сказали.
>>Когда заканчиваются аргументы, остается только назвать собеседника фанатиком?
>Собеседника следует называть фанатиком, как только он начинает отрицать очевидную аргументацию. Вы
>же не сослались на уточнения и пояснения в самой документации, верно?
>Кроме того, видимо, вы не знакомы с историей и целью создания
>языка, иначе знали бы, что Л.Уолл объяснял, почему именно он внес
>в язык большое количество контекстно-зависимых конструкций.Не знаком и не горю желанием, честно. У раскладки qwerty тоже своя история есть, а все пользуют и не жалуются.
>>>То есть наследования в perl-е нет. Или начнете доказывать, что это хорошо
>>>и все ООП зиждется на знании реализации класса-родителя?
>>А в Python duck typing. Покажите-ка мне реализацию ООП вообще без проблем.
>И что duck typing? Потрудитесь внятно объяснить значение этого понятия своими словами,
>заодно аргументируйте, почему это проблема.С чего это я должен вам что-то объяснять? И прекратите додумывать мои посты за меня, я нигде не писал что duck typing - проблема.
>>Напомню, что мы обсуждаем вашу реплику: `Perl с его нечитаемым синтаксисом и
>>сложной контекстно-зависимой семантикой агонизирует'. Весомых аргументов в поддержку вы не привели,
>В сухом остатке: у Perla ужасный синтаксис и неразвитая ООП-парадигма.Я уже понял вашу мысль, спасибо.
>>только из разряда `я не умею'. А на ООП переходить не
>>надо, тут все проблемы известны и давно обсуждены. К слову, очень
>>небольшому числу людей они _реально_ мешают.
>Ну да. Миллион леммингов не может не ошибаться. Жду ваших аргументов в
>защиту тезиса "ООП - Вселенское Зло".Жду цитаты, где я такое сказал.
>Можно хотя бы пару каких-нибудь, которые реально портят жизнь?Из-за чрезмерно свободного синтаксиса читать код сложно, так как смешение стилей в perl - обычное дело. Ряд стилей в Perl крайне неудобочитаем, что сказывается на скорости разработки и поддержке. Особенно, когда над проектом работает пару десятков человек - приходится вводить coding styles, заставляющих писать читаемо, т.е. фактически принуждать к С-синтаксису.
>Ну и пару реальных языков, где исключений и неоднозначностей нет.
Lisp. Forth.
>Что вам не нравится-то, объясните. Что перед if нельзя {}, а после
>надо обязательно?Не нравится, что оппонент апеллирует к документации, а сам не видит разницы между простым и составным выражением. Цикл с пост\предусловием - это составное выражение, я же говорил про одинаковый синтаксис с разной семантикой. Привести пример или и так понятно?
>Потому что вы меня пока ни в чем не убедили. `У перл
>плохой синтаксис потому что мне он не нравится' - это все
>что вы пока сказали.Ужасный, а не плохой. 600-фунтовая горилла ужасна, но не плоха. Чувствуете разницу?
>>И что duck typing? Потрудитесь внятно объяснить значение этого понятия своими словами,
>>заодно аргументируйте, почему это проблема.
>С чего это я должен вам что-то объяснять? И прекратите додумывать мои
>посты за меня, я нигде не писал что duck typing -
>проблема.Тогда к чему было сказано "а в Python duck-typing"?
>>Ну да. Миллион леммингов не может не ошибаться. Жду ваших аргументов в
>>защиту тезиса "ООП - Вселенское Зло".
>Жду цитаты, где я такое сказал.Это был сарказм. Естественно, что я этого не жду.
>>Можно хотя бы пару каких-нибудь, которые реально портят жизнь?
>Из-за чрезмерно свободного синтаксиса читать код сложно, так как смешение стилей в
>perl - обычное дело. Ряд стилей в Perl крайне неудобочитаем, что
>сказывается на скорости разработки и поддержке. Особенно, когда над проектом работает
>пару десятков человек - приходится вводить coding styles, заставляющих писать читаемо,
>т.е. фактически принуждать к С-синтаксису.Ужасный и чрезмерно свободный - очень разные характеристики, не находите?
>>Что вам не нравится-то, объясните. Что перед if нельзя {}, а после
>>надо обязательно?
>Не нравится, что оппонент апеллирует к документации, а сам не видит разницы
>между простым и составным выражением. Цикл с пост\предусловием - это составное
>выражение, я же говорил про одинаковый синтаксис с разной семантикой. Привести
>пример или и так понятно?Я знаю что такое составное выражение, я просил не додумывать бреда. Приведи пример того, что тебе не нравится, ибо я тебя вообще не понял.
>>С чего это я должен вам что-то объяснять? И прекратите додумывать мои
>>посты за меня, я нигде не писал что duck typing -
>>проблема.
>Тогда к чему было сказано "а в Python duck-typing"?К тому что ООП ООП рознь.
>Я знаю что такое составное выражение, я просил не додумывать бреда. Приведи
>пример того, что тебе не нравится, ибо я тебя вообще не
>понял.Simple statement:
# простое выражение с модификатором
print "Greater" while ($i > 10);
print "Greater" if ($i > 10);# составное выражение
while($i < 10) { print 'Hello'; $i++ }
if ( $i < 10) { print 'Hello'; $i++ }# цикл с постусловием
{ print 'Hello'; $i++ } while($i < 10);
{ print 'Hello'; $i++ } if ($i < 10); # бам! нельзя.
># цикл с постусловием
>{ print 'Hello'; $i++ } if ($i < 10); # бам! нельзя.# Бум! можно.
do { print 'Hello'; $i++ } if ($i < 10);
># цикл с постусловием
>{ print 'Hello'; $i++ } if ($i < 10); # бам! нельзя.# Бум! можно.
do { print 'Hello'; $i++ } if ($i < 10);
>># цикл с постусловием
>>{ print 'Hello'; $i++ } if ($i < 10); # бам! нельзя.
>
># Бум! можно.
>do { print 'Hello'; $i++ } if ($i < 10);Черт подери. Я же не спрашивал, как можно. Я привел пример неоднозначной семантики.
># цикл с постусловием
>{ print 'Hello'; $i++ } while($i < 10);$ perl -e '$i=0; { print "Hello"; $i++ } while($i < 10); print "\n"; '
syntax error at -e line 1, near ");"
Execution of -e aborted due to compilation errors.~$ perl -e '$i=0; do { print "Hello"; $i++ } while($i < 10); print "\n"; '
HelloHelloHelloHelloHelloHelloHelloHelloHelloHelloИ соответственно:
>{ print 'Hello'; $i++ } if ($i < 10); # бам! нельзя.
~$ perl -e '$i=0; { print "Hello"; $i++ } if($i < 10); print "\n"; '
syntax error at -e line 1, near ");"
Execution of -e aborted due to compilation errors.
~$ perl -e '$i=0; do { print "Hello"; $i++ } if($i < 10); print "\n"; '
Hello
Style guide, к слову, нужны вообще всегда.
>Правило с исключением и исключением на исключение. Следом: "BLOCK if EXPR" и
>"if EXPR BLOCK". Короче, можно продолжать до бесконечности. Или и сейчас
>будем спорить, что все в perl-е однозначно, последовательно и логично?серьезно, не понимаю в чем разница?
если условие истинно выполнить блок
и
выполнить блок, если условие истинно O_Oобъясните pls
>серьезно, не понимаю в чем разница?
>если условие истинно выполнить блок
>и
>выполнить блок, если условие истинно O_Oпосмотри в perlsyn, секции simple statements и compound statements. штука как и в случае со срезом хэша - if одновременно и модификатор, и блочное выражение, однако в отличие от таких же while, do и unless не работает как блок с постусловием, хотя работает как модификатор простого выражения.
кстати, это одна из первых деталек. если захотеть, то подобного в Perl масса. Perl вообще контекстно-зависимый язык, если так можно выразиться. Поэтому практически каждая конструкция имеет несколько вариантов, в зависимости от контекста, причем набор возможных контекстов всегда разный.
> Perl вообще контекстно-зависимый язык, если так можно выразиться.Так разве не в этом его "фишка"? Не просто так он написан лингвистом.
>То есть наследования в perl-е нет. Или начнете доказывать, что это хорошо
>и все ООП зиждется на знании реализации класса-родителя?То есть наследование в перле есть и активно используется.
>>То есть наследования в perl-е нет. Или начнете доказывать, что это хорошо
>>и все ООП зиждется на знании реализации класса-родителя?
>
>То есть наследование в перле есть и активно используется.В библиотеку, читать основы теории ООП.
>В библиотеку, читать основы теории ООП.Основы ООП я изучал когда Вы ещё под стол пешком ходили :)
>Основы ООП я изучал когда Вы ещё под стол пешком ходили :)когда я под стол пешком ходил, ООП еще не существовало. или вы работали с Аланом Кеем?
> Какие там затруднения у изучившего всю гору невнятной и разрозненной документации?
> Не спорю, Л. Уолл замечательный автор и лингвист, его книги просто интересны, но зачем
> такому интуитивному языку так много документации и книги в стиле "Как правильно
> программировать на Perl" и "Сборник рецептов"? Что ни правило - 40 исключений и 8
> контекстов использования. О последовательности (concise) правил лучше умолчать.Почему я не испытываю никаких ужасных проблем с 40 исключениями и 8 контекстами использования? Не могу сказать что
>>> Perl с его нечитаемым синтаксисом
>>Нечитаемым _вами_. У неполенившихся разобраться проблем не возникает. А со включенным syntax
>>highlighting вообще праздник для глаз.
>Замечательно. Включите, пожалуйста, подсветку кода и расскажите, что имелось ввиду здесь:
>@isatype{@isatype} = (1) x @isatype;Сообщение было не мне, но все-таки, зачем приводить элементарные примеры? Попросили бы привести в читабельный вид знаменитый однострочник.
Создается хэш %isatype с ключами из массива @isatype и единицами в качестве значений.
Если вы считаете, что это неочевидно, зачем так писать? Пишите по старинке
foreach my $type (@isatype) {
$isatype{$type} = 1;
}для этого не надо читать `всю гору невнятной и разрозненной документации'.
А если это чужой код, надо было один раз пробежать по диагонали perldata, что по логике вы уже давно сделали, потому что вам было интересно, как указать диапазон значений массива (@foo[1,3]), и узнать что то же самое можно делать с хэшом.
*Не могу сказать что очень часто заглядываю в документацию, да и вообще что прочитал весь perldoc, тем не менее по работе встречается все подряд и понимается без проблем.
>Сообщение было не мне, но все-таки, зачем приводить элементарные примеры? Попросили бы
>привести в читабельный вид знаменитый однострочник.Спасибо за ответ, это как раз то, что я хотел проиллюстрировать.
>Если вы считаете, что это неочевидно, зачем так писать? Пишите по старинке
>foreach my $type (@isatype) {
> $isatype{$type} = 1;
>}
>для этого не надо читать `всю гору невнятной и разрозненной документации'.
>А если это чужой код, надо было один раз пробежать по диагонали
>perldata, что по логике вы уже давно сделали, потому что вам
>было интересно, как указать диапазон значений массива (@foo[1,3]), и узнать что
>то же самое можно делать с хэшом.То есть пример плохо читаем, верно? И улучшить читаемость удается только с использованием более близкого к С синтаксиса, так?
> Спасибо за ответ, это как раз то, что я хотел проиллюстрировать.Что именно?
> То есть пример плохо читаем, верно?
> И улучшить читаемость удается только с использованием более близкого к С синтаксиса, так?Неверно, оденьте очки и перечитайте мой пост.
Я сказал, если _вам_ кажется непонятным то, что там написано, пишите в стиле C, понятно и раздуто, и не заикайтесь о плохом синтаксисе.
Я проблем с этой строчкой не испытываю и считаю возможность писать такие вещи одной из сильных сторон perl'а.
>Неверно, оденьте очки и перечитайте мой пост.Одел. Две пары очков постоянно падают и мешают.
>Я сказал, если _вам_ кажется непонятным то, что там написано, пишите в
>стиле C, понятно и раздуто, и не заикайтесь о плохом синтаксисе.Дефектами речи не страдаю. Свое мнение излагаю четко и внятно. Или вы где-то усмотрели сообщения в стиле "мнэээ... ну это... у меня ващета все нормальна и perldoc"?
>Я проблем с этой строчкой не испытываю и считаю возможность писать такие
>вещи одной из сильных сторон perl'а.Замечательная строчка. Треть присутствующих тут перл-апологетов считают строчку плохой. Еще две трети считают, что хоть хэш и обозначается через %, но иногда обозначать его через @ - нормально. Вы же вообще считаете возможность писать семантически-неоднозначный код сильной стороной языка.
Кстати, ситуацию с ООП тоже считаете нормальной?
> Замечательная строчка. Треть присутствующих тут перл-апологетов считают строчку плохой. Еще две трети считают, что хоть хэш и обозначается через %, но иногда обозначать его через @ - нормально. Вы же вообще считаете возможность писать семантически-неоднозначный код сильной стороной языка.Да, считаю. И это абсолютно однозначный код. Если кто-то не знает возможностей языка, путает [] и {}, не видит @ и т.д., это никак не проблема языка. Если людей с такими проблемами много, это уже странно, но пока есть люди, которые эффективно решают свои проблема с помощью этого языка и радуются, я считаю логичным большинству либо доучиваться, либо выбирать другой инструмент.
> Кстати, ситуацию с ООП тоже считаете нормальной?
Для Perl'а - да.
поддержуPerl - правильный язык на своем месте. Альтернативы ему в задачах распарсивания обработки регулярных данных и написания сложных административных скриптов "малой кровью" как то не наблюдается
Понятно, что под некоторые задачи лучше подходят другие языки. Ну так и пользуйтесь правильными инструментами под каждую вашу задачу
Хотя однозначно правильные инструменты - эти сложный вопрос. Например, при разработке сайтов в разных случаях оптимальным может быть назван и Perl, и PHP (дрянь, однако ж), и Oracle PL/SQL + mod_plsql для Apache и т.д.
Что касается ООП - он вреден в ряде задач, процедурного подхода более чем за глаза ... Если кто то лелеет надежду на универсальный язык под удобства одного человека - пусть сядет и напишет такой язык. А народ потом проголосует за это _поделие_ использованием или неиспользованием. Кстати, за Perl не первое десятиление голосуют, достаточно на объём CPAN посмотреть ...
>Если вы считаете, что это неочевидно, зачем так писать? Пишите по старинке
>
>foreach my $type (@isatype) {
> $isatype{$type} = 1;
>}этот вариант медленный.
правильно использовать while в паре с each
>>> Perl с его нечитаемым синтаксисом
>>
>>Нечитаемым _вами_. У неполенившихся разобраться проблем не возникает. А со включенным syntax highlighting вообще праздник для глаз.
>
>Замечательно. Включите, пожалуйста, подсветку кода и расскажите, что имелось ввиду здесь:
>@isatype{@isatype} = (1) x @isatype;Говоря сетевым языком, слив защитан, camel! Тупо выкрикнуть (повторяя за другими кретинами) "Синтаксис Перла - говно!" - много ума не надо, куда сложнее поднять свою задницу и ХОТЯ БЫ ПРОЧЕСТЬ пару доков по Перлу.
Я изучал Перл после Паскаля и Си. Непривычным показалось обилие $, @ и %. Но когда стал РЕАЛЬНО ПИСАТЬ КОД, понял насколько это элегантнее гадания по мудацкой префиксной нотации _lpstrzName и т.п.
Да, с Перлом надо быть внимательнее - точно так же как водитель-профи отличается вниманием от блондинки за "Корсой". Сам же кодинг на Перле превращается в песню - что думаешь, то и пишешь. Впрочем, если у кого-то пустая голова, писать действительно сложно. :)
Проблемы в Перле есть, но далеко не в синтаксисе. Ему бы обновить и улучшить CPAN, цены бы не было!
>Говоря сетевым языком, слив защитан, camel! Тупо выкрикнуть (повторяя за другими кретинами)
>"Синтаксис Перла - говно!" - много ума не надо, куда сложнее
>поднять свою задницу и ХОТЯ БЫ ПРОЧЕСТЬ пару доков по Перлу.Деточка, я писал на Perl еще тогда, когда тебе родители объясняли значение слова "кретин". Хотя, конечно, лучше бы тебе объяснили элементарные правила приличия.
>> Не надо утверждать, что Perl лучше, потому что PHP хуже.
>Как инструмент он таки удобнее. Пример: см. про конструкторы и static. Я
>б ещё чего написал, но пока не увидел вашей аргументации.Вернусь немного, было сказано
> Ещё советую попробовать один и тот же метод использовать как static и как метод объекта.
Если я правильно вас понял, то в перл возможна конструкция аналогичная
(привожу пример на java, язык не имеет значения, важна идея)class A {
public void methodA() {
static public void staticMethodA() {
}
}instanceA = new A();
// теперь как это правильно с точки зрения принципов ООП
instanceA.methodA();
// но
A.staticMethodA();если я правильно понимаю о чем речь, то видимо в перл можно сделать
instanceA.staticMethodA();
а если еще пофантазировать, то может быть при таком вызове даже можно
получить доступ к экземпляру instanceA внутри реализации staticMethodA()я не знаток перла и реализации концепции ООП в нем, только наслышан от людей,
что оно там жутко кривое.
если вышеописанное предположение верно, то позвольте искренне
посочувствовать. то что вы пытаетесь преподнести как "очень полезную фичу"
нарушает принципы изоляции ООП. таки "фичи" я в гробу видал, чего и вам
рекомендую.
http://search.cpan.org/~drolsky/Moose-0.62/lib/Moose.pm ?
>Если я правильно вас понял, то в перл возможна конструкция аналогичная
>(привожу пример на java, язык не имеет значения, важна идея)
>
>class A {
> public void methodA() {
> static public void staticMethodA() {
> }
>}Missing right curly, однако.
По существу: в perl'е любой метод может быть использован как static и object. Без всяких конструкций. Первый переданный аргумент либо instance, либо просто аргумент. Соответсвенно, один if/unless, и всё. Вы можете сколько угодно рассказывать про абстрактности навроде "прынцыпофф ООП", но есть одно большое "но": это _офигительно_ удобно.
Аналогично с конструкторами. В _любой_ функции класса можно вызвать bless, и -- вуаля -- готов объект. То есть, можно иметь два и более конструктора. И это тоже _офоигительно_ удобно.
>я не знаток перла и реализации концепции ООП в нем, только наслышан
>от людей,
>что оно там жутко кривое.А мне знакомый Мойша битлов напел. Картавят, шепелявят, фальшивят.
Не лублу спорить о вкусе устриц с теми, кто даже не знает, что это такое.
>я не знаток перла и реализации концепции ООП в нем, только наслышан от людей,
>что оно там жутко кривое.Браво! Хоть один "критик" сознался, что "не читал, но осуждает". :) ОБС на сегодня, безусловно, самый популярный источник новостей. ;]
Со своей же стороны, как программист на Перле, скажу: у Перла не просто ООП, а целая динамическая система, затыкающая за пояс все жабо-шарпо-подобные языки! Я бы даже сказал, это что-то приближающееся к Smalltalk - отцу и идеалу ООП. Есетственно, прежде чем влезать в споры, я бы порекомендовал сначала узнать, что есть ООП и почему Смоллток - лучший его представитель за последние 30 лет.
>Со своей же стороны, как программист на Перле, скажу: у Перла не
>просто ООП, а целая динамическая система, затыкающая за пояс все жабо-шарпо-подобные
>языки! Я бы даже сказал, это что-то приближающееся к Smalltalk -
>отцу и идеалу ООП. Есетственно, прежде чем влезать в споры, я
>бы порекомендовал сначала узнать, что есть ООП и почему Смоллток -
>лучший его представитель за последние 30 лет.Феерическая расстановка точек над ООП и Smalltalk.
Давай, уважаемый программист на Perl-е, покажи, как в твоей динамической системе реализовать наследование так, чтобы заткнуть за пояс все жабо-шарпо-подобные языки (ну и С++ тоже, одно семейство). Или ты считаешь, что оно там есть? Тогда, плз, реализацию полиморфных классов. Заодно продемонстрируй метапрограммирование (класс с объектом не путаешь уже, я надеюсь?) или мета-объектный протокол. Или, может, покажешь всю мощь и удобство интроспекции в твоей целой динамической системе?
>> Криптосинтаксис Perl'а погубит его.
>
>Синтаксис им, видите ли, не нравится. А Python'овский, видимо, верх совершенства.
>
>> На фоне его сложных правил с невероятным количество исключений
>
>Можно вот с этого места подробней, я записываю.Откройте доку по Perl (даже для начинающих!!!) - там уже все записано.
>[оверквотинг удален]
>HTML::Template, будь он не ладен. Во, сосед просит рассказать про CGI::Application.
>Ну, а про множественное наследование я не буду, и не просите.
>
>
>А какие удобные в PHP конструкторы! В perl'е я могу их настрогать
>ровно столько, сколько vim выдержит. А в php... ну, попробуйте. Ещё
>советую попробовать один и тот же метод использовать как static и
>как метод объекта. А как получится, напишите сюда. Доступ к передаваемым
>функции параметрам, ежели они произвольного количества -- омг, расскажите им про
>@_."Разумному - достаточно"
>
>После всех этих граблей у новичков будут напряги только с синтаксисом. Избавятся
>от нежной любви к синтаксису а-ля бейсик, и всё зашибётся. Можно
>методом от противного: показать им ook. :DВ ваших словах противоречие, не видите? Ведь после того, как ты разобрался с перловым синтаксисом - ты уже не новичок.
И не надо доказывать что его синтаксис прост, понятен и логичен - это чрезвычайно трудно, поверьте.
Лучше расскажите-ка как вы пришли к перлу, вернее, что вас заставило к нему придти.
>И не надо доказывать что его синтаксис прост, понятен и логичен -
>это чрезвычайно трудно, поверьте.Это трудно ровно настолько, насколько трудно обучение ленивых детей.
Имеет место такой парадокс: ленивые и групые люди скорее потратят в 10 раз больше времени на выполнение однообразной рутины, чем освоят новый инструмент, который позволит это сделать легче и быстрее, а кроме тогог, пригодится в дальнейшем.Не надо доказывать что синтаксис сложен - этим вы доказываете только что не освоили его.
>Лучше расскажите-ка как вы пришли к перлу, вернее, что вас заставило к
>нему придти.Вы этой поправкой пытаетесь выставить в невыгодном свете Perl, но на самом деле выставляете лишь свою некомпетентность.
Hint: если вы будете честным и вести бесету в ключе `я недостаточно работал с Perl и его синтаксис кажется мне ужасным, что вы в нем находите', дискуссия получится гораздо более конструктивной.Я например, освоил Perl на минимальном уровне когда учился `делать сайты' в школьные годы (лет 8 назад) по примерам за пару дней. С докой по регэкспам и perldoc perlfunc (тогда еще открытой в браузере в html виде, ибо дело было под windows) под рукой было расковыряно куча форумов и чужих скриптов, и написана такая же куча своих. Потом в институте на первой работе был большой perl проект, где я освоил еще кучу всего - от ООП до интеграции с C в обе стороны. При этом я, заметьте, ни разу не имел проблем с синтаксисом, ни в своем коде, ни в чужом.
Я совершенно не отрицаю проблем Perl'а, но синтаксис в них точно не входит.
>Hint: если вы будете честным и вести бесету в ключе `я недостаточно
>работал с Perl и его синтаксис кажется мне ужасным, что вы
>в нем находите', дискуссия получится гораздо более конструктивной.А зачем вы навязываете свое доминирующее положение? Я достаточно работал с perl-ом, еще до того, как вы перешли в старшие классы средней школы, и нахожу perl ужасным языком, прививающим плохие привычки и портящим мышление программиста. Так может *вы* начнете вести дискуссию в ключе "я не знаю ни одного языка, с синтаксисом непохожим на С, поэтому защищаю то, что имею"?
>Я совершенно не отрицаю проблем Perl'а, но синтаксис в них точно не
>входит.Синтаксис и семантика - это основные характеристики языка, все остальное - околоязыковые проблемы. И да, синтаксис в Perl - его основная проблема.
> А зачем вы навязываете свое доминирующее положение?Не придумывайте, я просто указал на необъективность товарища, ибо она очевидна. Вам я таого не говорил.
> Я достаточно работал с perl-ом, еще до того, как вы перешли в старшие классы средней школы, и нахожу perl ужасным языком, прививающим плохие привычки и портящим мышление программиста.
Ваше право.
> Так может *вы* начнете вести дискуссию в ключе "я не знаю ни одного языка, с синтаксисом непохожим на С, поэтому защищаю то, что имею"?
Мне нет смысла ничего защищать, уважаемый. А вот узнать, почему люди имеют проблемы там, где у меня их нет, крайне интересно.
> И да, синтаксис в Perl - его основная проблема.Это мы уже слышали.
>Я совершенно не отрицаю проблем Perl'а, но синтаксис в них точно не входит.действительно, очень интересно, из чего же по вашему мнению состоит язык, кроме семантики и синтаксиса
>>Можно вот с этого места подробней, я записываю.
>Откройте доку по Perl (даже для начинающих!!!) - там уже все записано.Открыл. Почитал. Не нашёл. У меня не те man'ы?
>>А какие удобные в PHP конструкторы! В perl'е я могу их настрогать
>>ровно столько, сколько vim выдержит. А в php... ну, попробуйте. Ещё
>>советую попробовать один и тот же метод использовать как static и
>>как метод объекта. А как получится, напишите сюда. Доступ к передаваемым
>>функции параметрам, ежели они произвольного количества -- омг, расскажите им про
>>@_.
>"Разумному - достаточно""Кому и кобыла невеста".
PHP: вызов функции.
Perl: обращение к массиву @_.Теперь мне предстоит доказывать, что обращение к массиву проще?
>>После всех этих граблей у новичков будут напряги только с синтаксисом. Избавятся
>>от нежной любви к синтаксису а-ля бейсик, и всё зашибётся. Можно
>>методом от противного: показать им ook. :D
>В ваших словах противоречие, не видите? Ведь после того, как ты разобрался
>с перловым синтаксисом - ты уже не новичок.Да чего уж там, сразу достигнет нирваны, это ж синтаксис perl'а.
>И не надо доказывать что его синтаксис прост, понятен и логичен -
>это чрезвычайно трудно, поверьте.Строго говоря, вообще трудно доказывать что-нибудь человеку, обременённому опытом личных трудностей восприятия и нежелающему абстрагироваться от него. А ещё есть привычка, вторая натура. Она же инерционность сознания.
А если изучающий не удосужился прочитать man perlintro и man perlsyn... Таки ой. Очень сложная задача, особенно если учесть, что они на басурманском.
Короче, кругом сплошные трудности. Как страшно жить.
>Лучше расскажите-ка как вы пришли к перлу, вернее, что вас заставило к
>нему придти.Да как у всех: кушать очень хотелось. :D
> Криптосинтаксис Perl'а погубит егоОбязательно найдется пионер который это ляпнет. Это бред, запомните, у него очень вменяемый синтаксис.
>> Криптосинтаксис Perl'а погубит его
>
>Обязательно найдется пионер который это ляпнет. Это бред, запомните, у него очень
>вменяемый синтаксис.perl -wlne'/^(\S+)/;$h{$1}++}{print"$h{$}\t$"for sort{$h{$a}<=>$h{$b}}keys%h'
это вменяемый синтаксис, по вашему?
А если я вам с'шный код в одну строку запихаю, вы и цэ на помойку истории отправите?
Это абсолютно вменяемый и логичный синтаксис.
Скрипт простейший, если вы его приводите в качестве примера непонятности и невменяемости синтаксиса, то вам в программирование вообще рано руки совать. Там кстати, 2 ошибки.
Кроме того, это однострочник, расположенный целиком в коммандной строке. Python такое со своими отступами вообще умеет? И посмотрите на sed и awk, используемые таким же способом, на досуге.
Наконец, согласно вашей логике, C много, много хуже: http://www.ioccc.org/
>Это абсолютно вменяемый и логичный синтаксис.
>Скрипт простейший, если вы его приводите в качестве примера непонятности и невменяемости
>синтаксиса, то вам в программирование вообще рано руки совать. Там кстати,
>2 ошибки.Замечательно. Это рабочий код, не содержащий никаких ошибок. См. linuxjournal.
>Кроме того, это однострочник, расположенный целиком в коммандной строке. Python такое со
>своими отступами вообще умеет? И посмотрите на sed и awk, используемые
>таким же способом, на досуге.Вместить такое кол-во символов в командную строку можно. Почитайте про ; в Python. Правда, какой смысл в таких однострочниках, пока что никто не объяснил. А sed и awk - DSL, в отличии от тьюринг-полного Perl. Может, с javascript сравнимся?
>Наконец, согласно вашей логике, C много, много хуже: http://www.ioccc.org/
Как известно, подобного состязания для perl не существует, иначе туда пришлось бы отправить практически весь код на Perl
>Замечательно. Это рабочий код, не содержащий никаких ошибок. См. linuxjournal.ткните, в каком месте он рабочий.
>Замечательно. Это рабочий код, не содержащий никаких ошибок. См. linuxjournal.Ну попробуй запусти.
>Вместить такое кол-во символов в командную строку можно. Почитайте про ; в
>Python. Правда, какой смысл в таких однострочниках, пока что никто не
>объяснил.Тяжелый случай.
>А sed и awk - DSL, в отличии от тьюринг-полного
>Perl. Может, с javascript сравнимся?И что, у DSL, значит, все равно, какой синтаксис?
>Как известно, подобного состязания для perl не существует, иначе туда пришлось бы
>отправить практически весь код на PerlА вот это уже фанатизм.
> Обязательно найдется пионер который это ляпнет. Это бред, запомните, у него очень вменяемый синтаксис.Тривиальный импринтинг. Выучили бейсик, а всё остальное кажется сложным. Серьёзная ломка сознания происходит лишь после знакомства с чем-нибудь навроде sendmail'овского cf'а, особенно если таковое вызвано производственной необходимостью. Стимулирует.
>> Обязательно найдется пионер который это ляпнет. Это бред, запомните, у него очень вменяемый синтаксис.
>
>Тривиальный импринтинг. Выучили бейсик, а всё остальное кажется сложным. Серьёзная ломка сознания
>происходит лишь после знакомства с чем-нибудь навроде sendmail'овского cf'а, особенно если
>таковое вызвано производственной необходимостью. Стимулирует.+100
> сокращение за год базы пользователей на 0.86%Какой
> В то же время ...
> Впрочем,У меня есть мнение, но я с ним не согласен?
0.86% -- это потери доли рынка. Рынок растёт, база пользователей тоже. Остальные просто растут быстрее.
Не растут. Надуваются. Да и чёрт с ними.PHP удобен для напиания вещей в духе "сделал и забыл". Отсюда и численное превосходство базы пользователей. Для более других систем смотрят обычно в сторону java/всякие c и, та-дам! в сторону того же perl'а. На java, кстати, смотрят и разработчики php, судя по тенденциям php5. Видимо, догадываются о месте их детища. :)
Python и его синтаксис... Ой, блин, я уж лучше криптосинтаксисом perl'а. И объектность последнего, кажется, таки лучше. Впрочем, эту сову ещё надо прояснить.
По-моему, в инструменте, коим является язык программирования, по идее должна интересовать функциональность. А сколько там долей рынка -- дело десятое.
> Python и его синтаксис... Ой, блин, я уж лучше криптосинтаксисом perl'а.Не хватает $ перед переменными?
> И объектность последнего, кажется, таки лучше. Впрочем, эту сову ещё надо прояснить.
"Лучше" чем? Полным отсутствием?
> Не хватает $ перед переменными?Не-а. Умения и терпения расставлять пробелы в нужном количестве.
> "Лучше" чем? Полным отсутствием?
Да чего уж там, полнейшим-с-тремя-восклицательным-знаками-и-включенным-caps'ом. Осталось только выдрать из дистрибутива perltoot и прочие man'ы, и ваша точка зрения возобладает.
Кстати, вы в моём сообщении заметили глагол "кажется" и высказывание про сову?
>Кстати, вы в моём сообщении заметили глагол "кажется" и высказывание про сову?Просто показалось, что отвечать афоризмом Пруткова про сыр - вообще верх банальности. Я все-таки уважаю своих оппонентов.
> сокращение за год базы пользователей на 0.86%Какой страшный цыфр.
> серьёзную конкуренцию со стороны PHP, Python, Ruby.
PHP, ну как же. Куда ж без него. :)
> Управленцы компаний и учреждений, использующих данную технологию, в свою очередь, начинают полагать
> что Perl может обернуться для них такой же обузой, как в своё время COBOLСкоро управлянцы доберутся до си. Хватайте мешки, вокзал тронулся.
> В то же время свободное ПО, написанное на Perl, начинает испытывает существенные проблемы, связанные с развитием конкурентного фона, в отношении и качества кода, улучшить который будет уже сложно в силу основанности на его конкретных недостатках массы других модулей, и с качеством документации, направленной в первую очередь на уже занятых разработкой, а не на просто заинтересовавшихся.
"Дорогая пешеход набежал на переход". Не испытываю проблем со сложносочинёнными предложениями, но этот шыдевр, простите, ниасилил.
> В то же время ...
> Впрочем,У меня есть мнение, но я с ним не согласен?
Спокойствие, только спокойствие. Всё будет пучком. Собаки лают, караван идёт, код пишется.
>Спокойствие, только спокойствие. Всё будет пучком. Собаки лают, караван идёт, код пишется.Уязвленный перловод на opennet.ru? О судьбе perl-а написано еще в "Искусстве программирования в UNIX" за авторством Э. Реймонда. Слабо оспорить его аргументацию?
> Уязвленный перловод на opennet.ru?Я вот не увидел там никаой уязвленности, почему-то. Здравая ирония над новостью ни о чем.
А чего там Реймонд говорил? Искать лень.
>> Уязвленный перловод на opennet.ru?
>
>Я вот не увидел там никаой уязвленности, почему-то. Здравая ирония над новостью
>ни о чем.
>А чего там Реймонд говорил? Искать лень.Книга издания 1998 или 1999 года, кажется. Говорилось там о стагнации развития perl-а и о потере пользователей языком. Так же Реймонд утверждал, что многие переходят с Perl на Python, но практически никто не переходит с Python на Perl. Заметьте, это говорит Э. Реймонд, а не лично я.
> Заметьте, это говорит Э. Реймонд, а не лично я.А при чем тут Реймонд? Это факты. Только к судьбе perl-а никакого отношения они пока не имеют.
У Реймонда в нескольких местах проскальзывали фразы, вроде: "сложность структуры данных, совершенно однозначно говорит о невозможности использовать perl, но python был бы в самый раз".
Из чего можно достаточно уверенно сделать вывод, что человек не освоил ссылки, или освоил, но не до конца.
Согласен. Структуры данных там точно не сложнее чем в питоне.
>Книга издания 1998 или 1999 года, кажется. Говорилось там о стагнации развития
>perl-а и о потере пользователей языком. Так же Реймонд утверждал, что
>многие переходят с Perl на Python, но практически никто не переходит
>с Python на Perl. Заметьте, это говорит Э. Реймонд, а не
>лично я.А еще Э. Реймонд говорил что Python сильно проигрывает перед Perl в связи с отсутствием аналога CPAN. Заметьте, это не я сказал, а Э. Реймонд ;)
Кстати о синтаксисе. После BASIC, C/C++, Java, JavaScript, диалектов Lisp и Perl, мне очень тяжело даётся синтаксис Python...
А еще Ален Кар говорил что начать курить сложно. Это не я сказал (с) =) Это Ален Кар. И я ему верю. Тут главное нАчать (с). И после этого, если лень не задушит, можно разобраться с любым синтаксисом, а потом вполне откровенно удивляться - почему же у других это вызывает такие проблемы? =)
Вот как я сейчас не понимаю в чем сложность синтаксиса Perl. Только не надо повторять все сказанное выше. Это я так сказал, как бы между прочим =)
>А еще Э. Реймонд говорил что Python сильно проигрывает перед Perl в
>связи с отсутствием аналога CPAN. Заметьте, это не я сказал, а
>Э. Реймонд ;)Когда Коран писали, мин не было.
CheeseShop и easy_install развиваются достаточно быстро. Не CPAN, конечно, но большая часть нужных модулей там уже есть.>Кстати о синтаксисе. После BASIC, C/C++, Java, JavaScript, диалектов Lisp и Perl,
>мне очень тяжело даётся синтаксис Python...Python тоже не серебрянная пуля.
>Спокойствие, только спокойствие. Всё будет пучком. Собаки лают, караван идёт, код пишется.Полностью согласен. Новосте последнее время одна бредовей другой.
С одной стороны, перловый синтаксис ужасен! Куда приятнее писать на том же Lua.С другой стороны, на каком еще языке можно за пару часов навалять скрипт для автоматического обновления конфигурации файрвола, пары сотен демонов (sic!), шести сотен сетевых интерфейсов, берущий конфиги из потенциально недоступной базы данных?! Выбор не так уж велик.
>С одной стороны, перловый синтаксис ужасен! Куда приятнее писать на том же
>берущий конфиги из потенциально недоступной базы данных?!Это как, с модулем Perl::Astral?
>Выбор не так уж велик.
Ага. Любой Тьюринг-полный язык.
> С одной стороны, перловый синтаксис ужасен!Еще один. И что же там ужасного?
> Куда приятнее писать на том же Lua.
Приятнее?! Вот у Lua синтаксис как раз очень неудобный, из за этой паскалевской громоздкости и многословкости. Писать на этом долго, а читать уныло. И эти ужасные нестандартные комментарии (особенно многострочные)...
Размышления о популярности языка по воплям на различных форумах ошибочны. Ноют те кто не смог осилить что-то отличное BASIC. :) Нормальные люди пишут и не парятся популярен не популярен. Из-за кол-ва готовых решений в CPAN Perl трудно сбросить его со счетов. Поэтому пусть дальше пЕарятся пхпысты и прочие, а мы будем брать готовые решения из CPAN и оперативно решать свои задачи. В результате чего будет куча свободного времени. ;)
>пхпысты и прочие, а мы будем брать готовые решения из CPANPython -- batteries included since 1990(c)
Да понятно, понятно... ;) Фиг с вами как тока amazon.com перейдет с Перл на Питон мы будем считать что Перл умер. Главное чтобы Питон справился и не тормозил как поделия типа Plone.
>Фиг с вами как тока amazon.com перейдет с Перл на Питон мы будем считать что Перл умер.Да и с вами тоже фиг!
Как только google.com перейдет с Питона на Перл - будем считать что Перл жив.>Главное чтобы Питон справился и не тормозил как поделия типа Plone.
Да в конце концов - попробуй же уже Django ... 2 лямона хитов в день 1.8 Гц процессоре и IDE харде и не жжужжу :)
>[оверквотинг удален]
>
>Да и с вами тоже фиг!
>Как только google.com перейдет с Питона на Перл - будем считать что
>Перл жив.
>
>>Главное чтобы Питон справился и не тормозил как поделия типа Plone.
>
>Да в конце концов - попробуй же уже Django ... 2 лямона
>хитов в день 1.8 Гц процессоре и IDE харде и не
>жжужжу :)Да, да... Самый крупный магазин в интернете с оборотом в миллиарды долларов, куда им до твоего Целерона. :)))
>Да, да... Самый крупный магазин в интернете с оборотом в миллиарды долларов, куда им до твоего Целерона. :)))Да - ты прав, они от зависти умрут когда посчитают что делает мой серверок\затраты на его создание и их 70-ти тысячная серверная армада :)
Я _не_ гений программирования. Мои программы достаточно "прямолинейны" - без "бантиков". Но я в одиночку сделал этот серверок и оно очень хорошо работает! Мне в отличие от тебя есть чем гордится :-р
Насчет самого толстого в интернете - у тебя слово гугель прямо из тсп пакетиков вырезается да? Жаль ... там насколько я помню счет уже на сотни тысяч серверков ...
> ... есть чем гордится :-рГордыня грех, с грехами надо бороться. Давай адрес, будем досить!!! ;)
2 млн. хитов / 86400 сек. равно примерно 23 запроса в секунду. Хоть бы еще один ноль штоли приписал для большей гордости. :D
предлагаю хоть примерно рассказать о реализации простейшей задачи:одновременная выборка данных из нескольких баз Oracle(запрос сложный, большую часть времени мы ждём данных из оракла) в один большой хеш.
В базе табличка вида:
id data1 data2 data3 data4 data5Ключ этого хеша - id, значение - хеш с ключами - имена полей, а значения - соотв. значения для данного id.
Интересует момент синхронизации между тредами и организация хеша хешей.
Я бы реализовал это средствами базы данных. А потом бы выполнил запрос соответствующей хранимой процедуры и получил бы результат запроса.Или Oracle не умеет выполнить запрос из одной базы данных к другой? ;-)
Ты и в правду думаешь что оно Oracle видело? :)
>Ты и в правду думаешь что оно Oracle видело? :)для шибко умных: не всегда есть возможность создавать в базе свои объекты и максимум что вы можете - это сделать select.
Собсна, интересовала простая вещь: чтение в несколько потоков из базы и реализация хеша хешей.
Ну или хотя бы самое простое: конкатенацию двух массивов с последующей сортировкой результата.
>[оверквотинг удален]
>для шибко умных: не всегда есть возможность создавать в базе свои объекты
>и максимум что вы можете - это сделать select.
>
>
>Собсна, интересовала простая вещь: чтение в несколько потоков из базы и реализация
>хеша хешей.
>
>
>Ну или хотя бы самое простое: конкатенацию двух массивов с последующей сортировкой
>результата.вам сюда http://www.dhs.net.ru/documentation/en/OREILLY/books/perl2/c...
забивание гвоздей микроскопом занятие может быть и интересное, но бесперспективное на мой взгляд. поэтому перестаньте заниматься ерундой заставляя клиента базы данных делать то, что должна выполнить RDBMS. просто рано или поздно клиент базы данных столкнется с таким объемом данных которые он будет не в состоянии оперативно обработать.
По поводу сложности для начинающих - на русском языке издано много книг по Perl, большинство из них классические издания с качественным переводом. Lama, Cammel и Perl regexp - этих книг более чем достаточно. По Python у нас толком книг вообще нет, одна иди две которые были изданы по существу лишь сборники примеров. По PHP книг море, но покажите мне хоть одну действительно качественную, а не очередное издание для чайников "как стать гуру за 7 дней" или с промптоподобным переводом человека который в жизни не программировал ?
>По поводу сложности для начинающих - на русском языке издано много книг
>по Perl, большинство из них классические издания с качественным переводом. Lama,
>Cammel и Perl regexp - этих книг более чем достаточно. По
>Python у нас толком книг вообще нет, одна иди две которые
>были изданы по существу лишь сборники примеров. По PHP книг море,
>но покажите мне хоть одну действительно качественную, а не очередное издание
>для чайников "как стать гуру за 7 дней" или с промптоподобным
>переводом человека который в жизни не программировал ?Да, казалось бы логично. Но почему все же новички тянутся к PHP а не к Perl? Не потому ли что "...очередное издание для чайников "как стать гуру за 7 дней..."?
> Но почему все же новички тянутся к PHP а не к Perl?Куда они тянутся ничего не значит. Я тоже начинал с Pascal, а не C, с .bat файлов, а не shell. Интересно другое - почему крупные проекты типа популярых web форумов, mediawiki, блоговых движков, пишут на php? Их пишут явно не новички. Если бы такого парадокса не было, новичкам пришлось бы рано или поздно переходить на нормальные языки, как дельфисты переходят на C++. А куда деться? Не кросс платформенный, язык убог, код тормозной, половины возможностей плюсов нет, половины библиотек нет. А PHP удалось очень `удачно', являясь убогим и как язык, и архитектурно, занять web нишу, предоставляя пользователям якобы все, что может понадобиться. Увы.
>почему крупные проекты типа популярых web форумов, mediawiki, блоговых движков, пишут
>на php? Их пишут явно не новички.Не скажите, судя по ошибкам в phpbb этот форум пишут именно новички, которые только к версии 3.0 освоили программирование на php и начали немного думать о кешировании и безопасности.
Drupal и wordpress тоже очень долго доводили до работающего вида и избавлялись от наследия прошлого, многие из подобных проектов выросли из работ студентов.Из удачных проектов на php разве, что mediawiki можно привести, но ее писали за деньги с участием гуру и не без содействия помешанной в те годы на PHP Yahoo.
Интересно, спасибо.
А не следует ли из Ваших слов, что на PHP, как язык, тут совершенно не причем? Главное, кто и как на нем пишет?
Сейчас модно пинать PHP - только ленивый не пинает. Но хорошие и отлаженные проекты на PHP разве не показатель того факта, что PHP - вполне себе нормальный язык? Свои задачи он решает. Его "проблема" в его простоте и доступности, из за чего новички выбирают его и начинают ваять на нем свои первые испещренные ошибками программы.
>Сейчас модно пинать PHP - только ленивый не пинает. Но хорошие и
>отлаженные проекты на PHP разве не показатель того факта, что PHP
>- вполне себе нормальный язык? Свои задачи он решает. Его "проблема"
>в его простоте и доступности, из за чего новички выбирают его
>и начинают ваять на нем свои первые испещренные ошибками программы.Его пинают не за простоту и кучу детей, а за убогость.
Ладно, REGISTER_GLOBALS и прочее огромное число косяков уходят в лету.
Но это язык где используется сотня функций с названиями длиной от 10 символов, когда в perl используется десяток с длиной в районе 4 или вообще без названий (//). Там нет массивов. Там можно писать HTML прямо в код. Там совершенно ублюдочная установка модулей.
>>Сейчас модно пинать PHP - только ленивый не пинает. Но хорошие и
>>отлаженные проекты на PHP разве не показатель того факта, что PHP
>>- вполне себе нормальный язык? Свои задачи он решает. Его "проблема"
>>в его простоте и доступности, из за чего новички выбирают его
>>и начинают ваять на нем свои первые испещренные ошибками программы.
>
>Его пинают не за простоту и кучу детей, а за убогость.
>Ладно, REGISTER_GLOBALS и прочее огромное число косяков уходят в лету.По умолчанию REGISTER_GLOBALS отключен. А когда сто лет назад был по умолчанию включен - была возможность отключить.
>Но это язык где используется сотня функций с названиями длиной от 10
>символов, когда в perl используется десяток с длиной в районе 4
>или вообще без названий (//).Странно: для любителей Перла изучать груду документации по его особенностям не сложно, а вот запомнить названия нескольких десятков наиболее часто требующихся функций в PHP - неподъемно. А ключи для повседневных команд в linux-консоли вам не жмут? Их же превеликое множество...
Короче, ответ в Perl'овом стиле: "сотню функций с названиями длиной от 10 символов не знает тот, кто не смог их осилить"> Там нет массивов.
Где нет массивов? В Perl?
> Там можно писать HTML прямо в код.
Конечно можно! А можно и не писать! Мне не требуется - я никогда не пишу. В чем проблема?
> Там совершенно ублюдочная установка модулей.
Подробности в студию!
>>Его пинают не за простоту и кучу детей, а за убогость.
>>Ладно, REGISTER_GLOBALS и прочее огромное число косяков уходят в лету.
>
>По умолчанию REGISTER_GLOBALS отключен. А когда сто лет назад был по умолчанию
>включен - была возможность отключить.Язык, поведений лексем которого зависит от кучи настроек -- это очень, очень здорово. Видимо, чтобы программист не скучал, азартно расставляя if'ы по всему коду.
>>Но это язык где используется сотня функций с названиями длиной от 10
>>символов, когда в perl используется десяток с длиной в районе 4
>>или вообще без названий (//).
>Странно: для любителей Перла изучать груду документации по его особенностям не сложно,
>а вот запомнить названия нескольких десятков наиболее часто требующихся функций в
>PHP - неподъемно."Несколько десятков", да. Одни array_* не тянут на десяток. А ведь повседневные. А теперь почитайте perlfunc, сколько там функций для работы с массивом. И ведь в совокупности с другими они дают гораздо больший функционал. И не нужно запоминать весь кошмар array_* и прочих *_*.
> А ключи для повседневных команд в linux-консоли вам
>не жмут? Их же превеликое множество...Беда этого вашего якобы аргумента в том, что это ключи _команд_. Обратите внимание -- команд, а не командЫ. А вы про функции языкА, а не языкОВ. Ключи команд (именно команд) запоминаются легче. Ассоциативные связи, максимальное количество объектов, удерживаемых одновременно в памяти и всё такое. Такие дела. Тут мне следовало бы отослать вас к механизмам человеческой памяти, но не буду, всё равно ведь не пойдёте.
>Короче, ответ в Perl'овом стиле: "сотню функций с названиями длиной от 10
>символов не знает тот, кто не смог их осилить"Вы случайно не с зеркалом разговариваете?
>>>Его пинают не за простоту и кучу детей, а за убогость.
>>>Ладно, REGISTER_GLOBALS и прочее огромное число косяков уходят в лету.
>>
>>По умолчанию REGISTER_GLOBALS отключен. А когда сто лет назад был по умолчанию
>>включен - была возможность отключить.
>
>Язык, поведений лексем которого зависит от кучи настроек -- это очень, очень
>здорово. Видимо, чтобы программист не скучал, азартно расставляя if'ы по всему
>коду.
>Давайте конкретнее: REGISTER_GLOBALS по умолчанию уже давно отключен. Что тут не так?
>>>Но это язык где используется сотня функций с названиями длиной от 10
>>>символов, когда в perl используется десяток с длиной в районе 4
>>>или вообще без названий (//).
>>Странно: для любителей Перла изучать груду документации по его особенностям не сложно,
>>а вот запомнить названия нескольких десятков наиболее часто требующихся функций в
>>PHP - неподъемно.
>
>"Несколько десятков", да. Одни array_* не тянут на десяток. А ведь повседневные.А зачем мне сразу все array_* ?
>А теперь почитайте perlfunc, сколько там функций для работы с массивом.
>И ведь в совокупности с другими они дают гораздо больший функционал.Т.е. на PHP нельзя что-то сделать с массивом что можно сделать в Perl?
>И не нужно запоминать весь кошмар array_* и прочих *_*.
>Повторюсь еще раз: зачем запоминать все до одной? Вы не поверите! У меня нечасто бывают ситуации, когда я не помню синтаксис какой-то функции. Но если такое случается - я смотрю доку - она всегда под рукой.
>> А ключи для повседневных команд в linux-консоли вам
>>не жмут? Их же превеликое множество...
>
>Беда этого вашего якобы аргумента в том, что это ключи _команд_. Обратите
>внимание -- команд, а не командЫ. А вы про функции языкА,
>а не языкОВ. Ключи команд (именно команд) запоминаются легче. Ассоциативные связи,
>максимальное количество объектов, удерживаемых одновременно в памяти и всё такое. Такие
>дела. Тут мне следовало бы отослать вас к механизмам человеческой памяти,
>но не буду, всё равно ведь не пойдёте.
>Вот вы, опираясь на механизмы человеческой памяти, сможете не заглядывая в man вспомнить все ключи у, к пример, ls ?
>>Короче, ответ в Perl'овом стиле: "сотню функций с названиями длиной от 10
>>символов не знает тот, кто не смог их осилить"
>
>Вы случайно не с зеркалом разговариваете?Нет. Это я вам адресовал.
Перл труден для изучения. Но изучивший его (сюда же можно причислить и тех, кто досконально разобрался в sendmail.cf) начинает ложноскромничать, типа: "тут все просто, изящно и красиво; почему этого никто не понимает?.." Может и так. Но для этого надо сначала его осилить. Я когда-то попытался: в самом начале доки - у каждого правила куча исключений. По-моему, это не просто, не изящно и не красиво. Я не осилил и не боюсь в этом признаться. У меня гораздо проще в мозгу улеглась груда функций PHP - ничего не заучивал - само запомнилось.
Так понятней?
>> Но почему все же новички тянутся к PHP а не к Perl?
>
>Куда они тянутся ничего не значит. Я тоже начинал с Pascal, а
>не C, с .bat файлов, а не shell. Интересно другое -
>почему крупные проекты типа популярых web форумов, mediawiki, блоговых движков, пишут
>на php? Их пишут явно не новички. Если бы такого парадокса
>не было, новичкам пришлось бы рано или поздно переходить на нормальные
>языки, как дельфисты переходят на C++.Не кажется ли Вам странным наличие такого парадокса? Может, это не парадокс вовсе, а закономерность, смотря с какой стороны посмотреть?
Если "нормальный" язык неудобен в конкретном случае, то я думаю что он ненормален (опять же для этого случая).А куда деться? Не кросс
>платформенный, язык убог, код тормозной, половины возможностей плюсов нет, половины библиотек
>нет. А PHP удалось очень `удачно', являясь убогим и как язык,
>и архитектурно, занять web нишу, предоставляя пользователям якобы все, что может
>понадобиться. Увы.Вот когда пользователям потребуется больше чем может их инструмент (ЯП), тогда они будут использовать что-то другое. А до той поры - "Разумному - достаточно". Не надо стрелять из пушки по воробьям.
>Куда они тянутся ничего не значит.очень даже значит.
>как дельфисты переходят на C++
да? что-то не видел толп дельфистов, бегущих к оазису С++
>Не кросс платформенный
тут, на опеннете, кагбэ тема рядышком про "некроссплатформенную" среду разработку
>язык убог, код тормозной, половины возможностей плюсов нет
тролль толст, очень толст
>половины библиотек нет
ну, вам виднее, вы же у нас счетовод.
программеры пишут, не парятся, деньги зарабатывают>PHP удалось очень `удачно', являясь убогим и как язык, и архитектурно, занять
>web нишу, предоставляя пользователям якобы все, что может понадобиться. Увы.Увы. Вы не знаете о существовании ZF, Symfony, CakePHP, CodeIgniter.
А это для любого языка справедливо, думаю. Необходимы 3(три) книги, а именно 1) вводная вроде ламы, 2) подробное описание a-la верблюд, и 3) сборник рецептов, который поможет быстро решить типовую задачу, пока осиливаешь верблюда. Остальное - уже глубокая специфика. Хотя вру, четвертое дожно быть еще руководство по стилю, вроде Effective Perl Programming.
>А это для любого языка справедливо, думаю. Необходимы 3(три) книги, а именно
>1) вводная вроде ламы, 2) подробное описание a-la верблюд, и 3)
>сборник рецептов, который поможет быстро решить типовую задачу, пока осиливаешь верблюда.
>Остальное - уже глубокая специфика. Хотя вру, четвертое дожно быть еще
>руководство по стилю, вроде Effective Perl Programming.Кому интересно - в моем собрании 61 книга по Perl (rus+engl)
А насчет того, почему новички тянутся к PHP - тут все просто. Он прост в Web разраборке - положил файл на сервер и не думаешь ни о правах на запуск, ни о строке с путем к интерпретатору - такие вот "мелочи" Perl и задвинули.
я,кстати, о таких мелочах подумал и поделал FCGI::Spawn. а по-Вашему, что лучше бы сделать в этом направлении?>А насчет того, почему новички тянутся к PHP - тут все просто.
>Он прост в Web разраборке - положил файл на сервер и
>не думаешь ни о правах на запуск, ни о строке с
>путем к интерпретатору - такие вот "мелочи" Perl и задвинули.
PHP — очень „вредный“ язык: он расхолаживает, расслабляет. Конечно, человека, который делает, например, Google, это не касается. А какой-нибудь Вася Пупкин, который строит сайты на Народ.ру, может получить „синдром PHP“: потерять способность и желание развиваться. По мне лучше, чтобы в резюме этого языка не было совсем. Конечно, на PHP делают мощные, большие сайты, но в основном на нем пишется всякий мусор. Соответственно и зарплаты PHP-программистов самые низкие — от 1000 $, а иногда и меньше. Загляните на Фриланс.ру: „пэхэпэшников“ там очень много, и они согласны трудиться буквально за еду. Ну а как по-другому расценивать положительный отклик на предложение поработать две недели за 50 долларов?»
>PHP — очень „вредный“ язык: он расхолаживает, расслабляет. Конечно, человека, который делает,
>например, Google, это не касается. А какой-нибудь Вася Пупкин, который строит
>сайты на Народ.ру, может получить „синдром PHP“: потерять способность и желание
>развиваться. По мне лучше, чтобы в резюме этого языка не было
>совсем. Конечно, на PHP делают мощные, большие сайты, но в основном
>на нем пишется всякий мусор. Соответственно и зарплаты PHP-программистов самые низкие
>— от 1000 $, а иногда и меньше. Загляните на Фриланс.ру:
>„пэхэпэшников“ там очень много, и они согласны трудиться буквально за еду.
>Ну а как по-другому расценивать положительный отклик на предложение поработать две
>недели за 50 долларов?»Т.е. простота PHP, обилие инфы по нему в интернете - это его недостаток, не так ли?
Но новички не должны искать легких решений! Для домашней странички надо изучить Перл, обязательно заюзать Oracle, на dedicated сервер все это...
Никак не могу понять что плохого в том, что на PHP "...пишется всякий мусор..." и "...на PHP делают мощные, большие сайты..." Не зависит ли это от программиста?
>Никак не могу понять что плохого в том, что на PHP "...пишется
>всякий мусор..." и "...на PHP делают мощные, большие сайты..." Не зависит
>ли это от программиста?Ничего в PHP плохого нет, мне он вообще параллелен. Плохо то, что Perl даже не пытается избавиться от многих "мелких" неудобств, которые, по большому счету ему и не нужны.
FCGI конечно хорошо, но много ли хостеров его дают? А почему так происходит? Вот где надо искать причины непопулярности, а отнюдь не в синтаксисе. Я вот, когда Perl начал изучать - просто наслаждался.
> Плохо то, что Perl даже не пытается избавиться от многих "мелких" неудобствА может, оно не неудобства? Раз уж примеров не удосужились привести. Вы не подумали, что это именно _вам_ кажется неудобством, в силу привязанности восприятия (опять же, персонально вашего) к тем языковым конструкциям, которым вас обучили в школе/институте? Импринтинг, как я уже говорил.
> FCGI конечно хорошо, но много ли хостеров его дают?
А-а-а, вон мы про что. То есть, речь идёт о проектах на _массовых_ хостингах. Ну, это ооочень серьёзный спектр применения, без "бэ".
Тут как с 1с. В бухгалтерии она хороша. Но только там. Хотя мне демонстрировали и более другие применения, но это были скорее упражнения в гибкости извилин при ограниченности инструментов. Но в отличие от фоннатов php, 1c-ники не проповедуют анекдотичные лозунги "скоро любая бабка в маршрутке будет знать, что такое php". Хотя чёрт его знает, может, уже и там подросло поколение с соответствующим образом мышления.
>Тут как с 1с. В бухгалтерии она хороша. Но только там. Хотя
>мне демонстрировали и более другие применения, но это были скорее упражнения
>в гибкости извилин при ограниченности инструментов. Но в отличие от фоннатов
>php, 1c-ники не проповедуют анекдотичные лозунги "скоро любая бабка в маршрутке
>будет знать, что такое php". Хотя чёрт его знает, может, уже
>и там подросло поколение с соответствующим образом мышления.могу Вас-таки уверить, что подросло! хотя, надо быть справедливым - мы честные люди, речь шла о "восьмерке", про "семерку" они сами недовольны...
А чем вам не нравится COBOL уважаемые?
Я вот давно пишу на нём и в ус не дую.
А вы мне "Perl, Python, Java" - дикие люди
>А чем вам не нравится COBOL уважаемые?
>Я вот давно пишу на нём и в ус не дую.Дык так и делают. А на форум вылезешь - оказывается синтаксис ужасный я вообще язык уже 21 год как мертв.
Что для меня в Perl не нравится:1) Документирование и документация.
phpdoc на голову лучше pod - а скорее даже на две или на три. Описать аргументы функций стандартными средствами на perl невозможно, получить удобную документацию в стандартном виде тоже нельзя. Поддержки документирования в IDE я не встречал.2) Запуск на сервере. mod_perl слишком сложен, mod_perl и fast_cgi нераспространён на хостингах. Отладку приходится делать в режиме CGI, чтобы не перегружать сервер.
3) Современные протоколы, такие как SOAP, поддерживаются в зачаточном состоянии. На практике использовать perl для написания soap12 сервиса не получилось.
4) Разностильность кодирования. Код какого-нибудь энтузиаста поддерживать невозможно.
5) Нет поддержки со стороны производителей софта. Например, WSO2 поддерживает всё кроме perl. Кстати, хороший пример сравнения perl и php - странички документации http://wso2.org/project/wsf/php/2.0.0/docs/index.html и http://search.cpan.org/~chintana/WSO2-WSF-Perl-1.1/ . Такое отношение к перлу типично.
6) Отсутствие перспектив развития. Perl6 показал, что развиваться perl5 не будет.
>Что для меня в Perl не нравится:Во, вот тут со всем согласен. На счет 3 не уверен, SOAP 1.0 использовал без проблем, выше не пробовал.
>>Что для меня в Perl не нравится:
>
>Во, вот тут со всем согласен. На счет 3 не уверен, SOAP
>1.0 использовал без проблем, выше не пробовал.1.0 действительно есть. 1.2 есть теоретически, практически есть проблемы, кажется к нему интерес авторов модулей полностью пропал.
Python, Ruby :D сравнили блин. Не все могут понять этот синтаксис, а php не конкурент.
Perl хорош для прочистки мозгов;
Но есть рынок - и там пифоны с джангами и руби с рельсами;
Catalyst и прочие перловые вкусности только для олдовых Ъ.
А язык этот будет жить, хотя бы в выжеозначенном качестве.
Всем спокойной ночи.
Кто-нибудь озадачивался замером производительности Perl VS PHP VS Python хотя бы в плане быстродействия и объемом потребляемой при этом памяти? Можете рассказать, что у вас получилось?
>Кто-нибудь озадачивался замером производительности Perl VS PHP VS Python хотя бы в
>плане быстродействия и объемом потребляемой при этом памяти? Можете рассказать, что
>у вас получилось?Perl обгоняет по времени в большинстве случаев и меньше потребляет памяти.
На Python пишут и отлаживают быстрее, потому что он интерактивный. Perl 6 тоже должен быть интерактивный.
>>Кто-нибудь озадачивался замером производительности Perl VS PHP VS Python хотя бы в
>>плане быстродействия и объемом потребляемой при этом памяти? Можете рассказать, что
>>у вас получилось?Ещё один забаненный в гугле?
>Perl обгоняет по времени в большинстве случаев и меньше потребляет памяти.
А вот этот перец http://shootout.alioth.debian.org/ - говорит что ты врешь! Питон получается почти всегда быстрее! А на современных процах таки сильно быстрее.
И я Алиоту (в отличие от тебя) - верю!
Если сравнивать CGI то да Змий будет побеждать во многих случаях за счет того что он байт-код, но как-то Вы прикруте к апачу мой ник, я всех урою, мне больше не нужно будет тратить время на интерпрЫтацию. ;-)
>Ещё один забаненный в гугле?Каждый кулик хвалит свое болото. :-\
Вообщем я смастерил четыре простеньких скрипта выводящих Hello World!!! со счетчиком от 1 до 1000000. Вывод команды time ниже...
PHP 5.2.6:
real 0m43.768s
user 0m1.224s
sys 0m0.903s
Perl 5.8.8:real 0m35.856s
user 0m0.787s
sys 0m0.847sPython 2.5.2:
real 0m41.790s
user 0m2.004s
sys 0m0.939sBash 3.2.033
real 1m5.762s
user 0m15.250s
sys 0m1.341s
P.S. Все интерпретаторы оптимизированы с одинаковыми флагами.
>Вообщем я смастерил четыре простеньких скрипта выводящих Hello World!!! со счетчиком от
>1 до 1000000. Вывод команды time ниже...
>P.S. Все интерпретаторы оптимизированы с одинаковыми флагами.Поздравляю, только что Вы опубликовали еще один нерелевантный тест.
Ничего, что в замеры попало время запуска интерпретаторов?
>>Вообщем я смастерил четыре простеньких скрипта выводящих Hello World!!! со счетчиком от
>>1 до 1000000. Вывод команды time ниже...
>>P.S. Все интерпретаторы оптимизированы с одинаковыми флагами.
>
>Поздравляю, только что Вы опубликовали еще один нерелевантный тест.
>Ничего, что в замеры попало время запуска интерпретаторов?А как надо правильно?
О! Чую, сейчас будет сравнение mod_php с cgi/perl. Любимое развлечение фанатов php, при том, что они в большистве своём даже не знают, что такое mod_*.Уже запасся попкроном. Можно начинать.
Вот вы тут синтаксис, ООП, скорость....А все на поверхности лежит. Если людям надо сделать маленький форум для маленькой группы людей, причем никто не представляет ни о ПХП ни о Перл. Что они сделают? Правильно пойдут в гугл и "скачать форум" Что им выдаст? Phpbb, IPB, PHPnuke, Drupal .... Еще столько же вариантов выдаст поисковик на фотогаллерея, блог, чат ... Что будет качать пользователь. Именно это и будет. А что подобное написано на перл? Где готовые решения а не модули библиотеки? Кроме того, хостеры, особенно бесплатные, зачастую предоставляют поддержку только пхп, о перле речь идет только на платных. На старт апе этих условий вполне достаточно чтобы начать писать на пхп.
С другой стороны на чем пишут админы скрипты? На пхп... фу. .. на баш или перл. Вот вам и ответ. Языки для разных целей существуют! Всего то. Это как обсуждать что лучше камаз или лада калина
>Это как обсуждать что лучше камаз или
>лада калиналучше пешком ходить :)
>>Это как обсуждать что лучше камаз или
>>лада калина
>
>лучше пешком ходить :)Во во я про это как раз и говорю!
>>Это как обсуждать что лучше камаз или
>>лада калина
>
>лучше пешком ходить :)Владельцы "Лада Калина" и "Камазов" всегда говорят "лучше пешком ходить", но почему-то никогда пешком не ходят! :-D
>С другой стороны на чем пишут админы скрипты? На пхп... фу. ..
>на баш или перл. Вот вам и ответ.На bash и python. Начинал трудовую деятельность как программист на C++, когда встал вопрос про выбор скриптового языка для мелких задач, первым делом я конечно взглянул на перл, но.. нет в нем красоты :) язык должен быть приближен к человечьему а не к закарючкам и скобочкам ))) а что до отступов в питоне, так есть такая кнопка "Tab" называется :)
Для каждого хорош тот язык которым он влядеет, но при изучении "с нуля" есть выбор...
Закорючки и скобочки тоже можно красиво расставить. Я вот для себя это уже очень отчетливо понял и стараюсь писать так, чтобы было красиво -- благо в отношении количества пробелов перл не обременяет -- ставь где душе угодно, если синтаксис позволяет. Насчет питона -- ничего не имею против, начинал даже заниматься, но при наличии перл питон не пошел. Языки занимают практически одну нишу, но лично для меня перл оказался не в пример удобнее.
>язык должен быть приближен к человечьему а не к закарючкам и
>скобочкам )))язык человеку не должден ничего кроме свободы равного выражения своих мыслей разными, подходящими человеку, способами. Нравится без скобок и закорюк --- делай. в php --- точно не сможешь сделать мой недавний one-liner таким же читаемым:
cp -v $* | perl -ne 's/^(.*) -> .*$/$1/; chomp; my $fs = [stat $_]->[7]; our $sum += $fs; my $sum_rep = $sum; $sum_rep=~ s/(\d{6})$/ $1/g; print "$fs\t$sum_rep\n"'
> а что до отступов в питоне, так есть такая
>кнопка "Tab" называется :)она к шеллу относилась и будет отнситься, так что по части one-liners python в глубоком пролёте. :)
кстати, о "человечьести": а кто за лингвиста у авторов питона? я, как всегда, "просто разобраться хочу" :)
>cp -v $* | perl -ne 's/^(.*) -> .*$/$1/; chomp; my $fs = [stat $_]->[7]; our $sum += $fs; my $sum_rep = $sum; $sum_rep=~ s/(\d{6})$/ $1/g; print "$fs\t$sum_rep\n"'Офигеть как читаемо!
>>cp -v $* | perl -ne 's/^(.*) -> .*$/$1/; chomp; my $fs = [stat $_]->[7]; our $sum += $fs; my $sum_rep = $sum; $sum_rep=~ s/(\d{6})$/ $1/g; print "$fs\t$sum_rep\n"'
>
>Офигеть как читаемо!man regexp
и далее по ссылкам, если так "нечитаемо" =)
время - деньги
чем понятнее код, тем дешевле его поддерживать
>время - деньги
>чем понятнее код, тем дешевле его поддерживатьТо, что выполняют регулярные выражения в "нормальном" коде как правило выглядит куда как более нечитабельно.
Так и признайтесь, что просто не осилили регекспы, потому синтаксис Perl и кажется ужасным.
>Так и признайтесь, что просто не осилили регекспы, потому синтаксис Perl и
>кажется ужасным.может хватит постить фигню, а?
я вот языки не учу, оно как то собо самой получается. Сначала поправишь где-то что-то,
потом помелочи напишешь, потом может доку в интересных местах подиагонали и нормально.
Для не профессионального использования. С перл-ом так не получилось. Видимо я не лингвист.
Хорошо сказал, наверное, самая правильная мысль из всех высказываний...
>С другой стороны на чем пишут админы скрипты? На пхп... фу. ..Я пишу на пхп. Рулит. Вообще никакой cpan не нужен - всё нужное в одном флаконе.
По моему основная проблема perl - его свобода синтаксиса.
Если синтаксис языков подобных ruby и php "заталкивает" программиста писать и читать "как надо", то в случае perl эту функция возложена на стайлгайды.
Какой и методов вернее если честно я не знаю )
Большое спасибо, граждане хорошие.
Тут вот о чём забыли померяться: количеством и качеством реализованных демонов.
Прямо сейчас пишу в юзнет на news.php.net через... Colobus. На мой взгляд, лучшего признания Perl'а Php'ом не найти.
Слышал, конечно, и о pure php демоне для http. Но как он соревнуется с Perl'овским? я бы почитал.
а семантика и синтаксис... недавно же здесь статья была о том, что постепенно они теряют своё значение, это проявляется не только в том, что языки заимствуют друг у друга всё больше --- я, например, в своё время рыдал от того счастья, что в php наконец-то появился foreach(), но и в том, что на рынке труда и услуг всё большее значение заказчики придают не применяемым языкам, а тому, что с ними связано --- каркасам, например, ведь в конце концов и Zope можно найти переписанный на PHP ( кажется ), и CGI::Application даже. Sajax вон, вроде и на perl тоже есть, я бы даже сказал, что большой разницы между ним и CGI::Ajax не вижу. Языки шаблонирования современные тоже всё больше стремятся поддержать разные языки программирования --- XSL, CTPP, Smarty(?) кто следующий? ;) или вот методологиям (QnD, RAD, RUP), средствам контроля версий и учёта задач. Вот, например, что бы присутствующие улучшили в PAUSE, может быть, с учётом опыта конкурентов?
а вы тут о синтаксисе... да скучно уже, разжёвано 300 раз.
Господа, я скажу так. Я пересел с питона на перл, а почему? Потому что лучше языка для системного администратора не найти. Он вполне себя оправдывает хотябы в том, для чего был сделан, т.е. делать отчеты, парсить и работать с файлами, а также выполнять рутинную работу. Да и интеграция с оболочкой намного удобнее напримере тех же дескрипторов файлов, чем через подключаемую библиотеку в питоне. Вспомните насколько просто реализована работа с каталогами и файлами. И все это можно делать из оболочки не создавая файлов, что зачастую бывает удобно. Не забываем, что во многих книгах по перлу есть особая атмосфера, которая так и называется "Perl как культура". Об этом языке можно говорить и говорить. Этот язык легко отделяет профессионалов от новичков.
Я по-прежнему считаю, что круче парсера, чем перл -- нет. Понравилась выдержка из "Кэмел бук": "В любой книге по регулярным выражениям указывается, что стандартные регулярные выражения не могут правильно находить вложенные скобки. И это правильно. Правильно и то, что регулярные выражения Перл не являются стандартными" :). В общем, каждый язык, если он создан и востребован сообществом -- имеет право быть. Человек, по-настоящему знакомый с перл, вряд ли с него уйдет. Вот мне перловский синтаксис прост и понятен. А питоновские __XXX__ мягко говоря, раздражают. И зачем мне чтобы распарсить строку в логе, подключать модуль регулярных выражений? С другой стороны, если я без этого не могу, что мешает завернуть регулярное выражение в объект? Почитайте книжку про OO в Перл Дэмиэна Конвея, (на русский, правда, не переводилась) -- человек показывает объектно-ориентированые фокусы на Перл с точки зрения правильного объектно-ориентированного программирования. В общем, тема себя изжила. Перл будет долго еще на сцене, что бы там ни выдумывали разные всякие.
>И зачем мне чтобы распарсить строку
>в логе, подключать модуль регулярных выражений?Ээээ, простите, а что, подключать модуль - Коран не велит? То есть, что с того, что надо подключать модуль?
>Почитайте книжку про OO в Перл Дэмиэна Конвея, (на русский, правда,
>не переводилась) -- человек показывает объектно-ориентированые фокусы на Перл с точки
>зрения правильного объектно-ориентированного программирования.Будьте добры ссылки на материалы с объяснением, что такое "правильное ООП". Неужто то, что в Perl - единственно верное православное ООП?
ИМХО Перл сузится до пользователей для которых его придумал Лари Велл - админов уникс-базет систем. Я конечно видел как пишут на Sed+Shell+Awk но енто мне кажется слижком сложновато и неоправдано :-). Ну возможно ещё на нем будут писать те люди - которые любят в веб и веб интерфейсах для СУБД разделять яблоки и гвозди. Но этот процесс мне кажется вполне вминяемым. Сейчас много языков-скриптов для разработки всяких оконных приблуд. Я както писал на перл+егоМодульТК и чесно сказать - подрезочаровался. Не в перл, а в локализации егоМодуляТк под отечественные потребности. Мож что не докрутил - но в итоге под МВ+активеСтате5.X он работал лутьчше чем под ЛинуксМандрива :-). Ирония!
А для всякого рода ТекстаРазборов и Отчётов - Руль. Пороще чем везде гре видел. И глуппый вопрос - а зачем мне для создания отчёта из СУБД в обычную форму ВЕБ или для суммирования значений в логах накручивать Объеты? Можно конечно и объекты - но зачем? Чм плох структурный подход к программированию к решению СреднеМелких задач? Пусть объектом будет сам ВЕБ сервер А его свойствами - набор скриптов! ИМХО - шустрее выйдет.Мы все умрём - НО МЫ ЖЕ ЖИВЫ!
>Я както писал на перл+егоМодульТК и чесно сказать
>- подрезочаровался. Не в перл, а в локализации егоМодуляТк под отечественные
>потребности. Мож что не докрутил - но в итоге под МВ+активеСтате5.X
>он работал лутьчше чем под ЛинуксМандрива :-). Ирония!Мож, стоит обратить внимание на WxWidgets? Я как-то начинал на kiev.pm.org (http://kiev.pm.org:8000/Kiev.PM/wiki/WxPerl), но ввиду катастрофической нехватки времени и врожденной лени подзабросил это дело. А вообще достойная штука и для достаточно продвинутых вещей. В линуксе и венде выглядит практически одинаково.
подтверждаю что да.>Мож, стоит обратить внимание на WxWidgets? Я как-то начинал на kiev.pm.org
>подтверждаю что да.
>
>>Мож, стоит обратить внимание на WxWidgets? Я как-то начинал на kiev.pm.orgНо при всем при этом сайт поднят на друпале... =)
>>подтверждаю что да.
>>
>>>Мож, стоит обратить внимание на WxWidgets? Я как-то начинал на kiev.pm.org
>
>Но при всем при этом сайт поднят на друпале... =):-)
Drupal среди CMS очень похож на Perl.
Те, кто по-настоящему разобрался с его возможностями просто в восторге.
Но большинство его не понимают(не хотят понимать, не способны понять) и употребляют по отношению к нему термины "не понятен", "сложен", "не логичен", "а вот в (имярек) все просто и понятно".
>[оверквотинг удален]
>>>>Мож, стоит обратить внимание на WxWidgets? Я как-то начинал на kiev.pm.org
>>
>>Но при всем при этом сайт поднят на друпале... =)
>
>:-)
>Drupal среди CMS очень похож на Perl.
>Те, кто по-настоящему разобрался с его возможностями просто в восторге.
>Но большинство его не понимают(не хотят понимать, не способны понять) и употребляют
>по отношению к нему термины "не понятен", "сложен", "не логичен", "а
>вот в (имярек) все просто и понятно".Я в восторге от Drupal, так как поднял на нем не один сайт различных конфигураций. =)
Я про то, что товарищ несколькими тредами выше сделал замечание, что на перл не написано не одной более-менее известной ЦМС и даже упомянутый выше сайт, посвященный Perl использует движок, написанный на PHP. Может действительно не стоит лукавить, пытаясь пропихнуть Perl в нишу "языков для WEB"?P.S. Я не холиварщик и не отношусь предвзято ни к PHP, ни Perl, ни к чему бы то небыло. Я разобраться хочу...
webgui.org
Спасибо!
Перл появился как замена шел/авк/сед, и он, конечно, куда круче этого симбиоза костылей. Но мегакостыль остаётся костылём. Всё что я о нём думаю, я давно выразил тут
http://able.com.ua/~gnut/php-perl.html
Вкратце:
1) local, my - уродство
2) сложные структуры (массивы массивов) - вообще маразм дикий
3) возвращаемое значение функций зависит от контекста
4) кривой do, сравните с include/require/require_once
5) eq/gt - ещё то уродство.
6) кто-то говорит что функции ПХП сложно запомнить, лицемерие. Знаешь английский - помнишь функции. куда хуже новичку читать map/grep/lc/qq/tr/qx/uc и прочий bless. Хорошо что там не китайские иероглифы, а то пришлось бы и их запоминать.
7) CPAN - пхпшники вообще часто не понимают зачем это, тем же pear пользуются куда реже.
8) да и вообще, PHP - это уже технология, а не просто язык. А перл больше даже не язык, а фреймворк для своего языка.
В догонку:
9) в ПХП переменная - уже является неявной ссылкой. $a = & $b; красота. Нафига ещё одна сущность которую нужно дереференсить????В результате перл это язык, который вместо решения проблем их ставит программисту.
А всё нытьё по поводу безопасности ПХП сводится вообще в 0, потому что это проблемы задач, которые перл вообще не решает, потому что просто язык, а не технология. Где у перла safe_mode, где у перла open_basedir? Не слышал о таком вообще. Не интересовался, но на вскидку не помню о профайлинге перл-приложений, в том же пхп это красиво делается дебаггерами. А кеширование байт-кода в перле типа eaccelerator?