Pull to refresh

Comments 88

Вы забыли самы вопиющий пример:

$a = "11";
$b = "a";
$c = 2;
echo $a < $b; // Истина
echo $b < $c; // Истина
echo $c < $a; // Истина

Фактически это значит что никакие операции ни с какими переменными без явной проверки типа использовать нельзя. Такой, с позволения сказать, "оператор сравнения" неприменим ни для операций сортировки ни для поиска - то есть вообще практически ни для чего. Ах да - дыры в безопасности с его помощью создаются просто великолепно. Но больше - ни для чего (пока вы типы явно не проверите).
Отличный пример, спасибо! Пришел в голову еще один
$a = "a";
$b = "b";
$c = 0;
echo $a==$c; // true
echo $c==$b; // true
echo $a==$b; // false

Значит == не есть соотношение эквивалентности, а < не есть соотношение порядка.
UFO landed and left these words here
а что придумано вместо < и > для сохранения транзитивности?
UFO landed and left these words here
Явная проверка типа должна быть в голове программиста. Какой бы PHP ни был динамический и слаботипизированный, всё равно все значения являются результатом совершенно определенных последовательных вычислений. И моментов, когда программист не знает, что у него сейчас в переменной не так много. В этих случаях пара простых проверок совершенно не повредит.
Программист может ожидать что-то, а что там реально окажется - одному богу ведомо. Так как PHP (тогда ещё PHP/FI) создавался для быстрого создания тяп-тяп сайтов, то он пытается угадать что имели ввиду - в результате неправильно написанные программы часто работают. До поры до времени. Для серъёзных работ такое поведение языка - просто хуже не придумаешь: если бы всё накрывалось медным тазом сразу, то люди бы больше думали о том чего они пишут. А так - делается "нечто" за месяц, а потом годами в нём затыкаются дыры.
$var = 2 + 2;
Лично я уверен, что в var будет int настолько, насколько вообще можно быть уверенным в чём-то в этом мире.

Как любят все вспоминать про этот FI и зачем он создавался.
Для чего C в 70-м году создавался помните? Согласны ли вы с тем, что он за эти годы прошел некоторый путь эволюции? Почему же пыху вы в этом отказываете?
UFO landed and left these words here
езжайте, езжайте ...
UFO landed and left these words here
предложения начинаются с заглавной буквы
в конце предложения ставится точка
Для чего C в 70-м году создавался помните?
Ну меня тогда и на свете-то не было, но судя по рассказам - создавался C для написания низкоуровневых программ (в первую очеред операционок). И некоторые "элегантные" решения аукаются до сих пор и порождают лишь слегка меньше дыр, чем галлюцинация под названием PHP. Но там хотя бы ясно за что боролись: все проверки (обязательные в безопасных языках - Ada или Java) в C отсутствуют для достижения максимальной эффективности.

Согласны ли вы с тем, что он за эти годы прошел некоторый путь эволюции?
Всё течёт, всё изменяется. Но 90% без в программах на С/C++ (да, включая C++) - последствия родимых пятен из 70х...

