Не совсем ясно, что мешает автору выстроить работу с заказчиком (будь то внутренний или внешний, неважно) так, что есть условная команда матерящихся через слово инженеров, крепко знающих своё дело, но не общающихся с душевно-тонкими личностями с «той стороны» и команда пахнущих ромашками менеджеров проекта, которые как раз и берут задачу «презентации» команды на себя?

Проще если. Клиента встречает метросексуал, пишет код ему бородатый вечно пьяный хакер, а по пятницам они вместе обсуждают проекты в ближайшей рюмочной?

Или вы заставляете инженеров говорить с бизнесом? Тогда может в этом проблема?

Сейчас для меня нет особо большой разницы, на чем писать.

Если писать одинаково плохо на любом языке, то действительно, нет разницы…

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

* проще было сделать импорт данных в нормализованную БД, чем пытаться построить REST API на битриксовой БД.

Собственно минусы-то за что?
Смотрим знаменитые картинки замеров производительности, коллеги:



Где же здесь «не очень производительный»?

Если вам нужна производительность, вам нужен настоящий Excel, например через COM-объекты.

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

Почитал комментарии и подумал (не судите строго дилетанта): а разве нет аналогии между тем, что у фотона нет его внутреннего времени (поскольку он двигается со скоростью света и между испусканием и поглощением по его внутренним часам всегда проходит ровно ноль) и неопределенностью пространственных координат?

Нет ли точно такой же неопределенности координаты временной, выражающейся в том, что оный фотон можно равновероятно встретить в любой точке временного отрезка его существования и только факт «наблюдения» (поглощения) сводит эту вероятность к точно определенной временной точке?

Простите, если бред ))

Тестовые стенды? Не слышали?

Собственно, если нужны серверные ресурсы, квалифицированные админы для сохранения и зеркалирования данных, программисты для оптимизации работы форума — обращайтесь. Всё дадим бесплатно.

С кем связаться из журнала, кто знает? Напишите, пожалуйста, контакты.

Базовый класс исключений для внутренних ошибок PHP.
Я не вижу никакого противоречия.

Внутри PHP возникает некая ошибка, он создает и выбрасывает исключение соответствующего класса.

Да, согласен, терминология может запутать.

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

Итак, у нас есть интерфейс Throwable. Это общий интерфейс для всех объектов, которые можно выбросить (throw) и поймать (catch).

Далее есть два класса, реализующих этот интерфейс: Error (для исключений системных) и Exception (для пользовательских). От первого наследуется большое количество системных исключений, вроде TypeError, от второго тоже немало, например InvalidArgumentException.

Важно понимать, что Error — это не ошибка. Это класс исключений, который называется «Error».

Что такое ошибки в PHP можно почитать здесь: php.net/manual/ru/errorfunc.constants.php

Почему же мы видим всё-таки ошибку Fatal error? Потому что не поймали исключение! Обратите внимание, что любое исключение, хоть наследующееся от Error, хоть от Exception, если вы его не отловите с помощью catch, всплывет по стеку вызовов до самого верха и вызовет фатальную ошибку.

Вот и всё.

Резюме:
— Error это не «ошибка», а класс исключений, называющийся «Error»
— Любой Throwable можно поймать, в том числе и любой Error
— Ошибки в PHP — не исключения, это совсем другой механизм
— Фатальная oшибка неизбежно возникает, если вы упустили любой Throwable

Исключение — это не только Exception и его наследники, но всё, что реализует Throwable.

define() работает в рантайме, const — конструкция этапа компиляции. Стоит ли говорить, что второе предпочтительнее?

Fatal error здесь потому, что исключение не было поймано. Вам никто не мешает его поймать.

Когда люди обсуждают изменения в PHP7

Нормальные программисты давно уже обсуждают изменения в PHP 8.
И стараются не использовать define()

предлагает два разных объявления типов

Никакого «объявления типов» здесь нет. Это рантайм контроль типов.
И не «сообщение об ошибке», а исключение.

Безграмотная статья.

Ваш коммент напомнил мне CRM в одной банковской организации, которую «пионеры» пытались делать на основе MongoDB…

Навскиду:
— просто так симлинк не создашь, нужны как минимум права администратора
— pcntl нет, как нет и многого другого, что требуется в многопроцессной среде, той же системы сигналов, например
— собрать ZTS — боль, использовать потоки — адская боль
— да блин, хотя бы вечная беда с регистронезависимой ФС… сколько джуниоров на это натыкались?

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

Если ваш пример запустят, условно говоря, вместо

php ./index.php

так:

php ./public/index.php

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

Неиспользование __DIR__ — это вредительство, конечно. Зато асинхронный реакт, ага.