@Bibainet16 июн 2015 в 09:21

PHP 7 Alpha 1. Что нового

3 мин

49K

PHP * Веб-разработка *

Recovery Mode

+26

Комментарии 96

@MaximChistov 16 июн 2015 в 09:34

>оператор ??
Побыстрее бы его в Java/C# ввели, очень удобная штуковина :)

@Quetzal 16 июн 2015 в 09:46

Эм, как бы в C# он уже есть (см. Null coalescing operator)

@difiso 16 июн 2015 в 09:59

C#:

// Set y to the value of x if x is NOT null; otherwise, 
// if x = null, set y to -1. 
int y = x ?? -1;
// Assign i to return value of the method if the method's result 
// is NOT null; otherwise, if the result is null, set i to the 
// default value of int. 
int i = GetNullableInt() ?? default(int);

@MaximChistov 16 июн 2015 в 10:12

класс :)
java как всегда не торопится )

@Borz 16 июн 2015 в 11:31

в Groovy есть Elvis-оператор "?:"

@neolink 22 июн 2015 в 10:02

elvis это другое кстати в php от тоже есть

@Borz 22 июн 2015 в 10:48

разве?

@neolink 22 июн 2015 в 10:56

ну у меня кармы не хватает ссылками отвечать:

def g = false // 0, ''
def v = g ?: '123'

а ?? это только null, в php ещё и с обработкой isset

@Borz 22 июн 2015 в 11:24

вон вы про что. согласен — есть отличие.

ЗЫ: чуть поправил карму

@avolver 16 июн 2015 в 10:48

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

$action = $_POST['action'] ?: 'index';

@MaximChistov 16 июн 2015 в 10:51

а если в $_POST['action'] будет false?)
все-таки основной смысл ?? в обработке null, что больше проблема компилируемых языков

@Bibainet 16 июн 2015 в 11:03

А если $_POST['action'] не существует, то вообще будет notice.

@marapper 16 июн 2015 в 11:18

Проблема в isset.

@Opik 16 июн 2015 в 11:25

Только вот будет notice, если в посте нет action

@falke2 16 июн 2015 в 13:18

Разве что так, чтобы без нотайса:

$action = @$_POST['action'] ?: 'index';

@Bibainet 16 июн 2015 в 13:34

Тут уже отвечали, что там может быть false, 0, «0», пустой массив. И эти значения будут проигнорированы. В любом случае здесь будет ошибка, а ошибки лучше не глушить, а избегать. Тем более @ — затратный оператор, он устанавливает error_reporting в 0 перед вычислением выражения.

@WaveCut 16 июн 2015 в 09:49

Не написали очень важное изменение, что PHP для Windows x64 наконец-то начал представлять целые числа в виде 64-х битных, а не как раньше, 32-х, что делало использование х64 сборок на Windows бессмысленным занятием, если нужны манипуляции с большими числами.

@Bibainet 16 июн 2015 в 09:59

Добавил. Спасибо.

@falke2 16 июн 2015 в 10:28

Вот разработчикам фреймворков и CMS веселья добавилось :)

@Bibainet 16 июн 2015 в 10:32

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

@falke2 16 июн 2015 в 10:35

Ну с релизом PHP 7 каждый разработчик захочет ускорить свои приложения. Вот тогда уже 5.6 будет постепенно отходить.

@dizews 16 июн 2015 в 10:31

Итерация по массиву при помощи foreach() больше не сдвигает внутренний указатель массива, который можно получать и изменять при помощи функций current()/next()/reset() и им подобных.

Я правильно понимаю что без явного вызова next() цикл будет бесконечным?

@Bibainet 16 июн 2015 в 10:37

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

@SilverFire 16 июн 2015 в 10:41

Нет, скорее:

$array = [1,2,3,4,5];
next($array);
var_dump(current($array)); // 2

foreach ($array as $item) {
    continue; // iterate over array
}

