| 1.1, Аноним (1), 17:30, 23/06/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Надеюсь, о дырявости реализаций скриптовых языков на различных платформах там также честно рассказывается? xD
| | |
| |
| 2.2, PavelR (??), 18:00, 23/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Надеюсь, о дырявости реализаций скриптовых языков на различных платформах там также честно
>рассказывается? xD
Нет нет, что Вы, не рассказано. Расскажите, интересно послушать.
| | |
| |
| 3.3, Алекс (??), 19:00, 23/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
ИМХО, популяризация "удобных" ЯВУ сделает сишников такой же сектой как сейчас ассемблерщики...
| | |
| |
| 4.4, pavlinux (ok), 19:11, 23/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Пока железяки проектируют люди, будут нужны люди которые будут заставлять их работать как надо.
| | |
| |
| 5.18, Кирилл (??), 11:31, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Пока железяки проектируют люди, будут нужны люди которые будут заставлять их работать
>как надо.
Это как же? Как надо? ))))
Си сейчас постепенно занимает подабающее ему место в системном программировании. А уж ошибки быдлокодеров на нём куда фатальнее для безопасности, чем на более свежих языках. Ну ведь так это.
| | |
| |
| 6.31, User294 (ok), 16:15, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>ошибки быдлокодеров на нём куда фатальнее для безопасности, чем на более
>свежих языках. Ну ведь так это.
Ну да, в итоге быдлокодеры наляпают на "безопасном" языке скажем биллинг.Ну, конечно код на нем не выполнишь напрямую.Зато транзакции могут быть реализованы абы как, логика работы может быть brain damaged и в итоге юзеры которых это должно биллинговать могут скажем шутя и совершенно легитимными и штатными действиями прокинуть обладателя этого гуано на такую сумму баблосов что лучше бы пожалуй там выполнили код.Это достаточно заметно хотя-бы и легко ловится.А вот логические ошибки и проблемы секурити обычно замечают только когда вас уже смачно натянули на много денег.
| | |
|
|
| 4.5, Аноним (-), 19:42, 23/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>ИМХО, популяризация "удобных" ЯВУ сделает сишников такой же сектой как сейчас ассемблерщики...
>
Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby ? В этом списке таких нет. JS примитивен и нет своих библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для небольших скриптов и без модулей вообще фигня уровня bash. Python - угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
Rexx в списке нет.
| | |
| |
| 5.6, kroz (?), 21:50, 23/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >[оверквотинг удален]
>>
>
>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
>? В этом списке таких нет. JS примитивен и нет своих
>библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для
>небольших скриптов и без модулей вообще фигня уровня bash. Python -
>угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
>
>
>Rexx в списке нет.
+100
| | |
| 5.7, Anatolik (?), 22:54, 23/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >[оверквотинг удален]
>>
>
>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
>? В этом списке таких нет. JS примитивен и нет своих
>библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для
>небольших скриптов и без модулей вообще фигня уровня bash. Python -
>угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
>
>
>Rexx в списке нет.
Perl и Python ты осилить не смог -> Ruby можешь не смотреть.
| | |
| |
| 6.9, Anonymous (?), 02:18, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
>>? В этом списке таких нет. JS примитивен и нет своих
>>библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для
>>небольших скриптов и без модулей вообще фигня уровня bash. Python -
>>угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
>>
>>
>>Rexx в списке нет.
>
>Perl и Python ты осилить не смог -> Ruby можешь не смотреть.
PERL - мазохизм не для здоровых людей - язык для обработки текстов, созвездие кракозябр.
Python - попсовая игрушка, гадящая сама под себя. Для быстрых набросков, которые потом нужно переписывать на чем то другом, чтоб не страшно было.
Ruby посмотрю, но кажысь такое же детское безпринципное.
| | |
| |
| 7.17, prapor (??), 11:27, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
Не освоив правило "жи-ши" глупо пытаться доказать свои знания "как правильно создавать языки программирования".
| | |
|
|
| 5.8, lad (?), 23:32, 23/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
Чем PHP не удобен? Классы, виртуальные методы и свойства, отличные фреймворки (в частности Zend), поддержка разных баз данных и еще много разных вкусностей.
>PHP - для "быстробучаемых веб-кодеров"
Быстрое обучение это не минус. На PHP МОЖНО писать качественный код. Не качественный код можно писать на ЛЮБОМ языке, включая C, C++, Java и Rexx - всё зависит от того кто пишит.
| | |
| |
| 6.10, Anonymous (?), 02:22, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>
>Чем PHP не удобен? Классы, виртуальные методы и свойства, отличные фреймворки (в
>частности Zend), поддержка разных баз данных и еще много разных вкусностей.
>
>
>>PHP - для "быстробучаемых веб-кодеров"
>
>Быстрое обучение это не минус. На PHP МОЖНО писать качественный код. Не
>качественный код можно писать на ЛЮБОМ языке, включая C, C++, Java
>и Rexx - всё зависит от того кто пишит.
Можно и руками копать, но лучше лопатой. Просто средства разработки могут и должны способствовать писать легко и качественно. Это закладывается в язык разработчиками через концепцию и идеологию. Если в голове разработчиков языка бардак, то и писать на таком будет можно либо бардак, либо с большим напряжением для компенсации.
| | |
| |
| 7.14, lad (?), 10:07, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Можно и руками копать, но лучше лопатой. Просто средства разработки могут и
>должны способствовать писать легко и качественно. Это закладывается в язык разработчиками
>через концепцию и идеологию.
Попробуйте Zend Framework. По Вашей аналогии - это экскаватор :-) Результат - чистый и понятный код, разделение данных и логики и т.д. Надо IDE - попробуйте Zend Studio.
>Если в голове разработчиков языка бардак, то
>и писать на таком будет можно либо бардак, либо с большим
>напряжением для компенсации.
Это применимо к любым языкам.
| | |
|
| 6.11, Аноним (1), 02:41, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
Ну многие при приёме на работу не пишут, что требуется php, а пишут asp или .net. Это для того, чтобы отсечь многих ламеров, начитавшихся "php для чайников". Хотя на самом деле, когда мне потребовалось написать код для сайта на js+php, подобные книжки меня не сильно порадовали. Слишком много тонкостей у этих языков, на деле всё оказалось сложнее чем в си. JS вообще беспредел, не понимаю, почему он получил такое распространение.
| | |
|
|
|
|
|
| |
| 2.13, SKeeper (?), 09:52, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
 статья "PHP vs Perl" просто лажа. "Аффтар" противоречит сам себе в ней.
Он пишет, что в php много модулей и это плохо, а вот то, что в perl можно подключить модуль и получить нужный функционал - это уже хорошо!
Переносимость, как ее описывает автор, вообще сомнительное преимущество перла. Вот фактическая несовместимость PHP5 и PHP4 - это похуже будет.
Так же автор говорит, что большое количество функций - это беда... уменьшает читабельность кода видети ли... Ну, во-первых, менее читабельного кода чем на перле я не видел (эзотерические языки не в счет). А, во-вторых, жизнь показывает, что лучше разобраться с готовыми функциями, чем писать свои. (из-за чего популярен стал мелкософтовский .net? потому что большая библиотека)
Автор указывает perl-скороговорку как плюс перла, но плюс сомнительный. Иногда лучше удленить код в пользу читабельности.
Дальше идут вполне обоснованные упреки в сторону пробелов в безопасности (вывод на страницу ошибок и т.п.), смещения HTML и кода... Но все эти упреки скорее к стилю программирования нежели к языку, в зрелом проекте данных ошибок не будет.
Автор говорит, что неясно как передаются аргументы: по значению или по ссылке - вот это действительно минус, но минус, который еще надо умудриться встретить, но и он обходится использованием правильно документированных функций.
| | |
| |
| 3.15, Zoo (??), 10:07, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>статья "PHP vs Perl" просто лажа. "Аффтар" противоречит сам себе в ней.
>
>Он пишет, что в php много модулей и это плохо, а вот
>то, что в perl можно подключить модуль и получить нужный функционал
>- это уже хорошо!
он говорит, что в PHP много **функций** (а не модулей), и от этого имена функций оченьдлинные.
ну а вообще... вы зря упрекаете автора в любви к перлу :-) почитайте его заметки про питон, уж там-то он перл прописочивает :-) вам должно понравиться :-)))
| | |
| |
| 4.19, SKeeper (?), 11:33, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>он говорит, что в PHP много **функций** (а не модулей), и от
>этого имена функций оченьдлинные.
И про модули он тоже говорит, что из-за большого количества модулей надо искать хостера с нужным набором модулей.
>ну а вообще... вы зря упрекаете автора в любви к перлу :-)
>почитайте его заметки про питон, уж там-то он перл прописочивает :-)
>вам должно понравиться :-)))
Да я про статью восновном, а не про автора. Ну может я черезчур эмоционален, просто в последнее время, достали неаргументированные перлисты.
| | |
| |
| 5.20, Zoo (??), 11:56, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
И всё же я не понимаю. Вы про раздел "Количество функций"? Там говорится, что от хостера зависит не количество модулей, а количество функций.
Вы, если не согласны и уверены в своей правоте, то напишите автору и поспорьте с ним ,-)
А статья аргументирвоанная, с примерами...
А главное вывод: все средства хороши к месту.
| | |
|
|
|
|
| 1.16, lad (?), 10:36, 24/06/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
У Perl две проблемы:
1. Write-Only (не читабельный) код
2. Отсутствует нормальная поддержка объектов
Плюсы:
1. Присутствует "из коробки" в любом Линуксе
2. Модули на все случаи жизни
Настоящая дилемма - и плюсы и минусы очень весомы.
| | |
| |
| 2.21, squirL (ok), 12:19, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>У Perl две проблемы:
>1. Write-Only (не читабельный) код
это проблема программистов, язык ДАЕТ возможность писать нечитабельно, но никто не мешает писать читабельно ;)
| | |
| |
| 3.22, Zoo (??), 12:32, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
А зачем он ДАЁТ? ,-)
Кроме того, Perl часто провоцирует нечитабельность:
- требование (пуcть и не жёсткое) распихивать каждый класс в отдельный файл
- поощрение использования regexp-ов там где нужно и там где не нужно
пример:
Perlовик напишет if ($a=~/text/)
Питонщик напишет if 'text' in a
Что понятней? Я молчу о производительности.
- можно продолжать... но суть в том, что Perl специально подталкивает писать непонятно.
Кроме того, в Perl нет многих механизмов, повышающих понятность кода; на пример исключений
Логика программы становится менее понятна из-за "автооживления" переменных.
Не содействет понятности и нелогичность и незаконченность конструкций. На пример, есть if-elsif-else, есть unless, но нет unless-elsunless-else. Вместо этого есть unless-elsif-else. Легко ли понять код, в котором такое используется?
| | |
| |
| 4.24, Sarge (??), 13:29, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
> Perlовик напишет if ($a=~/text/)
> Питонщик напишет if 'text' in a
> Что понятней?
мне первый вариант гораздо понятней. Во втором варианте вообще непонятно что такое "а" - то ли массив, то ли объект. А о том, что это скалярная переменная думается в самую последнюю очередь.
| | |
| |
| 5.27, Zoo (??), 15:22, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
а это и не обязательно скалярная переменна :-) в этом и есть преимущество ОО (именно _НОРМАЛЬНОго_) -- любой объект может поддерживать in (и не только in) и большинство встроеных объектов его поддерживают. Угадайте, что такое in для массива? для словаря? получается? не прада ли удобно, когда язык объектно-ориентированный? ,-)
| | |
| |
| 6.29, JIP (??), 15:52, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >не прада ли удобно,
>когда язык объектно-ориентированный? ,-)
Perl вполне ОО язык имеющий встроенный механизм инкапсуляции :)
стоит отличать pure языки от остальных
зы конечно удобно :)
| | |
| 6.36, Аноним (1), 10:06, 25/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>а это и не обязательно скалярная переменна :-) в этом и есть
>преимущество ОО (именно _НОРМАЛЬНОго_) -- любой объект может поддерживать in (и
>не только in) и большинство встроеных объектов его поддерживают. Угадайте, что
>такое in для массива? для словаря? получается? не прада ли удобно,
>когда язык объектно-ориентированный? ,-)
ааа я понял НОРМАЛЬНОЕ ООП это когда поддерживается перегрузка операторов! Надо же
| | |
| |
| 7.37, Zoo (??), 12:06, 25/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>а это и не обязательно скалярная переменна :-) в этом и есть
>>преимущество ОО (именно _НОРМАЛЬНОго_) -- любой объект может поддерживать in (и
>>не только in) и большинство встроеных объектов его поддерживают. Угадайте, что
>>такое in для массива? для словаря? получается? не прада ли удобно,
>>когда язык объектно-ориентированный? ,-)
>
>ааа я понял НОРМАЛЬНОЕ ООП это когда поддерживается перегрузка операторов! Надо же
>
и это тоже :)
но если конструктор может вернуть не объект, то, извините, никак не ООП. возможно, это что-то очень хорошее, но всё же не ООП точно.
| | |
|
|
| 5.28, JIP (??), 15:42, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>> Perlовик напишет if ($a=~/text/)
>> Питонщик напишет if 'text' in a
>> Что понятней?
>
>мне первый вариант гораздо понятней. Во втором варианте вообще непонятно что такое
>"а" - то ли массив, то ли объект. А о том,
>что это скалярная переменная думается в самую последнюю очередь.
да, без перлового контекста if ($a=~/text/) и познаний в области питонокодерства трудно сказать что такое "а"
стоит различать условия <code>if $a eq 'text'</code> и <code>if $a =~ /text/</code>
язык Кенни (мультперсонаж из южного парка) не навязывает нам регэкспы. регэкспы используются строго по назначению
| | |
| |
| 6.30, Zoo (??), 16:08, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>мне первый вариант гораздо понятней. Во втором варианте вообще непонятно что такое
>>"а" - то ли массив, то ли объект. А о том,
>>что это скалярная переменная думается в самую последнюю очередь.
>
>да, без перлового контекста 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 :-)))
| | |
| |
| 7.32, squirL (??), 23:51, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
ну лично я бы использовал index(STR, SUBSTR) :) а не регексп. использовать регекспы для поиска фиксированной строки, а не шаблона - глупо.
| | |
|
|
|
| 4.35, Аноним (1), 09:46, 25/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>А зачем он ДАЁТ? ,-)
>
>Кроме того, 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 в таком контексте
еще есть вопросы???
| | |
| |
| 5.38, Zoo (??), 12:16, 25/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>Кроме того, в 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.23, JIP (??), 12:38, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>2. Отсутствует нормальная поддержка объектов
скромный боянчик:
"поддерживаются классы и объекты, одиночное и множественное наследование, методы экземпляров и методы классов, переопределение методов, конструкторы и деструкторы, перегрузка операторов, методы-посредники с автозагрузкой, делегирование, иерархия объектов и два уровня сборки мусора"
по поводу читабельности кода уже говорили. в хороших проектах perlstyle разработчиков похож и читать легко. в данный момент поддерживаю крупные (десятки тысяч строк) ООП системы реализованные на Perl и вполне ими доволен
| | |
| |
| 3.25, lad (?), 14:43, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>2. Отсутствует нормальная поддержка объектов
>
>скромный боянчик:
>"поддерживаются классы и объекты, одиночное и множественное наследование, методы экземпляров и методы
>классов, переопределение методов, конструкторы и деструкторы, перегрузка операторов, методы-посредники с автозагрузкой,
>делегирование, иерархия объектов и два уровня сборки мусора"
А никто и не говорил что объекты не поддерживаются. Они просто _НОРМАЛЬНО_ не поддерживаются (например как в C++, C#, Java или PHP).
| | |
| |
| 4.26, JIP (??), 14:49, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>А никто и не говорил что объекты не поддерживаются. Они просто _НОРМАЛЬНО_
>не поддерживаются (например как в C++, C#, Java или PHP).
есть опыт работы с Java.
можете вербализовать _НОРМАЛЬНО_?
очень интересно. пожалуйта.
| | |
| |
| 5.33, squirL (??), 23:53, 24/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>А никто и не говорил что объекты не поддерживаются. Они просто _НОРМАЛЬНО_
>>не поддерживаются (например как в C++, C#, Java или PHP).
>
>есть опыт работы с Java.
>можете вербализовать _НОРМАЛЬНО_?
думаю вряд-ли. это типичная критика на основании "ОБС". реальные недостатки перлового ООП - Анонимусам вряд-ли знакомы :) ну и славно - меньше знаешь, крепче спишь ;)
| | |
| 5.34, Аноним (1), 09:41, 25/06/2008 [^] [^^] [^^^] [ответить]
| +/– |
Да наврятли он то обьяснить сможет что такое _НОРМАЛЬНО_. Как по мне единственный недостаток перла это не типизированные параметры функций - а всё остальное типа НОРМАЛЬНОГО ООП и непонятного кода - сказки для бедных(на ПХП в перемешку с HTML можно писать такое что чёрт ногу сломит)
| | |
|
|
|
|
|