Почему же пыху вы в этом отказываете?
Почему отказываю? Кое-какие грабли удалось ликвидировать - в PHP5 объекты это таки объекты, а не пародия как PHP4. Но главное - не лезущая ни в какие ворота работа с динамическими типами - осталось неизменным. Зачем такое количество граблей в медленном интерпретируемом языке, каковым является PHP?
А если $var = $var + 2 ?
И этот $var может браться откуда угодно: из пришедших параметров запроса, базы, другой функции и т.п., то уже ни в чем нельзя быть уверенным.
Дык надо нормально писать(инициализировать переменные перед использованием) и всё будет окей. А также почитать про приведение типов в PHP - сразу всё станет ясно что куда. А так - нечего на язык программирования пенять, когда пишешь криво.
$var не может браться откуда угодно, оно может браться из:
1. Предыдущих вычислений и иметь абсолютно конкретный тип, зависящий от этих самых вычислений.
2. Из базы - в большинстве баз столбцы имеют совершенно определенный тип.
3. Из другой функции - смотрите документацию к этой функции
4. В пришедшем параметре запроса. Вот здесь нужно проверять. Так же, как и в других языках, следует проверять, что же там пришло извне.
Проверка типа в голове потребует от программиста держать в голове весь код. UNIX-путь программирования говорит, что каждая функция должна делать одну вещь и делать ее хорошо. Но в C в отличие от PHP все аргументы функции должны иметь определенный тип, в PHP добиться этого можно только явной проверкой. Поэтому нередки ситуации, когда программист, вызывая функцию не знает, какой тип она ожидает на входе и какой возвращает на выходе.
А зачем в PHP добиваться того, что должно быть в Си?
>программист, вызывая функцию не знает, какой тип она ожидает на входе и какой возвращает на выходе
точно так же, как и в Си, это можно узнать из документации, комментариев или самого кода.
Узнать это многими способами можно. Но вот отследить нарушение зачастую никак нельзя. PHP тут достиг полного апофигея: в C++ вы обнаруживаете ошибку типа "несоотвествие типа" на стадии компиляции, в Python - на стадии исполнение, в PHP - на стадии разборок с очередным обнаруженным у вас в программе эксплоитом. Вариант C++ - самый надёжный, но и самый жестокий - даже элементарные вещей типа списка объектов произвольных типов там нет, вариант Python - более гибкий, но и более опасный, вариант PHP - то, с чем не стоит связываться в принципе.
Почему бы не сделать
function some($arg)
{
if (!is_string($arg))
trigger_error('Wrong arg in some()', E_USER_ERROR);
}
Это не решение, это костыль.
К сожалению, всё что могу ответить на это, это повторить старые свои слова "khim, вот вы пишите на хабре очень много умного и интересного, но когда речь заходит о PHP на вас что-то находит нехорошее.".
А для этого есть Type Hinting и приведение типов. Если вы ожидаете массив, то и пишите function foo(array $bar), а если целое число, то function foo($bar) { $bar = intval($bar); ...}

Приведение типов конечно несколько затратно, но зато дает некоторые гарантии.
Type Hinting позволяет требовать только массив или объект определенного класса. Потребовать строку или целое число с помощью type hinting невозможно. Явная проверка типа, с помощью функций, подобных is_int() или приведение типов иногда единственный выход.
Я немного не понял, ссылка ваша на то, как контролировать ошибки, а не на type-hinting...
А вы попробуйте, попробуйте. Хотя…
В общем смысл вот в чём: вы вполне можете писать function(integer $a), равно как и function(array $a), вот только первый вариант выпадет с ошибкой, которую и надо поймать. Строка ошибки будет выглядеть примерно так: «……… instanse of integer, integer given…». На это и проверяет написанная мною регулярка. Вот вам и тайпхинтинг.
Понял, спасибо. Сэкономили мне время.
А почему разработчики PHP начали делать хинтинг, но не доделали? ._.
Вы не угадали, они его специально таким сделали. (А вот почему — не знаю, однако думаю чтобы лишний раз не парить насчёт преобразований типа Integer.valueOf() в java). Это просто особенность PHP, которая достаточно удобна, если ей не злоупотреблять.
Кстати, моя реализация — урезанная версия от этого.
Дык эта. Человек - сушество удивительно. Даже на велосипеде с одним колесом ездить может. И программ без дыр на PHP может писать. Но вот для путешествий лучше всё-таки велосипед с двумя колёсами и язык, как-то реагирующий на несоотвествие типов - есть разные модели велосипедов в зависимости от того, куда ехать и языки могут свою диагностику выдавать в разные моменты времени, но такого, чтобы её не было вообще - это надо поискать. В C++-то соглашение "всё что не 0 - то истина" сколько бед и разрушений вызывает, но по сравнение с "услужливостью" PHP это всё меркнет...
Ой, а можно пример "разрушительности соглашения в C++: всё что не 0 — истина"?
Типичный пример с разного рода строками:
if (s) {
  // blah-blah-blah
}
Так как строки обычно имеют преобразование в char*, а char* сравнивается с нулём, то это выражение истинно более-менее всегда. Решение известно - либо делать преобразование в char* так, чтобы на пустую строку возвращался NULL, либо не делать его вообще. Первое решение не слишком приятно ибо на полученную строку нельзя без проверок напускать функции, работающие с char*.

Но да, на фоне чудесатых чудес от PHP это всё мелочи, конечно.
Ещё забыли, что есть такая вещь, как PHP Manual:
http://ua.php.net/manual/ru/types.comparisons.php
if(isset($_GET['income']) && strlen($_GET['income'])) { .. }
Логичнее написать так:
if(isset($_GET['income']) && !empty($_GET['income'])) { .. }
UFO landed and left these words here
не поможет, зато поможет такой хак: if( strlen( $v= &$_GET[ 'income' ] ) )
Не совсем понял для чего такое извращение...
Нам нужно проверить лишь не пуста ли переменная, для этого используем !empty().
'0' - это тоже "пустое" значение.
Проверяется, если результат команды присваивания имеет не нулевую длину.
Всё нормально вроде...
зачем isset вообще?
empty это тоже конструкция, на undefined нотисов не выдаст.
Это с како-то версии php так, до этого выводился нотис.
Я искал в ченьдлоге для пхп, но не смог найти с какой версии ввели это изменение.
Может кто-то знает?
достаточно написать
if ( ! empty($_GET['income']) ... )
Вы статью-то читали? Не умеете вы ездить на цирковом велосипеде:

$ cat test.php
&lt?php
    $a['test']='0';
    if (empty($a['test'])) {
        echo "Приплыли...\n";
    }
?>
$ php test.php
Приплыли...

Либо купите хотя бы двухколёсник, либо учитесь... Я немного поразвлекался со вторым и предпочёл первое...
Многоточия вы и не заметили в моем комментарии?

empty используется для проверки на несуществование и "пустоту" переменной/индекса.
Дальше идут дополнительные проверки, зависящие от логики приложения.
khim имеет ввиду то, что, если вы введёте в поле «0», ваш код посчитает, что вы ничего не ввели.
Почему бы тупо не писать:
$s = $_GET["s"];//допустим такой вариант
if(!strlen($s)) {
//попробуй понять это как нить не так!
}
пусть $s не строка а любое значение, - тогда:
$s : !strlen($s)
true : true
int : true
false : false
null : false

Мне просто интересно чем плох такой вариант(мб он плох, мне просто интересно хнать чем)?

" Ой, а можно пример "разрушительности соглашения в C++: всё что не 0 — истина"?
Типичный пример с разного рода строками:
if (s) {
// blah-blah-blah
}"
И че в этом плохого? Да надо вам провреять длинну строки, вы и юзайте функцию для длинны строки.
UFO landed and left these words here
echo '"A"==0.0 is ' . ('A'==0?'true':'false') . "\n";
echo '"A"===0.0 is ' . ('A'===0?'true':'false') . "\n";

Ошибка.
Почему-то никого не смущает, что в SQL можно написать id=100 и id='100', а в PHP это бесит. SQL, PHP и т.п. - языки четвертого поколения (4GL), C, Basic, Pascal - третьего поколения. Сравнивать их просто неразумно.

Сама суть языков 4GL в том, чтобы избегать различного вида конвертирования типов и проверок, в угоду "чистому" бизнес алгоритму. Если вы часто используте isset() в PHP, то вы неправильно пользуетесь этим языком.
Это бесит в SQL и в PHP. Но
1. SQL-запросов обычно в программе немного и альтернативы не сильно привлекательнее - приходится терпеть
2. Когда вы пишите в SQL id='100' или id=100 то вы обычно знаете что и куда будет преобразовываться ибо id есть тип
А PHP лучше просто не использовать. Возьмите любой нормальный язык программирования, благо их сейчас на многих хостингах предлагают: Python, Ruby, Lisp или Haskell. Но не PHP.
> Почему-то никого не смущает, что в SQL можно написать id=100 и id='100',
В нормальном SQL есть правила приведения типов. В очевидных и недвусмысленных случаях когда у вас колонка числовая, а вставляете строку, база сделает за вас это приведение. Там где все неоднозначно, должна возникать ошибка. Попробуйте, например, вызвать хранимую процедуру с неправильным типом аргумента.
>"A"==0 is true
>"A"===0 is false
>"A"==0.0 is true
>"A"===0.0 is false
дык, PHP кастует строку в число, используя ее до первого нечислового символа:
"123qwe" == 123

отсюда и "ошибка" в кейсе:
0 == "John"