var_dump(current($array)); // 2. В PHP 5.5 будет FALSE

3v4l.org/nf3Cg

НЛО прилетело и опубликовало эту надпись здесь

@BAV_Lug 16 июн 2015 в 12:57

Как бы ничего нового глобального я в списке не увидел. Разве что «увеличение производительности» — на что еще тоже нужно будет посмотреть. Кстати, стало интересно, а кто и зачем юзает пых под виндой?

@Bibainet 16 июн 2015 в 13:03

Да и не совсем понятно зачем было перескакивать через 6 версию. Между 5.0 и 5.6 было даже больше изменений в самом языке, но возможно в движке их действительно много. А пых под виндой, для тестов, для разработки, а еще же есть IIS.

@BAV_Lug 16 июн 2015 в 13:08

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

@FractalizeR 16 июн 2015 в 13:37

Насколько я помню, это объяснялось тем, что в PHP6 предполагали вводить совсем другие изменения (в частности, родные Unicode-строки). И, как водится, появилось огромное количество книг и статей с названиями типа «Программируем на PHP6», несмотря на то, что изменения даже утверждены еще не были.

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

@khim 16 июн 2015 в 13:47

Да как бы вполне понятно.

@WaveCut 16 июн 2015 в 13:38

Иногда этого требует архитектурное решение.

@lexxpavlov 16 июн 2015 в 13:54

>Как бы ничего нового глобального я в списке не увидел
Так это 7.0 заморожен по фичам. А вот в будущих 7.* вполне могут быть новые изменения.
И ещё, очень важного изменения в списке в статье нет — это скалярный type-hint, и это немалая вещь, это серьёзно (хотя в некоторых случаях и не настолько полезно).

@Bibainet 16 июн 2015 в 14:22

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

@Fesor 16 июн 2015 в 23:56

Этот список — то что влияет на уже существующий код. То есть маленькие BC-брэйки. Помимо того что полностью переписали все что связано с основными структурами, вот вам кратенький список плюшек нового PHP:

— контекстно зависимый парсер (наконец-то, хоть он всеравно слегка туповат)
— тайп хинтинг для скаляров
— тайп хинтинг для возвращаемых значений
— анонимные классы
— добили генераторы

ну это то что я вспомнил из существенного для меня лично.

wiki.php.net/rfc#php_70 — тут подробнее.

@AxisPod 16 июн 2015 в 14:22

> Добавлен новый оператор сравнения <=>, так же известный как «spaceship operator». Конструкция $a <=> $b возвращает -1, 0 или +1 если $a соответственно меньше, равно или больше $b. Удобно использовать в колбэках для usort().

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

НЛО прилетело и опубликовало эту надпись здесь

@AxisPod 16 июн 2015 в 14:46

В C++ boost есть tribool, надо такой вводить.

@skobkin 17 июн 2015 в 00:28

Точно, нужно еще ввести булевые значения с сарказмом.

@nomadmoon 17 июн 2015 в 04:03

«Типа да»?

@Borz 17 июн 2015 в 04:40

«может быть»

@skobkin 18 июн 2015 в 00:25

«Ага-ага...»

@WaveCut 19 июн 2015 в 13:15

тайп хинт!

(сарказм) $var

@globik 16 июн 2015 в 15:49

зачем алгоритму сортировки знать больше, меньше или равно, если достаточно сравнения <

Заинтриговал ваш вопрос, поэтому провел небольшое расследование. Похоже, что сейчас PHP использует свою реализацию алгоритма Quicksort, в котором отдельно не используется информация о равенстве сравниваемых элементов. Но ранее (PHP 4) он использовал стандартную Си функцию qsort из stdlib, которая, в качестве одного из аргументов, как раз принимает функцию сравнения, возвращающую -1,0 или 1.

@mjr27 16 июн 2015 в 17:10

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

@meta4 16 июн 2015 в 15:11

>Так же foreach по значению теперь всегда работает с копией массива.

