Pull to refresh

Comments 103

Гораздо интереснее сравнивать новые фичи.
Типа, тайпхинтинг, конечно, крут, но он замедляет всё в 100500 раз.
UFO just landed and posted this here
А можно, пожалуйста, ссылку на какой-нибудь бенчмарк или слова разработчиков PHP? Иначе это какое-то голословное утверждение.
Я не делал никаких голословных утверждений.

Вот здесь, Дмитрий рассказывает как работает тайпхинтинг.

Что и требовалось доказать: никакого замедления в 100500 раз нет. Поскольку все происходит в рантайме, то конечно есть накладные расходы небольшие, это и так достаточно очевидно. Но так бы мы писали эти же проверки и касты самостоятельно.
Вы не разбираетесь в матчасти. Тайпхинтинг как минимум не замедляет. И даже отчасти ускоряет.
UFO just landed and posted this here
Верно. Высосан из пальца, потому что это синтетический пример, о чём было сказано в начале.
Я хотел показать каким образом скалярный тайпхинт может привести к ускорению. В конце ответа я написал: «код может ускорится при использовании скалярных тайпхинтов, но в среднем общая производительность останется такой же».
Разумеется синтетика имеет мало общего с реальным приложением в продакшене.
UFO just landed and posted this here
Тайпхинтинг в объявлении аргументов функции. И это таки тайпхинт, а не тупое насильное преобразование string -> int. Поскольку функция объявлена со скалярным тайпхинтом,
function foo(int $bar)
{
}
, то тогда в неё нельзя передать значение, которое не конвертируется в int строгим образом. Т.е. foo(«abc») приведёт к TypeError. Таким образом да, это таки тайпхинт, а не приведение к int.

Я замеряю время, которое тратится на отработку функции целиком, а не только её вызова.
Суть в том, что при наличии скалярного тайпхинта, значение аргумент будет преобразовано в требуемый строгим образом и далее это может привести к ускорению кода внутри функции поскольку в этом случае исчезает type juggling.

Скалярный тайпхинт таки отличается от приведения типа тем, что при тайпхинте значение аргумента не будет насильно приводится к требуемому.
Например, при вышеописанном объявлении функции корректными будут вызовы: foo(123), foo("123"), foo("12.3e1") (последние 2 допустимы, если не указан declare(strict_types=1)), но некорректными (при которых будет выброшено исключение): foo(null), foo("123abc") (внезапно!), foo("abc"), foo([]), foo(new stdClass),…
В то же время если заменить скалярный тайпхинт на приведение типа перед циклом, то тогда все перечисленные выше варианты станут а) допустимыми, б) приведение типа отработает во всех случаях.

Вы либо невнимательно читали, либо неправильно поняли. Скалярный тайпхинт может приводить к ускорению кода так как при использовании оного уменьшается количество неявных приведений типов.
UFO just landed and posted this here
UFO just landed and posted this here
Не в стрикт режиме аналог это
if (!is_numeric($x) || $x != (int) $x) {
    throw new TypeError(/* ... */);
}

$x = (int) $x;


То же самое можно сказать и про объекты:
if (!$x instanceof SomeClass) {
    throw new TypeError(/* ... */);
}


И не более.

И да, вы правы: тайпхинты нужны для валидации типов аргументов. И не более.
Разница в том, что тайпхинт работает таки быстрее, чем «аналоги». И не более.
UFO just landed and posted this here
Вы не разбираетесь в сослагательном наклонении.
А некоторые уверены, что PHP умрет… Впрочем как всегда ))
UFO just landed and posted this here
UFO just landed and posted this here
Наоборот. Удивительное развитие. То есть удивительно тем, что на насыщение скорость не выходит. Сколько же там косяков или принципиальных лагов, если он так постоянно и существенно совершенствуется? Впечатление, что он изначально был написан с бодуна левой ногой по-французски.
UFO just landed and posted this here
открыв эту статью вы как минимум 1 раз убили PHP
Ок, как раз в пару моей вчерашней статье из которой следует — «по возможности не используйте интерпретаторы!».