только вы учтите, что в get_salary почти наверняка придет строка (в том числе, из $_REQUEST может прийти только строка, а уже
"0" != "John"

Если все-таки страшно, что число попадет в кейс со строками - делайте ему strval() на входе.

Разумеется, === строки с числом ВСЕГДА вернет false.
Да всё можно. Но проблема в том, что в нормальной программе среднего объёма (про крупные я уж и не говорю) в 99% должны сравниваться объекты одной природы. А в том 1%, где это проблема несложно и преобразование типов написать. Но в случае коротких скриптов типа простейшей формочки - наоборот, 90% занимают простые проверки где типы перепутаны. В результате PHP оказался оптимизирован под этот 1%. Ну и нафига козе баян? Не лучше ли использовать язык оптимизированный под 99% use сase'ов, а не под 1%?
PHP - язык для веб-разработок. Там таких "неправильных" данных, пришедших из формочек, урлчиков и SQL базочек, как раз 99%.
Ага. И именно поэтому там, где приходится иметь дело с этими самыми "неправильными" даннами, их приходится обвешивать многоуровневыми костылями-проверками. И именно это чудесное свойство языка является причиной 99% взломов и некорректной работы сайтов, когда забывают подставить какой-нибудь из бесчисленного множества этих костылей.
Было бы сделано по-людски, 99% проблем просто невозможно было бы сделать непреднамеренно.
А при чем здесь язык? Как будто в другие языки данные из тех же источников приходят уже проверенными и "многоуровневые костыли" там не нужны.
Не, ну вы же сами написали при чём...
Смотрите - сделали херню для того, чтобы, как вы сами написали, было легко использовать неправильные данные. А потом ставятся многоуровневые костыли для того, чтобы побороть однотипность обработки "неправильных" данных.
То есть сначала переводим неправильные данные в правильный вид (довольно нетривиальным способом), потом проверяем. Потом опять в неправильный вид. Для того, чтобы на следующем уровне начать всё заново.
Многократно выполняется лишняя работа. khim всё правильно написал. Оптимизированый под 1% язык. Ну. и нафига такое убожество использовать? :)
Я ожидаю некое числовое данное. Оно приходит из внешнего источника в виде строки. Для того чтобы проверить не еденица ли это, я пишу:

if ($value==1)

И все! Одна лишь языковая конструкция, без различного рода дополнительных библиотек. Мне не надо думать какого он типа и какой мусор окажется в строке. Если это похоже на еденицу, значит так тому и быть. Меня даже не волнует, если данное NULL или вообще не передано. Нет данного - значит это не единица. Никаких проверок, как в типизированном языке, не требуется вообще. И используется
это сплошь и рядом, если работать с PHP, как с PHP, а не как с неким портом Си для веба. Это совсем другой подход в работе с данными, а не просто другой язык.

Если вы говорите о валидации данных, то это совсем другой вопрос и процедура ее одинаковая, независимо от типизации языка.
Смеялсо. Часто приходится проверять не еденица ли это? _этот_ пример тривиален, бессмыленен и пишется одинаково в любых используемых языках с поправкой на синтаксит.
if ("1".equals(value)) // java - сложнее всего за отсутствием перегрузки оператора ==
А теперь проверьте не ноль ли это. :)
А теперь, не ноль ли или не еденица ли это :) :).
А теперь проверьте не то ли это число, что содержится в переменной $must_be (ноль - разрешённое значение).
Не понял. А в чем проблема проверить?

$value = 0;
$must_be = 9;
switch ($value) {
case 1:
echo 'equal 1';
break;
case $must_be:
echo 'equal to ' . $must_be;
break;
case 0:
echo 'equal 0';
break;
}


Вам упорно твердят, что он для веб, а вы ссылаетесь на остальные мифические случаи.
Пацталом. Сами не видите? :)
Очень "ясный" и "простой" быдлокод. Патамушта даже такую элементарщину вы умудрились написать с ошибкой. Проверьте с $value=''. Ку? :)
>Вам упорно твердят, что он для веб
Веб - это такое специальное место, где чем больше сделаешь ошибок, тем лучше? И где чем сложнее и запутанее делаются совершенно элементарные вещи, тем лучше?
Уверяю вас, вы ошибаетесь. Для веба вполне можно писать ясный, простой, понятный, хорошо поддерживаемый код. Если не пользоваться пыхапой. :)
Ку-ку. http://www.php.net/manual/ru/types.comparisons.php

Пока я вижу человека абсолютно не разбирающегося в языках с динамической типизацией. И PHP в частности.

В чем проблема? '' == 0
Что Вас в этом смущает?
Пока что я вижу человека, который вместо решения элементарной задачи прислал запутаный малопонятный код с ошибкой и утверждающий, что ошибка не в коде, а в условии задачи :). Ну-ну. Вы своим работодателям и заказчикам тоже объясняете, что сделаный вами сайт работает криво, падает и ломается не потому, что в нём ошибки, а потому, что в мануале по пхп так написано? Прикольно.
А языков с динамической типизацией я периодически профессионально использую где-то три или четыре, из них только этому ублюдку пхп требуются постоянные костыли и подпорки на абсолютно ровном месте.
Условие задачи было "А теперь проверьте не то ли это число".
Вы умудрились впихнуть туда строку - и это Ваши личные проблемы. Поэтому Вам и нужны подпорки :)

