1. Бессистемное именование функций, нелогичные аргументы и возвращаемые значения — приводят к постоянной путанице, ошибках в коде, сложность запоминания требует постоянного копания в справочниках. В сочетании с тем, что язык динамический, это значит, что контроль кода до запуска сильно усложнён.
2. Чрезмерно большое количество глобально видимых функций — неожиданные конфликты имён, плохая диагностика проблем от этого. Опять-таки, 16 функций вместо 1-2 — никакая память такого не выдержит, значит, листание справочников и медленный поиск решения, ослабление возможности code review глазами.
3. Отсутствие раздельных пространств имен (кажется, исправлено в самых последних версиях? но это значит, что ещё несколько лет будут тянуться хвосты и попадаться грабли).
4. Проблемы обработки пользовательских данных — по принципу "или всё сами делаем, или мучайся сам со всеми деталями".
5. Офигенная куча граблей-недоработок собственно в языке, дико непродуманная реализация, тёмные углы со странностями.
И любая разработка на нём будет означать тотальное топтание по этим граблям.
The God is real, unless declared integer.
Re: Чем конкретно чревата разработка сложных проектов на PHP
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, netch80, Вы писали:
D>>>Тем, что динамика. N>>Для типичной области использования PHP это не проблема.
D>Речь идёт о сложных проектах, не?
Да, о сложных, и это не противоречит.
The God is real, unless declared integer.
Re[2]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, 0K, Вы писали:
0K>>Хотелось бы услышать конкретные причины.
С другой стороны, из собств. опыта:
N>1. Бессистемное именование функций, нелогичные аргументы и возвращаемые значения — приводят к постоянной путанице, ошибках в коде, сложность запоминания требует постоянного копания в справочниках. В сочетании с тем, что язык динамический, это значит, что контроль кода до запуска сильно усложнён. N>2. Чрезмерно большое количество глобально видимых функций — неожиданные конфликты имён, плохая диагностика проблем от этого. Опять-таки, 16 функций вместо 1-2 — никакая память такого не выдержит, значит, листание справочников и медленный поиск решения, ослабление возможности code review глазами.
Как правило, на уровне ф-ций мало-мальски сложные проекты не пишутся. Организуется либо доменно-специфичный API в виде набора классов, либо идет кодирование поверх к-л библиотеки (yii, например) — что сводит пункты 1 и 2 (да и 4 тоже) на нет.
N>3. Отсутствие раздельных пространств имен (кажется, исправлено в самых последних версиях? но это значит, что ещё несколько лет будут тянуться хвосты и попадаться грабли).
Это также спорное утверждение. Хоть лично я склоняюсь к тому, что лучше с пространствами, нежели без них.
N>4. Проблемы обработки пользовательских данных — по принципу "или всё сами делаем, или мучайся сам со всеми деталями". N>5. Офигенная куча граблей-недоработок собственно в языке, дико непродуманная реализация, тёмные углы со странностями.
Как-то неконкретно. Я то же самое могу сказать про любой другой ЯП
N>И любая разработка на нём будет означать тотальное топтание по этим граблям.
Re[2]: Чем конкретно чревата разработка сложных проектов на
Потому что все на свете знают, что Paamayim Nekudotayim на иврите означает «два двоеточия»
— Невнятное развитие самого языка. Фичи добавляются в язык по желанию левой задней пятки неизвестно, кого. В последнее время это идет под эгидой «ну, язые же должен развиваться». При этом часто фичи добавляются со странным синтаксисом (типа пространств имен) только потому, что нятный синтаксис может сломать парсер или лексер.
— fire-and-forget. Это, безусловно, хорошо в большинстве случаев и, возможно, для REST'а. Но нет никакой возможности нормально запустить в сторонке долгоиграющий процесс на РНР, чтобы он что-то там делал. Например: загрузили картинку, положили ее в очередь, вернулись к клиенту. Очередь обрабатывается запущенным в сторонке скриптом. Хухъ.
— досаточно медленный сам по себе, но это надо смотреть конкретные задачи.
Вчера ещё открывалось, сегодня ЖЖ совсем "того", но это не повезло наложением на российские выборы. Когда закончатся — рекомендую таки прочитать. Там сводка, ссылки и обсуждения.
The God is real, unless declared integer.
Re[3]: Чем конкретно чревата разработка сложных проектов на
[...] N>>5. Офигенная куча граблей-недоработок собственно в языке, дико непродуманная реализация, тёмные углы со странностями. W>Как-то неконкретно. Я то же самое могу сказать про любой другой ЯП
См. ссылку в follow-up (когда закончится DDoS на ЖЖ), там достаточно конкретных примеров этих недоработок.
The God is real, unless declared integer.
Re[4]: Чем конкретно чревата разработка сложных проектов на
07.12.11 11:13, netch80 написав(ла): > Чёрт побьери, я тут собирался ссылку выложить, но что-то не то нажалось. > Вот что там должно было быть: http://nuclight.livejournal.com/107170.html
Спасибо, интересно. Со многим согласен. Некоторые недостатки уже частично устранены (но попробуйте-ка пораспихивать 4 тыс. стандартных функций по неймспейсам), а большинство неисправимы в принципе. И это с точки зрения перловика, по сравнению с Питоном недостатков ещё больше.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, 0K, Вы писали:
0K>>А в чем практические преимущества динамической типизации? Недостатки очевидны: сложность поиска ошибок, невозможность рефакторинга.
M>Скорость разработки на порядок быстрее.