Я надеюсь там что-то вроде CoW?

@maxru 16 июн 2015 в 15:54

Совершенно не показательный, но забавный сравнительный тест hello world :)

@BAV_Lug 16 июн 2015 в 16:06

Откуда дровишки?

@maxru 16 июн 2015 в 16:08

3v4l.org

@vladon 17 июн 2015 в 07:58

Строго говоря, это тест не hello world, а времени выполнения eval()

@seregagl 17 июн 2015 в 09:40

У меня на реальном проекте семерка по сравнению с 5.6 показывает на треть лучший результат. Две секунды вместо трех

@Sanovskiy 16 июн 2015 в 16:09

Добавлен оператор "??" (Null coalescing operator), позволяющий проверить переменную на существование

Да! Еще больше запутанного говнокода!

В качестве значения констант, объявляемых через define() теперь можно указывать массивы.

facepalm

Синтаксис конструкторов в стиле PHP 4 (имя метода конструктора совпадает с именем класса) теперь считается устаревшим.

ДАНЕУЖЕЛИ!

Удалена INI директива «asp_tags

Это надо было сделать еще в 5.3

Добавлена поддержка type-hint'ов для скалярных типов. Ранее контроль типов был возможен только для классов, интерфейсов, массивов и типа callable.

Единственное, что радует.

И еще: где обещанная строгая типизация?

@Blumfontein 16 июн 2015 в 18:45

Кто вам обещал строгую типизацию?

@Sanovskiy 16 июн 2015 в 21:55

О ней еще при живой четверке кричали на всех углах.

Мне даже любопытно, кто и за что минусит?

@Blumfontein 17 июн 2015 в 04:51

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

@khim 17 июн 2015 в 07:13

Есть также понимание того, что нестрогая типизация — хороша для сохранения рабочих мест, но плоха, когда хочется написать что-то работающее без ошибок.