Может все-таки обратить внимание на /dev/hands, а не на PHP?
Вы клоун? Вы страдаете ретроградной амнезией? Вы забыли что сами "открывали мне глаза" на "самый страшный секрет" о том, что пыхыпе - это язык для веба? Чукча не читатель, чукча - писатель? Приглядитесь, мы обсуждаем обработку хттп параметров. Вы не в курсе, что они передаются в виде строк? И, о ужос(!) могут быть даже пустыми строками. И это надо отслеживать, если вы хотите программировать, а не балаболить.
На всякий случай (а случай, похоже, клинический, и все уловия нужно повторять в каждом сообщении) сообщаю - я в курсе, как это можно сделать. С помощью огромного, невнятного быдлокода. Но в более других языках то же смое делается куда проще и не провоцирует на ошибки, за которые вы так упорно держитесь. Для меня остаётся загадкой - зачем использовать это убожество, если можно пользоваться гороздо более удобными, приятными в использовании, логичными и простыми языками. Видимо, вы - секта. Деструктивная, судя по тому, что мозги она действует явно размягчающе :).
Удачи в вашем нелёгком деле - продолжайте объяснять заказчикам, что это они ставят вам неправильные задачи, а не вы пишите ошибочный быдлокод. Аминь.
Юноша, если Вас не научили фильтровать и проверять все приходящие параметры, ДО начала работы логики - то я Вам точно не доктор :) Если Вы настолько неопытны, что пытаетесь сразу их сравнивать... тогда не удивительно что у Вас не получается писать на PHP. Ведь тут надо думать самостоятельно.

Специально для школьников показываю, как нужно обрабатывать все пришедшие данные.

$user = new UserModel();
$filtered = $user->filter($_POST);
$validated = $user->validate($filtered);
$user->save($validated);

switch ($user->year)
{
case 2000:
echo 'equal 2000';
break;
case 2008:
echo 'equal 2008';
break;
}
Малчег, меня умиляют ваши отмазки. Нет, чтобы сразу признать, что облажались вы со своим быдлокодом, так лепите же одну отмазку нелепее другой. Шо ви тут показали? И где требуемое сравнение с нулём? :)
Думать, говорите, надо? Ну-ну. Пыхыпы - это как раз пример того, когда вместо "думать" (над логикой, алгоритмами, красотой и тд) предлагается упорно прыгать. Повторяюсь: элементарные вещи необходимо обвешивать безумным количеством костылей и подпорок. Вы блестяще продемонстрировали это вашими примерами, которые делают всё что угодно, кроме того, что требовалось.
Зачем заниматься хернёй, её богу. Бросьте ужо это убожество, займитесь делом. Или умишка не хватает осилить язык чуть более сложный, чем эта дурость?
Всё-таки интересно - почему вы на нём пишите. Какие у него преимущества, по сравнению с другими языками, используемыми в этой области, по-вашему? Тольк не надо это херню, про то, как полезно думать над какими-то низкоуровневым и никому не нужным бредом. Вам это приходится делать только потому, что создатель языка в свое время "ни асилил" зачем это было сделано на перле :).
Да, где хотите, туда и вставите сравнение себя с нулем. Понятия, - как я понимаю, - эквивалентные.

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

Я понятия не имею, какие элементарные вещи Вам пришлось обвешивать костылями. Мне очень жаль Вас, что Вам пришлось оправдываться перед своими заказчиками и валить все на PHP. Но право же, вина PHP лишь в том, что он Вам это позволил и это не оправдывает Вас.
Java, и иже с ней, точно так же получают HTTP запрос в виде строки и точно так же занимаются контролем и приведением типов. Только Вы этого не видите и не знаете.

Мне безразлично на каком языке писать PHP, C#, Java, VB, SQL.
Но мне удобны языки с нестрогой и неявной типизацией. На PHP я могу написать все - от домашней странички до ERP системы. Java и C# для многих небольших задач слишком тяжелы. Поэтому чтобы не плодить винегрет, я пользуюсь одним языком.
Оборжался. Вы продемонстрировали несколько кривых, косых, баговых примеров костылей и говорите, что мне нужны костыли. Мне-то как раз не нужны. А вы, да, продолжайте сражаться с ветряными мельницами и писать бессмысленный код. Квалификация ваша мне понятна. Иэрпе системы, ага. :)
Ниасилил вашу дискуссию, можно краткое резюме?
Краткое резюме, чтобы писать правильно на любом языке - нужны голова и руки :)

