"Scripting languages spark new programming era (http://www.infoworld.com/article/08/06/23/26NF-dynamic-scrip...)" - скриптовые языки открыли новую эру в программировании. В статье рассказывается об успехах JavaScript, PHP, Perl, Python и Ruby. Даже для платформы .Net появилась реализация языков Ruby и Python.URL: http://www.infoworld.com/article/08/06/23/26NF-dynamic-scrip...
Новость: http://www.opennet.me/opennews/art.shtml?num=16612
Надеюсь, о дырявости реализаций скриптовых языков на различных платформах там также честно рассказывается? xD
>Надеюсь, о дырявости реализаций скриптовых языков на различных платформах там также честно
>рассказывается? xDНет нет, что Вы, не рассказано. Расскажите, интересно послушать.
ИМХО, популяризация "удобных" ЯВУ сделает сишников такой же сектой как сейчас ассемблерщики...
Пока железяки проектируют люди, будут нужны люди которые будут заставлять их работать как надо.
>Пока железяки проектируют люди, будут нужны люди которые будут заставлять их работать
>как надо.Это как же? Как надо? ))))
Си сейчас постепенно занимает подабающее ему место в системном программировании. А уж ошибки быдлокодеров на нём куда фатальнее для безопасности, чем на более свежих языках. Ну ведь так это.
>ошибки быдлокодеров на нём куда фатальнее для безопасности, чем на более
>свежих языках. Ну ведь так это.Ну да, в итоге быдлокодеры наляпают на "безопасном" языке скажем биллинг.Ну, конечно код на нем не выполнишь напрямую.Зато транзакции могут быть реализованы абы как, логика работы может быть brain damaged и в итоге юзеры которых это должно биллинговать могут скажем шутя и совершенно легитимными и штатными действиями прокинуть обладателя этого гуано на такую сумму баблосов что лучше бы пожалуй там выполнили код.Это достаточно заметно хотя-бы и легко ловится.А вот логические ошибки и проблемы секурити обычно замечают только когда вас уже смачно натянули на много денег.
>ИМХО, популяризация "удобных" ЯВУ сделает сишников такой же сектой как сейчас ассемблерщики...
>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby ? В этом списке таких нет. JS примитивен и нет своих библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для небольших скриптов и без модулей вообще фигня уровня bash. Python - угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
Rexx в списке нет.
>[оверквотинг удален]
>>
>
>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
>? В этом списке таких нет. JS примитивен и нет своих
>библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для
>небольших скриптов и без модулей вообще фигня уровня bash. Python -
>угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
>
>
>Rexx в списке нет.+100
>[оверквотинг удален]
>>
>
>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
>? В этом списке таких нет. JS примитивен и нет своих
>библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для
>небольших скриптов и без модулей вообще фигня уровня bash. Python -
>угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
>
>
>Rexx в списке нет.Perl и Python ты осилить не смог -> Ruby можешь не смотреть.
>[оверквотинг удален]
>>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
>>? В этом списке таких нет. JS примитивен и нет своих
>>библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для
>>небольших скриптов и без модулей вообще фигня уровня bash. Python -
>>угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
>>
>>
>>Rexx в списке нет.
>
>Perl и Python ты осилить не смог -> Ruby можешь не смотреть.PERL - мазохизм не для здоровых людей - язык для обработки текстов, созвездие кракозябр.
Python - попсовая игрушка, гадящая сама под себя. Для быстрых набросков, которые потом нужно переписывать на чем то другом, чтоб не страшно было.Ruby посмотрю, но кажысь такое же детское безпринципное.
Не освоив правило "жи-ши" глупо пытаться доказать свои знания "как правильно создавать языки программирования".
>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и RubyЧем PHP не удобен? Классы, виртуальные методы и свойства, отличные фреймворки (в частности Zend), поддержка разных баз данных и еще много разных вкусностей.
>PHP - для "быстробучаемых веб-кодеров"
Быстрое обучение это не минус. На PHP МОЖНО писать качественный код. Не качественный код можно писать на ЛЮБОМ языке, включая C, C++, Java и Rexx - всё зависит от того кто пишит.
>[оверквотинг удален]
>
>Чем PHP не удобен? Классы, виртуальные методы и свойства, отличные фреймворки (в
>частности Zend), поддержка разных баз данных и еще много разных вкусностей.
>
>
>>PHP - для "быстробучаемых веб-кодеров"
>
>Быстрое обучение это не минус. На PHP МОЖНО писать качественный код. Не
>качественный код можно писать на ЛЮБОМ языке, включая C, C++, Java
>и Rexx - всё зависит от того кто пишит.Можно и руками копать, но лучше лопатой. Просто средства разработки могут и должны способствовать писать легко и качественно. Это закладывается в язык разработчиками через концепцию и идеологию. Если в голове разработчиков языка бардак, то и писать на таком будет можно либо бардак, либо с большим напряжением для компенсации.
>Можно и руками копать, но лучше лопатой. Просто средства разработки могут и
>должны способствовать писать легко и качественно. Это закладывается в язык разработчиками
>через концепцию и идеологию.Попробуйте Zend Framework. По Вашей аналогии - это экскаватор :-) Результат - чистый и понятный код, разделение данных и логики и т.д. Надо IDE - попробуйте Zend Studio.
>Если в голове разработчиков языка бардак, то
>и писать на таком будет можно либо бардак, либо с большим
>напряжением для компенсации.Это применимо к любым языкам.
Ну многие при приёме на работу не пишут, что требуется php, а пишут asp или .net. Это для того, чтобы отсечь многих ламеров, начитавшихся "php для чайников". Хотя на самом деле, когда мне потребовалось написать код для сайта на js+php, подобные книжки меня не сильно порадовали. Слишком много тонкостей у этих языков, на деле всё оказалось сложнее чем в си. JS вообще беспредел, не понимаю, почему он получил такое распространение.
Столько шума и ни одного аргумента! Ни одной ссылки!
Пора прекратить это :-) Вот дл яразгона:
Python vs Perl (с точки зрения программиста)
http://michurin.com.ru/python-vs-perl.shtml
Python vs Perl (с исторической точки зрения)
http://michurin.com.ru/python-vs-perl-2.shtml
PHP vs Perl
http://michurin.com.ru/php-vs-perl.shtml
статья "PHP vs Perl" просто лажа. "Аффтар" противоречит сам себе в ней.
Он пишет, что в php много модулей и это плохо, а вот то, что в perl можно подключить модуль и получить нужный функционал - это уже хорошо!
Переносимость, как ее описывает автор, вообще сомнительное преимущество перла. Вот фактическая несовместимость PHP5 и PHP4 - это похуже будет.
Так же автор говорит, что большое количество функций - это беда... уменьшает читабельность кода видети ли... Ну, во-первых, менее читабельного кода чем на перле я не видел (эзотерические языки не в счет). А, во-вторых, жизнь показывает, что лучше разобраться с готовыми функциями, чем писать свои. (из-за чего популярен стал мелкософтовский .net? потому что большая библиотека)
Автор указывает perl-скороговорку как плюс перла, но плюс сомнительный. Иногда лучше удленить код в пользу читабельности.
Дальше идут вполне обоснованные упреки в сторону пробелов в безопасности (вывод на страницу ошибок и т.п.), смещения HTML и кода... Но все эти упреки скорее к стилю программирования нежели к языку, в зрелом проекте данных ошибок не будет.
Автор говорит, что неясно как передаются аргументы: по значению или по ссылке - вот это действительно минус, но минус, который еще надо умудриться встретить, но и он обходится использованием правильно документированных функций.
>статья "PHP vs Perl" просто лажа. "Аффтар" противоречит сам себе в ней.
>
>Он пишет, что в php много модулей и это плохо, а вот
>то, что в perl можно подключить модуль и получить нужный функционал
>- это уже хорошо!он говорит, что в PHP много **функций** (а не модулей), и от этого имена функций оченьдлинные.
ну а вообще... вы зря упрекаете автора в любви к перлу :-) почитайте его заметки про питон, уж там-то он перл прописочивает :-) вам должно понравиться :-)))
>он говорит, что в PHP много **функций** (а не модулей), и от
>этого имена функций оченьдлинные.И про модули он тоже говорит, что из-за большого количества модулей надо искать хостера с нужным набором модулей.
>ну а вообще... вы зря упрекаете автора в любви к перлу :-)
>почитайте его заметки про питон, уж там-то он перл прописочивает :-)
>вам должно понравиться :-)))Да я про статью восновном, а не про автора. Ну может я черезчур эмоционален, просто в последнее время, достали неаргументированные перлисты.
И всё же я не понимаю. Вы про раздел "Количество функций"? Там говорится, что от хостера зависит не количество модулей, а количество функций.Вы, если не согласны и уверены в своей правоте, то напишите автору и поспорьте с ним ,-)
А статья аргументирвоанная, с примерами...
А главное вывод: все средства хороши к месту.
У Perl две проблемы:
1. Write-Only (не читабельный) код
2. Отсутствует нормальная поддержка объектовПлюсы:
1. Присутствует "из коробки" в любом Линуксе
2. Модули на все случаи жизниНастоящая дилемма - и плюсы и минусы очень весомы.
>У Perl две проблемы:
>1. Write-Only (не читабельный) кодэто проблема программистов, язык ДАЕТ возможность писать нечитабельно, но никто не мешает писать читабельно ;)
А зачем он ДАЁТ? ,-)Кроме того, Perl часто провоцирует нечитабельность:
- требование (пуcть и не жёсткое) распихивать каждый класс в отдельный файл
- поощрение использования regexp-ов там где нужно и там где не нужно
пример:
Perlовик напишет if ($a=~/text/)
Питонщик напишет if 'text' in a
Что понятней? Я молчу о производительности.
- можно продолжать... но суть в том, что Perl специально подталкивает писать непонятно.Кроме того, в Perl нет многих механизмов, повышающих понятность кода; на пример исключений
Логика программы становится менее понятна из-за "автооживления" переменных.
Не содействет понятности и нелогичность и незаконченность конструкций. На пример, есть if-elsif-else, есть unless, но нет unless-elsunless-else. Вместо этого есть unless-elsif-else. Легко ли понять код, в котором такое используется?
> Perlовик напишет if ($a=~/text/)
> Питонщик напишет if 'text' in a
> Что понятней?мне первый вариант гораздо понятней. Во втором варианте вообще непонятно что такое "а" - то ли массив, то ли объект. А о том, что это скалярная переменная думается в самую последнюю очередь.
а это и не обязательно скалярная переменна :-) в этом и есть преимущество ОО (именно _НОРМАЛЬНОго_) -- любой объект может поддерживать in (и не только in) и большинство встроеных объектов его поддерживают. Угадайте, что такое in для массива? для словаря? получается? не прада ли удобно, когда язык объектно-ориентированный? ,-)
>не прада ли удобно,
>когда язык объектно-ориентированный? ,-)Perl вполне ОО язык имеющий встроенный механизм инкапсуляции :)
стоит отличать pure языки от остальныхзы конечно удобно :)
>а это и не обязательно скалярная переменна :-) в этом и есть
>преимущество ОО (именно _НОРМАЛЬНОго_) -- любой объект может поддерживать in (и
>не только in) и большинство встроеных объектов его поддерживают. Угадайте, что
>такое in для массива? для словаря? получается? не прада ли удобно,
>когда язык объектно-ориентированный? ,-)ааа я понял НОРМАЛЬНОЕ ООП это когда поддерживается перегрузка операторов! Надо же
>>а это и не обязательно скалярная переменна :-) в этом и есть
>>преимущество ОО (именно _НОРМАЛЬНОго_) -- любой объект может поддерживать in (и
>>не только in) и большинство встроеных объектов его поддерживают. Угадайте, что
>>такое in для массива? для словаря? получается? не прада ли удобно,
>>когда язык объектно-ориентированный? ,-)
>
>ааа я понял НОРМАЛЬНОЕ ООП это когда поддерживается перегрузка операторов! Надо же
>и это тоже :)
но если конструктор может вернуть не объект, то, извините, никак не ООП. возможно, это что-то очень хорошее, но всё же не ООП точно.
>> Perlовик напишет if ($a=~/text/)
>> Питонщик напишет if 'text' in a
>> Что понятней?
>
>мне первый вариант гораздо понятней. Во втором варианте вообще непонятно что такое
>"а" - то ли массив, то ли объект. А о том,
>что это скалярная переменная думается в самую последнюю очередь.да, без перлового контекста if ($a=~/text/) и познаний в области питонокодерства трудно сказать что такое "а"
стоит различать условия <code>if $a eq 'text'</code> и <code>if $a =~ /text/</code>
язык Кенни (мультперсонаж из южного парка) не навязывает нам регэкспы. регэкспы используются строго по назначению
>[оверквотинг удален]
>>мне первый вариант гораздо понятней. Во втором варианте вообще непонятно что такое
>>"а" - то ли массив, то ли объект. А о том,
>>что это скалярная переменная думается в самую последнюю очередь.
>
>да, без перлового контекста if ($a=~/text/) и познаний в области питонокодерства трудно
>сказать что такое "а"
>
>стоит различать условия <code>if $a eq 'text'</code> и <code>if $a =~ /text/</code>
>язык Кенни (мультперсонаж из южного парка) не навязывает нам регэкспы. регэкспы используются
>строго по назначениювы кажется не поняли...
if 'text' in a
работает как
if ($a=~/text/)
а не как
if $a eq 'text' # рекомендую всегда ставить скобки
только ищется не совпадение регэкспа, а вхождение подстроки, что на много эффективнее.а что такое "а" трудно понять только людям, чей мозг съел Перл :-) ну или bash :-)))
ну лично я бы использовал index(STR, SUBSTR) :) а не регексп. использовать регекспы для поиска фиксированной строки, а не шаблона - глупо.
>А зачем он ДАЁТ? ,-)
>
>Кроме того, Perl часто провоцирует нечитабельность:
>- требование (пуcть и не жёсткое) распихивать каждый класс в отдельный файл
>
>- поощрение использования regexp-ов там где нужно и там где не нужно
>
> пример:
> Perlовик напишет if ($a=~/text/)
> Питонщик напишет if 'text' in aпервый вариант более понятен
> Что понятней? Я молчу о производительности.
используй index или substr
>- можно продолжать... но суть в том, что Perl специально подталкивает писать
>непонятно.
>
>Кроме того, в Perl нет многих механизмов, повышающих понятность кода; на пример
>исключенийuse Error qw(:try);
и будут тебе исключения>Логика программы становится менее понятна из-за "автооживления" переменных.
use strict;
>Не содействет понятности и нелогичность и незаконченность конструкций. На пример, есть if-elsif-else,
>есть unless, но нет unless-elsunless-else. Вместо этого есть unless-elsif-else. Легко ли
>понять код, в котором такое используется?не используй unless в таком контексте
еще есть вопросы???
>>Кроме того, в Perl нет многих механизмов, повышающих понятность кода; на пример
>>исключений
>
>use Error qw(:try);
>и будут тебе исключениявы в этот модуль заглядывали?
eval и die -- это не есть исключения!>
>>Логика программы становится менее понятна из-за "автооживления" переменных.
>
>use strict;вы, я смотрю, просто не в теме немного
#!/usr/bin/perl -w
use strict; # возможно это вернул конструктор :-)))
my $a=undef;
$a->{'key'}='val';ну и что теперь в $a?
ни -w ни strict не поможет вам отловить это превращение>>Не содействет понятности и нелогичность и незаконченность конструкций. На пример, есть if-elsif-else,
>>есть unless, но нет unless-elsunless-else. Вместо этого есть unless-elsif-else. Легко ли
>>понять код, в котором такое используется?
>
>не используй unless в таком контекстеэто вы не мне скажите, на напишите в perldoc :-)
а вопрос-то остался: нафига так делать язык?>еще есть вопросы???
все те же :-)
>2. Отсутствует нормальная поддержка объектовскромный боянчик:
"поддерживаются классы и объекты, одиночное и множественное наследование, методы экземпляров и методы классов, переопределение методов, конструкторы и деструкторы, перегрузка операторов, методы-посредники с автозагрузкой, делегирование, иерархия объектов и два уровня сборки мусора"по поводу читабельности кода уже говорили. в хороших проектах perlstyle разработчиков похож и читать легко. в данный момент поддерживаю крупные (десятки тысяч строк) ООП системы реализованные на Perl и вполне ими доволен
>>2. Отсутствует нормальная поддержка объектов
>
>скромный боянчик:
>"поддерживаются классы и объекты, одиночное и множественное наследование, методы экземпляров и методы
>классов, переопределение методов, конструкторы и деструкторы, перегрузка операторов, методы-посредники с автозагрузкой,
>делегирование, иерархия объектов и два уровня сборки мусора"А никто и не говорил что объекты не поддерживаются. Они просто _НОРМАЛЬНО_ не поддерживаются (например как в C++, C#, Java или PHP).
>А никто и не говорил что объекты не поддерживаются. Они просто _НОРМАЛЬНО_
>не поддерживаются (например как в C++, C#, Java или PHP).есть опыт работы с Java.
можете вербализовать _НОРМАЛЬНО_?
очень интересно. пожалуйта.
>>А никто и не говорил что объекты не поддерживаются. Они просто _НОРМАЛЬНО_
>>не поддерживаются (например как в C++, C#, Java или PHP).
>
>есть опыт работы с Java.
>можете вербализовать _НОРМАЛЬНО_?думаю вряд-ли. это типичная критика на основании "ОБС". реальные недостатки перлового ООП - Анонимусам вряд-ли знакомы :) ну и славно - меньше знаешь, крепче спишь ;)
Да наврятли он то обьяснить сможет что такое _НОРМАЛЬНО_. Как по мне единственный недостаток перла это не типизированные параметры функций - а всё остальное типа НОРМАЛЬНОГО ООП и непонятного кода - сказки для бедных(на ПХП в перемешку с HTML можно писать такое что чёрт ногу сломит)