PHP vs. Perl

Твоя контора -- не весь мир.
У меня например есть по крайней мере один проект, который ложится на эрланг 100% -- но из-за отсутствия парка специалистов (не самому же мне писать) сделан на С и к реализации туева хуча нареканий.

Блин, ну задалбал уже =)

>$a[$b] = 1;
>Что такое $a - массив или ассоциативный массив?
>Какая скорость выборки по массиву и ассоциативному массиву?

Если я не ошибаюсь, то все массивы все ассоциативные, хотя хз (по скорости и т.д.) надо смотреть исходники.

> $CoolVarialbe = 1873;
{
// .... тут 300 строк кода
if ($a == 5) { $CoolVariable = 7824; }
// .... тут еще 200 строк кода
}
Чему равна $CoolVarialbe ?
Почему так можно написать?

Потому что можно, используй нормальную среду для написания а не блокнот.
$CoolVarialbe == 1873;
$CoolVariable == 7824;

ЗЫ
На $a = 5 вывалится нотис, что типа не объявлена.

ЗЗЫ
А почему я в C могу написать:

int main () {
   int CoolVariable = 1873;
   int a = 5;
   {
     // .... тут 300 строк кода
     if (a == 5) { CoolVariable = 7824; }
     // .... тут еще 200 строк кода
   }

   return 0;
}

и скомпилится.

>Если я не ошибаюсь, то все массивы все ассоциативные, хотя хз (по скорости и т.д.) надо смотреть исходники.

И вот после этого некоторые говорят о крутизне скорости PHP. То-то ПО фирмы Zend отлично продается.

>Потому что можно, используй нормальную среду для написания а не блокнот.

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

Ладно, хрен с ним, с кривым наследием типа register globals и safe mode. Без этого 80% кодеров помрет от перенапряжения мозга и дефейсов.

Но хотя бы *опционально* включить обязательность декларирования переменных в какой-либо версии -- это что, так сложно?

>А почему я в C могу написать:

Потому, что все написано правильно.

> Но хотя бы *опционально* включить обязательность декларирования переменных в какой-либо версии -- это что, так сложно?
А кому это нужно ??? Считайте, что ВСЕ переменные уже декларированы и забудьте об этом.
А если и это для вас будет сложно - включите себе подходящий уровень error_reporting.
Честно говоря, вообще не понимаю что именно декларировать ? Типов-то как таковых нет. Начальные данные задавать что ли ? Так по-моему каждый сам решает нужно ему это в конкретном случае или нет.

> Сам интерпретатор языка, значит, не в состоянии отследить неиспользуемую или используемую только единожды переменную.
А можно узнать зачем это нужно ? И еще узнать зачем писать такие программы, в которых это может понадобиться ???

> И вот после этого некоторые говорят о крутизне скорости PHP
По-моему где-где, а для web-приложений существующая скорость вполне подходит.

>> Но хотя бы *опционально* включить обязательность декларирования переменных
>> в какой-либо версии -- это что, так сложно? 

>А кому это нужно ??? Считайте, что ВСЕ переменные уже декларированы и забудьте об этом. 
>А если и это для вас будет сложно - включите себе подходящий уровень error_reporting. 

Еще раз:
Ситуация с 
$CoolVarialbe = 1873;
$a = 5;
{
// .... тут 300 строк кода
if ($a == 5) { $CoolVariable = 7824; }
// .... тут еще 200 строк кода
}

НЕ ЛОВИТСЯ НИКАКИМ УРОВНЕМ error_reporting.
В PHP нет никакой возможности отследить неиспользуемую или используемую только единожды переменную. 

>Честно говоря, вообще не понимаю что именно декларировать ? Типов-то как таковых нет. Начальные
>данные задавать что ли ? Так по-моему каждый сам решает нужно ему это в конкретном случае или нет. 

Декларировать НАЛИЧИЕ переменной в программе. Тот факт, что переменная имеет право на существование.
Тот факт, что переменная не должна появляться ниоткуда и исчезать в никуда.
Чтобы НЕЛЬЗЯ БЫЛО НАПИСАТЬ вот такую глупость.
<?
        error_reporting(E_ALL);
        for($i = 1; $i < 10; $i++)
        {
                $abcd = 1234 * $i;
        }

        echo $abcd;
?>
Чтобы НЕЛЬЗЯ было написать в одном месте $CoolVarialbe, а в другом - $CoolVariable.


>А можно узнать зачем это нужно ? И еще узнать зачем писать такие программы, в которых это может понадобиться ??? 