PHP позволяет делать многие вещи "неправильно", но как делать - выбирает сам программист.
Краткое резюме с другой стороны баррикады сформулировал товарищ khim где-то там чуть повыше. PHP соптимизирован для решения 2% задач. Остальные 98% решаются на нём через жопу. Причём именно в этих 98% случаев PHP чаще всего и применяется.
Краткий вывод: PHP не имеет преимуществ ни перед одним из языков похожего типа. Одни недостатки. Использовать его нет никакого смысла, тк всё необходимое на более других языках делается проще, красивее, быстрее, качественнее и процесс менее подвержен ошибкам.
Краткое резюме в том что каждый из товарищей не прав=) Один хвалит недостатки PHP, другой говорит что у него нет достоинств. Помоему и то и другое далеко от истины.
вы бы представились для начала, а то как-то анонимно не то.
А смысл? Здесь же не симпозиумум гуманитариев, где истинность идеи зависит от авторитера персоны её декларирующей. У нас всё проверяется простым экспериментом.
Вы в своих "экспериментах" опираетесь на свой опыт. Вот и хотелось бы узнать, стоит ли ему доверять.
А так похоже что два человека прочитали книгу "пхп за 24 часа" и спорят кто внимательнее прочитал.
UFO landed and left these words here
Прямо сейчас моя лубофф - руби (всю рутину скриптую на руби, взамен перла), соответственно для веба - рельсы. Мелкие веб-поделия делаются вообще влёт. Крупные ещё не пробовал :).
Если хочется языка менее разгильдяйского, чем руби :), то питон. На нём есть несколько общеизвестных вещей, сильно облегчающих жизнь. Питон знаю крайне поверхностно - как-то не к душе он мне пришёлся.
Если уродский синтаксис пхп так сильно греет душу, то есть старый добрый перл - даже на перле писать приятнее, чем на пхп, а уж по богатству синтаксиса и общей мощности языка их даже сравнивать неприлично.
Если хочется странного. Очень странного. То я видел веб-фреймворк на схеме. Советовать не буду, я его только видел издалека, но о-очень прикольная штука. Декларируется щастье для всех и чтобы никто не ушёл обиженным. Бегает поверх явы, что облегчает вопрос хостинга.
Ну, а для большого и светлого, общеизвестный рулез - ява. Страдает, конечно, многословностью и некоторой тяжеловесностью, но плюсов у неё гораздо больше. Одних только явских веб-фреймворков столько, что архитектору проекта будет чем заняться, выбирая подходящий :). Ява - довольно лёгкий и приятный в изучении ОО-язык. Не ОО-программы на нём писать можно, но существенно тяжелее, чем ОО, что является для начинающих несомненным плюсом - дисциплинирует, тскзать. Дохренища библиотек на все случаи жизни. Ясный и понятный синтаксис. Навороченые IDE, которые буквально сами всё делают за разработчика :). Поддерживать явский код на порядок проще пехапешного. Если лень думать и разбираться с фреймворками, то там в вебовских комплектах есть технология jsp на которой можно быстро писать "в стиле пхп" - такую же развесистую клюкву кода, смешаного с разметкой Правда потом, если захочется бОльшего, проще будет выкинуть эту клюкву и написать всё заново, так что и в этом смысле с пхп разница небольшая :).
В мире предложений от микросовта не разбираюсь совсем, поэтому ничего сказать не могу.
UFO landed and left these words here
UFO landed and left these words here
Медленнее. Но, вроде бы, незначительно. К тому же, легко масштабируется. Что, в сочетании с низкой ценой на железо, более быстрой разработкой и более простой поддержкой, делает эту разницу несущественной.
Что касается твитера... У меня есть большие сомнения, что 99.99% пхп-программистов когда-нибудь столкнётся с проектом со сравнимой нагрузкой :).
Что касается твитера - 2. Насколько я знаю, проблема с производительностью там заключается не в рельсах. Вообще, на рельсах там только небольшая часть и, как-то проскакивало интервью, кто-то из создателей говорил, что как раз к рельсовой части у них меньше всего претензий :).
Что касается твитера - 3. У меня большие сомнения, что переписывание именно на пхп твитеру поможет :). Ну, во сколько раз руби медленнее пхп? В 2? В 3? Это смешно. Шило на мыло.
...
case 'Mary':
return 4600;
break;
...
какой смысл после ретерна брейк писать?
Only those users with full accounts are able to leave comments. Log in, please.