Всё остальное развивается и прилагается (если требуется).
Без поддержки на уровне синтаксиса многим из этого «всё остальное» будет просто невозможно нормально пользоваться, ну или, как минимум, предельно неудобное. Например, сравните удобство работы:
со строками в чистом C и C++ (где есть поддержка классов на уровне синтаксиса);
с традиционными ФП-шными map и filter в Lua (альтернативно: Python) и Haskell (где есть удобный синтаксис для лямбда-функций и срезов операторов);
с уже упомянутым Parboiled в Java и Scala (где есть кастомные и перегруженные операторы).
Синтаксис очень важен, в отличие от вечных споров вида «фигурные скобки против begin—end».
Можно немного подробнее про OpenCL — почему он «не очень» на AMD-картах?
У самого пока что для экспериментов с OpenCL только старая nVidia-карточка. Жажду со временем разорить университет на несколько видеокарт и присматриваюсь больше к AMD — у них шина памяти шире, и стоят дешевле Тесл.
Действительно, зачем Windows поддерживать стандартизованные технологии, когда свои родные vendor lock-in'ы работают как часы? А разработчики не треснут, напишут отдельную версию для Windows.
Если без сарказма, то OpenGL — это не столько игры (которые сегодня часто изначально ориентируются на DX-рендер), сколько программы визуализации чего бы то ни было. Научных данных, например. И необходимость думать о том, что где-то там на некой очень популярной платформе может внезапно не оказаться OpenGL, лично меня, например, очень удручает.
Вы уже как-то определитесь, они единое логическое приложение или таки не связаны.
Думаю, это следует читать как «содержит набор сервисов, фреймворков и библиотек, написанных специально для приложения и нигде более в свободном виде не использующихся». Они вроде как и не связаны, но и по-отдельности никому не нужны.
«Анемичная» модель в виде массива в качестве сущности бизнес-логики, наверное, совсем не айс, но в качестве DTO — почему нет? DTO не особенно нужна инкапсуляция, а хранить массив таких объектов в глобальной переменной никто не заставляет.
Кстати, в Python есть такая вещь, как collections.namedtuple, которая очень подходит для сущностей сложнее кортежа, но недостаточно сложных для написания отдельного рукотворного класса. Уверен, что в насквозь динамическом PHP можно сделать аналог (или он уже существует).
Само собой, зло — потому и кавычки. Но концептуально «PHP Object Notation» (или «PHP Array Notation»?) ничем не хуже JSON, кроме отсутствия аналога функции json_decode.
А чем описанное в статье использование PHP-массивов принципиально отличается от JSON, который сейчас, вроде как, везде принято любить? По-моему, это абсолютно то же самое, этот код можно даже вынести в отдельный файл (с расширением .phpon?) или хранить в БД, «декодируя» вызовом функции eval. Поэтому, думаю, определённая легитимная область применения у этого подхода есть, частично совпадающая с областью применения JSON/YAML/XML.
Без поддержки на уровне синтаксиса многим из этого «всё остальное» будет просто невозможно нормально пользоваться, ну или, как минимум, предельно неудобное. Например, сравните удобство работы:
mapиfilterв Lua (альтернативно: Python) и Haskell (где есть удобный синтаксис для лямбда-функций и срезов операторов);Синтаксис очень важен, в отличие от вечных споров вида «фигурные скобки против begin—end».
У самого пока что для экспериментов с OpenCL только старая nVidia-карточка. Жажду со временем разорить университет на несколько видеокарт и присматриваюсь больше к AMD — у них шина памяти шире, и стоят дешевле Тесл.
Если без сарказма, то OpenGL — это не столько игры (которые сегодня часто изначально ориентируются на DX-рендер), сколько программы визуализации чего бы то ни было. Научных данных, например. И необходимость думать о том, что где-то там на некой очень популярной платформе может внезапно не оказаться OpenGL, лично меня, например, очень удручает.
Думаю, это следует читать как «содержит набор сервисов, фреймворков и библиотек, написанных специально для приложения и нигде более в свободном виде не использующихся». Они вроде как и не связаны, но и по-отдельности никому не нужны.
Кстати, в Python есть такая вещь, как
collections.namedtuple, которая очень подходит для сущностей сложнее кортежа, но недостаточно сложных для написания отдельного рукотворного класса. Уверен, что в насквозь динамическом PHP можно сделать аналог (или он уже существует).