Основная проблема PHP

нулевой порог вхождения

Мне прикольно смотреть, как сегодня в PHP растёт разрыв между традиционным уровнем «берём HTML и насовываем в него код, исполняющийся на сервере», который и обеспечивает низкий порог вхождения и между современной актуальной инфраструктурой PHP (composer, пространства имён/замыкания/трейты/рост типизации/ОРМы/роутеры и т.д., и т.п.)

Получается растущая пропасть, которую не все начинающие смогу перепрыгнуть. Возникает ощущение, что если раньше уровень программистов PHP был плавно размазан от низкого до высокого и каждый мог или методично расти или остановиться на каком-то произвольном уровне, то теперь целый пласт будет отсутствовать. Т.е. программисты на PHP будут или низкого уровня («лепители html-вставок»), или среднего и выше (уже полноценное использование всего инструментария). Промежуточного не будет :)

Основная проблема PHP в том, что ты на нем пишешь

нулевой порог вхождения.

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

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

PHP — это язык программирования. И у него тоже есть порог вхождения — как минимум те, кто ориентирован на программинг.

PHP не осилят историки, к примеру, не осилят сварщики. Где ж ты, программист, видишь «нулевой уровень»? Ты еще про C++ скажи: там тоже есть нулевой порог вхождения — открыть книжку по C++, не умея складывать 2+2.

А на чем писать? На ваших скалах и прочей фигне?

Глядите, ребят, как мозг гниет от похапе.

Что, говнокод не смог в продакшн?

корреляция больше 1? ого

а как знание_основ_тервера коррелирует с быть_не_php_программистом?

эволюция всякого успешного универсального языка управления.

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

разоблачил!

есть люди могущие в программирование а есть тупые их обьединение есть универсум.

для программирования достаточно iq>=80

т.е пройдёт чутка лет и как ща место письму чтению арифметике в начальной школе так и scratch али ещё чё но в началке будет.

isset() есть ли переменная

А оно ВНЕЗАПНО не проверяет наличие переменной/ключа-массива/св-ва-объекта.

Что ты вообще несешь?

Все больше и больше смахиваешь на адепта кулинхао :)))

Ей же можно проверять, пришли ли данные от юзера через POST/GET запрос

Упрлс?

var_dump(isset($x)); // bool(false)

$x = 1;
var_dump(isset($x)); // bool(true)
var_dump($x);        // int(1)

unset($x);
var_dump(isset($x)); // PHP Notice:  Undefined variable: x
var_dump($x);        // NULL

$x = 1;
var_dump(isset($x)); // bool(true)
$x = null;
var_dump(isset($x)); // bool(false)
var_dump($x);        // NULL

$y = [];
var_dump(isset($y['x'])); // bool(false)
$y['x'] = null;
var_dump($y);             // array(1) { ["x"]=> NULL }
var_dump(isset($y['x'])); // bool(false)


//var_dump(isset(null)); // PHP Parse error:  syntax error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM

Основная проблема PHP ровно та же, что и главная проблема музыки в России

Основная проблема PHP ровно та же, что и главная проблема музыки в России

Что-то эффект какой-то разный. Российская музыка в мире почти незаметна, а PHP в Web'е — номер один :) Да и во всём программистском мире где-то на 5-7 местах.

Нет у PHP проблем. isset - это встроенный функционал и иногда он помогает, но я как то в силу того что программирую и на других ЯП и правда не использую его для проверки существования переменной, обычно только для проверки наличия ключа в массиве. И что насчет судьбы php? Тебе достался говнокод, да это немного печально, сочувствую. Сейчас у PHP всё как никогда лучше, а именно есть адекватный менеджер зависимостей, есть репозиторий пакетов (packagist), есть PHP7, который привнесёт клевые штуки. Те кто в теме уже в курсе давно, что PHP это как узкоспециализированная под веб Java. Остальные же просто довольствуются тем что лепят говнокод используя подходы из 90-х. Ну пхп и убогим помогает, ничего плохого не вижу.

самая большая проблема это код в шаблоне, ИМХО

isset была нужна во времена register_globals, чтобы проверять переменные запроса, в чём собственно и состояло её первоначальное назначение. Ну а в наше время её можно попользовать в связке extract/isset внутри функции при передаче аргументов в хэше. Такой выкрутас был особо актуален ещё недавно, пока не запилили дефолтные значения аргументов функции и списки аргументов переменной длины. Но и сейчас бывает удобно использовать для функций с большим количеством аргументов, там, где в питоне используют keyword-аргументы, хотя, это уже экзотика.

русскоязычная говнопопса в СНГ - номер один, да и во всём попсовом мире где-то на 5-7 местах, тупой штоле

Комментарии как всегда ждут.

Да, я сам такой код видел. Если переменные «динамически» создаются и потом через isset проверяются ниже по коду то это очень плохой признак.

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

Последняя строчка - это феерично. Неужели в PHP действительно все так плохо?

php по-прежнему считает обращение к несуществующей переменной ворнингом?

Нет, что ты, иногда даже нотис не бросает, вообще молчит:

// max report error level
ini_set('display_errors', 'On');
error_reporting(-1);

for ($i = 0; $i < 10; $i++) {
    $undefinedArray[][][] = $i;
}
var_dump($undefinedArray);

PHP7, который привнесёт клевые штуки

Ты лучше скажи где PHP6 который обещал привнести поддержку утф искаропки?

PHP это как узкоспециализированная под веб Java

Упрлс? Ему до жавы еще срать и срать. Но ИМХО, пыху в ту сторону ходить не надо.

PHP7, который привнесёт клевые штуки

Вот эти чтоле «function foo(): array {»? Лучше бы сишный синтаксис приделали. Всеравно совместимость ломают. Нахрена велосипедить то?

лепят говнокод используя подходы из 90-х

А чего эти подходы до сих пор не выпилили из ядра пыха?

isset только для проверки наличия ключа в массиве

Тоже лепишь (так еще и некорректную проверку на наличие ключа) подходы из 90-х? Почему не написал как положено в этой твоей «веб Java»? Надо было создать класс имплементирующий аррайакцесс, аррайитератор, расширить методами проверки/возвращения, обмазаться эксепшнами конкретно для этой вот шняги, и потом только проверять на наличие ключа. Где это все у тебя?

адекватный менеджер зависимостей

Ты про композер который жрет гигабайты не в себя?

Ты лучше скажи где PHP6 который обещал привнести поддержку утф искаропки?

utf8 искаробки уже лет 15 как есть. Лично у меня переход на него не PHP лимитировал, а поддержка в MySQL. Как вышел в феврале 2004-го MySQL 4.1.1-alpha с поддержкой utf-8, так я с тех пор в PHP только с этой кодировкой и работаю :)

http://forums.balancer.ru/support/2004/02/t25205--perevod-forumov-aviabazy-na...

Поначалу проблемы иногда появлялись (регулярные выражения те же), но даже тогда они шли уже просто как глюки, а не как «отсутствие utf-8».

А уже пару мажорных версий php utf-8 идёт по дефолту вместо прежнего latin1, так что даже ничего в системном конфиге менять не нужно.

Лучше бы сишный синтаксис приделали

Он обратно несовместим с PHP.

Всеравно совместимость ломают.

В каком месте? o_O У меня местами прекрасно работает код, написанный 15 лет назад.

А чего эти подходы до сих пор не выпилили из ядра пыха?

Именно потому что обратная совместимость.

Ты про композер который жрет гигабайты не в себя?

Что за facepalm? Как у меня composer ненапряжно живёт на говнохостингах с 256Мб оперативки и сотней мегов свободного места? :)

Что там вообще может измеряться гигабайтами? o_O

utf8 искаробки

mb_* костыли? И, у mb_* костылей конечно же есть нативный аналог, например для http://php.net/manual/en/function.wordwrap.php ?

utf-8 идёт по дефолту вместо latin1, ничего в системном конфиге менять не нужно

Достижение уровня большой новости на ЛОРе.

сишный синтаксис обратно несовместим с PHP

Аааа, стопы не влезают в чугунные ботинки?

Именно потому что обратная совместимость

Т.е. новый код «function foo(): array {» взлетит на старом интерпретаторе?

у меня composer ненапряжно живёт на говнохостингах с 256Мб

Это смотря что ты композишь и где. Тебе хватает.

потому что обратная совместимость

Да, мы тут с коллегами ржали, запилить PHPPP/PHPC (пи-эйч-пи-пи-пи/пи-эйч-пи-си) с строгой типизацией, выпиливанием говносинтаксиса и заменой его си-подобным.

mb_* костыли?

А в чём костыльность, когда просто работает «из коробки»?

И, у mb_* костылей конечно же есть нативный аналог, например для http://php.net/manual/en/function.wordwrap.php ?

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

Достижение уровня большой новости на ЛОРе.

Ну да. В том же Питоне без указания кодировки с utf-8 по дефолту пока работы нет :)

Именно потому что обратная совместимость

Т.е. новый код «function foo(): array {» взлетит на старом интерпретаторе?

А... Так ты даже значение термина «обратная совместимость» не знаешь? Ок, проехали.

Злой ты человек. 😃

Написал один раз

Т.е. я спросил о нативности, а ты мне такой — она есть, а, ну да, для такого нет, ну напиши ))

В том же Питоне

Если уазать, то работать будет для всего и искаропки, не?

значение термина «обратная совместимость» не знаешь?

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

Почему злой? У меня просто есть аргументы, которые я расписал. А у тебя есть аргументы? Вон, у крон73 есть, с ним интересно.

Ты лучше скажи где PHP6 который обещал привнести поддержку утф искаропки?

Ниасилили. Слишком сложно. http://habrahabr.ru/post/138269/

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

И это ужасно. mb_* функции, ЕМНИП, привносит расширение mbstring. Когда для работы с юникодом в языке нужно подключать расширение — это, как мне кажется, не нормально. Почему я вообще должен дописывать часть функций сам? Мне приложение писать надо, а не лепить подпорки и костыли.