Между языками с «динамическая/нестрогая типизацией» и «статической/строгой типизацией» лежат ещё языки с «динамическая/строгой типизацией» (от LIPA до Python'а) и практика показывает, что от нестрогой типизации выигрыша почти никогда нет, зато слёз — куча.

@Fesor 16 июн 2015 в 22:25

где обещанная строгая типизация?

<?php

declare(strict_types=1);

function foo(string $bar) : string {
    return $bar . $bar;
}

foo(123); // error

по умолчанию будет произведен каст (в случае если каст идет с потерями — ошибка), в «строгом» режиме все что не соответствует нужному типу — ошибка.

wiki.php.net/rfc/scalar_type_hints_v5

@Sanovskiy 17 июн 2015 в 04:13

Это больше на костыль похоже, если честно.

@Fesor 17 июн 2015 в 10:56

Давайте назовем это «компромисом», не так грустно будет. По другому этот RFC просто не приняли бы, причины собственно там описаны.

@DjOnline 16 июн 2015 в 20:13

>>В качестве значения констант, объявляемых через define() теперь можно указывать массивы.
Только define как был медленным, так и остался, вплоть до того что доступ к массиву по текстовому ключу быстрее чем по константе define. Писал об этом ранее habrahabr.ru/post/257237/#comment_8415927

@bBars 16 июн 2015 в 22:50

Type-хинты радуют. Не знал о том, что можно было указывать на callable. Здесь подразумевается closure или строку и массив тоже можно подсунуть под видом callable?

Прямо сегодня столкнулся с тем, что shr не трогает старший бит. Зачем так сделали? Неужто все эту операцию только для деления на 2 используют?

@Fesor 16 июн 2015 в 23:49

ответил чуть ниже…

@Fesor 16 июн 2015 в 23:48

Здесь подразумевается closure или строку и массив тоже можно подсунуть под видом callable?

Читаем документацию. Все что валидно для call_user_func.

Еще интересная штука, которая появилась в PHP7 но о чем не написано в статье (она написана на базе информации для обновления, новых фич тут как бы и не описано вовсе) — анонимные классы. То есть теперь можно упарываться почти как в java для описания колбэков, реализующих интерфейсы:

<?php

interface FooCallback {
    public function __call(string $foo, string $bar) : string;
}

function foo(FooCallback $foo) : string {
    return $foo('foo', 'bar');
}

foo(new class implements FooCallback {
    public function __call(string $foo, string $bar) : string {
         return $foo . $bar;
    }
});

что-то в этом духе.

wiki.php.net/rfc/anonymous_classes

@sevka_fedoroff 17 июн 2015 в 08:36

Люди, а объясните, что значит «Так же foreach по значению теперь всегда работает с копией массива»?

@Bibainet 17 июн 2015 в 10:32

В теле цикла foreach теперь не получится производить манипуляции над самим массивом.

@felicast 17 июн 2015 в 11:01

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

@Fesor 17 июн 2015 в 11:07

Да, при передаче массива в foreach теперь происходит копирование (как при передаче аргументов функции). Естественно Copy-on-write никто не отменял и если вы не меняли массив в цикле то реально копирование происходить не будет.

@sevka_fedoroff 17 июн 2015 в 11:11

foreach($a as $k => $v) {
    $a[k] = $v+1;
}

После этого изменится массив $a?

@sevka_fedoroff 17 июн 2015 в 13:08

Сам отвечу на свой вопрос. Судя по wiki.php.net/rfc/php7_foreach, массив $a изменится после завершения цикла (как и сейчас в ПХП5).
А речь вообще о другом. А именно, о том, как ведет себя текущий перебор массива в цикле foreach в том случае, если внутри цикла происходит модификация этого массива.
Сейчас в некоторых ситуациях поведение довольно странное. В ПХП7 хотят это поведение сделать предсказуемым.

@Bibainet 17 июн 2015 в 11:22

Но даже сейчас, в 5.6, если в теле цикла добавить элемент в массив, цикл его не затронет. Если изменить элемент, то цикл все равно получает неизмененное значение. Вот пример с пояснениями:

$a = [0, 1, 2];
foreach ($a as $item) {
	if ($item === 1) {
		$a[2] = 3; // Изменяем следующий элемент
		$a[] = 4; // Добавляем элемент в конец
		// $a теперь равно [0, 1, 3, 4], но цикл по прежнему выдает 0, 1, 2.
	};
	echo $item, ' ';
};
print_r($a);

Результат:
0 1 2 Array
(
[0] => 0
[1] => 1
[2] => 3
[3] => 4
)

@sevka_fedoroff 17 июн 2015 в 11:27

Да, так и есть. Вот я и не могу понять, что значит «foreach по значению теперь всегда работает с копией массива»
Вроде как он и в 5.х работает с копией. Тут некоторые говорят, что вообще нельзя будет в теле foreach производить манипуляции типа $a[1] = 2. По-моему это странно.

@reket 17 июн 2015 в 12:25

Похоже речь идет об этом wiki.php.net/rfc/php7_foreach (там подробно с примерами).

@sevka_fedoroff 17 июн 2015 в 12:53

Спасибо. То что нужно!

@gro 17 июн 2015 в 09:04

Двадцать раз уже на хабре написано, что нового в PHP 7.
Написали бы конкретно, какие в альфе нюансы.

@GEOgraf 17 июн 2015 в 12:40

Дайте пожалуйста ссылочки на несколько из двадцати статей, поиском не нашёл.

@gro 17 июн 2015 в 13:02

habrahabr.ru/search/?q=php7

@GEOgraf 17 июн 2015 в 13:07

а вот так (с пробелом) не находит habrahabr.ru/search/?q=php%207
спс.

@WildZero 17 июн 2015 в 21:41

Ну а теперь еще бы дождаться расшиерние под 7ку. Редиса очень не хватает.

@clockworkbird 10 июл 2015 в 06:03

Конечно все замечательно, но такими темпами язык все больше и больше отстает от жизни.

@Fesor 10 июл 2015 в 06:24

Можно как-то аргументировать?

@clockworkbird 10 июл 2015 в 08:23

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

Давно пора уже самому языку стать объектным.
Понятно, что обратная совместимость и куча стона «не ломайте наш язык» и мегатонны кода, но хотя бы с возможностью переключателя (для тех, кому хочется). Сообщество огромно и необходимый код, уверен, мигрировал бы на новый синтаксис достаточно быстро.
А так — это топтание в болоте.
Итак у языка репутация уже ниже плинтуса.

@Bibainet 10 июл 2015 в 09:18

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

@clockworkbird 10 июл 2015 в 11:25

Мне кажется, вопрос, как раз и в этом — назрело уже. Либо меняешься, либо умираешь.
Объекты в языке же появились в связи с развитием программирования — ничего страшного с языком и его популярностью не случилось, только лучше для всех стало.

@khim 10 июл 2015 в 11:32

С популярностью ничего не стало потому что все эти новомодности типа объектов можно тупо игнорировать — и при этом свои поделки как-то таки прождать. Если у PHP отнять это свойство и сделать так, что для использования языка его придётся изучать, то кому он такой будет нужен? Вы же убьёте единственное его достоинство — возможность программирования с помощью применения генетических алгоритмов к ответам на Stack Overflow без задействования головного мозга!

@clockworkbird 10 июл 2015 в 11:37

Да через Stack Overflow будут уже новый синтаксис копировать — делов то )