Переводим тест Мандельброта на C# и получаем на настольном ПК для 100 000 итераций
PHP Elapsed 46.472
PHP 7.0.18 (cli) (built: Apr 11 2017 16:35:10) ( NTS )

C# Elapsed 0,99 s
.NET 4.0

С ассемблером тест проводили?

Зачем?

C# может играть в той же нише веб-сервисов, что и PHP — они конкуренты, а асм тут не конкурент.

Конечно, правильнее было еще сравнить потребляемую память: PHP — 7Mb, C# — 7.8Mb

На этом тесте паритет, надо смотреть реальные задачи. Но в целом — для бомжатников — где 1000 сайтов на одном сервере, PHP будет в выигрыше.
82,7% рынка у PHP, 15,1% у ASP.NET
Какие уж тут конкуренты :)
Платформа MS полумёртвая и доля её продолжает снижаться каждый месяц. За последний год она упала на 0,6%.

Выразительность языка сравнима. На ассемблере программу писать существенно дольше. На C# и на PHP — примерно одинаковое количество времени получится.

Ну вообще есть Peachpie. Под капотом CLR и вперед.
Интересно было бы и его в статье для сравнения посмотреть.
1. тест Мандельброта не имеет ничего общего с сайтописанием
2. вы в реальной жизни, на болиде «формула 1» ездите, надеюсь? (а то иначе дуализм какой-то получается)
Хорошая статья, спасибо, но вот это вот:

5.0.5
5.1.6
5.2.17
5.3.29
5.4.45
5.5.38
— зачем?

Really, нет никаких причин тестировать и использовать старые версии. Переход на PHP 7.1 практически бесплатный для любого проекта.
UFO just landed and posted this here
Joomla 1.7.2
Поддержка брошена. Но сайт был работающим, пока админы не решили обновить РНР с 5.5 до 7.
Пришлось объяснять начальству, почему оно поломалось…
А апдейт джумлы на 3.5 штатными средствами не предусмотрен. Даже через промежуточные версии.
Опущу комментарии и эмоции, возникшие из-за воспоминаний о работе с этой ЦМС, и спрошу только одно — а почему вообще джумлу использовали?
Ни в коем случае не хочу сказать, что Джумла — хорошая CMS, но, отбросив программистский снобизм, хочу сказать, что, если сайт работает и выполняет свою функцию, то небольшой компании, далёкой от IT, могло быть просто бессмысленно тратить деньги на разработку сайта на нормальной платформе.
Именно. Сайт — он не для того, чтобы удовлетворять потребности программиста, ответственного за него, в изучении новых технологий.
Сайт достался от предшественника. Так как сайт был в первую очередь нужен дл того, чтобы он работал, переход на новую ЦМС был просто бессмысленен. Работает — не трожь.
Сайт — он не для того, чтобы удовлетворять потребности программиста, ответственного за него, в изучении новых технологий.

Сайт достался от предшественника.

Joomla 1.7.2

Ощущение что изначальная идея использования джумлы как-раз «удовлетворяла потребности программиста, ответственного за него, в изучении новых технологий» вместо «нечто максимально живучее для варианта „работает — не трожь“ ».

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

Особенно в части проектов завязанных на старые кодовые базы и расширения к пхп.
Например, php-gearman отлично сегфолтится под 7-ку, тогда как под 5.5 работал.
Я понимаю, тесты производительности в основном для числодробилок, как их можно интерпритировать?
Например реализация websocket сервера на php, будет ли она быстрее на php7/8/5? на те же 40%?

p.s. когда я слышу о производтельности php я сразу напоминаю, что очень многие программисты активно используют массивы со строковым ключом как идентификатор поля в своей универсальной структуре (вместо числового ключа, с определенным заранее дефайном, и это я молчу про поддержку классов или, например, использование кортежей), скорость выборки элементов в таком массиве уже не будет зависеть от версии php так сильно?
UFO just landed and posted this here
охх, ну нифига себе, двухкратный прирост:
$t1=microtime(true);

$m=[];
// fill array with random keys, 3chars len each with 0..255 char code
$mlen=(256*256*256)/16; // size of array, part of possble amount of keys to test key missing
for($i=$mlen;$i>0;$i--)
	$m[chr(rand(0,255)).chr(rand(0,255)).chr(rand(0,255))]=true;

