LINUX.ORG.RU

PHP Sniffer


0

0

Если кто-то до сих пор сомневается в способностях языка PHP, то это не так. Недавно появился написаный полностью на PHP снифер с поддержкой протоколов IP, ICMP, UDP и TCP. Для его работы требуется PHP >= 4.3.0 с сокетами.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

В аргументах противников php меня больше всего забавляет один факт.
Перечисляют недостатки _одного_ языка (php) в сравнении с совокупностью
достоинств _нескольких_ языков (java, python, ruby, lisp, perl).
Создаётся впечатление, что на php вымещается злость за невозможность
объединить эти достоинства в один супер-пуппер мега правильный язык,
который сгодился бы на все случаи жизни и отвечал бы самым утонченным
потребностям строителей биореакторов ;)

anonymous
()
Ответ на: комментарий от anonymous

>В аргументах противников php меня больше всего забавляет один факт. Перечисляют недостатки _одного_ языка (php) в сравнении с совокупностью достоинств _нескольких_ языков (java, python, ruby, lisp, perl). Создаётся впечатление, что на php вымещается злость за невозможность объединить эти достоинства в один супер-пуппер мега правильный язык, который сгодился бы на все случаи жизни и отвечал бы самым утонченным потребностям строителей биореакторов ;)

Меня, лично меня, вполне устраивает Perl + XS + C / C++.

И лично я не вымещаю злость, мне просто непонятно, КАК МОЖНО писать _серьезные_ системы без контроля типов, контроля декларации переменных и к тому же не различая массивы и ассоциативные массивы.

stellar
()
Ответ на: комментарий от stellar

>$SomeCoolVariable = 10;

>$i = 0;

>while($i < 10)

>{

> // тут - куча строчек кода

> $SomeCoolVariab1e = $i * 10;

> // тут - вторая куча строчек кода

>$i++;

>}

>echo $SomeCoolVariable ;

глаза почини да!

$SomeCoolVariab_1_e != $SomeCoolVariable

DeViL
()
Ответ на: комментарий от stellar

>КАК МОЖНО писать _серьезные_ системы без контроля типов это вы батенька загнули.... is_bool, is_num и тд и тп. Удем на php.net и учим матчасть

DeViL
()
Ответ на: комментарий от DeViL

>глаза почини да!

>$SomeCoolVariab_1_e != $SomeCoolVariable

Уважаемый, вот к Вам приедет на доработку 300 килобайт кода с подобными ляпами. Вы задолбаетесь ПРОВЕРЯТЬ такой код руками.

Язык НЕ ДОЛЖЕН позволять использовать необъявленные переменные. Точка.

P.S. И теме не менее, еще два моих примера остались без комментаривев.

stellar
()
Ответ на: комментарий от DeViL

>КАК МОЖНО писать _серьезные_ системы без контроля типов это вы батенька загнули.... is_bool, is_num и тд и тп. Удем на php.net и учим матчасть

Проверять тип переменной надо не на рантайме, а в момент __сборки__ программы, неважно, в объектный код или в байткод.

Потому, что КАЖДЫЙ раз в КАЖДОЙ функции писать is_num / is_bool - это не метод абсолютно. Это костыль, появившийся отнюдь не от хорошей жизни. Причем костыль этот - кривой.

stellar
()
Ответ на: комментарий от stellar

> Проверять тип переменной надо не на рантайме, а в момент __сборки__ программы, неважно, в объектный код или в байткод.

Кто сказал?

> Потому, что КАЖДЫЙ раз в КАЖДОЙ функции писать is_num / is_bool - это не метод абсолютно. Это костыль, появившийся отнюдь не от хорошей жизни. Причем костыль этот - кривой.

Просто всем кривым программерам надо вынуть руки из /dev/ass и перестать плакаться что у них ничего не работает из-за фишек долбаного php.

gloomdemon
()
Ответ на: комментарий от stellar

>Проверять тип переменной надо не на рантайме, а в момент __сборки__ программы, неважно, в объектный код или в байткод.

какая сборка? о чем вы бредите? это ИНТЕРПРЕТИРУЕМЫЙ язык.

DeViL
()
Ответ на: комментарий от stellar