Затем, что есть такая вешь как человеческий фактор. Человеку свойственно ошибаться, в том числе
и при написании программ. И если реализация ЯП позволяет допускать *такие* ошибки и не имеет средств
к их обнаружению, это очень и очень плохо. 

А в крупных проектах - дисквалифицирующе плохо.

>По-моему где-где, а для web-приложений существующая скорость вполне подходит.

Ага. То-то везде понатыканы всяко-разные прокси-акселераторы, лоад-балансеры и оптимизаторы :))

> Тот факт, что переменная не должна появляться ниоткуда и исчезать в никуда.
Извините, но php на этом базируется. Поэтому странно требовать от него отсутствия того, на чем он базируется. Если вас, к примеру, не устраивает наличие артиклей в англ. языке, вы ж не будете кричать, что их оттуда нужно убрать, что этот язык неправильный ? Наверное вы просто не будете на нем говорить...

> Чтобы НЕЛЬЗЯ БЫЛО НАПИСАТЬ вот такую глупость.
И где вы в приведенном примере (с циклом и $abcd) видите глупость ?
К тому же, если это для вас глупость, то не находите ли странной (скорее неинтуитивно понятной), например, передачу параметров в perl-е:
sub some_func {
%n = shift;
}
%a = ("a"=>11, "b"=>22);
some_func(%a);
Чему будет равно %n ?

> Человеку свойственно ошибаться, в том числе и при написании программ.
Как вы думаете, на сколько больше будет ошибаться тот же человек, программируя на perl-е ? Взять хотя бы те же $, @, % перед названиями переменных. Иметь одновременно $a, @a - это нормально ? $a[1] = $a - это не глупость ?

> А в крупных проектах - дисквалифицирующе плохо.
Я думаю крупные проекты пишут не в "блокноте"...

> прокси-акселераторы, лоад-балансеры и оптимизаторы
Вы хотите сказать, что они используются именно для устранения тормозов php ? Почему ж тогда не переходят на другое, тот же perl, python, ... ? Или с ними получаются те же самые тормоза ?
На сколько мне известно, при больших нагрузках поможет только статика, а не смена ЯП. Вот как раз для автоматического получения этой статики и используются proxy.

> Чтобы НЕЛЬЗЯ БЫЛО НАПИСАТЬ вот такую глупость. 

>Извините, но php на этом базируется.

Это очень и очень плохо.

>И где вы в приведенном примере (с циклом и $abcd) видите глупость ? 
Я вижу глупость в том, что переменная пао какой-то непонятной причине вдруг попала
из одной логической области видимости в другую.

>К тому же, если это для вас глупость, то не находите ли странной
>(скорее неинтуитивно понятной), например, передачу параметров в perl-е: 

cat a.pl
use strict;
sub some_func
{
        %n = shift;
}
%a = ("a"=>11, "b"=>22);
some_func(%a);

print %n;

>Чему будет равно %n ? 

perl a.pl
Global symbol "%n" requires explicit package name at a.pl line 4.
Global symbol "%a" requires explicit package name at a.pl line 6.
Global symbol "%a" requires explicit package name at a.pl line 7.
Global symbol "%n" requires explicit package name at a.pl line 9.
Execution of a.pl aborted due to compilation errors.

cat b.pl
use strict;
sub some_func
{
        my %n = shift;
}
my %a = ("a"=>11, "b"=>22);
some_func(%a);
my %n;
print %n;

perl b.pl
[пусто]

>Иметь одновременно %a, $a, @a - это нормально ?

Нормально. Сразу видно, что это за переменная.

>$a[1] = $a - это не глупость ? 

Нет. Потому, что видно, что происходит.

>Почему ж тогда не переходят на другое, тот же perl,

Зачем переходить, если все отлично работает на fcgi + perl?
Тот же Рамблер, к примеру....

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

> perl b.pl
> [пусто]
Ну вот, передавали непустой hash, а получили [пусто]... И это интуитивно понятная передача параметров ? (P.S. Я знаю как передавать такие параметры в perl-е, объяснять не нужно) Зато в php аналогичный код был бы более интуитивным: массив передал - массив получил.

> Сразу видно, что это за переменная.
Почему ж тогда этот знак нужно менять на $ при доступе к элементам ? Пусть бы тогда и было: %a{"b"}, а не $a{"b"}.
Да и зачем между индексным массивом и хешем делать различие ? Ради мифической скорости ? Смешно :-)

> Нет. Потому, что видно, что происходит.
Ага, из примера с передачей параметров отлично видно, что происходит. Не говоря уже о всем известной "строчке на perl", делающей "rm -rf /", различных переменных типа $', $", ...
Мое личное мнение: нормальный язык не должен допускать существования подобных конструкций.

Конечно, теперь понятно, что:
> язык позволяет писать в отвратительном стиле и
> делать очевидные глупости идет только в пользу языку --
> можно, не включая головного мозга, генерировать поток сознания.
Типичный пример - "строчка на perl": можно, не включая мозг, писать что попало, авось получится программа. Да и как же использовать мозг, если он и так загружен разной ахинеей типа $|, @a, %a, @{$r->{"n"}}, ... ?
В случае ж php над этим бредом думать не нужно, потому как его попросту нет. Но если кто-то все таки любит создавать себе проблемы, то...

> Зачем переходить, если все отлично работает на fcgi + perl?
А перед этим что, все было на php и все тормозило ?

К тому же вы не там вставили print %n (в функции нужно было вставлять):
> sub some_func
> {
>         my %n = shift;
> }
> ...
> my %n;
> print %n;

И после этого кто-то говорит про области видимости ?
Это отлично показывает как оно "все отлично работает на fcgi + perl".
Вопросов больше не имею.

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

Поймите, ЛЮБОЙ ЯП должен вести себя ОЖИДАЕМО. Использование переменной в одном логическом блоке,
с доступом из другого - НЕОЖИДАННОЕ поведение.

>> perl b.pl 
>> [пусто] 

>Ну вот, передавали непустой hash, а получили [пусто]...

Еще раз *ВНИМАТЕЛЬНО* проанализируйте код. Но только вни-ма-тель-но.
Задумайтесь над тем, что такое "область видимости переменной".

>Почему ж тогда этот знак нужно менять на $ при доступе к элементам ? Пусть бы тогда и было: %a{"b"}, а не $a{"b"}. 
>Да и зачем между индексным массивом и хешем делать различие ? Ради мифической скорости ? Смешно :-) 

Потому, что к элементу массива доступ - это адрес начала массива + мномер элемента * sizeof(элемента).

А доступ к элементу хеша - это хеширование + доступ по смещению + сравнение значений + поиск элемента. Что медленно.
Короче, все это описано в Кнуте.

>Ага, из примера с передачей параметров отлично видно, что происходит.
>Не говоря уже о всем известной "строчке на perl", делающей "rm -
> rf /", различных переменных типа $', $", ... 
>Мое личное мнение: нормальный язык не должен допускать существования 
>подобных конструкций. 

Вы *можете* писать на Перле криво. Вы *не*обязаны* писать криво.

На ПХП же *есть* *потенциально* *неисправляемые* проблемы. Какие - я перечислил.

Вдобавок, и на ПХП *можно* написать подобный непонятный код, хотя бы ]
потому, что есть функция eval.

> Ну вот, передавали непустой hash, а получили [пусто]...

передавали непустой, просто ничего не возвращали, оттого и пусто. и это не имеет никакого отношения к

> И это интуитивно понятная передача параметров ?

! не интуитивно, но понятная. с первого прочтения ман-а по диагонали понял...

> Почему ж тогда этот знак нужно менять на $ при доступе к элементам ?

потому что $ -- это скаляр. элемент массива -- это скаляр. $a[1] -- скаляр, представляющий собой ссылку на 1-й элемент. @a[1] -- слайс (кусок масива), представляющий собой подмассив с одного элемента.

> Пусть бы тогда и было: %a{"b"}, а не $a{"b"}.

будет. специально для леменгов в 6-м перле так и зделали, правда потом оно боком вылезло, пришлось усложнять некоторые конструкции, но зделали... млять :(...

> Типичный пример - "строчка на perl": можно, не включая мозг, писать что попало, авось получится программа. Да и как же использовать мозг, если он и так загружен разной ахинеей типа $|, @a, %a, @{$r->{"n"}}, ... ?

элементарно ватсон, через годик-второй кодинга на перле все вышеописанные конструкции генерятся на уровне подсознания, моск занят исключительно реализацией идеи в коде :)

> В случае ж php над этим бредом думать не нужно, потому как его попросту нет.

реализацией идеи? жуть :)

> Да и зачем между индексным массивом и хешем делать различие ? Ради мифической скорости ? Смешно :-)

аффтар, жжошь :) спасибо, посмеялсо :)

Уважаемые, о чем вы спорите ? "Когда Расмус Лердорф (Rasmus Lerdorf) начал работать над тем, что впоследствии стало PHP, единственной целью, которая была у него в мыслях, выяснить, кто читает его резюме."