$t2=microtime(true);

// count miss
$missed=0;
for($a=0;$a<255;$a++)
	for($b=0;$b<255;$b++)
		for($c=0;$c<255;$c++)
			if(!isset($m[chr($a).chr($b).chr($c)]))
				$missed++;

$t3=microtime(true);

echo 'filling: '.number_format($t2-$t1,6,'.','').', counting: '.number_format($t3-$t2,6,'.','').PHP_EOL;



PHP 7.1.1 (cli) (built: Jan 18 2017 18:38:28) ( NTS MSVC14 (Visual C++ 2015) x64 )
filling: 1.043060, counting: 8.288474

PHP 5.5.14 (cli) (built: Jun 25 2014 12:41:10)
filling: 2.028116, counting: 13.588777
хех, реализация для nodejs, как неоднозначно:
function rand(min, max)
{
	return Math.floor(Math.random() * (max - min)) + min;
}

var nl= require('os').EOL;

var t1=new Date().getTime()/1000;

var m=[];
// fill array with random keys, 3chars len each with 0..255 char code
var mlen=(256*256*256)/16; // size of array, part of possble amount of keys to test key missing
for(var i=mlen;i>0;i--)
	m[String.fromCharCode(rand(0,255))+String.fromCharCode(rand(0,255))+String.fromCharCode(rand(0,255))]=true;

var t2=new Date().getTime()/1000;

// count miss
var missed=0;
for(var a=0;a<255;a++)
	for(var b=0;b<255;b++)
		for(var c=0;c<255;c++)
			if(undefined===m[String.fromCharCode(a)+String.fromCharCode(b)+String.fromCharCode(c)])
				missed++;

var t3=new Date().getTime()/1000;

console.log('filling: '+(t2-t1)+', counting: '+(t3-t2)+nl);

текущий релиз nodejs:
x86 — v6.10.2
filling: 1.5170001983642578, counting: 15.236999988555908
x64 — v6.10.2
filling: 1.7149999141693115, counting: 18.02999997138977

а теперь внимание, шок (у меня лежала старая версия от 2015 года)
x64 — v0.12.7
filling: 1.5099999904632568, counting: 7.805999994277954

даже не знаю что сказать!
Ничего нового нет: чем меньше функционала, тем быстрее работает
а теперь внимание, шок (у меня лежала старая версия от 2015 года)
Этот, немного странноватый, тест наверное единственный случай когда старая нода оказалась быстрее, так как в реальном коде все наоборот.

Причешем немного код на php, и добавим 2 missed счетчика, чтобы была интрига у кого рандомайзер лучше:
php код
<?
$t1 = microtime(true);

$m = [];
// fill array with random keys, 3chars len each with 0..255 char code
$mlen = (256 * 256 * 256) / 16; // size of array, part of possble amount of keys to test key missing
for ($i = $mlen; $i > 0; $i--)
    $m[chr(rand(0, 255)).chr(rand(0, 255)).chr(rand(0, 255))] = true;

$t2 = microtime(true);

// count miss
$missed = 0;
$missed2 = 0;
for ($a = 0; $a < 255; $a++)
    for ($b = 0; $b < 255; $b++)
        for ($c = 0; $c < 255; $c++)
            if (!isset($m[chr($a).chr($b).chr($c)]))
                if (rand(0, 2) % 2 == 0)
                    $missed++;
                else
                    $missed2++;

$t3 = microtime(true);

echo 'filling: ' . number_format($t2 - $t1, 6, '.', '') * 1000 . 'ms' . PHP_EOL;
echo 'counting: ' . number_format($t3 - $t2, 6, '.', '') * 1000 . 'ms' . PHP_EOL;

echo PHP_EOL . $missed . '; ' . $missed2 . '; ';


В js коде (вдруг кому интересно):
1. В функция rand не хватает «min + 1»
2. Для подобных целей вместо ассоциативного массива нужно использовать Map
3. Проверять на отсутствие значения лучше так «if (!arr[key])»
4. fromCharCode можно в краткой форме записать «String.fromCharCode(rand(0, 255), rand(0, 255), rand(0, 255))»
5. В начале всех js файлов лучше писать 'use strict'; — избавит от множества проблем.
6. Для вычисления времени выполнения удобно использовать «console.time('metka')», хотя есть и более точный вариант «performance.now()»