писать надо на С и ассемблере, всё остальное это проституция. сам эдик говорил.

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

Уахаха ))

mb_* функции, ЕМНИП, привносит расширение mbstring.

Это искоробочное расширение :) Ты ещё не поставь php5-mysql и скажи, что PHP не умеет работать с MySQL :)

писать надо на С и ассемблере, всё остальное это проституция

Си и ассемблер — это проституция. Писать нужно в машинных кодах.

...

Интересно, есть в теме тут ещё кто-нибудь из тех, кто писал _в машинных кодах_? :)

bullshit without tasks

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

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

Опенсорс же.

есть в теме тут ещё кто-нибудь из тех, кто писал _в машинных кодах_?

Ну я писал, за не имением в 92 году ассемблера для ZX Spectrum - не завезли в наши пампасы таких кассет...

По поводу mbstring не вижу никакой проблемы, наоборот, есть определённый плюс в том, что сразу понятно, рассчитан код на работу с utf или нет, т.к. всё равно некоторые вещи требуют специальной обработки даже в тех языках, где обычные строковые функции переключаются на работу с utf, например сортировка строк, для которой нужно в том же питоне как минимум использовать strcoll, а вообще говоря, подключать отдельную библиотеку, типа PyICU и т.п. А с другой стороны в тех случаях когда utf не нужен, можно обойтись более быстрыми ascii функциями.

java не опенсорс, и что? она прямо вся доделанная во всём?тоже дохрена костылей.

Проблема в том, что это именно расширение.

Ок. Запишем, что PHP не может работать с MySQL, не может рисовать через GD, не может качать по http через curl, не может работать с JSON и DOM... Запишем, что вообще ничего не может и успокоимся :)

Проблема в том, что это именно расширение

Это не проблема, т.к. это builtin «расширение», т.е. оно есть всегда.

Нужен полноценный юникод на уровне языка

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

Ты лучше скажи где PHP6 который обещал привнести поддержку утф искаропки?

Наверное там же где и Windows 9. Почему я должен знать это? Спроси у Расмуса. А насчет utf8, да знаешь из коробки вполне себе работает успешно. Ну тебе уже вон сказали.

Упрлс? Ему до жавы еще срать и срать. Но ИМХО, пыху в ту сторону ходить не надо.

Я что, сказал что он именно Java? Перечитай, я ведь указал именно на то, что он узкоспециализированный инструмент. Современный код на PHP очень похож на код Java или C#, в силу прихода полноценного ООП.

Вот эти чтоле «function foo(): array {»? Лучше бы сишный синтаксис приделали. Всеравно совместимость ломают. Нахрена велосипедить то?

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

Тоже лепишь (так еще и некорректную проверку на наличие ключа) подходы из 90-х? Почему не написал как положено в этой твоей «веб Java»? Надо было создать класс имплементирующий аррайакцесс, аррайитератор, расширить методами проверки/возвращения, обмазаться эксепшнами конкретно для этой вот шняги, и потом только проверять на наличие ключа. Где это все у тебя?

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

Ты про композер который жрет гигабайты не в себя?

У меня, честно говоря, не получалось еще наткнуться на подобного рода проблемы. Что ты с ним делал? Обычно в моих проектах тянутся фреймворк и десяток другой библиотек, бутстрап. Сдается мне у меня какой то косяк с конфигами cli интерпретатора или просто у тебя в проекте over9000 зависимостей.

Не передёргивай. Расширения имеют свойство отключаться. А строки — это то, что лежит в основе языка. Без mbstring я не смогу нормально определить длину строки, обрезать её или провести любые другие подобные операции. Велика вероятность получить мусор вместо вменяемого результата. PHP — высокоуровневый язык, так? Почему я тогда должен думать о том, какие функции выбирать для работы со строками, вместо того, чтобы просто взять и получить например для strlen('абв') 3, а не 6? Если мне вдруг станет нужно работать с байтами, я преобразую строку в набор байтов, как это можно сделать в третьем питоне к примеру.

Это не проблема, т.к. это builtin «расширение», т.е. оно есть всегда.

Пока кто-то не забыл флаг --enable-mbstring при сборке. Ну или намеренно не стал включать.

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

Ну я не знаю, что сказать. Смотри выше ответ крону.

Сомневаюсь, что те, кто её пилят, могут сказать, что эта фича неинтересно и мы её делать не будем. Или же как в случае PHP потратить впустую лет 5 (ну почти).

Расширения имеют свойство отключаться.

Ага. Например, отключиться может php5-mysql.

Без mbstring я не смогу нормально определить длину строки, обрезать её или провести любые другие подобные операции.

Без php5-mysql ты не сможешь обратиться к MySQL.

PHP — высокоуровневый язык, так? Почему я тогда должен думать о том, какие функции выбирать для работы со строками

Python — высокоуровневый язык, так? Почему я тогда должен думать о том, какие функции выбирать для работы со строками?