По слухам, сегодня должен состояться релиз 7.1. Поэтому хотелось бы немного оглянуться назад и посмотреть, а как же php вырос из набора костылей и подпорок в полноценный язык для веба. Прямо по шагам, т.е. по версиям. А в конце хотелось бы немного поразжигать поразмыслить о роли php в современной экосистеме.
Давайте мысленно вернемся во времена php4, когда получили своё развитие wordpress, bitrix и миллионы других CMS и домашних страничек.
Php до пятой версии можно было называть языком с натяжкой. Скорее это был хаотический набор функций, которые можно было быстро вызывать, чтобы выплюнуть данные из mysql в браузер. Там были зачатки ООП, но такие, что наверно лучше бы их не было.
Каждый второй сайт работал с включенными галочками magic quotes. Т.е. все переменные, которые прилетали от браузера магически экранировались. Что якобы позволяло их безопасно вставлять в базу данных. На деле же универсальным CMS приходилось это дело чистить (или оставлять как есть, в зависимости от настроек в php.ini). В общем мрак. Но для новичка якобы было “удобно”: вставлять всё, что прилетело в базу и не париться.
Соответственно, порог входа был крайне низким, достаточно было выучить функцию mysql_query и htmlspecialchars. Это привело к тому, что сайты на php стали делать абсолютно все: чуть ли не каждый второй студент был членом “веб-студии”.
Порог был низким, качество кода соотвествовало. Возьмите любой крупный проект, который начался в те времена, и посмотрите на его код. Страх, ненависть, боль.
Но потом появился php5
php 5.0 ( 2004 год)
Эта версия языка сделала огромный рывок в ООП. Появились модификаторы доступа (public, protected, private). Выделились статические методы (static). Появились интерфейсы. Деструкторы. Reflection API. Работа с исключениями. Магические методы __get и __set. Итераторы. ArrayAccess (чтобы можно было сделать объект, имитирующий массив). И многое-многое другое. По большому счету парни взяли, и многое скопировали из java, включая даже названия ключевых слов (extends, implements, try, catch и т.д.). Т.е. получилась динамически типизированная джава. Правда без неймспейсов.
Насчет типизации тоже был сделан шаг вперед, а именно type hinting. Т.е. в аргументах методов стало можно указать имя класса (или интерфейса), таким образом стал проверяться тип (хоть где-то!).
Появилось расширение SPL (набор интерфейсов и классов для решения стандартных задач).
После релиза у многих разработчиков случился форменный разрыв шаблонов, так как люди внезапно стали резко разделяться на два лагеря: те, кто умеют ООП и те, кто не умеют ООП и костылируют старые вордпрессы. Понятно, что многие и раньше (еще на php4) пытались работать с тем ООП что было, но тот велосипед с квадратными колесами не позволял по-настоящему развернуться.
Также в php5 раза в два выросла скорость. Короче, php5 — это был тупо отдельный новый язык.
php 5.1 и 5.2 (2006-2009 годы)
5.1 и 5.2 не принесли много изменений в сам язык, их было всего парочка: магические методы __isset и __unset (в дополнение к __get и __set).
К type hinting добавился еще и array. Т.е. еще один шаг к чуть более статической типизации. Хочу заметить, что с каждым релизом, похоже, идет попытка избавиться от магии.
Добавился встроенный интерфейс Serializable.
Некоторые улучшения в SPL и Reflection
В основном это перепахивание различных функций и багфиксы. Например, появилась функция json_encode
Очень важной фичей было включение PDO по умолчанию. Всё меньше и меньше людей используют mysql_query и SQL-инъекции в них.
php 5.3 (2009 год)
А вот версия 5.3 стала очередным прорывом в языке.
Самое главное — появились неймспейсы (аналог package в java). Это дало большой толчок к развитию различных библиотек и фреймворков. Через пару лет после релиза начал зарождаться менеджер зависимостей composer.
Появились лямбды и замыкания. К примеру, в java лямбды появились на 5 лет позже.
(а в c# они к тому времени уже 5 лет как были)
Появился оператор goto
Сокращенный тернарный оператор ?:
Появился оператор static для позднего статического связывания и магический метод __callStatic
php-fpm включен в ядро
php 5.4 (2012 год)
Здесь наконец-то полностью выпилены магические кавычки и register_globals. Т.е. с какой-то версии они были deprecated, а начиная с 5.4 их наконец-то грохнули. Кстати, интересный факт: на одной конференции Расмус Лердорф (создатель php) сказал, что голосовал против выпиливания magic_quotes, что на мой взгляд очень странно. Мне казалось, что все уже давно наелись этой магией по горло.
Также в этой версии было еще очень важное изменение: появились примеси (traits).
Добавлена короткая запись массивов, т.е. вместо Array(1,2,3) стало можно писать [1,2,3]
Также можно отметить появление разыменования массивов
foo()[0]и возможность сделать так:
(new foo)->bar()В type hint стало возможно исползьовать callable
php 5.5 (2013 год)
В 5.5 появились генераторы и ключевое слово "finally".
А также рызыменование литералов массива и строки:
echo [1, 2, 3][0];
echo 'PHP'[0];Оператор ::class для получения имени класса вместе с неймспейсом.
php 5.6 (2014 год)
Стало можно использовать выражения в константах.
Добавилась возможность делать функции с переменным количеством аргументов (...$params) и развертывание аргументов c помощью оператора ...
php 6 (никогда)
php 6 так и не вышел. Главный challenge этой версии был в поддержке UTF на уровне ядра (был выбран UTF-16). Но там оказалось столько работы, что после длительной разработки в итоге от идеи отказались. Как утверждают разработчики, если бы выбрали UTF-8, все было бы гораздо легче и был бы какой-то результат. Уж не знаю почему.
php 7 (2015 год)
Седьмая версия стала очередным прорывом в языке, сопоставимая с 5.0 и 5.3. Во первых, всё стало быстрее работать раза в два-три.
Во-вторых, в тайпхинтинг стало возможным использовать скалярные типы: int, string и т.д. А также задавать тип возвращаенмого значения метода. Причем, если в начале файла указать
declare(strict_types=1)то на попытку передачи float в аргумент, требующий int, будет выдан Fatal Error.
По сути это дает возможность писать на php почти что как на строго типизированном языке.
Добавлены операторы ?? и <=>
Появились анонимные классы, групповые декларации use, улучшены генераторы, убрана некоторая магия из преобразования строк в числа и прочее.
php 7.1 (сегодня)
Типы аргументов и возвращаемых значений можно пометить как nullable с помощью оператора?
например ?string
тип возвращаемого значения void. Т.е. если в таком методе будет return, то это вызовет fatal error
Замена list на []
т.е. будет возможна запись
[$a, $b] = [$b, $a];У констант класса появилась видимость (public, protected, private)
Обработка нескольких исключений сразу (как в java)
catch (FirstException | SecondException $e) Отрицательные смещения для строк "abcdef"[-2]
Асинхронная обработка сигналов pcntl_async_signals()
Полный список php7.1 уже доступен в мануале: https://secure.php.net/manual/ru/migration71.php
Что мы имеем в итоге?
В итоге мы имеем хороший язык для веба, у которого есть всё: фреймворки (Symfony, Yii и т.д), менеджер зависимостей и т.д. Но порог входа теперь совсем другой. Т.е. человек, который пишет на современном php, должен как минимум знать кучу ООП best practices, использовать фреймворки и composer, знать кучу фич языка и его расширений.
К сожалению, огромное количество php-шников до сих пор используют php как php4, и не хотят учиться. Именно из-за того, что порог входа был низкий, а теперь надо сильно перестраиваться. Всё это, мягко говоря, не улучшает репутацию языка.
В итоге работодатели ожидают дешевую рабочую силу (это ж "похапе", там дешевые программисты), а на деле при найме выходит, что для решения современных задач нужны современные программисты, а их сильно не хватает.
Вообще, хотелось бы обсудить перспективы php на будущее. Какие у языка есть киллер-фичи?
Т.е. после внедрения в язык кучи языковых конструкций, он стал не очень привлекательным для новичков (мне кажется, новичок скорее выберет go из-за простоты). Но при всём своём развитии (которое я очень сильно приветствую), php не дотягивает до языков кровавого энтерпрайза, таких как C# или та же java. Потому что типизация все же не совсем строгая, нормальной многопоточности считай нет, и всё еще есть костыли разных видов. Также нет дженериков, человеческой поддержки utf. Массив в php — это странная смесь массива и HashMap и т.д. Т.е. если в энтерпрайзной нише уже есть java/c#, то зачем там нужен php, который слегка не дотягивает?
Как вы думаете, есть ли своя ниша у php, и в чем она заключается? Я не для того, чтобы потроллить, мне правда очень интересно.
Комментарии (284)
NeoCode
01.12.2016 08:12+1Я хочу чтобы в мейнстриме появился нормальный компилируемый язык со статической типизацией для веб-разработки. Да, конечно что-то есть, можно хоть на си писать сайты… но это не распространено. А распространены именно динамически типизированные языки php, python, ruby и js. Интересно почему?
Об уровне — это чистая правда. Я не веб-разработчик, но когда в старые времена для каких-то целей нужно было создать сайтик (по сути простой веб-интерфейс для доступа к БД в локалке), я это сделал на «php4» вообще не задумываясь — настолько все было просто.
Что там творится теперь — мне непонятно. Уровень абстракции очень сильно вырос, количество абстрактных прослоек выросло, и это привело к тому что я «не чувствую» ни сложности алгоритмов, ни низкоуровневой структуры программы. То есть современные фреймворки работают, но их работа превратилась в некую магию, для полного понимания которой нужно, вероятно, глубоко изучить внутреннюю структуру фреймворков на самом низком уровне. Все ли к этому готовы?
Все руководства по фреймвокам сводятся к написанию «hello-world» сайтов практически без объяснения внутренней работы самого фреймворка. Я после безуспешных поисков такого глубокого руководства пытаюсь сам разобраться понемногу в свободное время, может статью напишу:)
prostofilya
01.12.2016 08:24+3Все руководства по фреймвокам сводятся к написанию «hello-world» сайтов практически без объяснения внутренней работы самого фреймворка.
Не скажу за все, скажу за django — туториал на офсайте неплохой, показывается и MVC и работа с данными, с шеллом, с админкой, после него можно курить сами доки, они очень даже классные.
Что там творится теперь — мне непонятно. Уровень абстракции очень сильно вырос
Ну естественно вырос, сейчас требуется не просто отображение каких-то статичных данных, и чтобы нормально въехать во все возможности фреймворка, нужно потратить такое же количество времени, как на изучение какого-то десктоп фреймворка.
OnYourLips
01.12.2016 09:04+5Я хочу чтобы в мейнстриме появился нормальный компилируемый язык со статической типизацией для веб-разработки.
Java, C#, PHP (PHP не компилируемый, но тайпхинтинг — тоже вариант статической типизации).
Эти три языка чаще всего и используют на длительных веб-проектах.
Все ли к этому готовы?
Кто не готов, может клепать в старом стиле и получать зарплату немногим выше, чем настройщики вордпрессов.
На таких новичков спрос всегда будет.
Просто язык повзрослел, и стали популярны технологии, требующие навыков профессионального программиста.
DexterHD
01.12.2016 12:49Go посмотрите. Уже 13 позиция в TIOBE индексе (по сравнению с 48 в прошлом году). Вполне себе «мейнстрим».
Нормальный, компилируемый, со статической типизацией, лишенных кучи ненужного синтаксического сахара.
naghtigall
06.12.2016 14:19Если вы про этот индекс языков — то там Go на 16 позиции.
http://www.tiobe.com/tiobe-index/
polifill
01.12.2016 13:27-1Я хочу чтобы в мейнстриме появился нормальный компилируемый язык со статической типизацией для веб-разработки
Существует.
И уже как несколько лет в мейнстриме у серьезных разработчиков.
В т.ч. в production очень серьезных контор (как Dropbox, к примеру).
Называется Go, golang.
Да, конечно что-то есть, можно хоть на си писать сайты… но это не распространено. А распространены именно динамически типизированные языки php, python, ruby и js. Интересно почему?
Потому что вы просто не знаете об использовании в крупных веб-проектах Go, Java, Scala, C#.
Почему не знаете — потому что не сталкивались.
Почему не сталкивались тоже понятно — ведь хоумпейджи на них крайне редко пишут.
Aleks_ja
01.12.2016 15:20+1Я не веб-разработчик, но когда в старые времена для каких-то целей нужно было создать сайтик (по сути простой веб-интерфейс для доступа к БД в локалке), я это сделал на «php4» вообще не задумываясь — настолько все было просто.
Что там творится теперь — мне непонятно.
Ничто не мешает и теперь на php7 накидать. Более того, и ваш старый код скорее всего будет работать.
calvin_rus
02.12.2016 09:29+1Вроде как часть расширений убрали, в частности mysql ( и это не большая проблема, там где это вынесено в отдельный класс, а если это бесконечные mysql_query, написанные неким индусом?) А такого кода на РНР просто море, в виду того, что «работает не трогай», и «Вась, там кнопочку выведи еще одну, что бы отчеты в эксель строило». Хотя, признаюсь, сидим на работе глубоко на 5.х, и пробовал на 7.0 проект перевести только на одной шабашке, именно с подключением к БД и были проблемы.
Конечно, накидать нечто подобное по новой не составляет проблемы, но лично мне подобные изменения (углубление в ООП) в РНР нравятся.
vanxant
02.12.2016 14:42+1Ну за mysql (при наличии pdo, mysqli и mysqlnd я уж не знаю, десяток лет точно) надо карать. Я думаю, через пару лет к этому и придёт, когда php5 хостинг будет в 2 раза дороже php7.
http2
02.12.2016 22:18+1А какая разница, что человек использует mysql, кроме mysqli?
Ну кроме того, что он не поддался хайпу?
Запросы выполняются? Все, отлично.
https://habrahabr.ru/post/316506/
Fesor
03.12.2016 00:21А какая разница, что человек использует mysql, кроме mysqli?
mysql_* функции удалены из php7+. А так ничего.
Запросы выполняются? Все, отлично.
все завязано на устаревший функционал? Все отлично.
M-A-XG
03.12.2016 01:03Так карать-то зачем? :)
Я написал обертку для вызовов mysqli_ ф-й из mysql_ функций для php7 и продолжаю писать в привычном стиле :)Fesor
03.12.2016 01:23+1продолжаю писать в привычном стиле :)
Если всю работу с данными вы изолировали, и SQL не размазан по всему проекту, то "карать" действительно незачем. Особенно если в "привычный стиль" не входят штуки вроде "интерполирую ка я айдишку в строку с SQL". Ну мол prepared statements, параметры и все такое...
M-A-XG
03.12.2016 14:03+1Я бы сказал, что если SQL размазан, то карать нужно независимо от того, mysql_*, mysqli_* или PDO. :)
Grox
01.12.2016 15:36+3А распространены именно динамически типизированные языки php, python, ruby и js. Интересно почему?
Потому что скорость разработки на них выше. Достаточно исправить исходный код и тут же получить результат, в отличии от компилируемых языков, где много времени тратится на саму компиляцию.Splo1ter
01.12.2016 16:31-1Вы случайно не под vax пишите ?)
Я понимаю что ядро linux будет не 15 минут компилироватся(хотя возможно я ошибаюсь и это происходит быстрее), но давно уже прошло время когда те же самые java/C#/C/C++ компилировались.VolCh
01.12.2016 16:45+1Теперь они интерпретируются? :)
worldxaker
02.12.2016 09:29да, .net core при разработке можно юзать именно что в режиме интерпретатора
Grox
01.12.2016 16:52-1Я вот слышал, что браузеры собираются сутки. Но это к слову.
Для примера, если вы почитаете интервью с разработчиками Facebook, то они как раз и упоминали большую скорость разработки, когда мотивировали отказ от других языков.
P.S. даже если проект будет собираться 1-2 минуты, это уже долго, потому что таких минут для всей команды будет набираться на полчаса-час в день на разработчика, а в переводе на суммарные затраты времени будет очень большим.
P.P.S. Да и зачем компилирование? Скорость скриптовых языков достаточно велика. Качество кода? С новыми версиями PHP можно писать надёжнее. А если будут весомые аргументы, то и сейчас есть компилируемые языки, которые можно использовать. Тот же Nginx не на PHP написан.Splo1ter
01.12.2016 17:12Есть ли ЯП которые имеют статическую типизацию и не компилируются? Я о таких не слышал.
С компилируемыми языками тут вопрос стоит не о скорости(о ней меньше всего парятся), а о качестве кода, т.к. в динамических языках или позволяющих использовать динамику очень сложно писать большие ынтырпрайз приложения) т.к. требования к качеству и безопасности кода там выше.Grox
01.12.2016 17:48+2Ну PHP в версии 7, как раз обладает возможностями статической типизации и не компилируемый. Честно говоря, я не вижу преград в создании транслятора компилируемых языков. Те же С и С++ могут быть сконвертированы в кода на JS во многих случаях. И ещё и JS приблизился к скорости выполнения компилируемых.
О качестве.
if (a = b) сработает также хорошо, как и if ($a = $b). От этого защитит разве что статический анализатор или warning компилятора (если он умеет). А стат.анализаторы есть и для PHP.
Возможностей же выстрелить в ногу, что на С, что на С++ и других компилируемых предостаточно. И скриптовый язык может быть даже безопаснее, потому что он в редком случае завалит(?) систему, приложение же на компилируемом языке может вызвать «BSOD».
Я пришёл в PHP из мира С и С++ и понимаю, когда говорят о качестве компилируемых. Банально, их изучение даёт больше понимания того, как работает железо, на котором всё это исполняется. Но на PHP тоже можно писать очень качественный код, особенно обзаведясь типизацией.
Melkij
01.12.2016 18:09> Есть ли ЯП которые имеют статическую типизацию и не компилируются?
SQL
Если в чистом виде SQL по вашим убеждениям не является достаточным чтобы являться ЯП, то есть ещё хранимая логика.
merlin-vrn
02.12.2016 08:56врут. Сутки собирается webkit-gtk, нормальные браузеры собираются за пару-тройку часов.
vanxant
01.12.2016 16:39+3Думаю, не в компиляции дело, а в доскональном прописывании интерфейсов.
Зачем, если в вебе можно «херак херак и в продакшн», и оно будет работать.
Помню дикую боль при разработке веб-морды на старой Java, когда для каждой долбаной кнопки нужно было создавать свой класс с единственным перегруженным методом онклик. А потом создавать экземпляр этого класса. Зачем?asdf87
01.12.2016 21:02«Помню дикую боль при разработке веб-морды на старой Java, когда для каждой долбаной кнопки нужно было создавать свой класс с единственным перегруженным методом онклик. А потом создавать экземпляр этого класса. Зачем?»
Это всего лишь вопрос синтаксического сахара для удобства разработки. Принципиальных проблем тут нет. Что касается именно Java, то это консервативный язык. Он долго перенимает инновации, поэтому к нему легко придираться в таких холиварных обсуждениях.
Serj_By
09.12.2016 11:28Так ведь Java. Чем плохо? Статическая типизация, сайты писать — запросто. Мейнстрим? Вот тут вопрос. Почему-то ее относят к «кровавому энтерпрайзу», вот даже автор этой статьи. Хотя абсолютно ничего «кровавого» я в Java не вижу. Не более и не менее, чем еще один язык программирования с широкими возможностями. Выучить ее в любом случае лишним не будет, так как возможности действительно очень широкие. Практически все, что может потребовать разработка — запросто. Веб — легко, десктоп — пожалуйста, мобилки — только Андроид, но все же (хотя тут не уверен, возможно есть и под другие платформы уже свои костыли, поправьте, если не прав).
varanio
09.12.2016 11:37Ну, насчет десктопа спорно. По-моему swing уже устарел морально. javaFX по слухам загибается тоже.
terryP
09.12.2016 12:42+1хотя тут не уверен, возможно есть и под другие платформы уже свои костыли
Есть как и конвертирование Java проекта с Андроида на Аpple, так и просто JVM для Аpple.
Ну, насчет десктопа спорно. По-моему swing уже устарел морально. javaFX по слухам загибается тоже.
Нет, можно делать и десктоп, просто на Java предпочитают делать вебприложения, так как обычно Java используют в бизнес секторе, а там порталы удобнее десктопов. В принципе большинство задач можно решить с помощью вебприложений, если приложение только для win, то лучше взять что-то вроде C#, если приложение требуется кросплатформенное, то пойдет и Java.
flancer
01.12.2016 08:18Слой REST/JSON-сервисов в web-приложениях, если удастся вывести PHP из сферы действия Apache/Nginx и поднимать как standalone сервер (типа ExpressJS, Tomcat/java, WSGI/python). Ну или в рамках Apache/Nginx запускать PHP-приложения со стадиями инициализации приложения, обработки запросов, завершения приложения (типа servlet'ов). Делать вот это все на каждый GET/POST запрос с web'а — весьма расточительно, не говоря уже о сборке HTML'а на стороне сервера. В web-разработке позиции PHP весьма сильны, но с фронта всех теснит JS — остается back.
Fedcomp
01.12.2016 09:46+3есть php-pm
flancer
01.12.2016 10:25Да, очень похоже на то, что нужно :)
<?php require 'vendor/autoload.php'; $i = 0; $app = function ($request, $response) use ($i) { $response->writeHead(200, array('Content-Type' => 'text/plain')); $response->end("Hello World $i\n"); $i++; }; $loop = React\EventLoop\Factory::create(); $socket = new React\Socket\Server($loop); $http = new React\Http\Server($socket, $loop); $http->on('request', $app); echo "Server running at http://127.0.0.1:1337\n"; $socket->listen(1337); $loop->run();
Fesor
01.12.2016 10:55Из минусов — на данном этапе он требует php-cgi для воркеров, что я считаю недостатком. Я понимаю конечно почему так было сделано — поскольку в некоторых дурных скриптах стоят проверки на SAPI, но если хочется именно через CLI — то надо писать свой менеджер процессов.
alekciy
06.12.2016 12:32Почему недостатком?
Имхо, менеджер в более менее серьезном приложении приходится в любом случае писать самому.
xotey83
01.12.2016 16:56+1А также есть amphp/aerys — не просто сервер, но и с супервизором (как php-pm)
Мне кажется, что это самый развитый проект http-сервера на PHP
merlin-vrn
01.12.2016 10:53вывести PHP из сферы действия Apache/Nginx и поднимать как standalone сервер (типа ExpressJS, Tomcat/java, WSGI/python)
uWSGI с php-плагином очень к этом близок
tribesman
01.12.2016 08:36+4Я сначала сидел на php потом зачем то, пересел на rails, а потом снова вернулся на php + Yii. Сейчас мне очень нравиться PHP + Yii, а RubyOnRails вспоминать не хочется.
tribesman
01.12.2016 08:47+1На php очень дешёвая инфраструктура, легко поддерживать проекты на Yii ( мне кажется, что именно благодаря рельсам на php появилось столько замечательных фреймворков), при этом на php 7 + Yii порог входа все же сильно ниже .Net
zorgzerg
01.12.2016 09:26+1Yii — отличен, и про порог входа верно сказано. Я, не имея никакого практического опыта веб-разработки быстро въехал, и даже начал что-то делать. Но надо сказать, что у Yii, все же, неплохая документация, хотя есть и сложные (для не профессионала, по крайней мере) моменты, этого не отнять
v-derckach
01.12.2016 11:05+7Ух ты! Сколько встречал историй ухода с php на Python+Jango или Ruby+RoR, абсолютно все они заканчивались словами «о php теперь и вспоминать не хочется!»
И вот впервые встретил хотя бы кого-то, кто сказал, что вернулся с рельсов на php и о рельсах не хочет вспоминать!prostofilya
01.12.2016 11:19+8А с наступлением рассвета все питонщики, рубисты, сишарперы идут на работу и пишут на пхп+битрикс ...)
dizews
01.12.2016 12:10я вам больше скажу, в последнее время, тенденция что ли формируется, обратный переход на php. Сужу по общению с работодателями, которые говорят: «мы переписываем с rails или даже java на php» Хотя может это связанно, опять таки, с относительной дешевизной рабочей силы.
jrip
01.12.2016 12:24Уходили просто в те времена, когда на PHP на самом деле было кошмарненько — большая часть проектов на самописных фрейморках, особо выделяемых общепринятых не было, те что были все допиливали по разному. В результате приходя в новый проект можно было слегка приуныть, понимая что прошлый опыт помогает лишь от части и нужно опять учиться использовать очередные инструменты, которые делают одно и тоже.
DieSlogan
01.12.2016 17:24+1Если уходили действительно, когда на PHP было кошмарненько, то приходя в Java/Spring сначала одуревали от сложности этой штуки, а потом говорили — вау, практически ничего не надо делать, само заводится и круто пашет.
Сейчас, соглашусь, переходить сейчас чуть проблемнее ибо те же фреймворки, только иначе.
vshemarov
01.12.2016 19:06+1Про тенденции сказать не могу, но знаю несколько проектов, которые изначально создавались на Руби, а сейчас переписываются на ПХП. Примечательно, что во всех случаях основным мотивом создания на Руби было то, что на нем «невозможно писать плохой код» (до сих пор популярное утверждение среди рубистов). Но потом оказывалось, что код-то, может, и красивый, но от плохого результата это не спасает, а найти людей на поддержку и сопровождение тяжелее и дороже. А на ПХП с его низким входом не только говнокодеры плодились, но и вполне себе грамотные программеры выросли
alekciy
06.12.2016 12:37Наверное сказывается выход PHP7 и информационный шум связанный с этим. Много обсуждений, разговоров. И он да, действительно получился достаточно вкусным. От расширения DS вообще пришел в полный восторг (нужны были множества, оказались, что они там работают даже быстрее, чем в Redis).
ls18
01.12.2016 09:27+3ИМХО, пока в PHP можно писать как хочешь(не используя ООП и кучу других печенек), то поток «вечных новичков» в PHP не уменьшится. Но есть вопрос: ведьPython тоже не сложный, так почему там такого нет?
Archon
01.12.2016 09:46+4Потому что на нём сложнее написать Hello World и мгновенно получить положительную эмоцию от того, что всё завелось. Порог входа в PHP действительно самый низкий из всех платформ на рынке. Можно просто положить файлик из одной строчки на копеечный хостинг и всё заработает само собой.
В тот же .NET, например, порог входа с точки зрения написания кода не особо выше, но всё равно зачастую новички могут не сразу врубиться, что и куда надо положить, чтобы страничка открылась.
Zazza
01.12.2016 10:27+3Часто, почему-то сравнивают с .net. Но копеечный хостинг и windows сервер с iis это разные категории.
Недавно проскакивала статься про delphi, и там было правильно подмечено, что огромное число разработчиков на delphi перешли на сторону .net. Те же кто испытывал «теплые чувства» к unix перешли на другую сторону и выбрали perl, php.
Про себя скажу, что я много лет проработал администратором разных unix, поэтому и php. И кстати python с django, но это спустя много лет, после php4 и затем php5 (как было правильно замечено, что 4 и 5 это разные, если не языки, то принципы и подходы). Сравнивать, что лучше python (или отдельно django) или php считаю не уместным, всё хорошо где-то на своём месте.
И еще вектор развития задаёт учеба. Раньше в институтах изучали pascal+delphi. Сейчас появилась тенденция преподавать python.
Еще роль играет география. Если на php вакансии есть везде, то c# это Москва и филиалы. А разные местечковые компании выбирают 1с-bitrix.
Так и получается, что php универсальнее и переживет много других языков, хотя идейным вдохновителем для других не был и не будет.Archon
01.12.2016 11:07+14У PHP есть ещё одно важнейшее преимущество, о котором многие профессиональные разработчики успешно забывают. Сайт на PHP — это просто набор скриптов, раскиданных по разным каталогам. Надо добавить на существующий сайт форум? Качаем движок форума, кладём его в /forum, всё мгновенно заводится. Клиенты попросили отдавать им какую-нибудь мелкую фигню в их формате? Не вопрос, пишем маленький скриптик, кидаем туда же, и он просто берёт и работает. Не надо перенастраивать сайт, не надо пересобирать весь проект, не надо ничего хитро проксировать, даже не надо ничего перезапускать, просто кладёшь файлик и он работает.
Поэтому никаких разумных альтернатив PHP для отдачи по HTTP кучи бессвязной фигни, не объединённой в общее понятие «приложение», я не вижу.Zazza
01.12.2016 11:39Ага, заказчики или люди из другого «лагеря» не понимают, почему я:
— «Не хочу подзаработать и сделать маленький сайтик на wordpress, там делов-то на пару часов»
или:
— «Как? Ты не знаешь „1С-Bitrix!?“
Php очень сильно расслоился на крайности между cms и symfony с doctrine. Ну и люди, там мечутся соответствующие, я бы еще третий лагерь, где-то между выделил — YII. Ничего не имею против, отличный инструмент, прям даже уникальный получился.ls18
01.12.2016 11:54Можно по подробней про Yii? В чем его уникальность? Это не попытка оспаривания, а чистый интерес. Сам сейчас работаю ~1.5 месяца с Yii2.
Zazza
01.12.2016 12:03Что на ум пришло (если подумать, можно еще придумать):
— порог входа ниже чем у того же symfony
— следует из предыдущего, удачно выбранные инструменты/функционал: приятный AR, ненавязчивый DI, хорошо и понятно структурирован внутри, без всякий сервисов, бандлов. Но если требуется, можно и закопаться в более advanced решениях
— много и очень много виджетов и плагингов, причём как низкоуровневых, так и для фронтенда
— достаточно хорошая поддержка и развитие, здесь же много информации в интернете
Ну и от себя, я очень не люблю виджеты, но они очень экономят время разработки. Мне не нравится структура проекта по умолчанию, но ее можно менять.
Zazza
01.12.2016 12:37Решил добавить: я прохладно отношусь к yii. За то, что для большинства разработчиков это первый фреймворк, они не знаю паттернов, антипаттернов, psr. Продолжать чужой проект на этом фреймворке — боль, прям как во времена php4. Но тогда я был моложе и лезть в чужой код было неким experience.
0x9d8e
01.12.2016 16:08Вот я такой разработчик. Два-три года писал почти только на собственном CMF компании, перерос его и больше не хочу с ним работать над проектами «сложнее полугода». До этого пару лет писал либо на всяких вордпрессах, либо на голом php. В ближайшее время собираюсь начать проект на YII2 и немного беспокоюсь о том, что буду сильно велосипедить. Большинство паттернов и антипаттернов описание которых встречал вызывали реакцию «эх, это всё уже описано, а я так долго сам к этому шел через все грабли». К PSR кмк мне просто привыкнуть нужно, тем более, что к некоторым вещам оттуда как раз сам начал приходить.
Но беспокоит то, что не знаю лучших практик и рискую вляпаться. Беспокоит, что не знаю библиотек, расширений и, скажем так, практики их применения т.е. какие там есть неявные проблемы, нужно ли заранее к этому свои обёртки написать или можно считать «верным клинком». Не знаю кода фреймворка «в глубину» и сложности которая стоит за вызовом каждого метода.
Толкового описания таких вещей не попадалось, а сам могу это всё приобретать ещё год-два.
Fedot
03.12.2016 02:23Серебренной пули нет.
Идеально в твоём случае попасть в хорошую команду, где есть люди с понимание и опытом.
Вот я не очень люблю Yii, из за того что мне кажется он уж слишком мало пропагандирует best practics программирования, типа SOLID.
При этом я не могу сказать что, например, Symfony это прям то что нужно что бы эти практики постичь.
Идеально на мой взгляд писать код так что бы он не зависил сильно от фрэймворка. Т.е. когда вся бизнес логика заключена не в ActiveRecord модели, как часто бывает как раз в Yii, и не в контроллерах, а в отдельном месте, и уже для этой логики используется обвязка для использования фрэймвоком этого когда.
А вот как это написать, может сказать только опыт и хорошая команда, в которой такие вещи можно обсудить.0x9d8e
05.12.2016 21:03+1Насчёт отделения кода от фреймворка и библиотек как раз думал. Раз уж не я один такой, то и сомнения прочь. Спасибо. upd: Сейчас вспомнилось как прошлой осенью очень пожалел, что не делал так.
А с командой печаль. Сейчас, можно сказать, один работаю (если клиента, ПМ и маркетологов не считать). Иногда перед кем-то из удалёнщиков в роли живой документации и справочника «а как тут вот такое сделать?» выступаю, вот и всё взаимодействие. Можно было бы место работы сменить, да не хочется, полюбил уже всё. Так что как всегда всё самому.Fesor
05.12.2016 21:25+3Как жаль что люди не собираются в уютных чатиках и не филосовствуют на тему "как делать хорошо".
0x9d8e
07.12.2016 14:45Сидят. Сижу в таком чате по D https://telegram.me/dlangru
Можно и по PHP такой создать, но мне кажется там бардак будет.Fesor
07.12.2016 16:46+1https://telegram.me/prophp7 — тут душевненько. Ну и там есть смежные ссылки еще на чатики забавные.
zugo
01.12.2016 12:15+1Вы, кажется, застряли в 90-х. В любом современном PHP-приложении, как правило, единая точка входа и «нормальный» роутинг.
varnav
01.12.2016 15:15+1Я примерно то же самое писал несколько месяцев назад, но был заминусован. :)
PQR
04.12.2016 16:44+1Отлично подмечено про отдачу кучи бессвязных данных по HTTP не объединённых в «приложение». PHP скрипты по разным папкам — это же микросервисы!
edogs
01.12.2016 12:12пока в PHP можно писать как хочешь(не используя ООП и кучу других печенек), то поток «вечных новичков» в PHP не уменьшится
Нас всегда удивлял этот «парадокс».
Хочется сложностей? Выбирай яву и ныть по поводу наличия новичков не надо будет.
Что за то ли эгоизм, то ли садомазохизм — выбирать язык где новичков по определению много, а потом ныть по поводу их наличия и требовать «усложнить» язык, что бы новичков оттуда выгнать?
Типичное «залез в монастырь со своим уставом». Ну хочешь сложного языка — выбирай сложный, зачем выбирать простой и прогибать его под себя требованиями усложнить?ls18
01.12.2016 14:01А если в твоем городе есть вакансии только под этот язык? В том числе и джуниор позиции? И уехать никак?
edogs
01.12.2016 14:04+7Тогда возможно стоит купить в магазине книгу об интернете и узнать наконец о возможности удалённой работы. Особенно если речь о веб-вакансиях.
p.s.: «уехать никак» это всегда не более чем повод остаться, когда уезжать не хочется. Если Вы конечно не в колонии поселении отбываете.ls18
01.12.2016 15:48Кто же удаленно возьмет на работу человека без опыта?
vedenin1980
01.12.2016 17:31+4Фриланс это тоже удаленная работа, а в фрилансе и без опыта можно получить проект вопрос только в оплате.
Dromok
04.12.2016 00:42Легко. Создайте пару проектиков, аля магазинов, чисто для себя. И ставьте их в портфолио. Вот и опыт уже есть и легче искать заказы. Я лично уже несколько лет только за счет фриланса и живу и абсолютно пофиг где территориально находиться, лишь бы интернет нормальный был.
Fesor
04.12.2016 02:31Желательно еще дать эти проектики на ревью (они ж для себя, не под NDA). Благо нынче сложностей с этим нет.
Dromok
04.12.2016 02:37-1Если цель зарабатывание на фрилансе, то рефакторинг это лишнее. Тут главное побыстрее наклепать то что хочет заказчик, а качество кода второстепенно. Чем меньше потратишь на проект времени, тем больше в итоге заработаешь. Я лично не парюсь над качеством кода, поэтому код никогда не рефакторю. Правда у меня школа хорошая была — несколько лет в иностранной компании проработал, где делали ревью всего моего кода, и отправляли на рефакторинг если что-то не нравилось. Поэтому имхо у меня сейчас получается достаточно качественный код, так как натаскали меня, но качество кода вообще для меня на десятом месте.
Fesor
04.12.2016 11:34+3Если цель зарабатывание на фрилансе, то рефакторинг это лишнее.
Смотря что подразумевать под "рефакторингом". Речь идет о поддержании уровня технического долга на нужном уровне. Если говнокод изолирован — он не приносит много боли. А без опыта "изолированности" не выйдет.
Правда у меня школа хорошая была
Я рекомендую вам, когда вы даете подобные советы, начинайте с этого. Когда опыт есть и есть понимание "что есть хорошо и что есть плохо, и когда нужно делать плохо" — это одно. А когда новичку говорят "да пофигу на качество главное фигачить побольше" потом начинаются проблемы.
Именно о том что бы "натаскать" и был мой совет. Написали проект, скинули на ревью. Или попросить какого-нибудь человека "внести изменения в требования" что бы проверить насколько код плох. Что бы не услышать потом от заказчика "почему так долго? Почему так много багов? Это ж просто кнопку добавить нужно было!"
ls18
04.12.2016 09:13А можно узнать, на чем вы пишете и на какой бирже работаете(вангую Upwork)?
Dromok
04.12.2016 16:45Yii2, fl.ru. Честно, не понимаю почему на хабре эту биржу не любят. Одно дело, что качество кода их сайта низкое, но ведь не ради этого фриланс биржами пользуются. Но зато заказов там навалом, поэтому там и сижу. Единственная русскоязычная биржа с таким количеством заказов. Upwork пробовал, но там конкурировать с индусами очень сложно и как не парадоксально но на fl.ru в этом плане всё на порядок лучше, т.к. практически сразу реально найти заказ.
edogs
04.12.2016 23:47почему на хабре эту биржу не любят
Несколько взломов с раскрытием данных, неадекватное разрешение СБР, конские тарифы на всё, мониторинг личных сообщений администрацией, безосновательные задержки выплат денег и так далее — можете почитать на фл.ру в блогах отзывы пользователей.
Ах да, не можете, когда пошло много объективных негативных отзывов в блогах — их снесли на фиг безвозвратно.Dromok
04.12.2016 23:57Ну, я не спорю, не без недостатков конечно. Но факт остается фактом, там сейчас больше всего заказов в русскоязычном сегменте, поэтому особо выбирать не приходится. По раскрытию данных, у меня там нет никаких личных секретных данных, кроме яндекс кошелька для вывода денег, поэтому я особо и не опасаюсь. Выплату лично мне еще ни разу не задерживали, даже впервые о такой проблеме слышу. Лично для меня единственный недостаток это конские тарифы на «ПРО», а в остальном жить можно.
edogs
05.12.2016 00:05А зачем зацикливаться на русскоязычном сегменте, тем более с многолетним стажем в иностранной фирме? Иностранные биржи во многом лучше.
Раскрытие личных данных сыграло роль не самим фактом раскрытия, сколько полнейшим бардаком снизу доверху который этот взлом вскрыл.
А для нас лично мониторинг ЛС администрацией, при чем не особо скрывавшийся, поставил жирнющий крест на проекте.
Хотя в свое время мы были достаточно активными его пользователями.Dromok
05.12.2016 00:18Ну пока есть пул постоянных клиентов, плюс новые клиенты появляются, поэтому особой необходимости, по крайней мере сейчас, уходит на запад нет. Ну и общение на иностранном языке лично у меня вызывает дискомфорт, не смотря на то, что в иностранной компании приходилось постоянно писать отчеты на английском языке. То есть просто личные предпочтения и пока особой потребности в западных заказчиках нет.
edogs
05.12.2016 00:43есть пул постоянных клиентов
Так и работать с ними напрямую, а не через фл.
необходимости, по крайней мере сейчас, уходит на запад нет
В нулевых не было смысла работать на россию, на западе платили на порядок больше. Постепенно уровень оплаты выровнялся, где-то к 8 году был достаточно близок, но 14 год отбросил российские уровни оплаты в 2 раза.Dromok
05.12.2016 00:49Ну со старыми клиентами напрямую и работаю. Новых же нахожу на фл.ру.
Да, я в курсе про цены. Но как выше писал, мне было очень сложно на Upwork конкурировать с индусами, а всё что в итоге предлагали даже у нас стоит дороже. Поэтому для себя особого смысла работать на запад не вижу, если только найти нормальную компанию и работать чисто на нее удаленно.
elmm
01.12.2016 15:29-1Интересно, а что может быть причиной прям что «уехать ни как»? (кроме как ни хочется)
Dromok
04.12.2016 02:43Имхо, не мало причин может быть. Лично я цель — «уехать», никогда не ставил. Но, например, у меня жена ни в какую не хочет уезжать жить далеко от родителей, поэтому даже если бы я захотел уехать, это было бы очень сложно осуществить из-за жены :)
fishca
01.12.2016 09:39Именно из-за того, что порог входа был низкий, а теперь надо сильно перестраиваться.
Скорее из-за банальной лени. Кто хочет идти вперед, тот не стоит на месте. Наблюдается та же самая песня в мире 1С при переходе от использования обычных к управляемым формам. Кому-то удобнее сидеть в теплом и обжитом болоте, а кто-то перестраивает себя и свое окружение.
XXXXPro
01.12.2016 17:07Есть еще один вариант: за эти годы разработчик выработал определенные привычки написал себе собственный мини-фреймворк, которого для задач его уровня вполне хватает, и переучиваться на большие смысла нет: в плане результата получаем примерно то же, но свое все же удобнее тем что свое. (Мой случай как раз.)
Fesor
01.12.2016 21:15+3Вы поддерживаете все написанные вами проекты? Если да — то ок. Если нет, то для "других" разработчиков "ваше" будет "чужим" и чем больше вы делаете "для себя" тем хуже вы делаете бизнесу, внося огромные риски при поддержке. Да, риски могут не оправдаться (вдруг "ваше" на самом деле неплохое), но всеже.
DmitryKoterov
01.12.2016 10:04+7Ну следующим шагом должен быть уже async-await, наконец. Ядро почти к этому готово, осталось event loop встроить в язык, планировщик и библиотеку примитивов для кантования промисов туда-сюда. (Надеюсь, их назовут промисами здесь.)
xotey83
05.12.2016 02:06Не думаю, что async/await появится раньше версии 8.0
В 2015-м году было обсуждение в php internals. Длинное, тяжёлое.
https://www.mail-archive.com/internals@lists.php.net/msg80837.htmlDmitryKoterov
05.12.2016 07:49+2Ну почему оно «тяжелое», вроде бы обычный и даже типичный спор между теми, кто понимает, о чем идет речь, и теми, кто не очень. Главное, Дмитрий Стогов настроен позитивно (как мне показалось). Надеюсь, что все же реализуют в первую очередь из следующих больших вещей, потому что иначе опасно… скоро язык без async-await будет так же восприниматься, как язык без… в общем, как Фортран. :)
merlin-vrn
01.12.2016 10:50+6Следующим шагом должна стать нормальная, последовательная библиотека. С последовательным порядком аргументов. С последовательным наименованием, а не mysql_query и htmlspecialchars. Не быть тонкой обёрткой над C, и вообще с нормальными абстракциями, а не mysql_real_escape_string. С нормальными обобщениями, а не кучей функий sort/ksort/krsort/usort и так далее.
Пора чистить мусор и выкинуть вот это всё легаси. Тем более, раз уж всё равно порог входа вырос, как вы утверждаете.
varanio
01.12.2016 11:09+4Для баз уже все ползьуются PDO
А вот сортировка да, там всё хаотично
san4ez
01.12.2016 11:17в PDO тоже есть щепотка хаоса, которая вынуждает использовать ту же доктрину, например.
v-derckach
01.12.2016 11:18С одной стороны я приветствую приведение всех тех тонн функций к консистентному виду. Как сказал один программер:
array array_filter ( array $input [, callable $callback = "" ] )
array array_map ( callable $callback, array $arr1 [, array $… ] )
Это нельзя понять. Это можно только запомнить
С другой стороны это будет уже не php. Сейчас ещё довольно многие скрипты, написанные под php4, можно запустить под php7.1. Да, скорей всего придётся поправить deprecated и т.д.., но переписывать КАЖДЫЙ вызов КАЖДОЙ функции не придётся. А в случае такой радикальной чистки авгиевых конюшен придётся править и все-все исходники, написанные даже под 7.1. На такой радикальный и резкий слом никто не пойдёт.merlin-vrn
01.12.2016 12:12Это переход по смыслу эквивалентен переходу на Py3. Да, некоторое, довольно длительное время, будет два варианта, в старый не вносить новые фичи, чтобы разработчики потихоньку переходили на новый.
v-derckach
01.12.2016 12:49+1Вот, мне кажется, пример питона как раз (в том числе) и удерживает создателей языка от такого резкого масштабного изменения. Причём, раз уж его не сделали в php7, когда всё равно резко и масштабно многое поменяли, мне кажется, уже и не сделают. Революционно не сделают. Возможно, сделают эволюционно, за много версий.
Akdmeh
01.12.2016 13:22Всегда думал: а что мешает создать параллельно специальные объекты для управления стандартными типами.
К примеру:
<?php $var = array(5, 444, 121); $var_obj = new SplArrayWrapper($var); $var_obj->map('someFunction'); ?>
То есть, создать специальные оболочки, построенные более грамотно и последовательно, но при этом не нарушающие совместимость?
Ну, как минимум в моем примере идет оверхед на создание нового объекта, но все же, что мешает применять похожий подход?
Я понимаю, подобную оболочку можно написать за пару часов на PHP, но намного большей производительности можно было бы достичь, если написать код на C.
Недостатки, которые я вижу — это еще большая фрагментированность, так как часть кода будет на новых функциях, часть — на старых, и при этом будут возникать кое-какие различия между ними в принципах работы…
Но все же, это лучше, чем рубить с плеча совместимость со старым кодом.
Ну или мириться с тем, что без подсветки параметров функций никогда не можешь быть уверенным, где haystack, а где — needle, что раздражает в современном PHP чуть ли не больше всего
MetaDone
01.12.2016 13:26https://github.com/nikic/scalar_objects
подобное уже естьAkdmeh
01.12.2016 13:30+1Да, конечно, это интересная реализация и уверен, существует с десяток отличных библиотек на PHP. Но это — расширения и внешние библиотеки, а я размечтался о подобном в стандартной поставке PHP и написанное на C.
Fesor
01.12.2016 11:35+4функции аля mysql_query и mysql_real_escape_string были удалены из PHP еще в версии 7.0.
Не быть тонкой обёрткой над C
То есть предлагаете реализовать стандартную библиотеку на PHP? Не ну можно, но это тогда ждем JIT.
С нормальными обобщениями, а не кучей функий sort/ksort/krsort/usort и так далее.
А что именно вам тут не нравится? У каждой функции свое поведение. Нужно сортировать ключи — юзаем ksort. Реверсивная сортировка по ключам — rksort.
Если вам не нравится — вы всегда можете сделать так:
// std.php namespace array { function reverseKeySort(iterable $array): iterable { \rksort($array); return $array;} function keySort(iterable $array): iterable { \ksort($array); return $array); function split(iterable $arr, ?string $delimiter): iterable { /** ... */ } function join(iterable $arr, ?string $glue): string { /** ... */ } } namespace str { // по аналогии }
Я часто вижу вот такое вот "надо переименовать" но никто не переименовывает почему-то.
merlin-vrn
01.12.2016 12:18-1Функция сортировки должна быть ОДНА и она должна быть универсальной, с сигнатурой вида:
sort(seq, compare_func)
Порядок сортировки, способ сравнения аргументов (что там, массив целых? Массив хешей и сортируем сначала по полю "size" а потом, если совпало, по полю "weight"? Что угодно) задаётся compare_func, которая принимает два объекта и для них выдаёт ответ: 1 если arg2 должен стоять после arg1, 0 если они равны и -1 если arg2 должен стоять до arg1 в отсортированном массиве.
Для PHP есть примечание — в нём массивы — не массивы, а смесь из массивов и словарей, поэтому в данном случае у коллбек-функции может быть не два, а четыре аргумента — k1 v1 k2 v2, где k — ключ аргумента, v — значение; остальное по-прежнему.
А уж если вспомнить, что есть лямбды, так этот подход вообще идеален. Они как раз и придуманы специально для таких случаев.
varanio
01.12.2016 12:30вообще-то в php уже есть usort
правда нет стандартных compare_func для неёmerlin-vrn
01.12.2016 12:36В общем, для того, чтобы стало хорошо, надо теперь убрать старые костыли. Ну и да, стандартные функции сортировки стоит запилить. И хорошо бы, чтобы они в свою очереь всё-таки были параметризуемые.
Fesor
01.12.2016 12:50Функция сортировки должна быть ОДНА и она должна быть универсальной, с сигнатурой вида:
Ну так сделайте обертку на PHP и распространяйте как composer пакет. Вам же никто не мешает.
А уж если вспомнить, что есть лямбды, так этот подход вообще идеален.
Еще бы каррирование нормально можно было бы делать, вообще б зажили. А еще что бы лексические скоупы а не "один скоуп где все живет и локальный куда надо через use явно копировать".
michael_vostrikov
01.12.2016 13:28+1Думаю, лучше наоборот сделать — привести язык в порядок, и сделать composer пакет или расширение, которое включает старые названия.
franzose
02.12.2016 09:23В семёрке (только на ней проверял) можно осуществить такой вызов:
(func(...$args))(...$args);
То есть почти как в JavaScript, но с дополнительными скобочками.
MAXInator
13.03.2017 16:45Так в чем идея-то? Разве они не собираются продавать ровно то же самое, только планшет в комплекте идти будет?
Fesor
01.12.2016 21:30// Client.php // ... public static function byStatusAndNameComparator(Client $a, Client $b) { if ($a->isVip() === $b->isVip()) { return $a->name <=> $b->name; } if ($a->isVip()) return -1; if ($b->isVip()) return 1; }
Ну и где надо отсортировать
usort($clients, [Client::class, 'byStatusAndNameComparator']);
что-то в этом духе.
Ну и да, всегда можно сделать что-то типа linq или вообще дикость, сортировать средствами sql.
Mistx
13.03.2017 17:04+1А разве носимые устройства дополненной реальности не перспективнее? Ясно же, что голограммы — это сложно и очень дорого
SerafimArts
01.12.2016 21:16+1Это есть и в обычном php в веточке jit в репозитории от zend tech, внутри расширения opcache =)
paratagas
01.12.2016 11:58+2На мой взгляд, порог входа в PHP в целом вырос из-за того, что получили широкое распространение фрэймворки типа Symfony, Laravel, Yii и др., которые побуждают писать красивый код в ООП-стиле и изучать лучшие практики ООП. Причем фрэймворки активно и своевременно обновляют свои версии под новые версии PHP. Но это верно в основном только для PHP-фрэйморков. Если взять тот же Wordpress (или некоторые другие CMS), то ситуация здесь иная. Глядя на код ядра CMS в некоторых местах и многих плагинов под него иногда волосы дыбом встают. Там просто «лапша» из HTML и PHP, смешанного в самых неожиданных местах. Плюс в качестве основной версии языка выбирается не самая свежая, а 5-10 летней давности, потому что иначе теряется обратная совместимость. В целом экосистема PHP в последние годы переняла лучшее из опыта других языков и платформ и (что радует!) продолжает это делать.
am-amotion-city
01.12.2016 12:00Как утверждают разработчики, если бы выбрали UTF-8,
все было бы гораздо легче и был бы какой-то результат. Уж не знаю почему.Потому что сам код в UTF-8 и ASCII ничем не отличается, а в UTF-16 нужно полностью переписывать парсер, которому теперь прилетает два байта на каждый char.
Rastishka
01.12.2016 14:28Зато в UTF-16 всегда прилетает 2 байта, а в случае UTF-8 может прилететь как 2, так и 1 байт, как повезет.
Поэтому мне тоже кажется, что проще работать с UTF-16 чем с 8, и я тоже удивлен почему разрабы считают иначе.
Кто в теме, может объяснить?
pacaya
01.12.2016 14:52Не всегда. Иногда символ может выражаться двумя 16-битными словами https://ru.wikipedia.org/wiki/UTF-16
Melkij
01.12.2016 14:52+2Почему всегда? В utf-16 же может прилететь один символ в 4 байта.
Фиксированная ширина юникода — это только UTF32
В utf8 может существовать символ из 1, 2, 3 или 4 байт. Последний ли это байт в последовательности — определяется по крайнему биту (старшему или младшему — простите, я их вечно, откуда их надо считать)
Fesor
01.12.2016 17:00Поэтому мне тоже кажется, что проще работать с UTF-16 чем с 8
Почитайте почему PHP6 не взлетел
vanxant
01.12.2016 12:00+2В 7.1 приняли очень спорное решение выпилить настройку mbstring_overload. Кто не в курсе, она прозрачно заменяет однобайтовые строковые функции на многобайтовые.
До сих пор юзается куча легаси-кода, которая не знает про многобайтовые кодировки, но с этой магией нормально работает. Да что там легаси, тот же битрикс штатно работает на этой фигне.
Самое плохое, что нормальной замены до сих пор нет. Есть куча корявых функций из расширения mbstring, типа mb_substr вместо substr. Но оно не является нормальной заменой, так как а) для ряда функций типа регулярок (тот же preg_replace) замены 1-в-1 просто нет; б) часть вещей типа строка-как-массив ($str[2]) в принципе не заменяемая и в) заменить все строковые функции из всех используемых либ, шаблонов и т.д. — то ещё развлечение на тему рефакторинга.
То есть я бы понял, если бы они сначала запилили нормальные многобайтовые строки в ядро, а потом уже воевали с костылями. Но нет.
Поэтому, мне кажется, PHP надолго застынет в версии 7.0.Melkij
01.12.2016 14:55Тот же preg_replace умеет сам в юникод. Модификатор u только указать
vanxant
01.12.2016 16:18Особенно качественно он в него умеет, если таки включен mbstring.func_overload
(дисклеймер: не пытайтесь это повторить в реальном проекте)
batyrmastyr
02.12.2016 14:11+1Вот видите, без подмены функций одной проблемой меньше )
А с третьим пунктом: увы, неизбежная расплата за изначальную завязку на костыли.
Эх, ещё бы setlocale кто-нибудь догадался выпилить.
alekciy
06.12.2016 12:49Я бы еще дополнил, что в этом наборе функций есть много баг которым уже по многу лет, но не исправлены до сих пор (с ходу что вспоминается, это перевод регистров букв). И получается, что вроде начинаешь использовать, наталкиваешься на такую багу, плюешься и допиливаешь в свое приложение фикс. Потом проходит время, уже и минорных версий несколько сменилось, начинаешь юзать и опять бац… баги все там же. В общем да, хочется уже нормально с юником работать из коробки.
dimack
01.12.2016 12:16+4Мне кажется, PHP жив и будет пока жить, потому что за эти лет 15 накопилась огромная база написанных сайтов, к тому же выросло большое количество PHP-разработчиков. Новые проекты начинают писать на PHP, потому что найти среднего уровня разработчика не так сложно и стоить он будет в среднем дешевле.
PHP сейчас пожинает плоды так сказать своей былой и бурной популярности.
Но эта гонка языка за Java ни к чему хорошему не приведет. Разработчики обучившись ООП, DDD, TDD итп в PHP потом начинают переходить на сам Java, потому что там возможностей на порядок больше. А те, которые хотят что попроще, смотрят в сторону Gо, Python, может JavaScript.
Поэтому с трудом верится в светлое будущее PHP. А вспомнить его исходники и муки написания расширений(по сравнению с ffi того же Python), так вообще перекреститься хочется.Aleks_ja
01.12.2016 16:22+2Знаю людей которые, в своё время, отказались переходить на Java и решили сменить место работы, когда проекты на php закончились.
Лично мне, когда нужно написать какой-то код на Java — жутко бесит. Как-то переносил кусок кода из Java в PHP — в итоге, задумавшись, строк 100 Java кода заменил одной строкой PHP.terryP
01.12.2016 17:36Лично мне, когда нужно написать какой-то код на Java — жутко бесит. Как-то переносил кусок кода из Java в PHP — в итоге, задумавшись, строк 100 Java кода заменил одной строкой PHP.
Такое бывает только если плохо знать Java (и хорошо на PHP), на ней тоже можно писать быстро и коротко, другое дело что для этого нужно её довольно неплохо знать.
VolCh
01.12.2016 16:44Разработчики обучившись ООП, DDD, TDD итп в PHP потом начинают переходить на сам Java, потому что там возможностей на порядок больше. А те, которые хотят что попроще, смотрят в сторону Gо, Python, может JavaScript.
Вы не поверите, но есть и те, кому множество возможностей Java (как вариант C#) кажутся излишними, но тянущими лишний оверхид (хотя бы в виде необходимости компиляции), но «попроще» тоже не устраивает, хочется многоуровневых абстракций, инкапсуляции, сокрытия и т. п… Из скриптовых языков PHP больше всех, субъективно, подходит для ентерпрайза и как язык, и как экосистема. Только одна Doctrine даёт огромную фору по сравнению с другими скриптовыми языками. В экосистемах Ruby и Javascript ничего подобного нет, в Python — похожа sqlalchemy, но по защите данных PHP уже как язык отрывается.
dmtrrr
01.12.2016 17:15-18PHP как был fractal of bad design, так им и остался. Делать на нем что-то можно, но не нужно.
dmtrrr
02.12.2016 11:56-9Минусующие, вы хотя бы понимаете, что у вас стокгольмский синдром?
Anakros
02.12.2016 12:34+3А у вас отсутствие не только весомых, но и аргументов вообще. Зачем был написан комментарий?
dmtrrr
02.12.2016 17:29-3Все аргрументы давно известны: PHP: a fractal of bad design
PHP имел понятную нишу в эпоху shared hosting, сейчас смысла в этом «языке» нет.xotey83
02.12.2016 19:32+2Статья 2012-го года. С тех прошло больше 4-х лет. С тех появились вышли версии 5.4, 5.5, 5.6, 7.0, 7.1
PHP шагнул далеко вперёд.
Нет, ну некоторые момент остаются актуальными: неконсистентная стандартная библиотека функций, неконсистентная последовательность аргументов (haystack-needle). Но вещи, которые там описаны постепенно становятся неактуальными. Посмотрите сколько было задепрекейчено к релизам 7.0, 7.1, 7.2
И это всё постепенно отпиливается.
Да, увы, тяжёлое наследие прошлого не даёт возможность сразу всё исправить и сделать красиво ибо тогда язык постигнет та же ситуация, которая сложилась вокруг раскола Python 2/3.
Но постепенно всё будет причёсано.
Зря вы так яростно апеллируете к этой уже очень старой статье.
З.Ы.
Очень надеюсь, что когда-нибудь этот RFC воплотят в жизнь (скорее всего, к версии 8.0): https://wiki.php.net/rfc/consistent_function_namesdmtrrr
05.12.2016 10:31-1Есть кривая технология, которую пытаются выпрямить.
Зачем тратить время на изучение/применение кривой технологии, если можно взять что-то сразу нормально сделанное?merlin-vrn
05.12.2016 12:18+2Да любая прямая технология начиналась с кривого глючного hello, world-а. Если PHP выпрямят, будет только лучше. А фанатизм вида "говно всегда останется говном" как раз наоборот, ни к чему хорошему не приводит.
dmtrrr
05.12.2016 13:08-2Если сравнивать именно с php, то не любая.
И я видел какой код пишут php программисты, и как кривизна языка отражается на них.
В 2016 году есть альтернативы, поэтому начинать что-то делать на php довольно странно.SerafimArts
05.12.2016 13:11А ну-ка? Вот простой класс сообщений: https://gist.github.com/SerafimArts/798adfa04844bc3b311620a930c7727a чем этот код отличается от джавовского или шарпеца, например? Ну за исключением того, что он на порядок лаконичнее. Где эти хвалёные "костыли", которых я из-за "замыленного" глаза просто не замечаю?
SerafimArts
05.12.2016 13:16P.S. Если не найдёте — это некоторый повод задуматься на тему: "Может вы видели код совсем даже не программистов, а любителей, которых в любом языке предостаточно?"
terryP
05.12.2016 13:49+1Ну за исключением того, что он на порядок лаконичнее. Где эти хвалёные «костыли», которых я из-за «замыленного» глаза просто не замечаю? Ну за исключением того, что он на порядок лаконичнее.
Банально:
if ($this->rendered === null) { $this->rendered = $this->injectParameters($this->body->textContent, $this->parameters); } return $this->rendered;
На Java (которую ругают за многословность) записалось бы как:
if (rendered == null) { rendered = injectParameters(body.textContent, parameters); } return rendered
Без всяких ужасных многократных $this и созданий лишних переменных. Так что
на порядок лаконичнее.
Крайне спорно.SerafimArts
05.12.2016 19:57В пыхе это тоже можно заменить, например на
return static $rendered = $this->injectParameters(...);, что будет ещё короче, но плохо с точки зрения качества кода.
Согласен на счёт возможности опускания
this, но это просто из-за того, что в джаве просто нет общего неймспейса, отсюда в пыхе требуется явное указание контекста, для исключения аффектов переопределения методов глобальным неймспейсом. Так что это, по-моему, не проблема языка, а способ реализовать те возможности, которые просто захардкожены в джаве (имеется ввиду автоимпорт java.lang.String и аналогичных).
dmtrrr
05.12.2016 14:33Вы приводите один класс, к-й почти ничего не делает. Что это должно показать?
Я, например, видел как люди писали в лог без таймстэмпа, то есть элементраные вещи делали криво.merlin-vrn
05.12.2016 14:37Так эти люди и в django не встроенный механимз логирования (модуль python logging) будут использовать, а писать в текстовый файлик без таймстампа. Язык-то тут при чём?
dmtrrr
05.12.2016 15:16Язык при том, что люди привыкшие к тому, что есть http запрос и магически сформированные глобальные массивы, плохо понимают все что выходит за эти рамки.
А современный бэкенд это далеко не всегда обработка http запроса.
SerafimArts
05.12.2016 20:05Ну так я и показываю пример только того, что какие-то косяки языка — довольно стереотипны, при этом явно написал об этом, парируя утверждение про то "зачем M, если есть N". Так же явно упомянул, что если вы сталкивались с любителями — это не значит, что все такие.
А отвечая на ваш пример, могу даже сообщить, что в пыхе есть рекомендация (которую в 2016ом году можно считать стандартом) по реализации логгирования: http://www.php-fig.org/psr/psr-3/ И соответсвующая популярная либа, реализующая PSR-3: https://github.com/Seldaek/monolog/tree/master/src/Monolog/Handler То, что кто-то делал логи без даты как раз и говорит об уровне знаний ваших знакомых, а не о языке и его сообществе.
В каком ещё языке есть интерфейс логгирования на уровне почти что стандарта? Где написаны адаптеры под все возможные популярные APM и сервисы? И да, они с таймстампом.
dmtrrr
07.12.2016 12:29Вы говорите, что если сильно прищурить глаза, то php будет похож на java. Ну офигеть теперь.
Эти любители проходили собеседование и получали зарплату, так что не нужно додумывать.
Например, в python модуль logging входит в стандартную библиотеку.
http2
05.12.2016 13:59-1А на чем лучше стартовать проект, имея опыт PHP и не имея опыта другого серверного языка? :)
merlin-vrn
05.12.2016 14:32В статье, и особенно в данной конкретной ветке идёт речь о том, что PHP изменился, стал лучше, но чтобы стать лучше вместе с ним, нужно капитально переучиваться.
Короче, считайте, что если вы хотите не наговнокодить по-быстрому, а реально делать проект по-человечески, у вас нет опыта нового PHP. И далее — см. рис. 1
http2
05.12.2016 16:57Я как бы уточнял на
В 2016 году есть альтернативы, поэтому начинать что-то делать на php довольно странно.
К чему Ваша писанина, я хз. :)merlin-vrn
05.12.2016 21:07+2К вашему "имея опыт PHP" — я говорю, что ваш "опыт PHP" нерелевантен. Вам следовало сказать: "не имея опыта разработки сайтов ни на каком современном языке".
И тут сразу же становится вопрос, если честно выбирать: если никакого опыта нет, почему, собственно, PHP? Почему не PHP я запросто расскажу: в интернете гуглится такое количество вредных советов, некоторые из которых вообще не заработают на современной версии, что лучше начать с чего-то такого, что в прошлом не было столь популярно, но при этом так сильно отличалось от современной версии. Проще будет.
"Ложное знание хуже незнания", как тут в соседнем топике подмечают, а ваш "опыт PHP" — это как раз ложное знание, и лучше будет, если его будет некуда применить.
SerafimArts
05.12.2016 22:06+3Прошу заметить, что процентов 80% этих вредных советов из прошлого PHP являются стандартной практикой, например на JS + Node в настоящем. Да, конечно, некоторые неактуальны в связи с наличием commonjs, манки-патчинга и прочих штук, но в целом ведь картина примерно такая же, нет?… Открываешь сырцы какого-нибудь JQuery (до компиляции т.е.) и вспоминаешь времена тысяч реквайров и чистой процедурщины на пыхе 4, ностальгия ;)
Я веду к тому, что языки, где все архитектурные тупики уже обкатаны и очевидны, а инструментарий на порядок превосходит более молодые альтернативы (и не обязательно JS, просто пример) — скорее наоборот является плюсом.
http2
06.12.2016 13:09Сравнивать JQuery и PHP — как бы не совсем правильно. :)
SerafimArts
06.12.2016 13:14Сравнивать подходы в одном языке и в другом, а не сравнивать либу с языком. =)
Как давно вы в php видели код подобного вида? А в JS?
<?php return (function() { function a() { // ... } })();http2
06.12.2016 13:31В мире PHP слабо используют функциональную парадигму. :)
В исходниках JQuery — дерьмо (из-за ограничений языка)?
Сейчас или в году эдак 2008? :)
В JS тоже много нового с 2008 года.SerafimArts
06.12.2016 13:46Там ES6, какие ограничения языка при наличии бабела, вы что? =)
На современный пых больше всех похожи исходники Ангулара и Аурелии. Если бы только добавить правило "один файл — один модуль/класс" можно было бы ими даже восхищаться.
Для примера, JS: https://github.com/angular/angular/blob/master/modules/%40angular/router/src/router.ts PHP: https://github.com/illuminate/routing/blob/master/Router.php Подходы очень похожи, родственные я бы сказал.
Но если эти две штуки (Angular + Aurelia) скорее исключение из общего правила node-сообщества и скорее специфика TS (исключение, учитывая наборы решений в npm), то в случае пыха процентов 90% пакагиста содержит код подобного уровня.
SerafimArts
06.12.2016 13:52P.S. Хотя, начиная с 579ой строки в ангуларе начинается просто неперевариваемая дичь без единого комментария "зачем и почему", достигающая апогея к 1000ой. Макконнелл переворачивается в кровати, бедняга.
http2
06.12.2016 13:59-1Там ES6, какие ограничения языка при наличии бабела, вы что? =)
Так к чему было это? :)
Открываешь сырцы какого-нибудь JQuery (до компиляции т.е.) и вспоминаешь времена тысяч реквайров и чистой процедурщины на пыхе 4, ностальгия ;)
Что не так с исходниками JQuery?
JQuery использует бабель?
Значит Ангуляр и Аурелию писали php-программисты :)
Ну и то не JS, а TS. :)
http2
06.12.2016 13:07-1Бред.
Тогда ни у кого нету якобы релевантного опыта на php7.
Всем бросать из-за этого php и писать на чем-то другом?
В своем же рассуждении Вы отконились от первоначального вопроса.
По другим языкам тоже куча мусора гуглится.
А в том же питоне и вовсе 2 актуальные НЕСОВМЕСТИМЫЕ ветки, старая никак не умрет.
Возможно и в других языках такое.
Ну и мусор гуглился в 2000-ых.
Тогда параллельно существовали PHP 4 и 5.
Ну и не ответили на каком же языке стартовать проект.
Но Ваш дерьмоответ заплюсовали, а мой уточняющий вопрос, на который так и не был дан ответ, заминусовали.
Что характеризует преобладающее стадо на ресурсе.
VolCh
05.12.2016 18:02Чтобы капитально не переучиваться, нужно было переучиваться плавно, с релизом, а ещё лучше хотя бы с RC каждой значимой версией. И за тем, что в экосистеме творится следить постоянно, а не так что писал-писал на PHP3 «с нуля», а тут бац и на 7.1 решил перейти с композером и симфоней или зендом.
http2
06.12.2016 13:14Чтобы капитально не переучиваться
Неправильная постановка вопроса.
А зачем вообще переучиваться? Почему это стало догмой?
Старый код продолжит работать, нужно поправить чуток deprecated, но это было и между минорными релизами.
Кому нужны новые фичи, пускай учат.
Какие это фичи? Строгая типизация? Чего там ее учить? :)
Сложно не учить, сложно программировать в строгой типизиции.
Именно из-за нестрогой типизации PHP и выстрелил.
А сейчас в язык пришла куча академиков, которые пытаются сделать из него Java.
Большинству это просто не нужно.VolCh
06.12.2016 13:34+2Например, если компания в которой ты поддерживал проект на PHP3, решила его закрыть. Пускай он даже крутился последнее время на PHP5.6 фактически, может даже $a = [1,2,3] использовал, но ООП не использовал вообще. Очень маловероятно, что легко найдешь работу на современном рынке без переучивания — и тут не просто deprecated и syntax sugar надо выучить, а начинать в других парадигмах программировать, забыв процедурную с глобальными переменными как страшный сон.
http2
06.12.2016 13:52PHP3
Как всегда пример слабо связанный с реальностью. :)
Та боже мой.
deprecated они и так выучили, раз их проект на 5.6.
Будут переходить на 7 — выучат и 7.
Обратная совместимость PHP — еще один его плюс. А не как в уже упоминаемом питоне, фактически имеем 2 разных языка. :)
ООП?
Так в последнее время уже тренд говорить, что ООП — говно.
То наследование не стоит использовать. А без наследования и другие киты, на которых стоит ООП, имеют мало смысла.
Очень маловероятно, что легко найдешь работу на современном рынке
Да, вероятность найти работу падает. Сейчас ищут программиста не по умению думать, а по внешним признакам, вроде знания «чем отличается абстрактный класс от интерфейса», которые:
а) можно натаскать перед собеседованиями.
б) это вряд ли существенные детали. Это реализация. А реализация может быть любой, желательно самой простой.
в) это все равно не используется в проекте. :)
Если человек писал качественный код в процедурном стиле, то он будет его писать и в другом стиле. :)
Ну вот что дает Вам использование ООП? :)VolCh
06.12.2016 14:01+2Абстракции и инкапсуляцию, как минимум.
http2
06.12.2016 14:07Этому сложно научится тому, кто не работал с ООП? :)
Можно перед собеседованием прочитать? :)VolCh
06.12.2016 15:18+1Прочитать можно. Но я за 5 минут выясню только прочитал человек или способен мыслить в объектно-ориентированной парадигме. Банальная задачка: накидать описания классов для прямоугольника, квадрата и ромба для моделирования школьных задач по геометрии.
Вторая: накидать описания классов для моделирования процесса кормления человеком собаки.
Бумажка, ручка, любой псевдокод, любые вопросы.http2
06.12.2016 15:30прямоугольника, квадрата и ромба
Вы хотите, чтобы квадрат наследовал и прямоугольника, и ромба? :)
У вас на проекте используется множественное наследование? :)
Кмк, человек, который ранее с ООП не работал, но имеет мозги, пройдет Ваш тест.
Вторая задача — вообще какой-то бред. :)
varanio
06.12.2016 14:18дело в том, что есть по сути два современных подхода: ооп и фп, у каждого есть плюсы и минусы. В старом пхп не было ни того, ни другого, только процедурки.
В новом есть нормальное ООП и какие-то зачатки ФП (лямбды и т.д)
Так что выбора особого не вижу тут.
XXXXPro
01.12.2016 17:15+3На мой взгляд, чего реально в PHP не хватает, так это легкого встроенного шаблонизатора с нормальным экранированием вывода. В результате приходится либо подключать сторонний (что оправдано для больших проектов, но очень сильно «утяжеляет» маленькие), либо городить вечные <?php echo htmlspecialchars();?>
jrip
01.12.2016 17:37А вы это как себе на практике представляете? Внезапно все echo будут по некой магической директиве принудительно прогонятся через htmlspecialchars, типа такая же веселая штука будет, как незабвенные magic quotes?
Starche
01.12.2016 18:09на практике это реализуется шаблонизацией) Какой-нибудь встроенный класс-парсер шаблонов с подставлением переменных.
Ну просто чтобы не тащить целый twig в домашнюю страничку.jrip
01.12.2016 18:43Ну класс парсер пишется за 5 минут и вообщем-то для такой хотелки как выше займет строк 10, толку его в ядро языка тащить?
vanxant
01.12.2016 18:40+1Нет, ну есть синтаксис <?=, могли бы добавить какой-нибудь условный <?#= для искейпа
jrip
01.12.2016 18:46+2В чем проблема для вас определить функцию и делать <?= p()?>? Забыть не сложнее чем <?#=, лишние пара символов играют роль разве? При этом экранирование оно как бы разное бывает, не везде хватит htmlspecialchars, а кое-где его будет много. Собтсвенно c помощью PHP не только html генерят.
DmitryKoterov
01.12.2016 20:13+1Не нужно даже ничего изобретать на тему экранирования — «все уже украдено до нас» ((с) «Операция Ы»), называется XHP:
https://facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919/
https://github.com/facebookarchive/xhp-php5-extension/blob/master/README.textile
Даже расширение для PHP есть, осталось его только включить в дефолтный список.
Вообще, это придумала Мозилла первая, кажется (они заметили, что синтаксис XML не противоречит синтаксису языка, поэтому XML-конструкции пожно вставлять в код не как сторки, а как first-coass citizen). Он позволили встраивать XML в JS при написани движка браузера/расширений. Идея, совершенно лежащая на поверхности, но почему-то потребовалось почти 20 лет, прежде чем она стала использоваться (так бывает; иногда мы совершенно не видим то, что прямо перед нами — другие примеры: async-await, а также банкльное колесо).michael_vostrikov
02.12.2016 17:49+1Мне кажется, он слишком тяжелый, чтобы просто использовать его для экранирования данных. Ну и синтаксис одного языка внутри другого языка выглядит как-то не очень красиво.
jrip
05.12.2016 13:56+1Но мысли там интересные и правильные.
Вообщем-то если подумать, например, когда мы генерим json,
то написание что-то вроде
echo('{var:"'.$var.'"}')
или
{var:"<?=$var?>"}
выглядит довольно странно и обычно так все-таки не делают.
Опять же при генерации XML, обычно стараются делать это на основе каких-то структур.
Однако в Html для браузера мы привыкли делать как-то так:
<input type="text" value="<?=$var?>">
Собственно все проблемы типа безопасности, необходимости экранирования и тд, как мне кажется, они именно из-за этого подхода. Т.е., по-моему, суть в том, что такой подход не органичен.
michael_vostrikov
01.12.2016 17:47+3Во-во, и я о том же)
jrip
01.12.2016 18:53Вот у вас грамотный подход, но стоило ли оно того? Возможно все эти усилия стоило потратить на решение какой-то более существенной проблемы?
michael_vostrikov
01.12.2016 19:03Если бы получилось, сделал бы полезную вещь и поучаствовал в разработке известного языка) Чем не мотивация.
jrip
01.12.2016 19:14Так надо было делать что-то более эпичное) Знак доллара перед переменной, например, попытаться отменить)
Fesor
02.12.2016 21:24Знак доллара у переменных это не проблема, это способ избавиться от явного объявления новых переменных. Вот лексические скоупы — другой разговор. Или дженерики для пыха.
Для тех кто не хочет вникать в Си, есть другой вариант помочь продвигать фичи — yay. Берем RFC и реализуем как пакет для composer. Тем самым давая возможность народу "покрутить повертеть" фичу на этапе обсуждения. Мало кто не ленится собрать себе пых при наличии MR с новой фичей и покрутить. А так хоть народ вместо "непонятно" будет давать фидбэк внятный.
SerafimArts
02.12.2016 21:31Доллар играет очень важную роль в языке:
1) Позволяет визуально отличать декларации переменных от структур, например:
$a; // переменная a; // константа
2) Добавляет грандиозные и консистентные возможности метапрограммирования, например:
$obj->field; // Получение ссылки на задекларированное поле $obj->$field; // Получение ссылки на поле, имя которого содержится в строковой переменной $field echo $some; // Вывод значения переменной some echo $$some; // Вывод значения переменной, имя которой содержится внутри переменной some
3) Позволяет делать интерполяцию без спец.символов (сомнительно очень), например:
$world = 'Вася'; echo "Привет $world";jrip
03.12.2016 01:00Да пошутил же я ))
Просто одно время был холивар, ну типа лишний шифт нажимать))SerafimArts
03.12.2016 04:57А некоторые не шутят и действительно считают, что без "долларов" лучше, а конкатенировать стоит символом "+"...
jrip
05.12.2016 13:33>А некоторые не шутят и действительно считают, что без «долларов» лучше
Ну если быть совсем честным, то их мнение имеет право на жизнь, вот на ваши примеры можно вот так посмотреть:
>1) Позволяет визуально отличать декларации переменных от структур, например:
>$a; // переменная
>a; // константа
Обычно константы все-таки заглавными выделяют, типа define («CONST1», "")
>2) Добавляет грандиозные и консистентные возможности метапрограммирования, >например:
А часто ли в реальном коде такое оправдано используется? Почти все случаи, которые я встречал были либо с проблемами в безопасности, либо слабо читаемыми, либо бажными. При этом ктож мешает бакс оставить именно для этого. т.е.
someVar // Вывод значения переменной some
$someVar // Вывод значения переменной, имя которой содержится внутри переменной some
>3) Позволяет делать интерполяцию без спец.символов (сомнительно очень), например:
Опять же как раз в этом случае бакс можно и оставить, так например сделано в Scala:
println(s"${msg}\n\n")SerafimArts
05.12.2016 13:41+1Согласен. Я преувеличил. Но, с другой стороны довольно тривиальный пример:
public function __get(string $field) { $getter = 'get' . ucfirst($field); return method_exists($this, $getter) ? $this->{$getter}(); : null; }jrip
05.12.2016 14:02+2Тут сразу большой вопрос, а зачем так делать?
Нужны гетеры — средства современных IDE позволяют их сгенерить нажатием пары кнопок. Ваш же пример, как и многие другие с ипользованием $$ открывает простор для багов. Ошиблись где-то: либо в названии переменной или названии метода и сходу баг уже не обнаружить, а при другом подходе сама IDE нам бы об этом сказала.
Serj_By
09.12.2016 12:20Ага, и будет как в JavaScript:
Fesor
09.12.2016 14:22вот бы как в python
13 + "42"
TypeError: unsupported operand type(s) for +: 'int' and 'str'
в целом же всегда есть typescript/flow что бы сделать свою работу чуть более типобезопаснее.
Serj_By
09.12.2016 14:39Ну это, по крайней мере, более предсказуемое поведение. Хотя, если знать как это работает в JS — все тоже предсказуемо. Но для начинающих разработчиков — это, конечно, мрачный мрак.
M-A-XG
01.12.2016 18:02-5человек, который пишет на современном php, должен как минимум знать кучу ООП best practices, использовать фреймворки и composer, знать кучу фич языка и его расширений
Ничего никто не должен :)http2
05.12.2016 12:41-2Мне тоже интересно, почему это я должен забивать голову мусором? :)
Все это легко гуглится при необходимости.
А вот умение думать — не нагуглишь. :)
Starche
01.12.2016 18:19Мне болезненно не хватает встроенных в ядро асинхронных возможностей. Ну хотя бы банально — письмо послать без ожидания, в фоновом режиме.
SerafimArts
01.12.2016 21:03+2Такое норм? =)
register_shutdown_function(function() { // Send email });SerafimArts
01.12.2016 21:09P.S. Ну понятно, что эта штука не асинхронная, но вполне решает подобную проблему без внешних зависимостей. Хотя по-хорошему, конечно, лучше очереди.
Starche
01.12.2016 22:38Сессия же остаётся заблокированной при этом. В общем да, этот вариант я иногда использую на совсем мелких проектах, где это не существенно. Когда проект большой — подключаю треды. А вот на среднем чём-нибудь у меня начинаются метания, т.к. оптимального решения всё же нету.
Nicklasos
01.12.2016 22:19+1Если используется php-fpm, то можно использовать функцию fastcgi_finish_request();
Fesor
01.12.2016 23:33+2в Symfony и swiftmailer для этого есть spool. причем в двух реализациях, через файлы и cli команду или in-memory очередь и fastcgi-finish-request (то есть отправка идет после завершения обработки запроса). Для большинства этого хватает. Если нет — всегда есть очереди, нечего загружать процесс обрабатывающий запросы чушью вроде отправки email-ов.
ivlasov
01.12.2016 19:25Мое мнение PHP может и должен остаться только как backend JS морд. То есть как прослойка с нормальной аутентификацией между базой и клиентом. REST API и иже с ним
Имею многолетний опыт с PHP и с Yii в частности, последние 2 года полностью переехал на JS и не жалею.
AmdY
01.12.2016 20:41+1Основные изменения произошли в инфраструктуре и головах разработчиков, которые начали этой инфраструктурой пользоваться. Ускорили производительность, улучшили синтаксис, много изменений внутри, но ничего принципиально нового, что бы вывело язык на новый уровень не случилось. А вот то, что начали пользоваться компосером и фреймворками сильно всё поменяло, хотя ещё и во времена php4 были pear, pecl, seagull, cakephp и т.д.
Очень хотелось бы чтобы улучшилась асинхронность, многопоточность, появился loop, библиотеки стали неблокирующими, но глядя на костыли с какими добавляются новые фичи, думаю продолжу при надобности подтыкать проект на других языках nodejs, go. Может и не надо делать универсальный инструмент.
Mugik
01.12.2016 23:00Я бы наверно смог писать на php.
Но когда я сделал
и php с радостью исполнил мою просьбу и даже продолжил работать дальше — я понял, что это уж совсем перебор.$array = array('foo' => 'bar', 33 => 'bin', 'lorem' => 'ipsum'); $array = array_values($array); echo $array[12];Melkij
01.12.2016 23:19+8Не совсем радостно. Высказал вам своё «фи» в виде E_NOTICE. Но, видимо, у вас вывод этого уровня ошибок выключен.
Продолжил после этого выполнение — к сожалению да. Будет пытаться выполнить любой бред максимально долго. Но нехитрый фокус с set_error_handler, который делают наверное все фреймворки — и можно попросить останавливаться и кидать нормальное исключение.
Acuna
08.12.2016 12:13На этом примере PHP выдаст Fatal Error, но у Вас просто отключен вывод ошибок. Точно так же как и если попытаться, например, сложить строку с массивом. Или объект со строкой. И так далее. Так что все эти неправильные выводы (как и созданная его репутация) проистекают от поверхностного ознакомления с ним и желание делать преждевременные выводы.
franzose
02.12.2016 09:10+5К сожалению, огромное количество php-шников до сих пор используют php как php4, и не хотят учиться.
Люто плюсую.
shurkandak
02.12.2016 09:20Многие вещи в PHP скопированы из Java к примеру реализация классов, по сути есть разработчик может в ООП на PHP, значит он хороший Java программист.
Так что кода в php добавят виртуальную машину, аннотации, многопоточность php станет джавой.Acuna
08.12.2016 12:14А ничего, что многое на PHP (те же лямбды) появилось даже раньше чем в Джаве?)
Fesor
08.12.2016 15:49А ничего, что до php5 там и так были функции? Да что там, до php4 у вас были только функции для организации кода (подпрограммы тип), как в Си. Так что факт наличия анонимных функций в языке где функции были с самого начала — это просто факт. А вот в java функций как самодостаточных единиц небыло отродясь, теперь есть и это прогресс.
Acuna
08.12.2016 19:41-1А Вы, простите, зачем вступаете в оппозицию? Я вас что, в чем-то обвиняю как создателя языка, или обвиняю в чем-то Джаву? Естественно Джава даст сто очков вперед языку для создания веб-страничек, их даже сравнивать бессмысленно. Я просто говорю что что-то там появилось даже раньше чем в Джаве, поэтому не стоит язвить и объяснять, что там было «у нас». Что было «у нас» мы и так знаем, благодарю. Язык, каким бы он ни был, не стоит того, чтобы воспринимать разговоры о нем как личное оскорбление, есть много и других тем, в которых можно оскорбиться, если уж Вы этого так хотите.
SerafimArts
08.12.2016 12:22Доктриновские аннотации уже стали почти что дефолтом. Многопоточность тоже есть (pthread экстеншн), виртуальная машина 100 лет как, не классическая, но наличие опкодов и их кешеров (opcache, apc, etc) намекает ;)
begor
02.12.2016 09:20Когда я работаю с динамически типизированным языком, я ожидаю получить скорость и гибкость разработки, отказываясь при этом от sound системы типов. Классический трейд-офф, из палаты мер и весов.
Поэтому, например, в Python все — объекты первого класса (модуль можно передать в функцию форматирования строки, как вариант), что дает гибкость и заменяет некоторые паттерны из GoF простой передачей объектов.
В PHP же совсем недавно появились лямбды (и то весьма странные, с костылем-use вместо нормального скоупинга), первый класс только у скаляров, да объектов, кажется. Отсюда монстроузные решения типа Симфони и Доктрины, которые в динамическом языке выглядят странной пародией на Java-экосистему.
Вопрос: какие преимущества дает PHP, чтобы предпочесть его для нового проекта с одной стороны динамике Python/Ruby, с другой стороны — статике и энтерпрайзу Java?VolCh
02.12.2016 11:35Динамику по умолчанию с возможностью (псевдо)статики, сокрытие данных, ну и, как вы говорите, «пародия на экосистему». Можно считать, что PHP сочетает лучшее из двух миров. Можно, что худшее, но что сочетает — факт.
mihacoder
02.12.2016 09:207-я версия языка порадовала скоростью, вот только большая часть сайтов нашей фирмы на Битриксе, их просто так не переключишь. Те, что на Yii2, вообще не потребовали правок, там уже все готово. А в целом насчет ниши php — уверен, что он так и останется ближайшие годы основным языком для многих сайтов, особенно с невеликим бюджетом. По уровню сложности изучения — да, уровень входа минимальный, даже меньше, чем на python, поскольку на любом серваке поддерживается, больше инфы в сети. Легко учить, но так же легко и писать жуткие вещи, смешивая в одном файле верстку, логику и работу с базой. Это уже вопрос самодисциплины, думаю.
ls18
02.12.2016 09:38Использование фреймворка и опытного(грамотного) ведущего, который будет стучать по голове в случае чего хорошо прививает привычку писать более менее аккуратно и грамотно.
mihacoder
02.12.2016 16:26У нас начальство не вникает, кто и как пишет. Поэтому про самодисциплину и написал. А так при желании мог бы просто имитировать, работая значительно меньше :)
vanxant
02.12.2016 14:39Если битрикс обновлять, и при этом изначально нормально писать свои шаблоны/компоненты/модули/чтотамувас, то всё заводится на 7 без проблем. Даже сайты, которые пятый год в продакшене. Прям удивительно.
mihacoder
02.12.2016 16:24Вот как раз не обновляли Битрикс, начальство решило поэкономить, поэтому версии не самые свежие. Да они в принципе и работают, только на 5.6. А новые пишем уже на Yii2. Просто хотелось бы и старые чуток ускорить. Ну это не критично.
DemosBlack
06.12.2016 09:50+1Не спеши навешивать ярлык на PHP, тем более на живой, новые диалекты которых появляются чуть ли не каждый месяц. Прежде чем выслушать критику в адрес языка, спроси у собеседника, не имеет ли он в виду версию 15-ти летней давности
Itachi261092
06.12.2016 11:12+1Братаны, хелп. Я из тех, кто входил с низкого порога, и не дружит с ООП. (быдлокодю для битрикса.) Хочу учиться, перестраиваться, расти профессионально и улучшать репутацию PHP. Подкиньте кто нибудь хороших ресурсов/книжек на русском, которые лично вам помогли лучше в этом разбираться.
varanio
06.12.2016 12:45Я бы начинал с изучения принципов SOLID. В гугле полно статей, видео и т.д.
Книга «чистый код» Роберта Мартина.
Концепция «Domain Driven Design» — подчеркивает важность того, что код и термины в нем должны отражать суть бизнес-задач
У Фаулера есть различные книги, которые стоит почитать.xotey83
06.12.2016 13:22Добавлю ещё про Code Complete (Совершенный код) Макконела.
Классика — Gang of FourItachi261092
06.12.2016 14:17Большое всем спасибо. Обязательно всё посмотрю. + поставить не могу — нет кармы.
http2
06.12.2016 13:19улучшать репутацию PHP
Улучшайте свою репутацию… :)
Книжки?
Я хз, есть ли что-то особенного под PHP.
Но одними книжками сыт не будешь.
Ресурсы?
гугл, стековерфлоу (английский), хабр. Слышали эти ресурсы? :) Ах да, официальная документация и комментарии к ней (тоже на английском).
Нужна прежде всего практика и общее правильное представление о программировании.
Если Вы собрались вообще без английского языка писать на PHP — ну это близко к тупиковому пути. :)
П.С.
Книги, указанные предыдущим оратором поддерживаю (это как раз общие книги).Itachi261092
06.12.2016 14:15+1Советчик из разряда «спасибо, кэп». Специально для людей, не умеющих читать, я повторю ещё раз с акцентом:
Подкиньте кто нибудь хороших ресурсов/книжек на русском, которые лично вам помогли лучше в этом разбираться.
Всё что я могу найти самостоятельно в гугле — пока я это не прочту и не изучу, заранее не скажет мне, кому, как, и в чём оно помогло. И помогло ли вообще. Я могу найти абсолютный шизофреничный бред, или категорию литературы, которая не подходит мне по уровню, и не даст никаких адекватных результатов. Я не плохо знаю битрикс, и с этим знанием, я порой нахожу такие неудачные примеры и статьи от левых людей в их говноблогах, от которых хочется повеситься. По битриксу в непрофильных блогах уйма идиотских и вредных советов. Где гарантия что я не наткнусь на такие же, при поиске информации о PHP и ООП? Даже та же «чистый код», которую мне посоветовали выше, была немного раскритикована на этом же хабре
Если тебе нечего сказать конкретно по вопросу — уж лучше бы молчал, чем писать очевидные вещи.http2
06.12.2016 15:02-1Так а нету никаких секретов.
Книжек тебе уже подкинули. Читай. Это общие книги. Я поддержал эти книги, если ты не увидел…
Если умения думать у тебя нету, вряд ли они тебе помогут.
Я могу найти абсолютный шизофреничный бред, или категорию литературы, которая не подходит мне по уровню, и не даст никаких адекватных результатов.
А откуда уверенность, что тут Вы получите то, что хотите? :)
была немного раскритикована на этом же хабре
А Вы читали эту книгу? :)
Мало ли что какой-то дурак написал. (Да, последнее время концентрация некомпетентности на хабре зашкаливает, возможно хабр и с натяжкой в списке предложенных мною ресурсов).
уж лучше бы молчал, чем писать очевидные вещи.
Ну почему же. Вот вам:
Но одними книжками сыт не будешь.
Но если Вы, как упертый баран, хотите только книжек без практики, то это тоже путь, близок к тупиковому. :)
Поменяй работу, походи на собеседования.
А чем Вас не устраивает Битрикс? Он же ООП. Там тоже непаханное поле.
Новое ядро — еще ближе к новомодным фреймворкам.Itachi261092
06.12.2016 15:04В том то и дело, что практики мне на основной работе и фрилансе пока хватает. Хочу хорошо знать, и применять теорию.
http2
06.12.2016 15:14Найдите работу, где будет нужна эта теория. :)
А она мало где в действительности нужна. :)
А то на собеседованиях спрашивают ООП и прочую ерунду, а в проекте это и близко не используется. :)
Если Вы будете писать на готовом фреймворке / CMS, то многое будет сделано за Вас, скорее всего Вам не нужно будет городить иерархии наследований и т.п. :)
Вам нужно только их документацию прочитать. Многие разработчики этим и злоупотребляют. Они знают только свой фреймворк, а в незнакомом месте и шагу самостоятельно ступить не могут. :) Самого языка и программирования вообще они, можно сказать, и не знают. :)
Начните свой проект на самописи. :)
Ах да, читайте исходники. :)
Что-то непонятно — в гугл. (что-то по предыдущему предложению, а то еще опять неправильно поймете) :)
Skit25
06.12.2016 12:19После прочтения, у меня возник эмоушн:
Кодил на php еще с 4х, молча кодил, рос php, что и как не задумывался, просто обновлялся и использовал новые фичи.
Ниша конечно есть! Уверен она никуда не денется. Куча php фреймворков, так и останутся php фреймворками. Когда выбирал фреймворк, увидел, что между ними неплохая конкуренция. Конечно, с повышением уровня входа в php, будет расти вход и на то, что на нем пишется. Очень вдохновляет к личному росту и рад, что успел запрыгнуть в этот поезд. Благодаря php, сейчас углубляюсь и другие языки программирования. Спасибо Расмусу за это!
Кто вперед на PHP 7.1?http2
06.12.2016 13:21-3Вход в PHP вообще-то не вырос. :)
Он остался простым языком. :)
Это фреймворки просто переусложнены. :)VolCh
06.12.2016 13:50Фреймворки и библиотеки упрощены за счёт того, что часть сложности перенесена на уровень языка.
http2
06.12.2016 13:54Упрощены? Сейчас? Вы что? Зачем лгать?
SerafimArts
06.12.2016 14:02+2Человек не совсем корректно выразился, подозреваю.
Упрощены за счёт того, что часть задач архитектурирования бизнес-логики уже реализована самым эффективным образом (эффективность этого "образа" выбирает уже сообщество) в рамках общих идей конкретного фрейма. При ручной реализации подобных штук, получится либо архитектурный оверхед, либо одноразовая шляпа.
http2
06.12.2016 14:15Это когда же оно было упрощено во фреймворках?
С выходом PHP7? :)
А ниче, что все они работают и на PHP5? :)
часть задач архитектурирования бизнес-логики уже реализована в рамках общих идей конкретного фрейма
То есть программисту не нужно писать кусок бизнес-логики ибо за него это сделано на фреймворке? :)
Что же такого за него реализовали, что ему не нужно писать? :)
Но все равно разработка на фреймворке какая-то оверхедная. Куча ненужных дырявых абстракций, которые нужно постоянно переступать. :)
Кстати, использование фреймворка стимулирует разработчика и дальше все усложнять. :)
либо одноразовая шляпа
Почему же одноразовая? :)
Можно использовать в других своих проектах.
А если проект один и большой, то можно иметь нужную шляпу, а не брать в аренду не совсем нужную. :)
VolCh
06.12.2016 15:06+2Грубо называть ложью мнение.
Одно введение в язык позднего связывания значительно упростило фреймворки. Интерфейсы и абстрактные классы. Сокрытие членов классов. Callable, включая анонимные функции с замыканиями. Итераторы. Всего и не упомнить.
Если вы разработку на PHP4 не застали, то поверьте на слово, что фреймворк аналогичный по функциональности Symfony или Yii был бы гораздо сложнее и внутренне, и в использовании.
http2
06.12.2016 15:25-7Мнение?
Чет мне показалось, что это как всегда приукрашенное мнение, которое навязывают сектанты фреймворков.
Ну или Вы сами купились на их пропаганду. :)
Одно введение в язык позднего связывания значительно упростило фреймворки.
Это когда было сделано?
С выходом 7? :)
Об остальном и говорить не хочу. Ощущение, будто Вы пытаетесь втянуть меня в какое-то болото. :)
Если вы разработку на PHP4 не застали, то поверьте на слово, что фреймворк аналогичный по функциональности Symfony или Yii был бы гораздо сложнее и внутренне, и в использовании.
Только фреймворк был бы сложнее?
Мой код тоже был бы не таким без упомянутого Вами без причины позднего статического связывания.
Более странно, что его не было изначально. :)
Ах да.
Я человек простой. Вижу тупость или ложь, выражения не особо подбираю. :)VolCh
07.12.2016 10:44+1Что значит «приукрашенное мнение»? Парсер в моей голове ломается.
Тред о прогрессе с 4 до 7.
Больше похоже, что вы видите свои фантазии.http2
07.12.2016 12:47Возможно мы не поняли друг друга. :)
Я отвечал прежде всего на это.
Конечно, с повышением уровня входа в php, будет расти вход и на то, что на нем пишется.
Перехода 4-5 — можно сказать, не застал. Но не заметил там повышения уровня входа.
Ну и не заметил повышения уровня входа при текущем переходе 5-7.
Где же идет повышение уровня входа — так это на фреймворках.
Были ли фреймворки при переходе 4-5 — хрен его знает. :)
Но при переходе 5-7 во фреймворках ничего не упрощено, так как они хотя бы все совместимы с 5.
Есть вопросы? :)Fesor
07.12.2016 18:05+1Давайте разберемся что такое значит "проще".
Для меня "проще" выражается в возможности вносить изменения не внося изменений в то, что уже было написано ранее. Такие штуки проще поддерживать, проще развивать (потому что риск регрессий меньше). Что для вас проще?
Были ли фреймворки при переходе 4-5 — хрен его знает. :)
Они были
http2
08.12.2016 10:31-1Проще — прежде всего код прост для понимания.
В простой для понимания код скорее всего будет просто вносить изменения.
Стараясь, чтобы вносить изменения было просто, нужно не переусердствовать.
А то можно накодить ерунды якобы для возможности будущего расширения, а оно и не понадобиться и все придется выпиливать. :)
Fesor
07.12.2016 11:51Это когда было сделано?
В принципе где-то с версии 4 где появились классы. До этого в целом у вас были только функции и переменные.
без упомянутого Вами без причины позднего статического связывания.
А что бы устранить немного неграмотности поясню, что связываются вместе вызов метода и код, который выполняется. Соответственно есть два вида связывания — раннее и позднее.
Проверить какой вид связанности используется можно легко и просто. Берете свою любимую IDE, открываете интересующий вас кусочек кода, смотрите вызовы метода и если вы можете перейти прямо в вызываемый код — значит связывание раннее. А если вы попадаете на абстрактный метод без реализации — позднее связывание. То есть связь между вызовом метода и кодом. который будет выполняться по этому вызову, происходит исключительно в рантайме.
Что дает позднее связывание — возможность подменять реализацию в рантайме. А это дает огромные возможности в плане того, как писать код. Между прочим это одна из основных вещей, которые дает ООП. Не наследования всякие, а именно позднее связывание.
Позднее статическое связывание — это уже совершенно другая штука. Это возможность узнавать статическому методу контекст, в котором он был вызван. В целом это что-то типа "кастыль по необходимости" для фреймворков вроде того же Yii которые всецело были завязаны на статике + наследовании. Большинству же людей, которые адекватно используют статические методы и не перегибают палку с наследованием (которое в 90% случаев оверюзится), оно просто не нужно.
http2
07.12.2016 13:15-1О, вспомним PHP3 еще :)
Сколько процентов пользователей это застало? :)
А что бы устранить немного неграмотности поясню
При чем тут неграмотность?
Упоминание нелогичное, вот и все. :)
Я ж не по самому позднему статическому связыванию спорил. :)Fesor
07.12.2016 16:56+1При чем тут неграмотность?
В том что вы не знаете что такое раннее/позднее связывание и путаете это с late static binding, которая не имеет к этому всему ни малейшего отношения.
http2
07.12.2016 17:28VolCh
под «поздним связыванием» Вы имели в виду не «позднее статическое связывание»?
http://php.net/manual/ru/language.oop5.late-static-bindings.php
Можно ссылку, что Вы имели в виду и когда это было введено в PHP? :)
Roma1020
06.12.2016 15:27Хороший язык для входа в веб и дальнейшего роста в этой сфере. А вот для задач вычислительного характера, увы, я не считаю что он может подойти. Он занял свою нишу в сообществе, и его вполне хватает для большинства задач в браузере. Пусть лучше он развивается в сторону браузера-сервер(там на сервер запрос сделать, что бы тот на нем выполнил что-то с определенными данными и тд.). А вот в другие места ему соваться не надо.
franzose
08.12.2016 11:34Так вроде ж особо и не суётся, так как создавался именно для веб-разработки)
atemik
08.12.2016 12:01Вот-бы нормальное сравнение, а чем Php (скажем 7+) от Perl (скажем 5.10) отличается в таком случае ;)
webmasterx
На мой взгляд везде, где не требуется GUI без браузера, и не слишком критична скорость выполнения.
webmasterx
господа минусующие, а не проясните ли мне, в чем же это я не прав? И собственно за что минуса? за мое личное мнение?
jrip
Не минусил и PHP люблю, но думаю за слово «везде».
FractalizeR
Я думаю, все дело в аргументации. Когда речь идет о нише языка программирования, я полагаю, нужно учитывать его особенности. Я бы выделил следующие особенности PHP:
Все это вместе (и некоторые другие факторы тоже, конечно) и определяют нишу этого языка сегодня.
GUI на PHP не пишут не потому, что язык для этого неудобен или не подходит (есть расширения PHP для разработки GUI), а потому, что экосистема PHP ориентирована в основном на веб. Попробуй сделать что-нибудь сложнее калькулятора на PHP и сразу будет понятно, что нужно написать с нуля все контролы, реализовать, скажем, датабиндинг, поскольку функционала стандартных окажется более чем недостаточно.
Производительность имеет достаточно мало влияния на применение языка. PHP один из самых быстрых скриптовых языков, но тем не менее, в научных расчетах, обучающихся системах Python его превосходит по широте использования из-за наличия развитой экосистемы в этом сегменте.
webmasterx
но никаких других ограничений, кроме как отсутствие некоторых узконаправленных библиотек нет. Вот к чему я клонил.
FractalizeR
Я не думаю, что Тьюринг-полные языки программирования имеют "ограничения". На ассемблере тоже можно интернет-магазин написать. Ограничений нет. В данном случае лучше говорить не об ограничениях, а о тенденциях.
jrip
ниша != можно если зачем-то хочется.