Товарищ просто прикалывался - он никогда и не думал, что кому-то на ЭТОМ придет в голову писать 8)

> передавали непустой, просто ничего не возвращали, оттого и пусто. и это не имеет никакого отношения к
Да я имел в виду "какое значение будет иметь %n внутри самой функции непосредственно сразу после присвоения" ! Неужели это так сложно было понять, раз ничего не возвращается ?
И весь прикол в том, что %n не будет равно %a, как могло ожидаться. А все почему ? Потому что правила в perl-е такие, и если это нормально, то не понимаю почему, "Использование переменной в одном логическом блоке, с доступом из другого - НЕОЖИДАННОЕ поведение". Понятие "логичского блока" в php просто немного другое, и это не вина php.

> через годик-второй
Вопрос: зачем тратить "годик-второй" на освоение мутного синтаксиса perl-а, если можно *сразу* писать на php ?

> потому что $ -- это скаляр
Да это понятно, просто тогда значек перед именем переменной нельзя использовать как определитель ее типа. А если так, то почему бы не обойтись одним, например, "$" ? Зачем зоопарк "значков" ?

> *потенциально* *неисправляемые* проблемы
"Не так страшен черт, как его малюют". Лично я никогда с таким серьезно не сталкивался. (Тыкать "my" перед каждой переменной куда больше надоедает).
К тому же вы сами говорите: "Вы *не*обязаны* писать криво.". Не пишите криво - и подобных проблем не возникнет.
А вот на счет "не писать криво" и perl-а однозначно сказать нельзя: сколько авторов - столько и стилей написания (я про то, что в perl-е одно и то же можно написать кучей способов). Задалбывает иногда.

> потому, что есть функция eval
На СТОЛЬКО непонятный с помощью eval не напишешь :-)

> аффтар, жжошь :) спасибо, посмеялсо :)
Смех без причины ? :-) Ну смейтесь тогда.

> аффтар, жжошь :) спасибо, посмеялсо :)

Смех без причины ? :-) Ну смейтесь тогда.

ваша тупость тому причина. вас уже послали кнута читать? так чо ж вы тут делаете, уважаемый?

А вы не п..., вы пальцем покажите. Потому как лично я тупость вижу совсем в другом.
Кнут == БОХ ? :-) Прямо как Патрик ?
Тогда я в свою очередь осмелюсь послать читать php.net и не показывать вашу (тех, кто не осилил php) тупость.

> > передавали непустой, просто ничего не возвращали, оттого и пусто. и это не имеет никакого отношения к

> Да я имел в виду "какое значение будет иметь %n внутри самой функции непосредственно сразу после присвоения" ! Неужели это так сложно было понять, раз ничего не возвращается ?

так, давай по-порядку.

sub some_func {
%n = shift;
}
%a = ("a"=>11, "b"=>22);
some_func(%a);

облом в следующем: %n после присваивания будет равен { "a"=>undef }. почему? учи матчасть.

далее. если нада "какое значение будет иметь %n внутри самой функции непосредственно сразу после присвоения", так какого йуха, print не стоит "непосредственно сразу после присвоения"? за границами области видимости это совсем другая переменная.

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

весь прикол в том, что он никем и не ожидался :) этого в принцыпе не могло быть.

> А все почему ? Потому что правила в perl-е такие, и если это нормально, то не понимаю почему, "Использование переменной в одном логическом блоке, с доступом из другого - НЕОЖИДАННОЕ поведение".

потому что это правило выработано годами. подавляющее большенство программистов осознают необходимость в дополнительном контроле со стороны транслятора.

на заре своей юности, перл тоже не имел ни типизации, ни областей видимости. он повзрослел, желаю и вам того же :)

> Понятие "логичского блока" в php просто немного другое, и это не вина php.

я бы сказал, "Понятие \"логичского блока\"" в пхп просто отсутствует :)

> > через годик-второй
> Вопрос: зачем тратить "годик-второй" на освоение мутного синтаксиса perl-а, если можно *сразу* писать на php ?

*сразу* на пхп пишут токо виндузятники, не знакомые с другими скриптовыми языками.

> > потому что $ -- это скаляр
> Да это понятно, просто тогда значек перед именем переменной нельзя использовать как определитель ее типа.

значек указывает на тип выражения прямо, и на тип переменной косвенно.

> А если так, то почему бы не обойтись одним, например, "$" ? Зачем зоопарк "значков" ?

не поверите, для понятности ;)

