Насколько я понял магические методы это весьма ограниченный набор методов — в python это просто методы классов, они есть у int и у str. Базовые операции сделаны ими (в любой момент времени можно получить функцией dir список методов переданного объекта) и вы можете при желании передать в код, например не число, а свой объект который придаст коду новый смысл, например, вмеcто простого выполнения странслирует в SQL (наподобие LINQ).
Я не про наличие стандартной библиотеки, про решение включить это в сам язык — то есть вы имели ввиду поддержку сессий из коробки или поддержку сессий в синтаксисе и семантике-именно языка (в отличие от стандартной библиотеки или внешних библиотек)?
Во-первых, ассемблер довольно логичный язык (по крайней мере, те ассемблеры, которые я знаю) — это просто отражение архитектуры оборудования.
Во-вторых, про фортран я мало чего знаю, но мне знакомо выражение «программу на фортране можно написать на любом языке». Опять-таки, является ли фортран примером несистемности и самонесогласованности?
В-третьих, мне встречались программы, авторы которых подсознательно боялись длинных идентификаторов и которые содержали все прочие особенности работы в ограниченной среде, но перенесенные в среду, где таких ограничений нет — а вам нет?
Интересно, что для питона, например, есть способы встраивания.
>>>А разговоры о том, что какие-то языки как-то способствуют правильному написанию кода считаю в большой степени преувеличением. Способствуют учителя, документация, открытые проекты, литература.
Мне кажется, если сам по себе язык является примером плозого дизайна, то изучая и привыкая к нему программист приучивается к плозхому дизайну. Я помню свое впечатление нескольких лет назад, когда после написания скриптов и изучения питона, мне понадобилось попвавить скрипт на PHP и я прочитал просто введение, базовые средства языка и стандартные функции работы со строками и регуларными выражениями (там кстати, до сих пор ) — невозможно предсказать как называется функция, странные операторы поджидающие тебя прям на входе (вон во фрактальной статье "== is unusable").
И мне кажется, что это отпечаток мозга сосдателя, который не может не иметь влияния на мозг пользователей.
Мне странно, что при наличие механизма depreciated не приводят постепенно эти вещи в порядок.
>>>Как вы умудряетесь вообще критиковать PHP, не зная о нем таких базовых вещей?
Для того, чтобы критиковать вообще ничего знать не надо, при желании :). Лет пять назад, мне надо было подкурочить одну CMS на PHP и я почитал про базовые конструкции. У меня осталось весьма гаденькое впечатление от того, насколько неаккуратно и самонесогласованно все сделали.
Интерсно, почему не приняли общую схему для всего что упомянуто в разделе ‣Chunks of the library are wildly inconsistent from one another. и не сделали depreciated для всего остального?
Тут проблема в том, что PHP не только язык, но и платформа — как бы вы отнесличь, если бы рабочие сделали бы вам дом, к коророму надо подводить воду треугольных трубах. Причем сами треугольные ьрбы гораздо круче, только вот их можно купить только японского производства.
Для решения этой проблемы у Fog Creek даже свой язык есть с генератором PHP
если система типов позволяет, то можно сильно себе облегчить защиту от SQL injection.
Во-вторых, про фортран я мало чего знаю, но мне знакомо выражение «программу на фортране можно написать на любом языке». Опять-таки, является ли фортран примером несистемности и самонесогласованности?
В-третьих, мне встречались программы, авторы которых подсознательно боялись длинных идентификаторов и которые содержали все прочие особенности работы в ограниченной среде, но перенесенные в среду, где таких ограничений нет — а вам нет?
Ну это слова пользователя kashey. А Яндекс так не говорит. А для телефонов там свои SDK
>>>А разговоры о том, что какие-то языки как-то способствуют правильному написанию кода считаю в большой степени преувеличением. Способствуют учителя, документация, открытые проекты, литература.
Мне кажется, если сам по себе язык является примером плозого дизайна, то изучая и привыкая к нему программист приучивается к плозхому дизайну. Я помню свое впечатление нескольких лет назад, когда после написания скриптов и изучения питона, мне понадобилось попвавить скрипт на PHP и я прочитал просто введение, базовые средства языка и стандартные функции работы со строками и регуларными выражениями (там кстати, до сих пор ) — невозможно предсказать как называется функция, странные операторы поджидающие тебя прям на входе (вон во фрактальной статье "== is unusable").
И мне кажется, что это отпечаток мозга сосдателя, который не может не иметь влияния на мозг пользователей.
Мне странно, что при наличие механизма depreciated не приводят постепенно эти вещи в порядок.
Для того, чтобы критиковать вообще ничего знать не надо, при желании :). Лет пять назад, мне надо было подкурочить одну CMS на PHP и я почитал про базовые конструкции. У меня осталось весьма гаденькое впечатление от того, насколько неаккуратно и самонесогласованно все сделали.
Интерсно, почему не приняли общую схему для всего что упомянуто в разделе ‣Chunks of the library are wildly inconsistent from one another. и не сделали depreciated для всего остального?
Нужно ли это прям в языке?
Для решения этой проблемы у Fog Creek даже свой язык есть с генератором PHP