Понимаю, просто без этого простого типа данных в принципе гарантии "сильной" типизации уже не такие существенные, потому что эти две структуры применяются очень часто при написании кода.
В стандартной библиотеке есть класс с массивом, но он статический в стиле си, нельзя в него нельзя динамически добавлять лишние элементы. И он довольно вербозный, в реальной кодовой базе не видел, чтобы его применяли.
Это помогает конечно, но не меняет картину. Скажем в PHP есть великолепная структура хешмапамассив, которую можно задать при помощи []. Вроде бы обсуждали тут в комментариях и в языке нет способов указать явно без костылей, что нам нужно, массив настоящий (как во всех языках) или хешмапа с ключами и значениями. В этом месте как минимум при любых настройках проявляется натура слабой типизации, хотя если любой массив php воспринимать как хешмпапу и забыть о существовании массивов в принципе, то может быть и нормально.
Изначально по задумке языка SQL, сменить базу должно быть довольно легко, если писать в рамках стандарта SQL. Но что-то пошло не так...
Также довольно легко менять фреймворк и библиотеки, если их стараться не использовать. Фреймворк по факту вас в какой-то степени вендор-локают своей "гибкостью", перенести бизнес логику между фреймворками может быть не так просто, как вам кажется.
>не меняя язык, естественно А если придумают новые модные языковые конструкции, но в вашем конкретном языке нет? Есть ли у вас возможность дополнять его синтаксис, подгонять под современные реалии (скажем придумают лучшую замену парадигмы ООП)? Скорее всего нет. Но в рамках дискуссии о PHP это не имеет смысла, так как в языке даже стандартную библиотеку без костылей переопределить нельзя, не то что добавить языковые конструкции. Говорит ли это о том, что PHP негибкий язык? Скорее да. Перестают ли из-за этого использовать этот язык? Скорее нет.
Паттерны нужны для тех языков, где вне объектной модели нельзя достичь таких же результатов. Паттерны Haskell, Scala, Common Lisp, SML, Ocaml и т.д. могут отличаться и отличаться довольно сильно от паттернов принятых на мейнстримных Java-like объектных языках.
Мне кажется самым хорошим вариантом будет Slackware или какой-нибудь или такой дистрибутив, который может сразу тонны софта установить заранее, а не минимальный, где ты сам устанавливаешь по отдельности пакеты. Я не знаю есть ли в арче подобие .deb или .rpm, с ними оффлайново хотя бы пакетами можно обмениваться в приемлемом для пакетного менеджера виде, в арче вроде бы пакеты распространяются в виде "рецептов", скачай оттуда, сделай то, потом установи туда, но это не совсем то что надо. В дебиане при желании можно просто поставить скрипт, который бы скачал все эти .deb пакеты и устанавливать большую часть из них по необходимости. Также можно поднять свою билд-ферму для упомянутого NixOS и неупомянутого Guix и стараться набирать всю пакетную базу хотя бы на определённые даты.
Ни что не мешает конечно подготовиться вообще с какой-угодно Unix-подобной системой, скачав просто все исходники нужных тебе программ (через apt-src например) и собирать на своём же компьютере как в случае с билд-фермой в nixos и guix, но понадобится очень много свободного места на диске.
PHP не так плох с точки зрения того, что в языке возможно сделать используя его конструкции. У меня лично претензии скорее к историческим аспектам. Очевидный шаблонизатор, который практически заставляет настраивать редактор на автоматическую вставку <?php или пользоваться генераторами как в symfony cli, даже если тебе не нужно генерировать html. Стандартная библиотека со странным неймингом и отсутствием модульности, сам язык зовётся препроцессором, а концепция препроцессинга это прям очень сильный даунгрейд во времена C (с его include), язык модула-2 появился на 6 лет позже чем C, но намного раньше чем PHP в 1978м году (из него модульность стащил Python). В PHP нет модулей в стандартной библиотеке, если запустить php -a, то автодополнение будет работать на ~4.8к функций. Ну и слабая типизация не делает чести языку.
Из «фишек», которые есть в PHP, но нет в других языках (скриптовых) - поддержка LSP (не сервера). "Уникальный" тип данных массивохеш (в документации ещё практикуется подмена понятий из других языков) и проверка типов в рантайме без обязательного указания типа или auto. В целом PHP ощущается как C++ от мира веб-разработки, где в язык тащат вообще всё что можно, есть даже goto. Ну и из очевидных вещей не надо всякие wsgi настраивать. Ещё достаточно удобная вещь есть для дебага без дебаггера var_dump и die, в других языках есть аналоги для интроспекции, но в php вывод var_dump сделан хорошо, а die достаточно короток и понятен.
Лично мне очень не хватает объектной стандартной библиотеке с хорошим именованием. Если без объектном библиотеки, то хотя бы оператора pipe |> не хватает, чтобы собирать в цепочку вызовы функций. Ещё очень не хватает хорошего shell'а на манер python, ruby.
Подозревал, что нападка примерно в эту сторону будет. Модификаторы доступа не являются неотъемлемой частью ООП, их похоже в своё разрекламировали вместе с Java. Smalltalk, CLOS и кажется Simula не имеют модификаторов доступа, но вполне себе ООП.
Что не так? По идее в Python всё является объектом, +-*/ и т.д. просто сахар над вызовом метода у объекта числа, также как len() и другие функции это просто функция, которая дёргает метод с таким же названием у объекта из параметра функции, такая псевдо-процедурщина для неискушённых пользователей языка. Может я не в курсе чего-то, раскройте свою мысль.
Я могу привести те фичи, которые не перенял ни один язык полностью (хотя тут речь больше про реализации и культуру разработки):
REPL Driven Development. Сам подход разработки через REPL используется ограниченно (это либо полное написание программы в REPL или когда ты по мере написания кода в редакторе посылаешь куски кода в REPL, который работает на фоне и видишь сразу же результат вычисления). Из мейнстрима наверное ближайший к такому подходу Ruby, из немейнстрима языки семейства ML (SML, Ocaml, Haskell)
Хотрелоад. Можно изменять код по мере его работы через REPL, не перезапуская ни разу программу полностью. Erlang любят за подобный функционал, но он очень далёк от удобства того, что дают лиспы (могу ошибаться, с Erlang очень поверхностно знаком).
Компиляция в бинарник с рантайм системой и дебаггером. Когда какая-нибудь Java требует установки рантайма в системе, чтобы запускать программы на Java, программы на Common Lisp, собранные при помощи SBCL, дают эту рантайм систему в конечном бинаре. Из минусов всё это дело весит достаточно много и поставляется каждый раз, из плюсов смотреть предыдущий пункт.
Макросы даже сейчас далеко не в каждом языке есть. Если они есть, то зачастую весьма ограниченные.
Агностицизм стиля программирования. Вытекает из предыдущего пункта с макросами, так как язык можно расширять как вздумается. Потенциально лисп может быть приспособлен к любой парадигме без значительных сложностей. На данный момент можно писать императивно как в си (можно хоть вставки на ассемблере использовать), функционально как в каком-нибудь Haskell и в объектно-ориентированном стиле как в какой-нибудь Java. Сейчас популярно «каждый язык для своей задачи», который силён в чем-то одном, лиспы же помогают выражать свои мысли вне зависимости от задачи, хотя это не освобождает от учёта специфики используемой реализации
Рестарты. В CL есть система рестартов, которая позволяет в рантайме исправить возникающую ошибку. По неизвестной мне причине в мейнстримовых языках такого нет.
Если рассматривать язык в отрыве от реализаций и культуры разработки, то в лиспах как в наборе из текста действительно ничего примечательного нет, а скобки могут только затруднять чтение кода. Другие языки в основном впитали именно языковые особенности, а не особенности реализаций и культуры.
Функциональное программирование — это многообещающая тенденция. Скале она присуща в не меньшей степени чем ООП, и они взаимно обогащают друг друга благодаря этому языку. Рискну предположить, что скала — первый язык промышленного уровня с такими свойствами.
Разумеется не первый. Задолго до Scala вполне существовали подобные языки. Из тех что я знаю, это Common Lisp (CLOS) и Ocaml (диалект ML с элементами ООП). Если верить википедии, то эти языки повлияли на Scala. Также многие реализации языка Scheme имеют поддержку ООП, но это не определено в стандарте языка (например GNU Guile).
Мало какой язык может похвастать математически точным исчислением, лежащем в его основе.
Опять же из списка языков, которые повлияли на Scala. Standard ML и Scheme. Оба имеют формальную спецификацию. Но да, таких языков действительно мало.
Благодаря вашей статье в чатик GNU Guix'а залетели любители взломов (:
В оригинале явно речь про хакинг в старом понимании:
https://stallman.org/articles/on-hacking.html
http://www.catb.org/~esr/faqs/hacker-howto.html
Понимаю, просто без этого простого типа данных в принципе гарантии "сильной" типизации уже не такие существенные, потому что эти две структуры применяются очень часто при написании кода.
В стандартной библиотеке есть класс с массивом, но он статический в стиле си, нельзя в него нельзя динамически добавлять лишние элементы. И он довольно вербозный, в реальной кодовой базе не видел, чтобы его применяли.
https://php.net/manual/en/class.splfixedarray.php
Это помогает конечно, но не меняет картину. Скажем в PHP есть великолепная структура хешмапамассив, которую можно задать при помощи []. Вроде бы обсуждали тут в комментариях и в языке нет способов указать явно без костылей, что нам нужно, массив настоящий (как во всех языках) или хешмапа с ключами и значениями. В этом месте как минимум при любых настройках проявляется натура слабой типизации, хотя если любой массив php воспринимать как хешмпапу и забыть о существовании массивов в принципе, то может быть и нормально.
Изначально по задумке языка SQL, сменить базу должно быть довольно легко, если писать в рамках стандарта SQL. Но что-то пошло не так...
Также довольно легко менять фреймворк и библиотеки, если их стараться не использовать. Фреймворк по факту вас в какой-то степени вендор-локают своей "гибкостью", перенести бизнес логику между фреймворками может быть не так просто, как вам кажется.
>не меняя язык, естественно
А если придумают новые модные языковые конструкции, но в вашем конкретном языке нет? Есть ли у вас возможность дополнять его синтаксис, подгонять под современные реалии (скажем придумают лучшую замену парадигмы ООП)? Скорее всего нет. Но в рамках дискуссии о PHP это не имеет смысла, так как в языке даже стандартную библиотеку без костылей переопределить нельзя, не то что добавить языковые конструкции. Говорит ли это о том, что PHP негибкий язык? Скорее да. Перестают ли из-за этого использовать этот язык? Скорее нет.
На ваших проектах строгая статическая типизация. В самом языке она слабая динамическая с кучей неявных преобразований типов.
Паттерны нужны для тех языков, где вне объектной модели нельзя достичь таких же результатов. Паттерны Haskell, Scala, Common Lisp, SML, Ocaml и т.д. могут отличаться и отличаться довольно сильно от паттернов принятых на мейнстримных Java-like объектных языках.
Мне кажется самым хорошим вариантом будет Slackware или какой-нибудь или такой дистрибутив, который может сразу тонны софта установить заранее, а не минимальный, где ты сам устанавливаешь по отдельности пакеты. Я не знаю есть ли в арче подобие .deb или .rpm, с ними оффлайново хотя бы пакетами можно обмениваться в приемлемом для пакетного менеджера виде, в арче вроде бы пакеты распространяются в виде "рецептов", скачай оттуда, сделай то, потом установи туда, но это не совсем то что надо. В дебиане при желании можно просто поставить скрипт, который бы скачал все эти .deb пакеты и устанавливать большую часть из них по необходимости. Также можно поднять свою билд-ферму для упомянутого NixOS и неупомянутого Guix и стараться набирать всю пакетную базу хотя бы на определённые даты.
Ни что не мешает конечно подготовиться вообще с какой-угодно Unix-подобной системой, скачав просто все исходники нужных тебе программ (через apt-src например) и собирать на своём же компьютере как в случае с билд-фермой в nixos и guix, но понадобится очень много свободного места на диске.
Не знал про аналог в Lua, но согласитесь такой тип данных не очень популярен в языках программирования.
За рекомендацию библиотеки большое спасибо, скорее всего в ближайшее время начну использовать.
Пробовал, отличный инструмент, хотелось бы видеть его в поставке самого php вместо php -a, писать var_dump'ы и echo в шелле очень неприятно.
Согласен с приведёнными недостатками. Интересно вводу дженериков не мешает то, что основная структура данных для коллекций это массивохеш.
PHP не так плох с точки зрения того, что в языке возможно сделать используя его конструкции. У меня лично претензии скорее к историческим аспектам. Очевидный шаблонизатор, который практически заставляет настраивать редактор на автоматическую вставку <?php или пользоваться генераторами как в symfony cli, даже если тебе не нужно генерировать html. Стандартная библиотека со странным неймингом и отсутствием модульности, сам язык зовётся препроцессором, а концепция препроцессинга это прям очень сильный даунгрейд во времена C (с его include), язык модула-2 появился на 6 лет позже чем C, но намного раньше чем PHP в 1978м году (из него модульность стащил Python). В PHP нет модулей в стандартной библиотеке, если запустить php -a, то автодополнение будет работать на ~4.8к функций. Ну и слабая типизация не делает чести языку.
Из «фишек», которые есть в PHP, но нет в других языках (скриптовых) - поддержка LSP (не сервера). "Уникальный" тип данных массивохеш (в документации ещё практикуется подмена понятий из других языков) и проверка типов в рантайме без обязательного указания типа или auto. В целом PHP ощущается как C++ от мира веб-разработки, где в язык тащат вообще всё что можно, есть даже goto. Ну и из очевидных вещей не надо всякие wsgi настраивать. Ещё достаточно удобная вещь есть для дебага без дебаггера var_dump и die, в других языках есть аналоги для интроспекции, но в php вывод var_dump сделан хорошо, а die достаточно короток и понятен.
https://www.php.net/manual/ru/language.oop5.basic.php#language.oop.lsp
https://www.php.net/manual/en/control-structures.goto.php
https://www.php.net/manual/en/language.types.array.php
Лично мне очень не хватает объектной стандартной библиотеке с хорошим именованием. Если без объектном библиотеки, то хотя бы оператора pipe |> не хватает, чтобы собирать в цепочку вызовы функций. Ещё очень не хватает хорошего shell'а на манер python, ruby.
Подозревал, что нападка примерно в эту сторону будет. Модификаторы доступа не являются неотъемлемой частью ООП, их похоже в своё разрекламировали вместе с Java. Smalltalk, CLOS и кажется Simula не имеют модификаторов доступа, но вполне себе ООП.
Что не так? По идее в Python всё является объектом, +-*/ и т.д. просто сахар над вызовом метода у объекта числа, также как len() и другие функции это просто функция, которая дёргает метод с таким же названием у объекта из параметра функции, такая псевдо-процедурщина для неискушённых пользователей языка. Может я не в курсе чего-то, раскройте свою мысль.
Я могу привести те фичи, которые не перенял ни один язык полностью (хотя тут речь больше про реализации и культуру разработки):
Если рассматривать язык в отрыве от реализаций и культуры разработки, то в лиспах как в наборе из текста действительно ничего примечательного нет, а скобки могут только затруднять чтение кода. Другие языки в основном впитали именно языковые особенности, а не особенности реализаций и культуры.
Разумеется не первый. Задолго до Scala вполне существовали подобные языки. Из тех что я знаю, это Common Lisp (CLOS) и Ocaml (диалект ML с элементами ООП). Если верить википедии, то эти языки повлияли на Scala. Также многие реализации языка Scheme имеют поддержку ООП, но это не определено в стандарте языка (например GNU Guile).
Опять же из списка языков, которые повлияли на Scala. Standard ML и Scheme. Оба имеют формальную спецификацию. Но да, таких языков действительно мало.
ru.wikipedia.org/wiki/Эпиктет
www.gnu.org/philosophy/open-source-misses-the-point.html