Joomla 4.0

Если каждая страничка - отдельный файл PHP

ты путаешь с html вот там все гвоздями прибито особенно если не используется серверный жабаскрипт

РНР Поддерживает отправку писем, работу с БД

Это преимущество? Назови мне язык из этой сферы, который этого не умеет.

из коробки

Какая разница, из коробки или нет? Ну то есть разница есть для описанной мной выше задачи:

одна страничка с формой

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

являясь препроцессором гипертекста, он ещё и отлично интегрируется в html

Опять же преимущество только в контексте озвученной выше задачи. А в приличном обществе использовать встроенный в PHP шаблонизатор вообще считается моветоном.

Отойдя от темы, восстанавливаются.

Это была шутка (в которой как, известно есть доля шутки).

клиентский javascript тупо не имеет доступа ни к чему, ну к печенькам правда имеет но не к файлам...

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

Назови мне язык из этой сферы, который этого не умеет.

Не умеет в БД как РНР? Где-то все. Серьёзно, вы вообще знаете, как подключаться к БД на современном пхп?

Какая разница, из коробки или нет

А такая, что вы учите один язык, а не десяток средств.

Ещё и производительность будет выше, если код на си.

А в приличном обществе использовать встроенный в PHP шаблонизатор вообще считается моветоном

Для очень простых страниц подходит. Моветон — плодить сущности, усложняя код.

Сырое API БД с запросами в любом случае следует избегать. А конструктора запросов в PDO не завезли, если я не ошибаюсь. Так что в любом случае неважно насколько оно там офигительно.

Ничего я не путаю.

какой еще конструктор O_o?

Автор пытался создать язык для непрограммистов

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

лорчую

Сырое API БД с запросами в любом случае следует избегать

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

Типа такого.

https://laravel.com/docs/8.x/queries

обеспечивая лёгкий (и универсальный) механизм для работы с различными БД.

универсальный

не такой уж он универсальный кстати. между разными БД зачаcтую есть несовместимости на уровне SQL.

только не надо фреймворки не упоминать а чистое php

А такая, что вы учите один язык, а не десяток средств.

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

Это не его дело. ПДО — уровень абстракции для взаимодействия с различными БД. То, что SQL достаточно сильно отличается, я понимаю, но ваш клиентский код будет таким же.

ну и что в python тоже огромная стандартная библиотека потому что нужно.

Это лишь пример.

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

Кроме того, что косяков не так много (в современном пхп), так их ещё и можно нивелировать.

Учите огромную стандартную библиотеку

Она не такая большая, как вам кажется, просто область, отвечающая за веб, сильно развита.

потом выбрасываете все эти знания на помойку потому что при разработке сколько нибудь серьёзных приложений в любом случае используется какой то фреймворк

Вы же понимаете, что фреймворк написан на этом же ЯП (чаще всего), там и применяется стандартная библиотека.

что косяков не так много (в современном пхп)

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

там и применяется стандартная библиотека

В коде самого фреймворка - конечно. В коде приложения на этом фреймворке - обычно все вызовы к стандартной библиотеке обёрнуты в стройные вызовы самого фреймворка.

Фреймворки конечно бывают разные, в том числе легковесные. Но популярные фреймворки для PHP почему то (и почему бы это?) имеют тенденцию быть именно такими - заменять собой стандартную библиотеку.

вот и создавай 🙃 а мы всем обществом посмотрим

зы это идеализм

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

ага начал отмазываться уже😛 шютка

отваливай

воть можешь продолжить https://pastebin.com/V0xA6fHZ создание нового языка NLang я уж писал один оператор в строке кода, нет именнованных переменных и массивов.

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

Пишешь код на python это поэма легко и быстро, пишешь код на php это как учить гвинейский

лучше и не скажешь

Всё что сделали в последних версиях это капля в море.

Посмотрим на эту каплю. Открыл PHP: фрактал плохого дизайна, смотрю первые пункты:

PHP изначально создавался для непрограммистов(и если читать между строк не для программ); он не смог уйти от своих корней. Вот из документации по PHP 2.0 цитата о том, как делался выбор относительно приведения типов для + и прочих:

Уже говорил, да и не про развитие это.

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

Зависит от ошибок. Исключения класса Exception и подклассов перехватываются и обрабатываются чаще всего непосредственно в самой программе. Благодаря переработке обработке ошибок в 7-й версии, ПХП теперь умеет выбрасывать Error, которая останавливают программу, но которую можно перехватить.

Дизайн не имеет определённой философии. Ранний PHP был вдохновлён Perl’ом; огромная std-библиотека с «out»-параметрами из C; ОО-часть сделана как в C++ и Java.

Не так. Процедурный ПХП вдохновлён си, ОО пхп — скорее джавой.

PHP обширно черпает вдохновение из других языков, при этом ему удаётся быть непонятным для тех, кто эти языки знает. (int) выглядит как C, но int не существует. Нэймспэйсы используют . Новый синтаксис массивов получился уникальный среди всех языков с хэш-литералами: [key=>value].

