Разработчики PHP объявляют о предстоящем окончании поддержки PHP 4.

Ruby заявит о несоответствии типов:
a = "anonymous"
b = 2;
# идет какой-то код
puts a + b
и получим
TypeError: can't convert Fixnum into String
        from (irb):19:in `+'
        from (irb):19
        from :0
поэтому обязаны сделать
puts a.to_i + b или .to_f для float

УРААА!!!!

Да здравствует ПЫХПЫХКАПЕЦ!!!

Наконец то хосты очистяца от этого убожества 8)

PS

PHP5 хоть немного но юзабельней ;)

> На C программист сам этого попросил.

Я привел пример нормального кода, где если ввести в atoi() строку, то
она даже не пикнет про ошибку, а возвратит ноль. И с тем как printf()
автоматом преобразовал float в int при чем некорректно и не остановив
программу тоже все видели. Вот так она выглядит, строгая типизация в С.

> Здесь никто не просил таких фокусов вытворять.

Здесь языку подсунули строку и потребовали ее умножить. Это заведомо
некорректные данные, которые программист должен был проверять на входе. И
поведение PHP здесь один в один как у C с atoi("anonymous")*2.

>$ perl -e 'use strict "refs"; use warnings FATAL => qw(all); print "anonymous" * 2, "\n";'
Argument "anonymous" isn't numeric in multiplication (*) at -e line 1.

Ну а с такими читами можно и в PHP сделать вот так:

$ cat a.php
#!/usr/bin/php

<? $a="anonymous";
$b=2;

if(is_numeric($a)) {
print 'anonymous'*2;
echo "\n";
}
else die ("Идити нафик с умножением строки на число\n");
?>

$ ./a.php

Идити нафик с умножением строки на число

> Я привел пример нормального кода, где если ввести в atoi() строку, то она даже не пикнет про ошибку, а возвратит ноль. И с тем как printf() автоматом преобразовал float в int при чем некорректно и не остановив программу тоже все видели. Вот так она выглядит, строгая типизация в С.

Ну а кого ты хотел удивить? Назвать сишную типизацию строгой можно только условно. Манипуляции c void * и неявное приведение типов не очень то стыкуются с понятием "strong typing".

> Ну а с такими читами можно и в PHP сделать вот так:

:D Да, можно по всякому извращаться. И проверять ручками тип каждой переменной перед использованием тоже можно, если больше нечем заняться. Но я всё же предпочитаю чтобы за меня это делал компилятор.

> $ perl -e 'use strict "refs"; use warnings FATAL => qw(all); print "anonymous" * 2, "\n";' Argument "anonymous" isn't numeric in multiplication (*) at -e line 1.

Зато в стандартном режиме ничуть не лучше php:

$ perl -e 'print "anonymous" * 2,"\n";' 0

> :D Да, можно по всякому извращаться. И проверять ручками тип каждой переменной перед использованием тоже можно, если больше нечем
заняться. Но я всё же предпочитаю чтобы за меня это делал компилятор.

Ну вот вам strong typing:

$ cat x.c
#include <stdio.h>

int
main (int argc, char **argv)
{
int a = 1000000,
b = 1000000;

printf ("%d*%d=%d\n",a,b,a*b );

return 0;
}
$ ./x
1000000*1000000=-727379968

а вот dynamic:

$ php -r "print 1000000*1000000;";
1.0E+12

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

Строки поддерживают операцию умножения. Это не заведомо некорректные данные. Что тебя тут смущает?

> Строки поддерживают операцию умножения.

Ну и сколько будет "a"*"b"? В PHP не поддерживают, и сложение тоже не поддерживают - для конкатенации строк есть операция ".". В C++ тоже:

$ cat x.cpp #include <iostream> #include <string>

using namespace std;

int main() {

string a="anonymous";

cout << a*2;

return 0; } $ g++ x.cpp -o x x.cpp: In function ‘int main()’: x.cpp:10: error: no match for ‘operator*’ in ‘a * 2’

> Ну и сколько будет "a"*"b" Нисколько. Сгенерируется исключение.

TypeError: can't multiply sequence by non-int of type 'str'

Так что тебе неудобно в таком поведении строк и списков?

> Ну и сколько будет "a"*"b"

Нисколько. Сгенерируется исключение.

TypeError: can't multiply sequence by non-int of type 'str'

Так что тебе неудобно в таком поведении строк и списков?

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

После тюремной баланды гамбургер тоже приятно навернуть. Менее говёной пищей он от этого не становится.

> а вот dynamic:
> 
> $ php -r "print 1000000*1000000;";
> 1.0E+12 

Херня это, мой дорогой онанимус, а не дунамик. Ибо:

C:\>python -c "print 1000000*1000000"
1000000000000

>просто интерестно уже почти как год пишу на пхп

>ничего особо страшного и ужастного пока что не увидел ))

Не обращай внимания. Недостатки PHP, найденные на ЛОРе:

- глобальные переменные, автоматом забираемые из CGI-переменных окружения (ещё в 4ых версиях по умолчанию отключено, но и раньше этим пользовались тока ламеры);

- отсутствие namespace'ов (на мой взгляд, единственный реальный недостаток, собираются исправить в 6й версии);

- отсутствие замыканий и анонимных функций (как без них на ЛОРе?).

И отсутствие этой, как её, ну....хвостовой рекурсии, вот :-)

>1. Я сидел на МК-61 с 1987 по 1990 годы (примерно). 2. Я люблю питон (несмотря на сложности с кодогенерацией и другие реальные проблемы). 3. (вывод) рекомендую в 2007 году сидеть на БЗ-34 самому, а остальные уж сами решат как-нибудь ;)

Никто на мне не сидел в эти годы!

>- отсутствие замыканий и анонимных функций (как без них на ЛОРе?).

:) эт точно!

Но ты еще забыл одну вещь: непредсказуемое поведение при создании класса. (Это когда _выполнялся_ конструктор, несмотря на явную ошибку в его наименовании)

ну и - с безопасностью проблемки, куда ж без них.

Ещё к недостаткам:

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

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

- огромный code base, но запредельно низкого качества, что разом превращает доступность готовых решений в недостаток. Но ламерам нравиццо.

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

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