@khim 10 июл 2015 в 13:06

А кто старый оттуда изведёт и, главное, породить тысячи нового? Посмотрите на python — там вроде публика чуть больше думать приучена, а невозможность использования старого кода обозначает, что за многие годы, прошедшие с выхода python 3 на него пересели единицы.

Убирать из языка можно только то, что уже почти никто не использует, да и то с осторожностью, это ещё разработчики FORTRAN'а выяснили, когда попытались несколько фич выкинуть в FORTRAN 77!

@clockworkbird 10 июл 2015 в 13:36

Убирать не обязательно. Сделать параллельный синтаксис и опциональную возможность отключения в php.ini старого.
Надо же что-то с этим делать.

Миграция кода — не проблема в наше время.

@Fesor 10 июл 2015 в 14:06

Миграция кода — не проблема в наше время.

я бы хотел жить в вашем времени.

Сделать параллельный синтаксис

Сколько там чуваки мигрировали с Python2 на Python3?

@MaximChistov 10 июл 2015 в 14:15

мигрировали

Вы из будущего?))

@khim 10 июл 2015 в 15:26

Сделать параллельный синтаксис
Сколько там чуваки мигрировали с Python2 на Python3?

А причём тут Python? Как раз там никакого параллельного синтаксиса никто не сделал: вы не можете ни включить в проект на Python2 модуль написанный для Python3, ни наоборот.

Тут скорее нужно как раз на тот же FORTRAN смотреть, только на FORTRAN 90. Он как раз предложил новый синтаксис, в котором не нужно считать колонки — и им даже многие начали пользоваться. А многие (хорошо если не большинство) — по прежнему используют fixed form! А уж найти хоть одного программиста, который бы на фортране или коболе писал бы объектно-ориентированные программы мне не удалось. Хотя оба языка поддерживают OOP уже многие годы.

Я думаю разработчики PHP просто здраво оценивают свои силы и считают, что «два языка в одном» они просто не потянут. Особенно с учётом того, какие прелести могут ожидать их «на стыках».

@Fesor 10 июл 2015 в 09:27

То что приведено в статье это далеко не полный список изменений и плюшек.

Давно пора уже самому языку стать объектным.