Размеры инта зависят от конкретной машины (от разрядности процессора). Если число выходит за его пределы, интерпретатор пытается не допустить выход за пределы, поэтому превращает его во float. Чтобы этого не допустить, достаточно использовать ОО стиль, объявив тип.

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

Так-то нет. declare(strict_types=1)

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

Ну и пускай расширяют СПЛ.

Некоторые из проблем, описанных в этой статье на самом деле имеют первоклассное решение — если конечно вы хотите платить Zend’у за фиксы к их языку с открытыми исходниками.

Не относится к теме.

Целая куча событий происходит за сценой. Взять хотя бы вот этот код, откуда-то из PHP-документации:

@fopen('http://example.com/not-existing-file', 'r');

Если PHP скомпилирован с –disable-url-fopen-wrapper, он не будет работать. (Документация не говорит, что означает «не будет работать»; вернёт null, бросит исключение?) Заметьте, что этот флаг убрали в PHP 5.2.5.

Флаг убрали.

Если allow_url_fopen выключен в php.ini, он тоже не будет работать. (Как не будет? Нет идей.)

Так, как написано в документации, он не нашёл нужную обёртку, поэтому выдаст предупреждение.

Из-за @, предупреждение о несуществующем файле не будет выведено.

Не будет. Только если выключена опция allow_url_fopen, то до файла дело не дойдёт.

Но будет выведено, если scream.enabled установлен в php.ini.

Нет такой опции. ЕМНИП, это расширение пыхи, но больше я про него не помню.

Но не в том случае, если не установлен корректный error_reporting.

Ну да, всё логично.

Если оно будет выведено, куда оно будет выведено зависит от display_errors, снова в php.ini. Или ini_set.

Всё ещё всё логично.

Фреймворки конечно бывают разные, в том числе легковесные. Но популярные фреймворки для PHP почему то (и почему бы это?) имеют тенденцию быть именно такими - заменять собой стандартную библиотеку.

Сахар, сер. Не хотелось бы тянуть вообще всё в стандартную библиотеку.

Всё ещё всё логично.

Логично то оно логично, но ЗАЧЕМ? Зачем, мистер Андерсон? Зачем существует так много параметров, которые могут повлиять на результат работы языка? Зачем столько подковёрной возни? Зачем вообще существует такая вещь как php.ini?

Зачем существует так много параметров, которые могут повлиять на результат работы языка

Гибкость настройки.

Зачем вообще существует такая вещь как php.ini

А как настраивать интерпретатор? Он очень сложный и гибкий. Я не знаю, можно ли в питоне, но ПХП позволяет отключать стандартные функции, буквально. Да и стандартную библиотеку иногда надо как-то конфигурировать.

А как настраивать интерпретатор?

А зачем это делать из за пределов кода, контролируемого разработчиком?

ну например из безопасности

Ну то есть в интерпретаторе намеренно разработчиками оставлены дыры в безопасности и предлагается прикрывать их нашлёпками в php.ini? Или как? О какой безопасности речь? Какая угроза и как от неё защищиет наличие php.ini?

Ну да. Мы заворачиваем код третьей пыхи в классы и суем их в пространства имен. Получается офигенно ООПэшный семёрочный код.

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

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

Мы заворачиваем код третьей пыхи в классы и суем их в пространства имен

Только вот со времён третей пыхи много чего(вплоть до самой базовой работы с объектами) изменилось.

Не считаю хорошей идеей общение на эту тему дальше здесь. Создайте кто нибудь тему там продолжим.

А Joomla 4 хорош тем что в ней есть bootstrap 4

Удобно и безопасно.

Наоборот, неудобно и опасно. Ведь разработчик приложения не знает, будут ли на целевой машине включены или отключены те или иные фичи. Если что то нужное отключено, приложение упадёт. Если что то ненужное включено, может быть дыра в безопасности или непредсказуемое поведение, которое не наблюдалось на машине разработчика. Почему такой «фичи» больше ни в одном языке нет?

Нет,

и дальше подтверждает моё предположение…

Требования можно указать.

Если что то ненужное включено, может быть дыра в безопасности или непредсказуемое поведение, которое не наблюдалось на машине разработчика

Какая ещё дыра? Какое поведение? Вы получаете приложение, где написано, что должно быть включено в конфиге. Приложение само может проверить функции и изменять конфиг.

Почему такой «фичи» больше ни в одном языке нет

Слишком философский вопрос. Сфера у пыхи такая.

Вы не способны понять, что это не дыры в безопасности?

Вы получаете приложение, где написано, что должно быть включено в конфиге.

Тогда проще при запуске приложения включить всё что нужно. Зачем нужен ini? Кстати, некоторые фичи из ini нельзя менять программно из кода, если я правильно помню…

Зачем тогда их отключать, ели это не дыры?

Вообще, любой разговор о безопасности это пустословие без уточнения угрозы. От чего защищаться собрались?

Затем, что они могут быть использованы, если где-то найдётся дыра.

Допустим от подключения удалённых файлов.

Неукоснительно - неслабо что-ли?

Есть ещё xoops, и он даже живой.