>Потому, что КАЖДЫЙ раз в КАЖДОЙ функции писать is_num / is_bool - это не метод абсолютно. Это костыль, появившийся отнюдь не от хорошей жизни. Причем костыль этот - кривой.

достаточно проверить входные данные в _ОДНОМ_ месте и все. зачем их постоянно перепроверять?

DeViL
()
Ответ на: комментарий от gloomdemon

>Кто сказал?

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

>Просто всем кривым программерам надо вынуть руки из /dev/ass и перестать плакаться что у них ничего не работает из-за фишек долбаного php.

Еще раз: поймите, ЯЗЫК ПЛОХ, если позволяет писать неправильно. Идеальный язык - тот, который не дает возможности сделать что-то заведомо неправильно. К счастью, такого языка нет.

Да, у всех без исключения ЯП есть свои проблемы, безусловно. Но только в PHP их больше. И они - заведомо критичнее.

Много кривизны исправлено: register_globals, например; но много детских болезней осталось. И пока они остались, пользоваться им для серьезных разработок нельзя.

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

stellar
()
Ответ на: комментарий от stellar

> Да, у всех без исключения ЯП есть свои проблемы, безусловно. Но только в PHP их больше. И они - заведомо критичнее.

Точно, и не факт что у php они заведомо критичнее.

> Не потому, что не получится написать проект, а потому, что проект буде дорого поддерживать и развивать.

С такими аргументами можно выкинуть ядро linux нах*****, только потому что C позволяет делать переполнения буфера и т.д.

gloomdemon
()
Ответ на: комментарий от DeViL

>достаточно проверить входные данные в _ОДНОМ_ месте и все. зачем их 
> постоянно перепроверять?

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

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

А запись
int SomeFunction(int counter, bool foobar)
{
.....

гораздо проще, а самое главное - безопаснее записи
SomeFunction(counter, foobar)
{
     if is_bool....

Потому, что заранее известно, что мы получаем на вход и что - на 
выходе.

А если такого контроля нет, то код потенциально НЕБЕЗОПАСЕН. Заранее.

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

Хороший пример - огромное количество SQL-injections, возникающих 
именно по причине отсутствия типимзации переменных.

stellar
()
Ответ на: комментарий от stellar

>Не потому, что не получится написать проект, а потому, что проект буде дорого поддерживать и развивать.

если этот проект пишет обезьяна то да. Но елси писать с использованием стандартов и тд и тп, то будет все нормально. Уже 5 лет так работаю и ниче.

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

повторю фразу , которая тут пробегала - хреново можно писать на _ЛЮБОМ_ языке.

DeViL
()
Ответ на: комментарий от gloomdemon

>Точно, и не факт что у php они заведомо критичнее.

Увы, для серьезных проектов - заведомо.

>С такими аргументами можно выкинуть ядро linux нах*****, только потому что C позволяет делать переполнения буфера и т.д.

С - не лучший язык. Но зато он - один из самх (если не самый) гибкий и быстрый.

И там, где нужна производлительность, зачастую можно пожертвовать потенциальной небезопасностью (при условии серьезного аудита кода).

А вот PHP и не особо производителен по сравнению с другими ЯП и не слишком безопасен.

stellar
()
Ответ на: комментарий от stellar

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

эм... давай в привате пообщаемся, имхо тут неудобно. devil at devil dot mk dot ua

DeViL
()
Ответ на: комментарий от DeViL

>повторю фразу , которая тут пробегала - хреново можно писать на _ЛЮБОМ_ языке.

Согласен.

Но писать хреново на PHP - проще, а элементов контроля - меньше, чем в других ЯП.

stellar
()
Ответ на: комментарий от stellar

ну... бывает всякое.

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

cgi на сях - ито имхо изврат.

что у нас остаеться? python - да хороший, но сильно задумчивый. ruby - немного специфичесский.

DeViL
()
Ответ на: комментарий от stellar

> Увы, для серьезных проектов - заведомо. У всех своя ниша, ни при этом из того что windows стоит на ~90% рабочих станций не следут что linux на рабочих станция полное г**.

> С - не лучший язык. Но зато он - один из самх (если не самый) гибкий и быстрый. > А вот PHP и не особо производителен по сравнению с другими ЯП и не слишком безопасен.

Если уж на то пошло, то писать на PHP под web проще чем на многих других языках. А по поводу производительность и бехопасности это ещё бабушка надвое сказала.

gloomdemon
()

Работал у нас чудо-программер, пока я его не пнул под зад... Он даже скрипты, которые кроном гоняются (под соляркой, кстати), умудрялся на пых-пых ваять. Пых-пых - это диагноз! Почему я так говорю? Да потому, что он, в принципе, ничего больше не знал и знать не хотел. С тех пор я сразу выбрасываю резюме, в которых пых-пых указан как основной инструмент, использовавшийся соискателем. Условный рефлекс :(

anonymous
()
Ответ на: комментарий от anonymous

> Условный рефлекс :(

А знаешь, чем плох условный рейлекс? Когда собаку Павлова перестали бить
током, и только включали свет, она по-прежнему реагировала, как если бы
её били током ;)

anonymous
()
Ответ на: комментарий от stellar

> КАК МОЖНО писать _серьезные_ системы

Очевидно, что на несерьёзные системы спрос не меньше, чем на серьёзные...

anonymous
()
Ответ на: комментарий от anonymous

> А знаешь, чем плох условный рейлекс?

Думаю, что знаю, чем плох условный реФлекс. Поэтому-то и поставил :( в конец фразы. Мне, действительно, хватило этого урока на всю оставшуюся жизнь. Может быть, это и лечится, но против природы - не попрешь.

anonymous
()
Ответ на: комментарий от DeViL

> python - да хороший, но сильно задумчивый.

Не напомните, давно ли в Python-е появились декларации переменных?

Whoo ★★
()
Ответ на: комментарий от DeViL

>cgi на сях - ито имхо изврат.

Пишется сишная библиотека и к ней - модуль Perl XS. И все отлично работает.

Если уж так сильно надо - можно написать и модуль для apache. Их, модулей этих, дофига.

stellar
()
Ответ на: комментарий от stellar

Я немного пописывал на PHP5, и очень рад, что знать не знал ужасов PHP4, и хотя при виде PHP5 я признаться иногда просто плакал от счастья (вспоминая перл), но отсутствие обязательного описания переменных - это все-таки совершенно ужастно. Удивительно, что в том же перле такая возможность есть, но в PHP5 - нет.

Надеюсь, хотя бы в PHP6 такая опция появится. Дрянные хостинги конечно и тогда продолжат использовать php4 c register globals, но лично мне к счастью до них дела сейчас нет...

anonymous
()
Ответ на: комментарий от anonymous

>> Можно и презаерватив на глобус натянуть.
>В данном конкретном случае натянули глобус на презерватив. :)
А что такое глобус? :-)

anonymous
()

Я кстати, как-то видел ассемблер написанный на BASH.
Придурков хватало во все времена.

NonHuman ★★★
()
Ответ на: комментарий от anonymous

>>> Можно и презаерватив на глобус натянуть.

>>В данном конкретном случае натянули глобус на презерватив. :)

>А что такое глобус? :-)

А что такое презерватив?

anonymous
()
Ответ на: комментарий от anonymous

>> 2. ну оооочень слабые замашки на ООП (это как технология)

>Неправда. Примеры в студию.

ну здрасте... начиная от чудной вещи $this (сам факт меня веселит, ибо $this->a и $a почему-то разные вещи) и заканчивая множественным наследованием. что еще? :)

>> 3. при наличии п.1 и п.2 -- страшно тормозит... >> заранее отвечу на вопрос "это где это он тормозит?": ищи на лоре, линки с тестами уже как-то давали.

>Есть правда, есть ложь, а есть ещё статистика. Ты попался на последнее.

ну почему же. там есть сырцы, можно дома попробовать :)

опровергнешь сравнение скорости пхп с питоном/явой/прочими?

Rastafarra ★★★★
()
Ответ на: комментарий от anonymous

> А когда Питон обучат выделать логические блоки фигурными скобками?

и как это влияет на скорость в контексте вопроса? :)))

Rastafarra ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.