Тип все что вам нужно для счастья это что бы инты были объектами? И что вы будете делать? Наследоваться от интов? Примешивать поведение вы всеравно не сможете (во всяком случае пока, и я думаю это была бы опасная вещь в руках по-ха-пэшников).

Если только с точки зрения синтаксиса — раньше у PHP был крайне неуклюжий парсер и это сделать было просто невозможно. С 7-ой версии там уже нормальный парсер, даже местами контекстно зависимый и заимплементить это дело в принципе уже можно. Не превращать скаляры в объекты а просто синтаксис сделать схожий. Так же есть предпосылки для более глубоких оптимизаций на уровне генерации опкодов, аля алиасы для функций которые просто вызывают php-шные функции не будут добавлять оверхэда вообще, потому как на уровне опкодов мы не будем дергать лишние функции. А это значит что можно будет вместо резкого перехода сделать полифилы, шимы и т.д. которые и на производительность сильно влиять не будут и помогут проще перейти на новый синтаксис или просто добавить вариант использования.

Итак у языка репутация уже ниже плинтуса.

Она ниже плинтуса не потому что язык плохой, я бы так не сказал, а потому что любой идиот может на нем что-то написать. Именно по этому в PHP комьюнити так много индусов и быдла. Скажем возьми человек Python или Ruby ему придется чутка побиться головой и почитать документацию. А с PHP берешь и кодишь всякий треш, и мнишь себя гением. И добрая половина просто не считает необходимым развиваться куда-то дальше начального уровня. Таких людей хватает и в Ruby и Python сообществе, но процент сильно меньше, так как в самом начала всеравно придется чуть чуть поднапрячься. А затем кривая обучения идет примерно одинаково, По количеству же толковых разработчиков я думаю разницы особо нет.

@clockworkbird 10 июл 2015 в 10:54

Тип все что вам нужно для счастья это что бы инты были объектами?

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

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

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

Да нет, не от того, что пишут плохо. Это в любом языке можно сделать. Мы вот пишем и на Ruby и на PHP — что ж мы на Ruby специально пишем хорошо, а на PHP плохо? )

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

Отчего тот же композер не зашить в сам язык? Почему нельзя сделать сборку языка с библиотеками попроектной — в самом языке?
От того, что системно язык не организован — невозможно поставить произвольную версию под проект, не говоря уже про несколько версий одновременно (да, есть phpbrew, но попробуйте с ним построить нормальный продакшн — проще уж виртуализировать),…

Аналоги инструментов появляются, все-таки опенсорс великая штука, но все они всегда хуже конкурирующих продуктов других языков. В основном, за счет организации как раз самого языка.

Единственная и последняя опора PHP — виртуальный хостинг — возможность размещать проекты на нем на хостинге за $5 в год без необходимости иметь хоть какого-то сисадмина. В этой нише с PHP пока не может полноценно конкурировать ни один язык, поэтому PHP и остается пока лидером.

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

@khim 10 июл 2015 в 11:25

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

Неа. Ушли бы куда-нибудь на другой язык.

Да нет, не от того, что пишут плохо. Это в любом языке можно сделать. Мы вот пишем и на Ruby и на PHP — что ж мы на Ruby специально пишем хорошо, а на PHP плохо? )

Да. Естественный отбор, однако. Достоинство PHP является прямой причиной всех его недостатков: он был задуман так, чтобы человек, ничего не знающий о программировании, смог бы сделать работающую программу. Конечно в ней будет куча косяков, но она будет работать! А значит её можно отдать заказчику и пойти делать следующий сайт за 5 копеек.

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

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

@clockworkbird 10 июл 2015 в 11:30

Неа. Ушли бы куда-нибудь на другой язык.

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

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

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

Т.к. количество кода в наше время уже не является преимуществом.
Помню, как в свое время говорили, что у Windows Mobile огромное конкурентное преимущество за счет огромного количества написанного кода, а через год все работало уже под андроидом и ios и про WM никто уже даже и не вспоминал.

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