> > *потенциально* *неисправляемые* проблемы
> "Не так страшен черт, как его малюют". Лично я никогда с таким серьезно не сталкивался. (Тыкать "my" перед каждой переменной куда больше надоедает).

интересно посмотреть на ваш самый крупный проект на пхп :) ну так, чисто из интереса ;)

> К тому же вы сами говорите: "Вы *не*обязаны* писать криво.". Не пишите криво - и подобных проблем не возникнет.

дык. это о перле сказано было :) на пхп "не криво" не получается ;)

> А вот на счет "не писать криво" и perl-а однозначно сказать нельзя: сколько авторов - столько и стилей написания (я про то, что в perl-е одно и то же можно написать кучей способов). Задалбывает иногда.

мл%*ь, а вас не задалбывает иногда, проходя по улице, видеть здания в разных стилях? вот бы все по одному образцу строили... или видеть людей с разными лицами, по-разному одетых?

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

> Кнут == БОХ ? :-) Прямо как Патрик ?

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

> Тогда я в свою очередь осмелюсь послать читать php.net и не показывать вашу (тех, кто не осилил php) тупость.

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

> почему? учи матчасть.
Не волнуйтесь, матчасть я знаю. Там речь шла про интуитивно понятное/не_понятное поведение. Так вот лично я считаю поведение perl-а в этом примере интуитивно НЕ понятным. Передали параметр - получили кашу. А все потому что в perl-е такие правила. И меня возмущает не этот факт, а то, что некоторые, столкнувшись с аналогичным в php, почему-то считают это не правильным, ошибкой, вместо того, что "учить матчасть".

> весь прикол в том, что он никем и не ожидался :) этого в принцыпе не могло быть.
Точно так же и мне не понятно, что так удивило stellar-а в его php-примере с областью видимости.

> перл тоже не имел ни типизации, ни областей видимости
Так весь прикол в том, что в php они (области) есть, только не такие как в perl-е. Поэтому применение правил, действующих в perl-е, здесь не прокатывает. Следовательно нужно не кричать "а чего оно не так?", а идти читать документацию !

> не поверите, для понятности ;)
Спорное субъективное утверждение :-)

> я бы сказал, "Понятие \"логичского блока\"" в пхп просто отсутствует :)
Лично вашего понятия может и да. Или вы считаете, что логическим блоком может быть только то, что внутри фигурных скобок ?

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

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

> или видеть людей с разными лицами
Ключевое слово "видеть" ? Если б и на код я только смотрел - было бы все равно. А на счет зданий, лиц, одежды - спросите у соответствующих специалистов, думаю они вам много чего расскажут.
Тем более, вы пишете код для того, чтоб потом его кому-то показывать ? Его смысл в том, что его кто-либо видел ?

> что такое хэш и что такое массив. вот прочитали бы
Не нужно цепляться к словам, читайте в целом. Вот раз вы такой умный, начитанный объясните мне зачем в приложении под web различие между хешем и массивом ? Для достижения чего ? Почему иметь просто "ассоциативный массив" - это плохо ?

> я пхп осилил
А я лично вам по этому поводу ничего и не говорил.

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

>Не волнуйтесь, матчасть я знаю. Там речь шла про интуитивно понятное/не_понятное поведение. Так вот лично я считаю поведение perl-а в этом примере интуитивно НЕ понятным.

На самом деле вы тут не совсем правы. Потому что scope у пхп действительно , мягко говоря, нестандартны. Как раз более привычно ожидать, что область видимости ограничивается блоком в котором переменная определена. В С, яве, перл, руби ,насколько я помню,это именно так. Глобальные переменные это скорее исключение из правил - так что они или системные, вроде $` или это какая-то спец особенность и их надо специально обьявлять.

>> аффтар, жжошь :) спасибо, посмеялсо :) >Смех без причины ? :-) Ну смейтесь тогда.

И тут тоже приму сторону вашего оппонента. Боюсь показаться профаном, но если рассуждать логически, то обычный массив будет быстрее хеша по той причине, что поиск N-го элемента в обычном массиве это просто сдвиг на n байтов относительно начала - намного более быстрая операция по сравнению с поиском по ключам в ассоциативном массиве. Я не знаю как устроены конкретные реализации в обсуждаемых языках, но боюсь в пхп упростили понятие массива рассчитывая на то, что программировать на нем будут люди без С бекграунда. Потому что люди программировавшие на С понимают что массивы и хеши это принципиально разные вещи и незачем их смешивать.

> более привычно ожидать, что область видимости ограничивается блоком в котором переменная определена.
Возможно, так сказать одна из особенностей языка (понятие "блока" немного другое). Только я не понимаю в чем я там не совсем прав ? В том, что в php что-то не так, как в perl-е ? А особенности perl-а, приведенные мною выше, разве нельзя точно так же считать нестандартными ? А поэтому и неудобными (для меня), точно так же, как кому-то что-то неудобно в php ? Разве это говорит о том, что perl замечательный, а php ущербный ? Думаю нет.

> Глобальные переменные это скорее исключение из правил
А разве в perl-е переменные по умолчанию не являются глобальными ? (без использования всяких "use strict;") По-моему как раз их "локальность" и нужно объявлять. К примеру:
for($i = 1; $i < 10; $i++){
$abcd = 1234 * $i;
}
print "abcd=$abcd\n";

Результат:
abcd=11106

Кстати, perl-овый аналог $variaBLe и $variaLBe (для stellar-а):
как вы думаете, что будет, если сделать такую описку:
вместо for ($i=1; $i<=10; $i++){
написать for ($i=1; $<=10; $i++){
Чем сможете отловить подобную ситуацию ?
А php сразу выдаст ошибку...
И в чем же тут преимущество perl-а ?

> если рассуждать логически, то обычный массив будет быстрее хеша
Так я не спорю, что будет быстрее. Вопрос в том, будет ли этот выигрыш в скорости критичным именно для *WEB* приложения ? Если ваш скрипт при определенной нагрузке "тормозит" при работе с хешами, то сильно ли вы выиграете при переходе к массивам ? А если нагрузка чуть-чуть увеличится, что тогда ? Разве это метод ускорения программ ?
По-моему, если вопрос скорости становится критичным - ускорять нужно не массивами, а использовать совсем другой метод (в зависимости от условий).

Я бы рассказал про то чем отличаются между собой ЯП, про то как влияет выбор ЯП на методику решения задач и подход к программированию, но, увы, растерял всю злость в пейнтболе. Последня игра так ваще страшное мясо была. Мы играли вдвоем против пятерых. И, не смотря на то что у нас на двоих был всего один глючный маркер мокрый(был дождь) маркер почти без газа, 10 шаров и щит, мы порубили половину вржеской комманды(включая играещего судью), стыбрили флаг, донесли его до базы и даже удержали его там, причем с нашей стороны потерь не было. И это при том что с меня посттоянно сваливались штаны до колен и, чтобы я вообще мог ходить, мне их придерживал сзади идущий напарник. Более того, когда девушки растратили все боеприпасы я им отдал свой маркер с длинным стволом и нападал на врагов с одним щитом. Удалось даже забрать флаг, вернуть его опять на место(игрок со щитом не имеет права брать флаг), вернуться в укрытие, провести под щитом товарища и опять забрать флаг. Удалось даже здорового вражеского мужика загнать щитом в домик и удерживать его там пока шло подкрепление(одним щитом, без оружия!). Увы, наш боец забыл снять маркер с предохранителя :(. Получилось даже судью напугать. Жаль только что гранаты, автомат и дополнительная коробка шаров застряли в пробке и не приехали :(. Хотел рассказать то что знаю про erlang но надо кормить кота.

> Исходники там прилагаются (10-15 строк) вперед на мины.

Если вместо их кода со страницы http://linuxboxadmin.com/src/html-pl.txt
использовать вариант:

#!/usr/bin/perl

print <<'EOF';
Content-Type: text/html

<html>
<head>
<title>HTML test</title>
</head>
<body>
<h4>HTML test</h4>
<p>
EOF
for($i = 1; $i <=1024; $i++)
{
  print "$i<br>";
}
print <<'EOF';
<b>done</b>
</p>
</body>
</html>
EOF

то получается выйгрыш на порядок. Причём этот вариант больше
соответствует их скрипту на PHP, поскольку и здесь, и там начало
и конец страницы вставляются, а не генерируется. Тестировалось
правда не на веб-сервере, скрипт просто запускался из консоли
командой типа time ./test.pl > /dev/null. Вот лучший их результат:

real    0m0.055s
user    0m0.048s
sys     0m0.006s

А вот худший результат приведённого выше скрипта:

real    0m0.022s
user    0m0.002s
sys     0m0.002s

В среднем разница получилась в 13 раз. Не в их пользу :-)

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

Тестировалось на Debian GNU/Linux Sarge 3.1 (ядро 2.6.8),
perl 5.8.4.

> Да и зачем между индексным массивом и хешем делать различие ? Ради мифической скорости ? Смешно :-)

Даже если отбросить вопрос производительности, хеш не сохраня&#1108;т порядок елементов

>написать for ($i=1; $<=10; $i++){

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

>без использования всяких "use strict;")

НЕ НАДО ПИСАТЬ НА PERL БЕЗ прагмы use strict;

Никто, поймите, НИКТО ИЗ ВМЕНЯЕМЫХ программистов, не пишет на Perl без strict и warnings. Пользованию этим прагмам учат с первых страниц любого учебника по Perl.

Вы же, с упертостью осла, сравниваете Perl с PHP, ИГНОРИРУЯ при этом те возможности, которые ЕСТЬ в Perl и те, которых НЕТ и никогда не было в PHP.

Перечитайте весь топик заново.

Утверждалось, что отсутствие необходимости описывать переменные - это отвратительная особенность PHP.

Утверждалось, что отсутствие разницы между массивом и хешем - тоже отвратительно.

Утверждалось, что области видимости переменных, принятые в PHP, не только не логичны сами, но еще и опасны, так как позволяют писать небезопасный код.

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

Извините, но все ваши утверждения являются весьма спорными и 100% субъективными.

> отсутствие необходимости описывать переменные - это отвратительная особенность PHP.
Осознайте, что она просто неудобна лично для вас, не нужно говорить за всех. Лично мне более неудобно то, как есть perl-е.

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

> области видимости переменных, принятые в PHP, не только не логичны сами, но еще и опасны
Скорее не логичны с точки зрения логики perl-а. С точки зрения логики php perl тоже получается нелогичным. Естественно, что, принимая за аксиому какой-то частный случай, все остальное будет казаться неправильным. Но это ничего не доказывает, это всего лишь показывает ограниченность ваших взглядов.

При чем заметьте, я не пытался доказать, что perl ужасно неправильный, я всего лишь пытался показать вам, что для кого-то в perl-е тоже что-то может показаться неудобным, не интуитивно понятным, не логичным, точно так же, как вам в php. Поэтому просто признайте, что php неудобен ЛИЧНО ДЛЯ ВАС, но никак не для всех. И минусов в нем никак не больше, чем в perl.

> На мой взгляд, в PHP надо сделать следующие вещи
Меряем все одной меркой ? Вот вас не пугает, например, отсутствие в perl-е типов, как в C ? Ведь это тоже позволяет писать небезопасный код.
Не нужно это все в php, не нужно, это все атавизмы, и без этого все у всех работает. Почему-то только у вас с этим возникают проблемы (наверное в силу ограниченности на почве perl).

Мое мнение лучше бы ЯП имели настройки как обычные программы. Не нравится объявлять переменные? Поднастроил какой-нить .ini, .conf или .cfg и компилер\интерпертатор уже по-другому заработал. Не нравятся слишком смелые преобразования типов(типа присвоение unsigned-переменной значение signed, просто для примера привел)? Поправил настройки и все стало как тебе нравится. Правда излишняя свобода тоже пойдет во вред, но это тема другой дискуссии.

>Мое мнение лучше бы ЯП имели настройки как обычные программы. Не нравится объявлять переменные? Поднастроил какой-нить .ini, .conf или .cfg и компилер\интерпертатор уже по-другому заработал. Не нравятся слишком смелые преобразования типов(типа присвоение unsigned-переменной значение signed, просто для примера привел)? Поправил настройки и все стало как тебе нравится. Правда излишняя свобода тоже пойдет во вред, но это тема другой дискуссии.

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

> но возможность менять поведение стандартных типов уже чего стоит

А вот за такое надо в луже под автобусом убивать. Фантазер иптыть, слушай и врубайся. Стандартные типы - это СТАНДАРТНЫЕ типы. Не нравится - делай нестандартные типы. А хочется странной e#ли - пи$дуй на http://swingerclub.ru/, там такие нужны.

> Меряем все одной меркой ? Вот вас не пугает, например, отсутствие в perl-е типов, как в C ? Ведь это тоже позволяет писать небезопасный код.

Это очевидный недостаток Perl, здесь и спорить нечего. Но ведь точно такой же недостаток есть и у PHP (я не отношусь к его знатокам, но кажется очевидным, что раз переменная не описывается, значит PHP не может и контролировать её тип). Описание переменных - это хороший способ избежать ряда ошибок, непонятно как можно радоваться его отсутствию. Может посчитаешь ещё лучшим язык, для которого не предусмотрен отладчик?

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

if (b==1): a="1" else: a=1

if (a==1): print a=1

Он не преобразует строку "1" в число один, поэтому выражение "1"==1 всегда ложное. И это вызывает проблемы т.к. я ожидаю что "a" будет числом, но, если значение a передано через, скажем, POST или GET то оно будет считаться строкой. Даже если я объявлю что "a" это int питон вместо приведения строки в int преобразует переменную "a" из int в string даже глазом не моргнув. И хрен он где об этом напишет :(.

black_ondreyko, будь сдержаннее.

> Потому как следующий пример, например, на питоне сделает гадость

Гадость сделал твой учитель Питона, когда не рассказал тебе про явное приведение типов.

if (int(a) == 1): print "blablabla, мой юный друк"

>Гадость сделал твой учитель Питона, когда не рассказал тебе про явное приведение типов.

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

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

Ты невнимательно читал мой предыдущий пост. Свобода действий должна быть контролируемой. Или ты предлагаешь в каждом месте вставлять int(), str() итп? С одной стороны динамическая типизация это часто очень удобно, а с другой это и больше ошибок. Ошибок которых можно было бы легко избежать. Если уж следовать твоей логике то круче всего если бы все данные приводились к одному типу, например, string. Тогда даже динамической типизации не нужно, и так понятно что есть что.

Не ссы, лягуха. Всё будет. Читай первоисточники и много думай.

http://www.artima.com/weblogs/viewpost.jsp?thread=85551

http://www.artima.com/weblogs/viewpost.jsp?thread=86641

http://www.artima.com/weblogs/viewpost.jsp?thread=87182

Коменты тоже читай.

Бугога. Первая ссылка на текущую страницу.

А вот у меня под linux, даже в KDE таких глюков не бывает. Может быть дело в КривОС?

Ты тут привел очень хорошие ссылки которые очень хорошо подтверждают мои слова о том что фича востребована и то что в этом есть смысл. Притом от самого Гвидо. Так держать. "Optional static typing has long been requested as a Python feature."

Exe2, ты мой любимый клоун! Ты прочитал столько флейма в гвидовском блоге, и так них%я и не понял. Статическую типизацию к питону прикрутить сложно. Нет, АЦЦКИ СЛОЖНО. Из-за того, что питон задумывался как язык с динамической типизацией. И статическая типизация там уместна как на сраной корове седло.

Если ты мужик, пойди и сочини PEP с подробными предложениями и спецификациями. Сразу говорю, таких PEPов было уже три, и все они были отклонены. Знаешь, почему, дружок? Потому что те люди, которые уже вусмерть за$бали Гвидо своими просьбами, сами не знают, как должна выглядеть эта статическая типизация. В этих PEPах была полная х@йня пострашнее жабы. Короче, либо ты сейчас представляешь мне подробные спецификации того, что ты называешь "статической типизацией в Питоне", либо я всем буду говорить, что ты просто п#здливая балаболка.

Ты не все понял о чем я писал. Я предложил как один из выходов из ситуации не только вводить статические типы а ввести контроль над преобразованиями типов, разницу понимаешь? Пусть мне питон выдаст exeption и свалиться. Зато я это увижу и предприниму соотв. меры. Объясню на пальцах: это типа "floating point exception handling", только для типов. Сейчас нет статических типов потому что Гвидо не хочет идти на компромисы и принимать не совсем красивые решения либо решения которые могут что-то поломать или ведут к большим изменениям в питоне. Похвальное стремление.

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

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

>> но возможность менять поведение стандартных типов уже чего стоит >А вот за такое надо в луже под автобусом убивать. Фантазер иптыть, слушай и врубайся. Стандартные типы - это СТАНДАРТНЫЕ типы. Не нравится - делай нестандартные типы. А хочется странной e#ли - пи$дуй на http://swingerclub.ru/, там такие нужны.

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

> Это очевидный недостаток Perl, здесь и спорить нечего.
Ну так с этого и нужно было начинать: перечислить все, что вам требуется от языка и исходя из этого выбрать подходящий, а не лезть, как некоторые, "со своим уставом в чужой монастырь" (со своими требованиями в язык, при создании которого преследовались совершенно иные цели). В кратце: не хватает типизации, явного описания переменных и т.п. - пишите на C и нехрен лезть в php, perl, etc. Если же выбрали perl, php, python, радуйтесь тому, что есть.

анализ php в сравнении с perl: http://tnx.nl/php

неплохая статья ("please stop using perl 3") о том как нужно писать на perl появилась на www.perl.com: http://www.oreillynet.com/onlamp/blog/2006/08/please_stop_using_perl_3.html