Переписанный пример на js:
код js
'use strict';

function rand(min, max) {
    return Math.floor(Math.random() * (max - min + 1)) + min;
}

console.time('filling')

var m = new Map();
// fill array with random keys, 3chars len each with 0..255 char code
var mlen = (256 * 256 * 256) / 16; // size of array, part of possble amount of keys to test key missing
for (var i = mlen; i > 0; i--) {
    m.set(String.fromCharCode(rand(0, 255), rand(0, 255), rand(0, 255)), true);
}

console.timeEnd('filling')

console.time('counting')
// count miss
var missed = 0;
var missed2 = 0;
for (var a = 0; a < 255; a++) {
    for (var b = 0; b < 255; b++) {
        for (var c = 0; c < 255; c++) {
            if (!m.get(String.fromCharCode(a, b, c))) {
                if (rand(0, 2) % 2 === 0)
                    missed++;
                else
                    missed2++;
            }
        }
    }
}
console.timeEnd('counting')

//console.log(`\n${missed}; ${missed2}; `);
console.log('\n' + missed + '; ' + missed2 + ';'); // for node v0.12.7



И, соответственно, результат:

PHP 7.1.4 (cli):
>php test.php
filling: 788.352ms
counting: 7672.947ms

10387458; 5189704;


node v0.12.7:
>node test.js
filling: 616ms
counting: 7304ms

10393087; 5195409;


node v7.9.0:
>node test.js
filling: 533.590ms
counting: 6663.210ms

10386734; 5190004;


Результат уже более предсказуемый, если бы были просто массивы (не ассоциативные), то node был бы еще быстрее чем php, или вычисления какие с этими данными.
если бы были просто массивы (не ассоциативные)

Не, ну это не совсем честно. Вы ведь код под ноду оптимизировали?
Тогда уж используйте SPL а не классические массивы. А там преимущество будет уже не столь заметно.
Не, ну это не совсем честно. Вы ведь код под ноду оптимизировали?

Что не честно? Вы процитировали цитату из части про «если бы», о чем речь?
Я вообще ничего не оптимизировала, я написала как будет правильно под ноду.
Вы переписали код ноды так, как более правильно писать под ноду. Было? Было.
Использовались более эффективные конструкции языка.
Далее было сказано, что " если бы были просто массивы (не ассоциативные), то node был бы еще быстрее чем php". Было такое утверждение? Было.
Данное утверждение логически верно. Я не могу сказать что вы ошибаетесь, или врете.
Всё так. Всем известно что у пхп массивы довольно медленная часть, поскольку они универсальные. По этой причине были созданы другие структуры данных, а именно специальные классы.
Они тоже не очень удачно спроектированы, и я думаю что даже с ними нода будет в выигрыше. Но тем не менее если уж сравнивать код на разных языках, то стоит использовать оптимальные конструкции для каждого языка, даже если они несколько отличаются.
А значит _честно_ будет использовать не числовые массивы, а именно классы из SPL.
Двусвязный список или ФиксМассив, не суть.

Мне вот интересно, это я действительно настолько непонятно выразился что нужно было оценивать человека, а не комментарий, причем массово, или это оппоненты настолько плохо знают язык (в статье про пхп прошу заметить, не про ноду), что не пользуются SPL и не поняли моего высказывания?
UFO just landed and posted this here
Всем известно что у пхп массивы довольно медленная часть, поскольку они универсальные. По этой причине были созданы другие структуры данных, а именно специальные классы.

Любой кто когда либо работал с SPL знает, что они ужасны.

Далее было сказано, что " если бы были просто массивы (не ассоциативные), то node был бы еще быстрее чем php". Было такое утверждение? Было.

Разницы между 7672.947ms и 6663.210ms можно сказать вообще нет, поэтому я написала про обычные массивы или про вычисление каких-нибудь данных, где разница была бы заметнее.

Вы переписали код ноды так, как более правильно писать под ноду. Было? Было.

Я переписала код так, как правильно писать под js, ведь тянуть php практики в js не правильно по многим причинам, и это ни для кого ни секрет. «new Map» вместо ассоциативных массивов рекомендуют использовать все, в том числе и создатели node. Да если уж на то пошло, вообще использовать es6 рекомендуют по полной.

Если у php есть что-то подобное, то никто не запрещает вам переписать php-пример.
Но именно [] в php7 и есть лучший выбор, потому что на него был сделан основной упор оптимизаций по сравнению с php5.
Как только мы об этом узнали, мы перевели все сайты на php7-fpm (давно, еще в бете) и отлично он держит ~2.652.376 хитов в день. На ноду переходить вообще не вижу смысла, но это не отменяет того факта, что на js надо писать правильно.

И хотя я знала, что кто-то обязательно придерется к Map, я всё-таки сделала упор на new Map только по той причине, что он тут правильнее по смыслу, es6 все дела. Можно было бы и без него, достаточно всего 1 строчки кода в оригинальном примере после цикла:

m = m.slice();

И код бы ускорился в 2 раза, и так же бы обогнал php-версию, без каких-либо новых структур данных

Вы бы тоже сказали, что это читерство? Хотя все кто пишут на js знают, что если уж вы начали массив заполнять ассоциативными данными, то это будет череда скрытых классов, которые работают крайне не эффективно и после заполнения надо слить их в новый единый объект. А оправдывать тем фактом, что якобы не все про это знают, не говорит о скорости языка ни как.

А значит _честно_ будет использовать не числовые массивы, а именно классы из SPL. Двусвязный список или ФиксМассив, не суть.
Мне вот интересно, это я действительно настолько непонятно выразился

Вместо рассуждений, могли бы просто взять и привести правильный пример. Но у вас не получилось бы, потому что в SPL ни один из них не делает то, что нужно в данном случае. Или если делает, то очень заморочено, и нужно писать обвязку. И всё равно это было бы медленнее, чем [] в php7.
Просто Set специфичен (не прочитать рандомное значение, без перебора всего), а Map это почти прозрачная замена ассоциативного массива с удобным доступом

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

$ node map.js
filling: 637.137ms
counting: 7916.720ms

10388534; 5187885;

$ node set.js
filling: 502.317ms
counting: 7290.966ms

10384428; 5192356;



И в данной задаче сначала заполняются случайные ключи хэшмепа и им присваивается значение true (которое не используется, потому что оно не нужно). А потом проверяется наличие ключей в этом хэшмепе.
То есть обе операции которые используются во множествах.
Это да, я имела введу, что Set подходит под специфические задачи, а Map под любые
Спасибо за тест, не ожидал, что new Map даст такой прирост
Например реализация websocket сервера на php, будет ли она быстрее на php7/8/5? на те же 40%?

шо, опять? ©
Шутки не понял, если у меня сервер на php то мне будет сложно правильно использовать сторонние (но не невозможно само собой), а значит реализация именно серверной части с обслуживанием подключений и пользователей будет на php, гугл выдает с десяток реализаций.

Мало того, неплохой нормой становится http сервер тоже на php (само собой прикрытые nginx proxy), это очень часто заметно поднимает производительность итогового результата (за счет возможности повторно не инициализировать переменные на каждый запрос).

Логичный вопрос — смена версии даст сильный прирост или нет?
Это лучше попробовать, на сайтах на symfony 2 у меня был прирост в 2 раза по процу и снизилось потребление памяти на 30% после перехода с 5.6 на 7.0
Логичный вопрос — смена версии даст сильный прирост или нет?

для вебсокетного сервиса на PHP по скорости вряд ли, по памяти точно

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

да не было никакой шутки
да можно, решения есть, но при поддержке такого решения постоянно придется решать проблемы, которые давно уже решены.
php-шнику на том же nodejs ws-сервис сделать не сложнее чем на php, если не проще. и экосистема там богаче в этом плане, это его ниша.
Маленький оффтоп про экосистему.

Буквально недавно решал задачу, как в пределах одного процесса заставить эффективно по ресурсам работать websocket (а потом и push http) сервер и асинхронную загрузку файлов по http (позже и подключение к сторонним websocket).

на nodejs у меня не возникнет никаких проблем в реализации этого?

Используя готовые решения — websocket сервер на socket (расширение php) и асинхронную загрузку curl_multi_… красивого решения не получается — у них разные механизмы организации цикла

p.s.у каждого свой метод ожидания события на сокете, нет метода, который позволил бы ждать события в обоих библиотеках, можно только проверить их наличие по отдельности, т.е. либо 100% нагрузка в пустом цикле либо вставка слипов и таймаутов, которые заметно замедлят работу при нагрузке
подобные вещи я и имел в виду
предположу, чтобы подобное реализовать, потребуется реализация HTTP на PHP и работа с удаленным сервером через сокет. дальше, наверное, потребуется асинхронная работа с диском, БД…
на nodejs с этим проблем не будет
можно использовать Go, но это тема для холивара )
я смотрю примеры библиотек использования websocket на nodejs, у них нет явного вызова цикла обработки событий, т.е. этой обработкой занимается сам node, я считаю это огромный бонус, жаль этого нет (а так же соглашений по событийному циклу) в php.

Не хватает в таблице строки с каким нибудь другим языком (java например или go), что бы иметь общее представление о производительности php7.

Да, но все-таки строки в таблице не хватает.

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

UFO just landed and posted this here

А какое отношение языки-головоломки имеют к продакшену?

UFO just landed and posted this here
UFO just landed and posted this here

Мог бы ответить вам по существу, но не на такой хамский выпад, конечно.

UFO just landed and posted this here
А я бы с удовольствием почитал ваши доводы. Ну то есть тема, конечно, обсосанная до невозможности, но холивар на то и холивар. Имхо PHP для своей задачи подходит отлично, оттого и такой высокий процент на рынке. Он простой, всепрощающий, быстр в разработке, и позволяет быстро и легко решать каждодневные задачи, коих 99% в вебе. Писать на нём работающий код может даже не очень квалифицированный программист, но, повторюсь, для 99% задач в вебе и не нужна высокая квалификация. Разработка на более «правильных» языках была бы гораздо дороже и сложнее в поддержке. Хотя это и спорный вопрос, если бы исторически, например, Питон занимал такой процент рынка, то и программистов на нём было бы больше. Но на данный момент картина мира такова, и мне лично не видится, что из-за этого мир катится в пропасть, наоборот — сеть растёт и развивается, становится лучше. К тому же к JS, например, у меня лично гораздо больше претензий, и то — при сегодняшнем развитии фреймворков он стал гораздо более терпим.
Да я не болею за какой-то конкретный язык программирования, просто есть «более лучшие». PHP в принципе язык без достоинств, если не считать легкость обучения. Есть языки быстрее из коробки, есть типобезопасные, есть портируемые, есть сверхнадежные, и т.п. Потому я и написал «чтобы не учить нормальный язык», в данном случае нормальный — это будет что-то более подходящее под требование, что-то более быстрое.

Просто товарищи за меня додумали что я якобы критикую PHP. Я полностью с вами согласен — в рейтинге «самый простой язык для бэкенда» PHP будет в топе, и очень часто этого достаточно. Простота и отсутствие необходимости обучаться — это вещи в данном случае взаимосвязанные, на что я и указал.
А я бы с удовольствием почитал ваши доводы. Ну то есть тема, конечно, обсосанная до невозможности, но холивар на то и холивар.

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


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

В рамках холивора, вот два объективных недостатка, которых легко могло бы и не быть.

UFO just landed and posted this here
Ну хватит уже, ну правда. На эти вопросы уже раз 500 давали ответы и на хабре и везде где только можно.

Ну да, ответы обычно именно такие — в стиле — я пишу на PHP и эти недостатки меня совершенно не беспокоят. Это не значит, что недостатков нет.


Это все недостатки которые вас беспокоят или есть еще что-то?

Есть, конечно. У всех языков программирования есть недостатки. Эти конкретные — просто хороший пример. Очевидно они есть. Очевидно это недостатки. Отсутствие конкарренси можно оправдать например тем, что php не решает задач в которых она нужна. А тут — просто недостаки, без оправданий.

UFO just landed and posted this here

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


Что касается языков — Lua и Perl я не владею. С — успешный язык, недостатков в нём много, они расписаны много где. Но я про конкретику из PHP вообще.

UFO just landed and posted this here
И снова как и в предыдуший раз "PHP плохой потому что плохой.

На случай, если вы невнимательно читали в прошлый раз, я дам выжимку из того, что я говорил. У php как минимум 2 недостатка.


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

Вы почему-то в этом тексте видите буквы, которые складываются в "php плохой". Ну, бывает.

UFO just landed and posted this here
Да бесполезно с вами разаговаривать, вы не владеете информацией более чем полностью.

Действительно, ведь в php давно уже не надо ставить $ перед переменными и доступ для полей не через ->, да? :)


Php плохой,

Я так и сказал? Тогда цитируйте, не стесняйтесь.


  1. Это пришло если что из Perl. Потому что php писался под впечатлением от perl, а там то же переменные начинаются с $.
  2. Это отдельная операция, называется конкатенация строк. В начале, в самой первой версии php, ООП там вообще не было. По-этому доступ к членам класа там не то что не был продуман, о нём вообще не думали

Ну да, объективные недостатки php продиктованы тяжёлым наследием прошлого. От этого они не перестают быть недостатками.


И опять же, в предыдущем комменте я не просто так спросил про Lua. Представляете, в Lua конкатенация строк осуществялется (барабанная дробь) аж целыми двумя точкам '..'. Наверно теперь Lua для вас ну просто "ублюдок" какой-то?

Да нет, как конкатенировать строки не очень важно. Важно как прописываются операции, которые приходится делать постоянно. Как делается в Lua доступ к полям?

UFO just landed and posted this here

Заинтриговали. Погуглил. Доступ точками. Теперь интересно почему вы думали, что это повергнет меня в ужас.

UFO just landed and posted this here

Я до конца и разобрался. Доступо к полям с помощью точки в Lua есть. Что я могу тут посчитать ужасным? Чего ходить вокруг да около — расскажите.

На си и си++ тоже есть '->' и '.', собственно первое — переход к полю объекта по ссылке, второе, к самому объекту. Это вполне в духе php — объекты там все по ссылке.

Использование $ перед переменной не большая цена, к тому же это фича, двойной знак — переход к переменной по имени в переменной. Мало того, символ $ сразу говорит что мы имеем дело с идентификатором-переменной, без необходимости взгляду анализировать окружение (когда ищешь беглым взглядом что-либо, переменные сразу бросаются в глаза).

И вообще, короткая запись не всегда благо, лучше лишних символов добавить если читаемость повысится.
На си и си++ тоже есть '->' и '.', собственно первое — переход к полю объекта по ссылке, второе, к самому объекту. Это вполне в духе php — объекты там все по ссылке.

В си и си++ есть -> потому что точка занята другим похожим действием. В php точка посажена на конкатенацию, которая происходит существенно реже, чем обращение к полю объекта.


Использование $ перед переменной не большая цена

Я и говорю, программисты уже не замечают, насколько это странно.


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

Странно, что эту крайне важную фичу не засунули в языки, которые появились позже php :). Вы не пользуетесь подсветкой кода?


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

Не всегда. Но это не тот случай.

В целом мне не особо по нраву слабая динамическая типизация.
Но это одна из тех вещей которые привели пхп к его нынешней популярности.
И поскольку слабая динамическая типиизация это объективная реальность, то скажите мне, на что вы предлагаете заменить конкатенацию? Если точка будет занята, то что же у нас будет?
Привычный плюс? Тогда что мы получим на выходе если у нас будет $x = '2' + '2';?
Я пришел в пхп во времена пхп4. И меня тоже бесили эти странности языка (доллар не бесил).
Тогда еще по факту не было ООП в пхп (оно и сейчас еще не очень распространено, если по честному). Но все равно раздражало.
Однако положа руку на сердце — плюс тут будет еще страшнее.
И да, если в пхп4 (четыре Карл!) доступ к членам класса был еще не очень популярным, то что мы хотим от первых версий.
Странно, да.
Непривычно, да.
Но логично.
И к недостаткам языка оно явно не относится.
Недостаток языка это хаос в функциях.
Недостаток языка это то что все еще нормальная типизация скаляров не доступна на многих хостингах (пхп7+ еще недостаточно популярен). Недостатков много. Но в целом они следствие его достоинств, и воспринимаются как данность.
Что до _непривычности_, а это именно непривычность — ну бывает, чё.
Никогда не пробовали писать под 1С?
У меня ушло недели две, чтобы перестать обращать на это внимание.
Ну перевод и перевод.
И у языка 1с есть куча недостатков. Например его предметнориентированность подразумевает неестественные механизмы расширения существующих сущностей. ООП был бы удобнее.
Но русский язык это просто решение. И решение умное, правильное и удачное. Это его сильная сторона да.
Почему русский?
Многие заблуждаются думая что «глупые недопрограммисты ленятся заучивать конструкции». Это не так. Ведь конструкций не много. А правда в том, что предметная область вся на русском. План счетов как называть? Ну ок, это расхожий термин, вызубрим перевод. А что такое Invoice в коде Васи? Что он имел ввиду? У нас ведь не ВЭД. Это счет или накладная?
Или может вообще ТТН? (Я знаю что у большинства терминов есть перевод, но много ли заказчиков их знают? И знаю правильно? Программист должен знать про предметную область больше чем заказчик? Знать все эти явления, суть их, названия, да еще и переводы? Зачем?
Писать if актВыполненныхРабот.проведен then… можно. Но… зачем? Чтобы было привычнее? Все равно не привычно). А их SQL забавен, да. Взял сейчас томик справочника, нашел пример какого-то запроса, и смог понять только после мысленного перевода всех этих «объединить» на join и т.п. А когда имел с этим дело — на работе по русски, дома по английски, и нормально читалось и писалось.
Многабукафф, да.
Еще раз что сказать хотел. Коротко. $x = '2' + '2'; должно давать 4. Так проектировался язык.
И для него это норма. Такие были задачи. В форме данные все нетипизированные, в строках приходят, потом разбираем. Так что в нише пхп слабая динамическая была очень даже.
Сейчас при готовой инфраструктуре оно может и не очень надо. Но инфраструктуры бы не было, если бы не простота…
ПС: я вкурсе что вы не говорили что «пхп говно», я чисто в качестве аргумента что именно ваши недостатки — недостатками не считаю.

А много ли выигрыша от JIT, учитывая, что пхп умирает после каждого запроса в подавляющем большинстве сценариев использования? Или там скомпилированный код будет в opcache сохраняться?

UFO just landed and posted this here
Числодробление хорошо, но не хватает оценки памяти.
Плюс в реальности довольно много нагрузки приходится на всякие обходы массивов или объектов.
Бутылочным горлышком обычно являются таки СУБД а не пхп. Скорость не везде, но часто вторична, а вот прожорливость по памяти бывает мешает.
А у меня сейчас например главное это числодробилка. Памятью и СУБД можно пренебречь. А вот в предыдущем проекте, пришлось перевести все, что только можно но nosql хранилища. Иначе был ад.
Вся беда в том что проекту более 10 лет и перевод на php7 тяжек.
Если у вас числодробилка (настолько что это важно), то нужен не php, а любой язык со статической типизацией + определить интерфейс взаимодействия пхп (если уже есть легаси с ним) и этим новым языком.
Нужно конечно. только там работы на год минимум. А потом еще баги вылавливать.
С точки зрения программиста нужно все сжечь и переписать.
А с точки зрения руководителя проекта, просто перейти на новую версию php по возможности и более мощный сервер оплатить. А новые модули, писать на C++ но возможности. А часть вообще планируется под GPU.
Не я не про переписать конечно же, потому что числодробилка — обычно это какая-то небольшая часть от проекта, а как раз про что в сервис вынести числодробильную часть и её уже писать на подходящем диалекте,
Уже выше упоминал Peachpie — PHP поверх CLR. Тоесть код вроде как будет скомпилен в IL и можно пользоваться всеми приемуществами CLR… Вот бы кто попробовал и рассказал как оно…
Результат на лицо. Радует что растет производительность любимого языка программирования.

Sign up to leave a comment.