@khim 10 июл 2015 в 15:19

Неа. Ушли бы куда-нибудь на другой язык.
Зачем?

Затем что кушать что-то хочется, да.

Поймите вы: если человек понимает почему, скажем, в python'е (просто пример приличного языка, который я хорошо знаю) "10" < "5" — это True, 10 < 5 — это False, а "10" < 5 — это вообще TypeError (исключение, которое, если его не поймать, обрушит всю программу), то ему, конечно, хочется от языка некоторой стройности.

Но подавляющее большинство людей этого не понимают и понимать не хотят. А говнокодить-то хочется.

И вот для них сейчас PHP — лучший выбор. А поскольку их — гораздо больше, чем программистов на многих других языках, то и разработчики библиотек и расширений (которые, в большинстве своём, всё-таки способны такие вещи понять, да и вообще — программировать-то умеют) без работы не сидят.

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

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

А вы лучше посмотрите на количество сайтов на которых что-то такие крутится на основе WordPress'а (или, ещё того хуже, phpBB). Ни о каких гемах их разработчики (в большинстве своём) даже не мечтают!

PHP — это VisualBasic наших дней. Когда Microsoft решил «осовременить» Visial Basic и предложил программирующим на нём (которые в те времена составляли чуть ли не половину вообще всех людей, которые что-то там программировали) VisualBasic.NET со всякими новомодными плюшками, но люди их «ниасилили». Кто-то переключился на PHP, кто-то переквалифицировался в VBA-программистов, кто-то «закусил удила» и выучил-таки C#, но разбежались в разных направлениях почти все. Вся экосистема была уничтожена почти под корень за считанные годы.

Помню, как в свое время говорили, что у Windows Mobile огромное конкурентное преимущество за счет огромного количества написанного кода, а через год все работало уже под андроидом и ios и про WM никто уже даже и не вспоминал.

Дык правильно говорили. Во-первых через год ничего почти не работало (это я вам как человек, ходящий с Android'ом с 2008го года говорю). А во-вторых — это пример вообще не из той оперы: первые несколько лет много людей по прежнему пользовались телефонами на Windows Mobile и Symbian'е, так как под них нужный им софт был, а больше ни подо что не было, а потом Microsoft удавил сначала Windows Mobile (Windows Phone 7 использовал ядро от Windows Mobile, но старые программы использовать было нельзя), а потом внедрил своего засланного казачка в Nokia и Symbian тоже удавил. Разумеется если платформу насильственным образом убили, то количество софта под неё уже никакой роли играть не может!

У меня вообще есть ощущение, что весь проект Windows Phone (и особенно — с привлечением Nokia) был задуман и осуществлён как грандиозная диверсия. Потому что даже если кто-то решил бы специально уничтожить всех реальных конкурентов Android'у, то ничего лучше было придумать просто нельзя.

@neolink 10 июл 2015 в 09:48

> но процент сильно меньше
не факт, я видел много людей которые делали треш на ruby, java, c#. тут ещё общее кол-во вовлеченных влияет. как не крути а php популярен.

но вообще clockworkbird года на 2-3 опоздал с «топтанием». по поводу объектности языка не оч. понятно что имелось ввиду. да вы бы первый и плевались от этой объектности — когда $a->round(2) падает так как вы не сделали кастинг в int.
и кстати в 7 есть и переключатели для пары фич.

@clockworkbird 10 июл 2015 в 11:04

Да не я опоздал, а PHP походу )
Я с 3 версии работаю (после perl это был глоток свежего воздуха), а с 5 версии все жду — когда же, когда. Шестого не будет, ну ладно, ну в 7 то уже точно… Ага, щас — __constructor отменили, все дела.
Уже и с любимого PHP на Ruby переполз местами, уже заказчики в ответ на предложение сделать проект на PHP-фреймворке пишут: «Опять ты мне какое-то г@#$о прелагаешь»,… и чувствую — не дождусь.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий