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>Скорость разработки на порядок быстрее.
Дану?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Miroff, Вы писали:
0K>>А в чем практические преимущества динамической типизации? Недостатки очевидны: сложность поиска ошибок, невозможность рефакторинга.
M>Скорость разработки на порядок быстрее.
При невозможности рефакторинга и сложности поиска ошибок? На два порядка, ага.
Re[2]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Mamut, Вы писали:
M> — fire-and-forget. Это, безусловно, хорошо в большинстве случаев и, возможно, для REST'а. Но нет никакой возможности нормально запустить в сторонке долгоиграющий процесс на РНР, чтобы он что-то там делал. Например: загрузили картинку, положили ее в очередь, вернулись к клиенту. Очередь обрабатывается запущенным в сторонке скриптом. Хухъ.
Здравствуйте, dimgel, Вы писали:
D>При невозможности рефакторинга и сложности поиска ошибок? На два порядка, ага.
Разработки, а не поддержки. В поддержке, ясен пень, дороже. Но я тебе скажу, при такой скорости разработки дешевле выкинуть и написать еще раз чем рефакторить.
Re[7]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Miroff, Вы писали:
M>Разработки, а не поддержки. В поддержке, ясен пень, дороже.
Ну хоть это ты понимаешь. А то обычно народ кричит, что это нихрена не проблема.
M>Но я тебе скажу, при такой скорости разработки дешевле выкинуть и написать еще раз чем рефакторить.
Переписать хотя бы пару сотен килобайт кода... ага конечно.
А мне рассказывали про проект на 10 метров кода на PHP... вот там народ зверел...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Miroff, Вы писали:
M>Сравни RoR c каким-нибудь ASP.NET и проверь. Не владеешь сам, попроси оценить других. То, что на ASP.NET делается неделю, на RoR делается за полдня.
Так это не из-за динамической типизации, а из-за метапрограммирования.
А если взять статически типизированный язык с метапрограммированием то... http://code.google.com/p/nemerleonrails/source/browse/
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, gegMOPO4, Вы писали:
MOP>Более простой, естественный код, меньше синтаксического шума.
Это не правда.
То что в жабе все плохо это не проблема статической типизации, а проблема жабы.
MOP>Быстрее компиляция.
Секунда или меньше разницы никакой. Совсем.
MOP>Ну и всё, что из этого следует.
И что же из этого следует?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Чем конкретно чревата разработка сложных проектов на PHP
M>> — fire-and-forget. Это, безусловно, хорошо в большинстве случаев и, возможно, для REST'а. Но нет никакой возможности нормально запустить в сторонке долгоиграющий процесс на РНР, чтобы он что-то там делал. Например: загрузили картинку, положили ее в очередь, вернулись к клиенту. Очередь обрабатывается запущенным в сторонке скриптом. Хухъ.
AB>А в чем препятствие? Можно же.
ДОполнительный геморрой и костыли. Нормального внятного способа нет
Здравствуйте, WolfHound, Вы писали:
WH>Ну хоть это ты понимаешь. А то обычно народ кричит, что это нихрена не проблема.
Это зависит от срока жизни кода. Если код живет 3-5 лет это действительно не проблема.
WH>Переписать хотя бы пару сотен килобайт кода... ага конечно.
Динамическая типизация не отменяет функциональной декомпозиции. Если у кого-то модули по паре сотен килобайт на динамическом языке, то этот кто-то, очевидно, сам себе буратино. Особенно если у него нет тестов.
Re[8]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, WolfHound, Вы писали:
WH>Так это не из-за динамической типизации, а из-за метапрограммирования.
Ага, кто-нибудь кроме завсегдатаев RSDN верит в метапрограммирование как серебряную пулю?
WH>А если взять статически типизированный язык с метапрограммированием то... WH>http://code.google.com/p/nemerleonrails/source/browse/
Кто-нибудь уже взял или пока все только теоретически?
Re[4]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Mamut, Вы писали:
M> AB>А в чем препятствие? Можно же. M> ДОполнительный геморрой и костыли. Нормального внятного способа нет
Хорошо, а что ты понимаешь под нормальным внятным способом?
По мне, так поставить gearman в качестве диспетчера и подключить к нему агентов, которые занимаются обработкой задач из очереди, является вполне внятным нормальным способом.
Здравствуйте, Miroff, Вы писали:
WH>>Так это не из-за динамической типизации, а из-за метапрограммирования. M>Ага, кто-нибудь кроме завсегдатаев RSDN верит в метапрограммирование как серебряную пулю? Все что умеет RoR благодаря матапрограммированию, а не динамической типизации.
Это факт.
Спорить с этим просто глупо.
M>Кто-нибудь уже взял или пока все только теоретически?
Так, а я тебе ссылку на что дал?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Miroff, Вы писали:
WH>>Ну хоть это ты понимаешь. А то обычно народ кричит, что это нихрена не проблема. M>Это зависит от срока жизни кода. Если код живет 3-5 лет это действительно не проблема. Пара месяцев это уже проблема.
Ибо рефакторить без статической типизации практически невозможно.
А как править код на динамически типизированном языке, в который ты хотя бы полгода не заглядывал, я вообще не понимаю.
Ведь за это время все забудешь.
M>Динамическая типизация не отменяет функциональной декомпозиции. Если у кого-то модули по паре сотен килобайт на динамическом языке, то этот кто-то, очевидно, сам себе буратино. И как тут помогут модули, если они никаких контрактов не определяют и не проверяют?
Типов то нет.
M>Особенно если у него нет тестов. И сколько же должно быть этих тестов? 200% или больше от объема основного кода?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, WolfHound, Вы писали:
WH> Пара месяцев это уже проблема.
Проблема для чего? Для того чтобы вносить изменения рефакторинг не обязателен.
WH>Ибо рефакторить без статической типизации практически невозможно.
Достаточное тестовое покрытие заменяет статическую типизацию. Тесты даже лучше, потому что проверяют не какие попало инварианты, а ровно те что надо.
WH>А как править код на динамически типизированном языке, в который ты хотя бы полгода не заглядывал, я вообще не понимаю. WH>Ведь за это время все забудешь.
Это вопрос привычки и дисциплины кодирования. К сожалению опыт на статических языках в опыт на динамических языках конвертируется с отрицательным коэффициентом. Это проблема, да.
WH> И как тут помогут модули, если они никаких контрактов не определяют и не проверяют?
Тесты же. И контракты и проверяют.
WH>Типов то нет.
Прикинь, бывают контракты и без типов.
WH> И сколько же должно быть этих тестов? 200% или больше от объема основного кода?
Ровно столько, сколько нужно в зависимости от планируемых изменений и исходной сложности. Самое прикольное, что на динамических языках код получается лаконичнее и требует меньше тестов, чем код на статических языках для того же процента покрытия.
Re[11]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Miroff, Вы писали:
WH>>Спорить с этим просто глупо. M>Спорить с эзотерическими верованиями действительно глупо.
Ох. http://www.google.ru/search?q=Ruby%20on%20Rails%20metaprogramming
WH>>Так, а я тебе ссылку на что дал? M>На какое-то никому не известное поделие сомнительного качества.
Слив засчитан.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Miroff, Вы писали:
WH>>Так, а я тебе ссылку на что дал? M>На какое-то никому не известное поделие сомнительного качества.
Коллега, Вы поднимаете старые заснувшие флеймы и будите весь муравейник
Тут присутствует некоторое количество апологетов Nemerle, декларирующих его как панацею практически от всех проблем и, в частности, решением задачи метапрограммирования при статической типизации. При этом они в состоянии задолбать небольшого слона своим упорным долблением в одну и ту же точку. WH — самый выдающийся из них.
При этом того Nemerle ещё не было в сколь-нибудь доступном посторонним состоянии (я, например, буду пробовать когда они съедут с .NET на что-то менее извращённое и более доступное), но задолбали таки всех.
Назвать их продукт "никому не известное поделие сомнительного качества", конечно, справедливо, но возбудит самый лютый баттхерт, который только возможен в пределах RSDN.
Так что рекомендую игнорировать, по крайней мере пока оно не будет доступно для нормального использования.
The God is real, unless declared integer.
Re[12]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, netch80, Вы писали:
N>Тут присутствует некоторое количество апологетов Nemerle, декларирующих его как панацею практически от всех проблем и, в частности, решением задачи метапрограммирования при статической типизации.
Ты даже не понял о чем разговор.
Данный коллега не понимает что все плюшки RoR это не динамическая типизация, а метапрограммирование.
Данный факт он назвал "эзотерическими верованиями".
Я просто показал ему, что это все возможно и без динамической типизации.
На что получил жуткий батхерт и отрицание фактов.
Только и всего.
N>Назвать их продукт "никому не известное поделие сомнительного качества", конечно, справедливо, но возбудит самый лютый баттхерт, который только возможен в пределах RSDN. Батхерт тут возникает у димистов когда им показывают что на статике можно писать также как на динамике но без минусов динамики.
А вот такое колдунство вас ребятишки вгонит в полную депрессию. http://goto.ucsd.edu/~rjhala/liquid/
Если конечно найдете в себе силы прочитать, а не как обычно отрицать факты.
И заметь, там нет ни слова про немерле.
И вообще я не за немерле, а за создание статически типизированных ДСЛ под задачу.
А немерле просто самая адекватная из существующих реализаций.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Miroff, Вы писали:
M>>Сравни RoR c каким-нибудь ASP.NET и проверь. Не владеешь сам, попроси оценить других. То, что на ASP.NET делается неделю, на RoR делается за полдня. WH>Так это не из-за динамической типизации, а из-за метапрограммирования.
Я бы сказал, что дело не в том, из-за чего, а в том, что исходное утверждение на действительно крупных и сложных проектах вообще неверно. Оно становится неверным уже после первого крупного рефакторинга.
Re[13]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, netch80, Вы писали:
N>>Тут присутствует некоторое количество апологетов Nemerle, декларирующих его как панацею практически от всех проблем и, в частности, решением задачи метапрограммирования при статической типизации. WH>Ты даже не понял о чем разговор.
Это тебе так кажется.
WH>Данный коллега не понимает что все плюшки RoR это не динамическая типизация, а метапрограммирование.
Нет никаких оснований к подобному выводу.
WH>Данный факт он назвал "эзотерическими верованиями". WH>Я просто показал ему, что это все возможно и без динамической типизации. WH>На что получил жуткий батхерт и отрицание фактов. WH>Только и всего.
Ты проинтерпретировал всё по-своему, влез в своём стандартном стиле без нормального объяснения позиции, облил помоями и закономерно был послан нафиг.
N>>Назвать их продукт "никому не известное поделие сомнительного качества", конечно, справедливо, но возбудит самый лютый баттхерт, который только возможен в пределах RSDN. WH> Батхерт тут возникает у димистов когда им показывают что на статике можно писать также как на динамике но без минусов динамики. WH>А вот такое колдунство вас ребятишки вгонит в полную депрессию. WH>http://goto.ucsd.edu/~rjhala/liquid/ WH>Если конечно найдете в себе силы прочитать, а не как обычно отрицать факты.
А ты объясни внятно, так, чтобы массы поняли (а не только узкий круг ограниченных людей (tm)). А не кидаясь голыми ссылками с последующими "я дартаньян, а вы всё равно ниасилите". Переведи, проиллюстрируй. Хотя бы в стиле хабра.
Хотя кому я это предлагаю, смешно же...
WH>И заметь, там нет ни слова про немерле. WH>И вообще я не за немерле, а за создание статически типизированных ДСЛ под задачу. WH>А немерле просто самая адекватная из существующих реализаций.
Я уже объяснил, почему и для каких пор его для меня не существует.
The God is real, unless declared integer.
Re[9]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Miroff, Вы писали:
M>Ага, кто-нибудь кроме завсегдатаев RSDN верит в метапрограммирование как серебряную пулю?
Среди всего бреда, который развели тут в теме, пожалуй откомментирую именно этот пост
— Я не завсегдатай КЫВТ — по времени я куда больше сижу на ЛОР/development
— Я не просто "верю в метапрограммирование" — я его активно использую. Не на nemerle, конечно же — используется динамический ЯП.
— Т.к. работа идет в команде, сложилось такое наблюдение относительно метакода: почти все короткое и элегантное, но труднопонимаемое, вырезается путем рефакторинга (sic!) в пользу более простого и "прямого" кода при попадании в production. В "сухом" остатке, выводится удел приставки "мета-" — прототипирование и/или ориентация на write-only.
Re[14]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, netch80, Вы писали:
WH>>Данный коллега не понимает что все плюшки RoR это не динамическая типизация, а метапрограммирование. N>Нет никаких оснований к подобному выводу.
Он это прямым текстом сказал.
WH> Все что умеет RoR благодаря матапрограммированию, а не динамической типизации.
WH>Это факт.
WH>Спорить с этим просто глупо.
Спорить с эзотерическими верованиями действительно глупо.
Все еще утверждаешь, что нет оснований?
Или хочешь сказать, что RoR это не метапрограммирование чуть более чем полностью и 150 тысяч ссылок в гугле это тоже мои фантазии?
N>Ты проинтерпретировал всё по-своему, влез в своём стандартном стиле без нормального объяснения позиции, облил помоями и закономерно был послан нафиг.
А вот я вижу все иначе:
Человек сказал, что динамика рулит, ибо RoR круче ASP.NET.
Я сказал, что это не из-за динамики, а из-за метапрограммирования и что оно возможно и со статической типизацией.
И даже ссылку на решение привел.
После чего у человека случился батхерт:
Ага, кто-нибудь кроме завсегдатаев RSDN верит в метапрограммирование как серебряную пулю?
N>А ты объясни внятно, так, чтобы массы поняли (а не только узкий круг ограниченных людей (tm)). А не кидаясь голыми ссылками с последующими "я дартаньян, а вы всё равно ниасилите". Переведи, проиллюстрируй. Хотя бы в стиле хабра.
А зачем? Там в доках все очень подробно разжёвано и в рот положено.
N>Хотя кому я это предлагаю, смешно же...
Так и знал, что даже не попытаешься почитать.
N>Я уже объяснил, почему и для каких пор его для меня не существует.
У тебя тоже жуткий батхерт.
Я вообще тут про другое говорил. Но пришёл ты и начал разводить срач на тему немерле.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Wolverrum, Вы писали:
W>В "сухом" остатке, выводится удел приставки "мета-" — прототипирование и/или ориентация на write-only.
У тебя какое-то странное мета.
При правильном мета его никто не будет выпиливать, ибо без него кода будет минимум в десятки раз больше и понять его будет намного сложнее.
Возьмем, например вот этот код: https://github.com/rsdn/nemerle/blob/master/snippets/csharp-parser/CSharpParser/Parser.n
Из него генерируется 75 тысяч строк прямолинейного, но совершенно нечитаемого кода.
Хочешь сказать, что заменишь одно на другое?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, netch80, Вы писали:
WH>>>Данный коллега не понимает что все плюшки RoR это не динамическая типизация, а метапрограммирование. N>>Нет никаких оснований к подобному выводу. WH>Он это прямым текстом сказал.
Нет.
WH>
WH>> Все что умеет RoR благодаря матапрограммированию, а не динамической типизации.
WH>>Это факт.
WH>>Спорить с этим просто глупо.
WH>Спорить с эзотерическими верованиями действительно глупо.
Твоя повязка на глаза выделяет из этого только то, что "с эзотерическими верованиями" относилось к "благодаря метапрограммированию". А я без повязки вижу и то, что можно это с таким же успехом отнести и к "...а не статической типизации".
WH>Или хочешь сказать, что RoR это не метапрограммирование чуть более чем полностью и 150 тысяч ссылок в гугле это тоже мои фантазии?
Я хочу сказать, что ты вычитываешь только то, что хочешь вычитать. Поэтому дискуссия с тобой на любые темы за пределами конкретных технических примеров выливается в что-то очень странное (мягко говоря).
WH>После чего у человека случился батхерт: WH>
WH>Ага, кто-нибудь кроме завсегдатаев RSDN верит в метапрограммирование как серебряную пулю?
И опять-таки есть разница между использованием, верой и "верой как в серебряную пулю".
N>>А ты объясни внятно, так, чтобы массы поняли (а не только узкий круг ограниченных людей (tm)). А не кидаясь голыми ссылками с последующими "я дартаньян, а вы всё равно ниасилите". Переведи, проиллюстрируй. Хотя бы в стиле хабра. WH>А зачем? Там в доках все очень подробно разжёвано и в рот положено.
Это для тебя, для меня (не скромничаю, но при необходимости и не такое осиливали). А теперь повтори для широких народных масс.
N>>Хотя кому я это предлагаю, смешно же... WH>Так и знал, что даже не попытаешься почитать.
Опять смешные домыслы. Ну когда ты начнёшь оценивать свои выбрыки со стороны?
N>>Я уже объяснил, почему и для каких пор его для меня не существует. WH>У тебя тоже жуткий батхерт.
В ответ на твой, и пока есть время и настроение.
WH>Я вообще тут про другое говорил. Но пришёл ты и начал разводить срач на тему немерле.
Конечно, надо же было пояснить, куда его заведут местные сусанины...
The God is real, unless declared integer.
Re[5]: Чем конкретно чревата разработка сложных проектов на
M>> AB>А в чем препятствие? Можно же. M>> ДОполнительный геморрой и костыли. Нормального внятного способа нет
AB>Хорошо, а что ты понимаешь под нормальным внятным способом? AB>По мне, так поставить gearman в качестве диспетчера и подключить к нему агентов, которые занимаются обработкой задач из очереди, является вполне внятным нормальным способом.
Что это, как не костыль? А просто запустить долгоживущий процесс, который будет преиодически считывать очередь?
N>>Назвать их продукт "никому не известное поделие сомнительного качества", конечно, справедливо, но возбудит самый лютый баттхерт, который только возможен в пределах RSDN. WH> Батхерт тут возникает у димистов когда им показывают что на статике можно писать также как на динамике но без минусов динамики.
Здравствуйте, netch80, Вы писали:
N>Твоя повязка на глаза выделяет из этого только то, что "с эзотерическими верованиями" относилось к "благодаря метапрограммированию". А я без повязки вижу и то, что можно это с таким же успехом отнести и к "...а не статической типизации".
1)Выделенного в диалоге не было.
2)Плюшки RoR существуют благодоря матапрограммированию. Спорить будешь?
Восстановим контекст:
WH>>>Так это не из-за динамической типизации, а из-за метапрограммирования. M>>Ага, кто-нибудь кроме завсегдатаев RSDN верит в метапрограммирование как серебряную пулю?
WH>Все что умеет RoR благодаря матапрограммированию, а не динамической типизации.
WH>Это факт.
WH>Спорить с этим просто глупо.
Спорить с эзотерическими верованиями действительно глупо.
Твои попытки оправдать коллегу выглядят очень смешными.
Твой + на этом
сообщении также подтверждает версию насчет батхерта на тему наездов на динамическую типизаци.
N>Я хочу сказать, что ты вычитываешь только то, что хочешь вычитать. Поэтому дискуссия с тобой на любые темы за пределами конкретных технических примеров выливается в что-то очень странное (мягко говоря).
Я читаю то, что написано.
Коллега отрицает то, что RoR это метапрограммирование.
Любому у кого не случается батхерт на слова "динамическая типизация сосет" это очевидно.
N>Это для тебя, для меня (не скромничаю, но при необходимости и не такое осиливали). А теперь повтори для широких народных масс.
Зачем повторять хорошо написанную статью своими словами?
N>В ответ на твой, и пока есть время и настроение.
У меня его нет.
Я просто динамистов тролю.
И это знаешь ли очень весело смотреть на то как вы пытаетесь спорить с фактами.
N>Конечно, надо же было пояснить, куда его заведут местные сусанины...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Mamut, Вы писали:
WH>> Батхерт тут возникает у димистов когда им показывают что на статике можно писать также как на динамике но без минусов динамики. M>Свежо предание, агаага: http://rsdn.ru/forum/philosophy/4270550.aspx
Здравствуйте, netch80, Вы писали:
N>И опять-таки есть разница между использованием, верой и "верой как в серебряную пулю".
И на счет серебрянных пуль:
There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
Метапрограммирование в некоторых случаях не то что на порядок, на несколько порядков производительность программистов поднимает.
С reliability и simplicity тоже все очень хорошо.
Так что метапрограммирование это оно и есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Mamut, Вы писали:
M> AB>По мне, так поставить gearman в качестве диспетчера и подключить к нему агентов, которые занимаются обработкой задач из очереди, является вполне внятным нормальным способом. M> Что это, как не костыль? А просто запустить долгоживущий процесс, который будет преиодически считывать очередь?
Эм... А я про что выше написал?
* Короткоживущий процесс (скажем, скрипт, вызываемый веб-сервером) кидает задание в очередь и завершает работу.
* Запущены долгоживущие процессы-агенты, которые подключены к диспетчеру очереди.
* При получении задания диспетчер очереди информирует нужные процессы о новых заданиях.
* По окончанию обработки задания, задача удаляется из очереди с различными пред/пост условиями (типа проверки на ошибки, количества попыток выполнения и т.д.)
Разница с твоими словами лишь в том, что процесс не считывает очередь периодически (потребляя лишние ресурсы), а висит в ожидании нотификации от диспетчера или системного сигнала.
То, что в php нет собственного диспетчера очереди — так он там и не нужен в силу того, что существует множество реализаций на вкус и цвет.
WH>>> Батхерт тут возникает у димистов когда им показывают что на статике можно писать также как на динамике но без минусов динамики. M>>Свежо предание, агаага: http://rsdn.ru/forum/philosophy/4270550.aspx
Здравствуйте, Mamut, Вы писали:
M>ты считаешь приведенную ссылку доказательством твоей правоты?
Так по ней столько батхерта что аж жуть.
Причем на ровном месте.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Чем конкретно чревата разработка сложных проектов на
M>>ты считаешь приведенную ссылку доказательством твоей правоты? WH>Так по ней столько батхерта что аж жуть. WH>Причем на ровном месте.
Вообще-то,я там предельно кратко описал всю суть твоей «аргументации». Как только тебе начинаешь приводить примеры/контрпримеры из существующих языков со стат. типизацией, ВНЕЗАПНО оказывается, что языки не те, или в них реализовано не так, либо еще что-то, сводя все к Неуловимому Джомерле
И да, я тут недавно наткнулся на хорошее выступление одно: What We Actually Know About Software Development, and Why We Believe It's True. Совеую посмотреть. Обычно любые выступления типа «X sucks, Y rules» являются ничем не подтвержденным, неподкрепленным и необснованным личным мнением (эвфемизм для буллшита).
N>>И опять-таки есть разница между использованием, верой и "верой как в серебряную пулю". WH>И на счет серебрянных пуль: WH>
WH>There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
WH>Метапрограммирование в некоторых случаях не то что на порядок, на несколько порядков производительность программистов поднимает. WH>С reliability и simplicity тоже все очень хорошо. WH>Так что метапрограммирование это оно и есть.
Здравствуйте, Mamut, Вы писали:
M> M>> AB> * Запущены долгоживущие процессы-агенты, которые подключены к диспетчеру очереди. M> M>> На РНР? 0_о M> AB>Ну да, а что именно смущает? M> Именно это и смущает
Либо ты чего-то не договариваешь, либо я чего-то не понимаю, но на практике с этим нет абсолютно никаких проблем.
Ты что хочешь сказать, что написать 75 тысяч строк быстрее, чем 600?
Или может ты хочешь сказать, что 75 тысяч строк проще понять, чем 600?
Или может ты утверждаешь, что в 75 тысячах строк ты сделаешь меньше ошибок, чем в 600х строк?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Mamut, Вы писали:
M>Вообще-то,я там предельно кратко описал всю суть твоей «аргументации». Как только тебе начинаешь приводить примеры/контрпримеры из существующих языков со стат. типизацией, ВНЕЗАПНО оказывается, что языки не те, или в них реализовано не так, либо еще что-то, сводя все к Неуловимому Джомерле Батхерт просто зашкаливает.
Все что ты сказал, говорит лишь о том что ты очень сильно хочешь доказать преимущества динамики перед статикой но выходит только когда сравниваешь с уродцами типа жабы.
Поэтому ты всеми силами пытаешься опустить нормальные языки, называя их всякими нехорошими словами.
M>И да, я тут недавно наткнулся на хорошее выступление одно: What We Actually Know About Software Development, and Why We Believe It's True. Совеую посмотреть. Обычно любые выступления типа «X sucks, Y rules» являются ничем не подтвержденным, неподкрепленным и необснованным личным мнением (эвфемизм для буллшита).
Так данных то у меня полно.
Только ты их все тупо игнорируешь.
А то и просто жульничаешь. Например, когда ты размахивал бенчмарками ерланга, которые скорость ИО измеряли.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Чем конкретно чревата разработка сложных проектов на
M>> M>> AB> * Запущены долгоживущие процессы-агенты, которые подключены к диспетчеру очереди. M>> M>> На РНР? 0_о M>> AB>Ну да, а что именно смущает? M>> Именно это и смущает
AB>Либо ты чего-то не договариваешь, либо я чего-то не понимаю, но на практике с этим нет абсолютно никаких проблем.
На практике мы не смогли подружить Zend Framework с CLI (который, как я понимаю — единственный способ запустить долгоиграющий PHP-процесс)
WH>Ты что хочешь сказать, что написать 75 тысяч строк быстрее, чем 600? WH>Или может ты хочешь сказать, что 75 тысяч строк проще понять, чем 600? WH>Или может ты утверждаешь, что в 75 тысячах строк ты сделаешь меньше ошибок, чем в 600х строк?
Ни один из этих опросов не являются ответом на мой вопрос.
M>>Вообще-то,я там предельно кратко описал всю суть твоей «аргументации». Как только тебе начинаешь приводить примеры/контрпримеры из существующих языков со стат. типизацией, ВНЕЗАПНО оказывается, что языки не те, или в них реализовано не так, либо еще что-то, сводя все к Неуловимому Джомерле WH> Батхерт просто зашкаливает. WH>Все что ты сказал, говорит лишь о том что ты очень сильно хочешь доказать преимущества динамики перед статикой но выходит только когда сравниваешь с уродцами типа жабы. WH>Поэтому ты всеми силами пытаешься опустить нормальные языки, называя их всякими нехорошими словами.
Я ничего не хочу доказать и ничего никуда не опускаю. Батхерт, судя по всему, только у тебя Ж-\
M>>И да, я тут недавно наткнулся на хорошее выступление одно: What We Actually Know About Software Development, and Why We Believe It's True. Совеую посмотреть. Обычно любые выступления типа «X sucks, Y rules» являются ничем не подтвержденным, неподкрепленным и необснованным личным мнением (эвфемизм для буллшита). WH>Так данных то у меня полно. WH>Только ты их все тупо игнорируешь.
Ссылки в студию. Не hearsay и anecdotal evidence, а конкретные исследования, доказывающие твои лозунги.
WH>А то и просто жульничаешь. Например, когда ты размахивал бенчмарками ерланга, которые скорость ИО измеряли.
Жульничества там нет, там показано, что твой Неуловимый Джо для таких же задач тупо не нужен.
Здравствуйте, Mamut, Вы писали:
M> AB>Либо ты чего-то не договариваешь, либо я чего-то не понимаю, но на практике с этим нет абсолютно никаких проблем. M> На практике мы не смогли подружить Zend Framework с CLI (который, как я понимаю — единственный способ запустить долгоиграющий PHP-процесс)
Наиболее вероятно, проблема не в PHP, а в ZF (я лично достаточно скептически отношусь к данному фреймворку). Тем не менее, в моей реальности, как раз на нем ребята и запускают подобные процессы. Если еще актуально, могу дать контакты — возможно, проконсультируют.
M>> AB>Либо ты чего-то не договариваешь, либо я чего-то не понимаю, но на практике с этим нет абсолютно никаких проблем. M>> На практике мы не смогли подружить Zend Framework с CLI (который, как я понимаю — единственный способ запустить долгоиграющий PHP-процесс)
AB>Наиболее вероятно, проблема не в PHP, а в ZF (я лично достаточно скептически отношусь к данному фреймворку). Тем не менее, в моей реальности, как раз на нем ребята и запускают подобные процессы. Если еще актуально, могу дать контакты — возможно, проконсультируют.
Да не, уже не надо, написали нужный функционал на Питоне
Здравствуйте, WolfHound, Вы писали:
WH>Любому у кого не случается батхерт на слова "динамическая типизация сосет" это очевидно.
В данном случае мы наблюдаем классический баттехерт у любителя статики, который внезапно узнал что можно программировать без того чтобы заниматься извращенным сексом с системой типов.
WH>Я просто динамистов тролю.
Чтобы тролить динамистов, хорошо бы сперва показать преимущества своего языка на тех же задачах. Пока что одни общие слова и теоретические статьи. Как насчет практики: взять свой nemerle on rails и поучаствовать в каком-нибудь контесте?
WH>И это знаешь ли очень весело смотреть на то как вы пытаетесь спорить с фактами.
Какими фактами? Маргинальность статически-типизированных языков в вебе это факт. Маргинальность метапрограммирования как практики это тоже факт. В любом сборнике best pacticies полно призывов соблюдать осторожность при использовании макросов, templates, reflaction. Высокая производительность программистов на динамических языках тоже факт. Не с чем тут спорить.
Re[20]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Mamut, Вы писали:
M>Ни один из этих опросов не являются ответом на мой вопрос.
Давай прямо тут, и проведем исследование. http://rsdn.ru/poll/3390.aspx
Здравствуйте, Miroff, Вы писали:
M>В данном случае мы наблюдаем классический баттехерт у любителя статики, который внезапно узнал что можно программировать без того чтобы заниматься извращенным сексом с системой типов.
Система типов это лучший помощник.
С ее помощью я могу после полугодового перерыва залезть в код. Исправить несколько сотен строк в десятках файлов.
И не сломать ни одного теста.
Слабо повторить на динамике?
M>Чтобы тролить динамистов, хорошо бы сперва показать преимущества своего языка на тех же задачах. Пока что одни общие слова и теоретические статьи. Как насчет практики: взять свой nemerle on rails и поучаствовать в каком-нибудь контесте?
Так там же в демках есть реализация одного из этих твоих контестов.
M>Какими фактами? Маргинальность статически-типизированных языков в вебе это факт.
ЛОЛ.
Около 30% всех сайтов написано на статически типизированных языках.
Причем на динамике пишут в основном домашние странички Васей Пупкиних на которые никто не ходит.
И таких страничек очень много.
При этом чуть менее чем весь крупняк это статически типизированные языки.
M>Маргинальность метапрограммирования как практики это тоже факт.
Твой любимый RoR это метапрограммирование на 100%. Это блин факт.
M>В любом сборнике best pacticies полно призывов соблюдать осторожность при использовании макросов, templates, reflaction.
Макросы они очень разные бывают.
Я сам категорически против тех макросов что в С/С++. Да и к шаблонам С++ отношусь весьма скептически.
А что касается рефлекшена то не любителю динамики говорить о том, что его не рекомендуют.
Ибо его не рекомендуют именно по тому, что код с ним компилятором не проверить. IDE не работает. Да и тормозит он.
Это как раз то, что не люблю в динамически типизированных языках.
M>Высокая производительность программистов на динамических языках тоже факт. Не с чем тут спорить.
Ну да... в течение пары недель она сравнима с производительностью программиста на статически типизированным языке с выводом типов и метапрограммированием.
За то когда начинается поддержка и изменение требований.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, Sheridan, Вы писали:
S>>Язык сам по себе недодуман, не вычищен. От релиза к релизу вполне возможно разное поведение. Школоло, вобщем.
0K>В общем мы и так все знаем. А нужно конкретно.
Это и есть конкретно. Даже при минорном апдейте пхп может сломаться вся система.
Хотя есть очень неплохие большие проекты на пхп (тот же drupal), но они тоже периодически дохнут при обновлении, после чего приходится ждать патчей.
Вам грозит удвоенное количество работы по поддержке продукта: собственно, обычная поддержка, плюс поддержка обновлений пхп.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[21]: Чем конкретно чревата разработка сложных проектов на
M>>Грош цена такому исследованию. WH>Долго же ты этот ответ придумывал.
Просто не заходил на RSDN
WH>Хотя я другого и не ожидал.
А что ты ожидал? «Ах, да, Вульф, родненький, извини, конечно, все, что ты говоришь — истина в последней инстанции, а нерепрезентативная выборка в голосовании на RSDN — это, безусловно, серьезное исследование, являющееся дополнительным подтверждением твоих слов, каждое из которых нужно всенепременнейше отливать в бронзе, а то и выпиливать в граните»?
Пока что подавляющее большинство твоих заявлений являются, мягко говоря, голословными. Но безапелляционности в них — хоть камазами развози.
Здравствуйте, Mamut, Вы писали:
M>а нерепрезентативная выборка в голосовании на RSDN
И чем же выборка не репрезентативна?
Этот опрос имеет смысл только среди программистов.
Тут масса программистов работающих в разных сферах и использующих разные инструменты.
Так что с выборкой все нормально.
M>Пока что подавляющее большинство твоих заявлений являются, мягко говоря, голословными. Но безапелляционности в них — хоть камазами развози.
Они являются очевидными для 90% программистов.
Что голосование и показало.
И вообще, по-моему, это самое однозначное голосование после этого
Здравствуйте, WolfHound, Вы писали:
M>>Пока что подавляющее большинство твоих заявлений являются, мягко говоря, голословными. Но безапелляционности в них — хоть камазами развози. WH>Они являются очевидными для 90% программистов. WH>Что голосование и показало.
Зато связь этого голосования с поднятой темой ровно такая же, как "95% умерших от рака лёгких ели свежие огурцы, а 99.9% носили штаны. Поэтому надо запретить огурцы и штаны."
И, очевидно, ты сам знаешь, какую разводишь демагогию.
WH>И вообще, по-моему, это самое однозначное голосование после этого
Здравствуйте, netch80, Вы писали:
N>Зато связь этого голосования с поднятой темой ровно такая же, как "95% умерших от рака лёгких ели свежие огурцы, а 99.9% носили штаны. Поэтому надо запретить огурцы и штаны." N>И, очевидно, ты сам знаешь, какую разводишь демагогию.
Никакой демагогии в моих сообщениях нет.
Сравнивались два языка. На одном из которых нужно написать на 2 порядка больше кода, чем на другом.
Мамут попытался спорить с совершенно очевидными для чуть менее чем всех программистов утверждениями.
Что данное голосование и показало.
N>Если так — то снимай штаны.
Ты о чем? Что-то я не пойму, причем тут эти твои сексуальные фантазии?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, netch80, Вы писали:
N>>Зато связь этого голосования с поднятой темой ровно такая же, как "95% умерших от рака лёгких ели свежие огурцы, а 99.9% носили штаны. Поэтому надо запретить огурцы и штаны." N>>И, очевидно, ты сам знаешь, какую разводишь демагогию. WH>Никакой демагогии в моих сообщениях нет. WH>Сравнивались два языка. На одном из которых нужно написать на 2 порядка больше кода, чем на другом.
Тут ещё правда (если верить твоему примеру со сравнениями чисел — в чём я лично сомневаюсь).
WH>Мамут попытался спорить с совершенно очевидными для чуть менее чем всех программистов утверждениями.
А вот это уже ложь.
WH>Что данное голосование и показало.
Оно показало, что 2+2=4.
N>>Если так — то снимай штаны. WH>Ты о чем? Что-то я не пойму, причем тут эти твои сексуальные фантазии?
Про сексуальные — твои домыслы, что характерно.
The God is real, unless declared integer.
Re[25]: Чем конкретно чревата разработка сложных проектов на
M>>а нерепрезентативная выборка в голосовании на RSDN WH>И чем же выборка не репрезентативна? WH>Этот опрос имеет смысл только среди программистов. WH>Тут масса программистов работающих в разных сферах и использующих разные инструменты. WH>Так что с выборкой все нормально.
Угу. У тебя есть данные о сферах деятельности программистов? У тебя есть данные об уровне этих программистов? У тебя есть данные о проектах, в которых эти программисты примняли метапрограммирование и можно ли сравнивать их опыт? У тебя есть данные о реальном сравнении реализации одинаковой функциональности с применением метапрограммирования и без — и не один-два, а несколько? И т.д. и т.п.
А так на заборе тоже много, чего написано.
M>>Пока что подавляющее большинство твоих заявлений являются, мягко говоря, голословными. Но безапелляционности в них — хоть камазами развози. WH>Они являются очевидными для 90% программистов. WH>Что голосование и показало.
10 лет тому назад очевидным было, что C++-like ООП — это писк, и лучше ничего не придумаешь. Когда кто-то говорит про очевидность — это и есть голословное утверждение
WH>И вообще, по-моему, это самое однозначное голосование после этого
M>>>а нерепрезентативная выборка в голосовании на RSDN WH>>И чем же выборка не репрезентативна? WH>>Этот опрос имеет смысл только среди программистов. WH>>Тут масса программистов работающих в разных сферах и использующих разные инструменты. WH>>Так что с выборкой все нормально.
Решил все же взглянуть на голосование. Мда...
Дано:
Wolfhound:
И на счет серебрянных пуль:
There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
Метапрограммирование в некоторых случаях не то что на порядок, на несколько порядков производительность программистов поднимает.
Mamut:
Ссылки на исследования в студию
Если честно, я бы хотел и reliability и simplicity тоже увидеть в исследовании.
Дано 600 строк на языке высокого уровня.
И эквивалентные 75000 строк на языке уровнем пониже.
Числа реальные.
На основании своего опыта ответьте на вопросы: (WolfHound)
— Быстрее написать 600 строк.
— Быстрее написать 75000 строк.
— Проще понять 600 строк.
— Проще понять 75000 строк.
— Больше ошибок будет в 600х строках.
— Больше ошибок будет в 75000 строк.
Вопросы:
— как это голосование относится к метапрограммированию?
— как это голосование относится к reliability и simplicity?
— нормально ли считать автоматически сгенерированный код эквивалентом кода, написанного вручную?
— является ли вопрос «Проще понять 600 строк.» эквивалентом «синтаксического оверхеда Губанова» и «сверхкороткого языка PC_2»?
Пипец. И этот человек еще запрещает мне ковыряться в носу, ага
Здравствуйте, netch80, Вы писали:
WH>>Сравнивались два языка. На одном из которых нужно написать на 2 порядка больше кода, чем на другом. N>Тут ещё правда (если верить твоему примеру со сравнениями чисел — в чём я лично сомневаюсь).
Это факт. У меня два исходника на руках.
ДСЛ и то, что из него генерируется. Код получается весьма аккуратным и руками меньше не написать. Если конечно не жертвовать производительностью.
WH>>Мамут попытался спорить с совершенно очевидными для чуть менее чем всех программистов утверждениями. N>А вот это уже ложь.
Что лож?
Что 600 строк написать быстрее, чем 75000?
Что 600 строк понять проще, чем 75000?
Что в 600 строках будет меньше ошибок, чем в 75000?
Ты, правда, в это веришь?
N>Оно показало, что 2+2=4.
Ну, так Мамут с этим умудряется спорить.
N>>>Если так — то снимай штаны. WH>>Ты о чем? Что-то я не пойму, причем тут эти твои сексуальные фантазии? N>Про сексуальные — твои домыслы, что характерно.
А выделенное это про что?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Mamut, Вы писали:
M>И что ты мне хочешь этим сказать? Это доказывает верность твоих выводов или доказывает правильность результатов опроса?
Я хочу сказать, что лузеры которые сдуру начинают спорить с очевидным всегда начинают вертеться как ужи на сковородке.
А то, что сокращение кода на два порядка без потери производительности и без увеличения потребления памяти это безусловное благо было понятно всем и 10 и 50 лет назад.
И голосование показало, что и сейчас это всем очевидно. Даже твой авторитет из видео об этом говорит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Какая замечательная резьба по цитатам.
Там еще пара сообщений есть.
Дамагогия и подтасовки на марше.
M>Вопросы: M>- как это голосование относится к метапрограммированию?
Так именно благодаря ему вместо 75000 строк получилось 600.
M>- как это голосование относится к reliability и simplicity?
Проще понять 600 строк.
Проще понять 75000 строк.
Больше ошибок будет в 600х строках.
Больше ошибок будет в 75000 строк.
Это оно и есть.
И как видишь, тут народ также разделяет мою, а не твою точку зрения.
M>- нормально ли считать автоматически сгенерированный код эквивалентом кода, написанного вручную?
А почему нет?
M>- является ли вопрос «Проще понять 600 строк.» эквивалентом «синтаксического оверхеда Губанова» и «сверхкороткого языка PC_2»?
И кто тут после этого демагог?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: Чем конкретно чревата разработка сложных проектов на
M>>И что ты мне хочешь этим сказать? Это доказывает верность твоих выводов или доказывает правильность результатов опроса? WH>Я хочу сказать, что лузеры которые сдуру начинают спорить с очевидным всегда начинают вертеться как ужи на сковородке. WH>А то, что сокращение кода на два порядка без потери производительности и без увеличения потребления памяти это безусловное благо было понятно всем и 10 и 50 лет назад.
Лузеры — это те, от которых просишь хоть одной внятной ссылки или подтверждения их словам, а они начинают вертеться, ужи на сковородке, и делают все — оскорбляют оппонента, прибегают к любым способам демагогии, создают не имеющие отношения к теме голосования и называют их доказательствами — то есть делают все, только не приводят ни одной внятной ссылки или подтверждения своим словам.
WH>И голосование показало, что и сейчас это всем очевидно. Даже твой авторитет из видео об этом говорит.
Ну ка ну ка, что же он говорит про метапрограммирование, хотелось бы послушать.
Здравствуйте, Mamut, Вы писали:
M>Лузеры — это те, от которых просишь хоть одной внятной ссылки или подтверждения их словам,
Внятной ссылки на то, что уменьшение объема работы на два порядка это хорошо?
Ты серьезно считаешь, что есть здравомыслящий человек, который такие исследования будет проводить?
M>а они начинают вертеться, ужи на сковородке, и делают все — оскорбляют оппонента,
Wolfhound — трепл... демагог
Так что это ты тут обзываться начал.
M>Ну ка ну ка, что же он говорит про метапрограммирование, хотелось бы послушать.
Он говорит про объем кода.
А метапрограммирование этот объем существенно уменьшает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Ты это на полном серьезе спрашиваешь?
M>>- является ли вопрос «Проще понять 600 строк.» эквивалентом «синтаксического оверхеда Губанова» и «сверхкороткого языка PC_2»? WH>И кто тут после этого демагог?
Ты, стественно. Количество строк ничего не говорит о том, легко их понять, или нет. Тем более, если изначально речь идет о двух разных языках программирования
M>>Лузеры — это те, от которых просишь хоть одной внятной ссылки или подтверждения их словам, WH>Внятной ссылки на то, что уменьшение объема работы на два порядка это хорошо? WH>Ты серьезно считаешь, что есть здравомыслящий человек, который такие исследования будет проводить?
M>>а они начинают вертеться, ужи на сковородке, и делают все — оскорбляют оппонента, WH>
WH>Wolfhound — трепл... демагог
WH>Так что это ты тут обзываться начал.
M>>Ну ка ну ка, что же он говорит про метапрограммирование, хотелось бы послушать. WH>Он говорит про объем кода. WH>А метапрограммирование этот объем существенно уменьшает.
О, уже чуть-чуть ближе. Он говорит, емнип (могу путать с исследованиями моторолы), про то, что количество ошибок на строчку кода примерно одинаково. Из чего делается вывод о повышении уровня языка, что позволить писать меньше, пусть и с просаживанием в производительности.
Так что согласен — да, в некоторых случаях мтапрограммирование может помочь. Осталось только понять, включать ли в эти строчки нагенеренный метапрограммированием код, который тоже надо проверять на правильность — про это ты как-то молчишь. Более того, из этого следует и другой вывод — если предлагаемое метапрограммированием улучшение втроено в язык, то даром это метапрограммирование не нужно.
Поэтому осталось послушать про
И на счет серебрянных пуль:
There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
Метапрограммирование в некоторых случаях не то что на порядок, на несколько порядков производительность программистов поднимает. С reliability и simplicity тоже все очень хорошо.
Так что метапрограммирование это оно и есть.
N>>5. Офигенная куча граблей-недоработок собственно в языке, дико непродуманная реализация, тёмные углы со странностями. W>Как-то неконкретно. Я то же самое могу сказать про любой другой ЯП
Сказать то вы можете, но по факту такое огромное количество материала по атаке приложений на PHP в первую очередь и вызвано огромным количеством тёмных углов. Код написанный на более строгих и продуманных языки спецами того же уровня содержит меньшее количество уязвимостей.
Здравствуйте, Mamut, Вы писали:
M>О, уже чуть-чуть ближе. Он говорит, емнип (могу путать с исследованиями моторолы), про то, что количество ошибок на строчку кода примерно одинаково. Из чего делается вывод о повышении уровня языка, что позволить писать меньше, пусть и с просаживанием в производительности.
Это вы на всяких там питонах с просаживанием пишете.
А я на ДСЛях не только уделываю ваши питоны по объему кода, но по производительности рукопашный код на языке более низкого уровня. Ибо могу генерировать то, что хочется и использовать доменно ориентированные оптимизации.
M>Так что согласен — да, в некоторых случаях мтапрограммирование может помочь. Осталось только понять, включать ли в эти строчки нагенеренный метапрограммированием код, который тоже надо проверять на правильность — про это ты как-то молчишь.
Я просто охреневаю дорогая редакция.
Ты это блин серьезно?
M>Более того, из этого следует и другой вывод — если предлагаемое метапрограммированием улучшение втроено в язык, то даром это метапрограммирование не нужно.
Ой, блин. Не охренеешь все в язык встраивать?
И я тебе больше скажу. Любое метапрограммирование это создание нового языка.
M>Поэтому осталось послушать про
Ты своего авторитета иди еще раз послушай.
Это все следует из существенного уменьшения объема кода.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
WH>>Так именно благодаря ему вместо 75000 строк получилось 600. M>Как это отражено в голосовании?
Дано 600 строк на языке высокого уровня.
И эквивалентные 75000 строк на языке уровнем пониже.
M>Я уже говорил о репрезентативности этой выборки.
Лаптев что характерно тоже начал про репрезентативность плакать.
Тем не менее проголосовало более 100 программистов.
Да и вообще:
Вот этому человеку ты наставил кучу оценок: http://rsdn.ru/Users/71772.aspx
Вот тебе линуксойд С++ник: http://rsdn.ru/Users/19439.aspx
Вот тебе профессор. Любитель Виртовских поделий: http://rsdn.ru/Users/18459.aspx
Вот тебе .НЕТчик: http://rsdn.ru/Users/61389.aspx
Мне просто лень профили всех проголосовавших копать.
M>Особенно, если учесть, что в голосовании вообще не написано, к чему эти вопросы, с чем они связаны и т.п.
Как это не написано?
Там написано, что сравнивается два разных языка.
M>Ты это на полном серьезе спрашиваешь?
Да. Там код генерируется весьма похожий на рукописный.
M>Ты, стественно. Количество строк ничего не говорит о том, легко их понять, или нет. Тем более, если изначально речь идет о двух разных языках программирования
Вот только голосование показывает о том, что люди считают что говорит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Qwazar, Вы писали:
Q> Сказать то вы можете, но по факту такое огромное количество материала по атаке приложений на PHP в первую очередь и вызвано огромным количеством тёмных углов. Код написанный на более строгих и продуманных языки спецами того же уровня содержит меньшее количество уязвимостей.
В этом утверждении есть небольшая проблема, которая заключается в том, что "специалисты" по php, в основной своей массе, достаточно низкой квалификации и "строгими языками" просто не владеют. Соответственно, они гораздо чаще пишут код, который бродит по "темным углам", нежели специалисты более высокого уровня, для которых не составляет сложности залезть в исходник языка и узнать что же там на самом деле происходит.
Здравствуйте, WolfHound, Вы писали:
WH>>>Мамут попытался спорить с совершенно очевидными для чуть менее чем всех программистов утверждениями. N>>А вот это уже ложь. WH>Что лож? WH>Что 600 строк написать быстрее, чем 75000? WH>Что 600 строк понять проще, чем 75000? WH>Что в 600 строках будет меньше ошибок, чем в 75000?
Ложь — то, что Мамут спорил с этим.
WH>Ты, правда, в это веришь?
Во что? Я не верю, что метапрограммирование — это серебряная пуля. И Мамут не верит.
Ты приводишь в доказательство этого один пример. Один пример — не доказательство, сколь бы фантастический результат ты ни получил.
N>>Оно показало, что 2+2=4. WH>Ну, так Мамут с этим умудряется спорить.
Нет.
N>>>>Если так — то снимай штаны. WH>>>Ты о чем? Что-то я не пойму, причем тут эти твои сексуальные фантазии? N>>Про сексуальные — твои домыслы, что характерно. WH>А выделенное это про что?
Про то, что если твой пример является доказательством всеобщей пригодности и полезности метапрограммирования, то для защиты от болезней ты должен отказаться от ношения штанов и поедания огурцов.
Если ты продолжишь носить штаны (как бы они ни назывались) и есть огурцы, то у тебя или полный швах с логикой, или твой пример с 600/75000 ничего не доказывает (как оно и есть, для разумных людей).
Поэтому — снимай штаны или признавай, что прогнал с голосованием, наездами на Мамута и вообще со своим участием в этом треде.
The God is real, unless declared integer.
Re[30]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, netch80, Вы писали:
N>Ложь — то, что Мамут спорил с этим.
А чем же он занимается уже не один десяток сообщений?
N>Во что? Я не верю, что метапрограммирование — это серебряная пуля. И Мамут не верит.
Это серебряная пуля просто по определению серебряной пули.
N>Ты приводишь в доказательство этого один пример. Один пример — не доказательство, сколь бы фантастический результат ты ни получил.
Так у меня много примеров. Просто остальные несколько скромнее.
Там всего на порядок меньше работы получается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Чем конкретно чревата разработка сложных проектов на
AB>В этом утверждении есть небольшая проблема, которая заключается в том, что "специалисты" по php, в основной своей массе, достаточно низкой квалификации и "строгими языками" просто не владеют. Соответственно, они гораздо чаще пишут код, который бродит по "темным углам", нежели специалисты более высокого уровня, для которых не составляет сложности залезть в исходник языка и узнать что же там на самом деле происходит.
WH>>>Так именно благодаря ему вместо 75000 строк получилось 600. M>>Как это отражено в голосовании? WH>
WH>Дано 600 строк на языке высокого уровня.
WH>И эквивалентные 75000 строк на языке уровнем пониже.
M>>Я уже говорил о репрезентативности этой выборки. WH>Лаптев что характерно тоже начал про репрезентативность плакать. WH>Тем не менее проголосовало более 100 программистов.
И? Эти профили ничего не говорят о репрезентативности выборки.
M>>Особенно, если учесть, что в голосовании вообще не написано, к чему эти вопросы, с чем они связаны и т.п. WH>Как это не написано? WH>Там написано, что сравнивается два разных языка.
Именно. Каких-то два сферовакуумных языка. Про метапрограммирование — ноль.
M>>Ты это на полном серьезе спрашиваешь? WH>Да. Там код генерируется весьма похожий на рукописный.
M>>Ты, стественно. Количество строк ничего не говорит о том, легко их понять, или нет. Тем более, если изначально речь идет о двух разных языках программирования WH>Вот только голосование показывает о том, что люди считают что говорит.
Голосованию — грош цена.
Потворю любовно удаляемые тобой слова:
Про репрезентативность:
У тебя есть данные о сферах деятельности программистов?
У тебя есть данные об уровне этих программистов?
У тебя есть данные о проектах, в которых эти программисты примняли метапрограммирование и можно ли сравнивать их опыт?
У тебя есть данные о реальном сравнении реализации одинаковой функциональности с применением метапрограммирования и без — и не один-два, а несколько?
Про языки и количество строк:
Количество строк ничего не говорит о том, легко их понять, или нет. Тем более, если изначально речь идет о двух разных языках программирования
Про очевидность:
10 лет тому назад очевидным было, что C++-like ООП — это писк, и лучше ничего не придумаешь. Когда кто-то говорит про очевидность — это и есть голословное утверждение
Про голосование:
— как это голосование относится к метапрограммированию?
— как это голосование относится к reliability и simplicity?
Пока что ты размахиваешь этим голосованием, как красной тряпкой, потому что ни единого другого обоснования твоим словам нет и не предвидится. Ну-ну.
Из соседнего топика:
M>Так что согласен — да, в некоторых случаях мтапрограммирование может помочь. Осталось только понять, включать ли в эти строчки нагенеренный метапрограммированием код, который тоже надо проверять на правильность — про это ты как-то молчишь.
Я просто охреневаю дорогая редакция.
Ты это блин серьезно?
Да, я на полном серьезе. Где доказателсьва валидности генерируемого кода? Где тесты, указывающие на его валидность? Где доказательства того, что он генерирует код, близкий к тому, который можно написать вручную.
Хотя, о чем это я? Also spracht ZaraWolfhound, и это не обсуждается.
Здравствуйте, Mamut, Вы писали:
M>И? Эти профили ничего не говорят о репрезентативности выборки.
Конечно же, говорят.
Все эти люди имеют разное направление деятельности и все проголосовали правильно.
Хотя кому я это объясняю.
M>Именно. Каких-то два сферовакуумных языка. Про метапрограммирование — ноль.
Повторяю еще раз: Метапрограммирование это создание нового языка. Всегда.
M>Голосованию — грош цена.
Конечно. Оно же разбивает в пыль твои фантазии.
M>Потворю любовно удаляемые тобой слова:
Я на все это уже ответил.
Ответы ты как обычно проигнорировал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
M>>И? Эти профили ничего не говорят о репрезентативности выборки. WH>Конечно же, говорят. WH>Все эти люди имеют разное направление деятельности и все проголосовали правильно. WH>Хотя кому я это объясняю.
Так чему равно 2*2?
M>>Именно. Каких-то два сферовакуумных языка. Про метапрограммирование — ноль. WH>Повторяю еще раз: Метапрограммирование это создание нового языка. Всегда.
Ты хочешь об этом поговорить?
M>>Потворю любовно удаляемые тобой слова: WH>Я на все это уже ответил. WH>Ответы ты как обычно проигнорировал.
M>>И? Эти профили ничего не говорят о репрезентативности выборки. WH>Конечно же, говорят. WH>Все эти люди имеют разное направление деятельности и все проголосовали правильно. WH>Хотя кому я это объясняю.
M>>Именно. Каких-то два сферовакуумных языка. Про метапрограммирование — ноль. WH>Повторяю еще раз: Метапрограммирование это создание нового языка. Всегда.
Так какие языки сравниваются в голосовании, не напомнишь?
M>>Голосованию — грош цена. WH>Конечно. Оно же разбивает в пыль твои фантазии.
Кто бы тут говорил о фантазиях
M>>Потворю любовно удаляемые тобой слова: WH>Я на все это уже ответил. WH>Ответы ты как обычно проигнорировал.
Про reliability и simplicity: 0 ответов.
Про то, что сравнение двух сферовакуумных языков — это... хм... сравнение двух сферовакуумных языков — ноль ответов.
Про то, что количество строк буз указания языков — это не показатель легкости восприятия — 0 ответов.
Про тестирование, доказательство правильности сгенеренного кода — ноль ответов.
Про репрезентативность... Ну, после слов «все проголосовали правильно» понятно, что репрезентативность тебе не нужна.
Про очевидность... Ноль ответов, кроме того, что ты считаешь «очевидно» == «не подлежит сомнению».
Ссылки только подтверждают мои слова. Смотрим что у нас по первой ссылке:
<?php
include($_GET['a']);
?>
Дальше можно даже не читать, т.к.:
а) Ни один вменяемый разработчик не станет пропускать данные, которые пришли из внешнего мира без достаточной проверки.
б) На production окружении все сообщения об ошибках обязаны перехватываться или хотя бы подавляться для вывода пользователю.
в) Обсуждаемые проблемы имеют больше отношение к общей безопасности веб-приложений, а не к языку, на котором они написаны.
По ссылкам 2 и 3 тоже самое, только в профиль.
Это, конечно же, не значит, что нормальный разработчик не может сфейлить (например, в более сложных случаях), но хорошо поставленный процесс разработки эти риски сильно уменьшает и постановка процесса разработки так же к языку имеет лишь косвенное отношение.
[...]
AB>Это, конечно же, не значит, что нормальный разработчик не может сфейлить (например, в более сложных случаях),
Вот именно! Чуть более сложный случай, чуть менее очевидная картина, некоторое усложнение обстановки — и контроль теряется.
С тем же include очень характерный пример. Если бы был, например, include($path, $flags), где $flags задаёт режим интерпретации пути и может указывать, например, "только файлы, путь в явном виде и без откатов назад по пути" (элементов ".." и аналогов), то
1) разработчик обязательно бы задумался перед вызовом конкретного include(), что именно он хочет в данном месте,
2) он был бы вообще более начеку о проблемах (за счёт регулярного напоминания).
Давая же простое include($path), не акцентируя, что путь может быть чем угодно включая аццкие диверсии со сжатием, URL'ями и тому подобным — авторы языка в принципе провоцируют бездумие и грабли.
AB> но хорошо поставленный процесс разработки эти риски сильно уменьшает и постановка процесса разработки так же к языку имеет лишь косвенное отношение.
"Хорошо поставленный процесс разработки" приводит к удорожанию разработки во много раз, привязке к продукту (например, за счёт того, что кто-то должен рассказать, что в очередной версии тот же include() тайком получил новую фичу, и надо вокруг неё тоже расставить защит), к библиотекам, которые приводят эту функциональность в нормальную, и так далее. В общем, авторы PHP сознательно работают на создание инфраструктуры, за счёт окружающих. (Что и так было очевидно на примере Zend.)
Из-за всего вышесказанного у меня чёткое правило — PHP не допускается ни для разработки, ни для эксплуатации. Ни под каким соусом, ни в какие временные решения. Слава богу, альтернатив достаточно.
The God is real, unless declared integer.
Re[7]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, netch80, Вы писали:
n> Давая же простое include($path), не акцентируя, что путь может быть чем угодно включая аццкие диверсии со сжатием, URL'ями и тому подобным — авторы языка в принципе провоцируют бездумие и грабли.
Бездумие — да, по этому язык и имеет низкий порог входа и большое количество разработчиков невысокой квалификации, которые не думают. А вот на счет граблей — это не к языку вопросы, а к тому, кто его так применяет.
Паттерн include($path), где $path напрямую получен из $_GET (по сути, враждебного мира) порочен по своей сути и является тем самым провокатором различных диверсий (классическая вариация паттерна "Паблик Морозов"). Внедрение же простого ассоциированного массива {"имя_модуля" => "путь_к_include"} и проведение операции маппинга от имени модуля к заранее известным путям снижает эффективность подобных диверсий более чем полностью.
Попробуем посмотреть на проблему с другой стороны. Предположим, ты пишешь системную утилиту, на которой установлен suid бит и она в качестве одного из параметров принимает от пользователя имя внешнего .so модуля. Неужели ты точно так же бездумно вызовешь dlopen не проверив что же именно тебя просят загрузить? Уверен, что нет, т.к. прекрасно осознаешь меру/степень/глубину. И если после этого ты начинаешь писать на php, то это осознание никуда не исчезает.
В обратную сторону это не работает. Если сегодня посмотреть на то, что лежит в директориях пользователей обычного LAMP хостинга, то увидим там ужас-ужас начиная от прав 0777 на все файлы и директории, получения путей к скриптам через $_SERVER['DOCUMENT_ROOT'] и т.д. Такой "электорат" даже провоцировать не требуется.
n> AB> но хорошо поставленный процесс разработки эти риски сильно уменьшает и постановка процесса разработки так же к языку имеет лишь косвенное отношение. n> "Хорошо поставленный процесс разработки" приводит к удорожанию разработки во много раз, привязке к продукту (например, за счёт того, что кто-то должен рассказать, что в очередной версии тот же include() тайком получил новую фичу, и надо вокруг неё тоже расставить защит), к библиотекам, которые приводят эту функциональность в нормальную, и так далее.
Возьми любой другой язык и ты получишь абсолютно то же самое. Постановка процесса не специфична только для PHP — это просто вопрос гигиены разработки в больших проектах. Или в проектах на других языках не используют системы контроля версий / тестирования / etc? Или не читают документацию / changelog к новым версиям языка / библиотек?
n> Из-за всего вышесказанного у меня чёткое правило — PHP не допускается ни для разработки, ни для эксплуатации. Ни под каким соусом, ни в какие временные решения. Слава богу, альтернатив достаточно.
Ну ещё пример, в php при десериализации можно переписывать глобальные переменные. в некоторых условиях. Программист таких приколов никак не ожидает. Или например php в отличии от java позволяет переписывать при десериализации приватные поля базового класса, что тоже местами приводит к приколам.
Или к примеру регулярные выражения обламываются на некоторых символах (даже не только /00). Или функции призванные защищать sql запросы от инъекци тоже работают не при всех кодировках БД. Всего этого программист не знает и знать не может, т.к. в официальных мануалах по языку о таких фишках ничего не сказано.
Здравствуйте, Qwazar, Вы писали:
Q> Ну ещё пример, в php при десериализации можно переписывать глобальные переменные. в некоторых условиях. Программист таких приколов никак не ожидает. Или например php в отличии от java позволяет переписывать при десериализации приватные поля базового класса, что тоже местами приводит к приколам.
Предлагаю рассматривать конструктивно конкретные примеры на конкретном коде. Т.е. тестовый код воспроизводящий проблему, что (и на основании чего!) ожидается, что получается на самом деле и т.д.
При этом не рассматриваем случаи вида "Доктор, когда я спускаю штаны и немного наклоняюсь...", т.к. на эти случаи будет ответ "Не делайте так". Так же, по вполне понятным причинам, я никак не смогу прокомментировать работу php под windows.
Если конкретно, то моя работа как раз заключается в том, что бы проводить в том числе и code review с точки зрения информационной безопасности. Так вот такого количества нюансов как для PHP не приходится держать в голове ни для одного интерпретируемого языка, и уж тем более для Java/.Net таких проблем нет.
Выкладывать гору примеров как то не хочется, гораздо проще сравнить количественно статьи об уязвимостях PHP со статьями об уязвимостях Java/.Net. Первых гораздо больше.
И когда видишь код не на PHP, уязвимости в нём есть в основном только при наличии антипаттернов программирования, за которые в приличных компаниях лупили бы линейкой по пальцам (если бы не "демократия"). А в PHP и прилично написанный код содержит уязвимости, о которых программист даже не догадывается.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Qwazar, Вы писали:
Q>> Сказать то вы можете, но по факту такое огромное количество материала по атаке приложений на PHP в первую очередь и вызвано огромным количеством тёмных углов. Код написанный на более строгих и продуманных языки спецами того же уровня содержит меньшее количество уязвимостей.
AB>В этом утверждении есть небольшая проблема, которая заключается в том, что "специалисты" по php, в основной своей массе, достаточно низкой квалификации и "строгими языками" просто не владеют. Соответственно, они гораздо чаще пишут код, который бродит по "темным углам", нежели специалисты более высокого уровня, для которых не составляет сложности залезть в исходник языка и узнать что же там на самом деле происходит.
В этом утверждении есть небольшая проблема. Даже две:
1. к сложным проектам оно неприменимо;
2. его автор говорит за всех.
Я по работе пишу на PHP, для себя — на scala. Квалификация нормальная. Так вот: на большом сложном проекте ситуация "отвинтили пупок — отвалилась задница" является вполне типичной. Scala её сводит почти на нет благодаря статической типизации, а в PHP приходится при рефакторинге каждой мелочи скурпулёзно и долго разными способами искать, где и как она используется.
И кстати, насчёт include($_GET['a']) — это косяк прежде всего языка, а уж потом разработчика. Слабо на сервлетах такую же дыру организовать? Вот то-то же. А чем больше в языке возможностей злоупотребления, тем чаще эти злоупотребления будут встречаться, очевидно ж.
И кстати, чье-то утверждения ниже, что люди, приходящие со статики в динамику, пишут хуже, чем те, кто в динамике изначально — бред собачий. Статика приучает к дисциплине, в отличие от. Я когда-то переносил lib.web.forms со скалы на PHP — вышло так же строго и удобно (хотя и более многословно, что предсказуемо); динамические фреймворки, переносимые на статику, выглядят совершенно кошмарно. На мой PHP-код Idea не ругается, её type hinting работает, рефакторинги она мне делает автоматом; а те, кто изначально на динамике, пишут так, что концов вообще не найти — скажем, имена вызываемых методов (да и include-файлов, ага, гыгы) формируются динамически, поэтому при переименовании метода ты хрен найдёшь все места, где он используется, и в итоге всё это вылезает на боевом рантайме.
Re[6]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, dimgel, Вы писали:
d> Я по работе пишу на PHP, для себя — на scala. Квалификация нормальная. Так вот: на большом сложном проекте ситуация "отвинтили пупок — отвалилась задница" является вполне типичной. Scala её сводит почти на нет благодаря статической типизации, а в PHP приходится при рефакторинге каждой мелочи скурпулёзно и долго разными способами искать, где и как она используется.
Запустить автотесты в рамках CI после коммита и выявить все места — чего проще? Вон, даже Немерлисты вкус CI распробовали (чему я офигенно удивлен, если честно).
Статическая типизация никак не поможет от инъекции левой строки, когда так же ожидается строка, и т.д.
d> И кстати, насчёт include($_GET['a']) — это косяк прежде всего языка, а уж потом разработчика. Слабо на сервлетах такую же дыру организовать? Вот то-то же. А чем больше в языке возможностей злоупотребления, тем чаще эти злоупотребления будут встречаться, очевидно ж.
Язык С/С++ — статически типизирован (не будем сильно придираться к кастованию void*), возможностей злоупотребления вагон и маленькая тележка. Рядом я приводил пример с загрузкой внешней so-шки в процесс с suid битом. Я очень сильно удивлюсь, если кому-то придет в голову не проверять по какому пути эта so-шка находится (впрочем, исключать тоже не буду, но тут на полную работает теория Дарвина).
d> И кстати, чье-то утверждения ниже, что люди, приходящие со статики в динамику, пишут хуже, чем те, кто в динамике изначально — бред собачий.
Здравствуйте, Qwazar, Вы писали:
Q> Выкладывать гору примеров как то не хочется, гораздо проще сравнить количественно статьи об уязвимостях PHP со статьями об уязвимостях Java/.Net. Первых гораздо больше.
Не, ну это из той же серии, что "большинство умерших от Х если огурцы => огурцы причина Х". Большое количество статей говорит лишь о распространенности языка/технологии и о частоте неправильного использования.
Q> И когда видишь код не на PHP, уязвимости в нём есть в основном только при наличии антипаттернов программирования, за которые в приличных компаниях лупили бы линейкой по пальцам (если бы не "демократия"). А в PHP и прилично написанный код содержит уязвимости, о которых программист даже не догадывается.
Та же самая история и с PHP — как только применяются "скользкие" пути реализации, так что-нибудь начнет вылазить. Лупите линейкой за элементарные нарушения и программисты чудесным образом будут "догадываться" и упреждать деструктивные явления.
Еще раз повторю свой тезис — проблема не в языке, проблема в квалификации и сопутствующих факторах (состояние рынка труда, низкий порог вхождения, etc).
Здравствуйте, kochetkov.vladimir, Вы писали:
k> AB>классическая вариация паттерна "Паблик Морозов" k> Ох уж эти разработчики, со своими паттернами k> Это называется remote file inclusion aka RFI (WASC-05) и, по сути, ведет к выполнению произвольного PHP-кода на сервере с правами веб-сервера
Уф... Я уже хотел кастовать твое появление, чтобы все было "по науке" А почему только на PHP? На к-л других языках разве это невозможно?
Здравствуйте, Anton Batenev, Вы писали:
d>> Я по работе пишу на PHP, для себя — на scala. Квалификация нормальная. Так вот: на большом сложном проекте ситуация "отвинтили пупок — отвалилась задница" является вполне типичной. Scala её сводит почти на нет благодаря статической типизации, а в PHP приходится при рефакторинге каждой мелочи скурпулёзно и долго разными способами искать, где и как она используется. AB>Запустить автотесты в рамках CI после коммита и выявить все места — чего проще? Вон, даже Немерлисты вкус CI распробовали (чему я офигенно удивлен, если честно).
Что такое CI?
The God is real, unless declared integer.
Re[8]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, netch80, Вы писали:
n> AB>Запустить автотесты в рамках CI после коммита и выявить все места — чего проще? Вон, даже Немерлисты вкус CI распробовали (чему я офигенно удивлен, если честно). n> Что такое CI?
Continuous Integration (Непрерывная интеграция). Ночные билды, различные автотесты и т.д. и т.п. — очень гибкая практика, но, главное, без фанатизма.
AB>Еще раз повторю свой тезис — проблема не в языке, проблема в квалификации и сопутствующих факторах (состояние рынка труда, низкий порог вхождения, etc).
В том то и дело, что нет, в Java к примеру для запросов к бд используют PrepearedStatements или ORM, оба подхода исключают SQL инъекции, а составление запросов конкатенацией однозначный признак совсем совсем новичка.
В то же время в PHP, до недавнего времени не было параметризованных запросов вообще, а для защиты от инъекций предлагалось использовать функции:
mysql_escape_string
addslashes
mysql_real_escape_string
и ко всему этому добавляется директива:
magic-quotes-gpc
Только одна из этих функций не подвержена уязвимостям зависящим от конфигурации, + довольно большая часть старого кода рассчитана на директиву magic-quotes-gpc=ON, которая в скором времени будет в принципе отключена в старых версиях PHP. Как результат, поставили вы старый движок на форум, он работает и неуязвим, а тут хостер обновил свои сервера — всё, вас поломали.
В мире Java и .Net — таких заморочек нет.
Или к примеру функции регулярных выражений:
preg_replace (без модификатора обламывается на символе %0a)
ereg_replace (обламывается на символе %00)
eregi_replace (обламывается на символе %00)
Т.е. мало того что функций с идентичным функционалом много, так они ещё и содержат специфичные баги.
Функция проверки ip адреса:
ip2long — на многих ОС обходится 1.1.1.1".chr(09)."'or'a'='a'/* , т.е. программист ожидает что в запрос к БД или в файл уйдёт IP адрес а там код с нагрузкой.
Десериализация позволяет переписывать приватные поля базовых классов, при записи переменных в сессию при некоторых условиях можно переписать все суперглобальные массивы, в инклудах можно отбрасывать расширения инклудящихся файлов при помощи символа %00 или большого кол-ва слешей, да много где в реализации функций встречаются подобные баги.
Такого дублирования функций и настолько плохой их реализации нет нигде, а многие вновь вводящиеся средства языка убивают все потуги программистов обеспечить защиту своих сайтов.
Здравствуйте, Anton Batenev, Вы писали:
n>> Давая же простое include($path), не акцентируя, что путь может быть чем угодно включая аццкие диверсии со сжатием, URL'ями и тому подобным — авторы языка в принципе провоцируют бездумие и грабли. AB>Бездумие — да, по этому язык и имеет низкий порог входа и большое количество разработчиков невысокой квалификации, которые не думают. А вот на счет граблей — это не к языку вопросы, а к тому, кто его так применяет. AB>Паттерн include($path), где $path напрямую получен из $_GET (по сути, враждебного мира) порочен по своей сути и является тем самым провокатором различных диверсий (классическая вариация паттерна "Паблик Морозов"). Внедрение же простого ассоциированного массива {"имя_модуля" => "путь_к_include"} и проведение операции маппинга от имени модуля к заранее известным путям снижает эффективность подобных диверсий более чем полностью.
В чём-то верно (но — см. ниже). Но см. мой подробный рассказ — если кто-то вообще решил использовать подобный подход без явного маппинга или контроля на вхождение в заданный диапазон, то
1) если функция не будет позволять исполнять что угодно (а по плотности возможностей к исполнению include() в описанном виде плавно приближается к машине Тьюринга), то даже с таким подходом граблей будет меньше;
2) если функция будет позволять исполнять что угодно, но для этого требовать явных флагов — любой просто-кодер с задачей "сделать этот модуль на позавчера" ткнётся в документацию, посмотрит, что ему нужны именно такие ключи (включать локальный файл без лишних возможностей) и сразу и ограничит плотность диверсий.
Наконец, кто сказал, что путь исполнения из внешнего мира "порочен по своей сути"? Например, если серверу типа апача (привычный нам обоим) передано вызвать /cgi-bin/zuka.cgi, то проверка идёт по наличию этого zuka.cgi в месте трансляции cgi-bin, и если кто-то положил туда левый скрипт, то его можно будет исполнять по запросу извне. И что — ты будешь считать, что это уже "паблик морозов"? Возможность исполнения по типу include($fixed_base+$_GET['a']), в случае, если контролируется защита от стандартных диверсий, идентична возможности исполнения скрипта только потому, что он оказался в cgi-bin, и столь же безопасна, как и она — пока контролируется содержимое исполняемого каталога.
AB>Попробуем посмотреть на проблему с другой стороны. Предположим, ты пишешь системную утилиту, на которой установлен suid бит и она в качестве одного из параметров принимает от пользователя имя внешнего .so модуля. Неужели ты точно так же бездумно вызовешь dlopen не проверив что же именно тебя просят загрузить?
Если модуль лежит в конкретном каталоге, содержимое которого определяется сетапом утилиты — да, вызову. И ничего тут "бездумного" нет. Мало того, у меня есть живой пример такого: это wrapper из состава majordomo:
У него нет проверки, что именно исполняется из целевого каталога — у него только проверяется, что argv[1] не содержит '/'. Majordomo существует с 1992 года, в нём, естественно, находили дыры, но собственно сама концепция wrapper'а в таком виде не подвергалась сомнению.
AB> Уверен, что нет, т.к. прекрасно осознаешь меру/степень/глубину. И если после этого ты начинаешь писать на php, то это осознание никуда не исчезает.
Ты ошибаешься. Примеры с cgi-bin и wrapper это чётко показывают. При адекватных мерах по контролю происходящего нет проблем в такой обработке. PHP же именно что маскирует необходимость адекватного контроля.
AB>В обратную сторону это не работает. Если сегодня посмотреть на то, что лежит в директориях пользователей обычного LAMP хостинга, то увидим там ужас-ужас начиная от прав 0777 на все файлы и директории, получения путей к скриптам через $_SERVER['DOCUMENT_ROOT'] и т.д. Такой "электорат" даже провоцировать не требуется.
И что, из-за этого надо рекламировать принципиально дырявые механизмы с недокументированными возможностями, увеличивая риск проблем и в без того бардачной среде???
n>> "Хорошо поставленный процесс разработки" приводит к удорожанию разработки во много раз, привязке к продукту (например, за счёт того, что кто-то должен рассказать, что в очередной версии тот же include() тайком получил новую фичу, и надо вокруг неё тоже расставить защит), к библиотекам, которые приводят эту функциональность в нормальную, и так далее.
AB>Возьми любой другой язык и ты получишь абсолютно то же самое.
Не получу. Только для Personal Home Page (как бы его потом ни переименовывали) бардак и свобода его творить с наплевательством на качество и на защиту — возведена в принцип.
AB> Постановка процесса не специфична только для PHP — это просто вопрос гигиены разработки в больших проектах. Или в проектах на других языках не используют системы контроля версий / тестирования / etc? Или не читают документацию / changelog к новым версиям языка / библиотек?
1. POLA никто не отменял.
2. Как быть с тем, что очень плохо документировано или вообще не документировано (см. ссылки Qwazar'а)?
n>> Из-за всего вышесказанного у меня чёткое правило — PHP не допускается ни для разработки, ни для эксплуатации. Ни под каким соусом, ни в какие временные решения. Слава богу, альтернатив достаточно. AB>Так тут "хозяин — барин"
Вопрос не в том, что я могу сделать что-то как левая пятка захочет (это и так очевидно), а в том, что тут совсем не желание левой пятки, а продуманное обоснованное решение.
The God is real, unless declared integer.
Re[9]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, netch80, Вы писали:
n>> AB>Запустить автотесты в рамках CI после коммита и выявить все места — чего проще? Вон, даже Немерлисты вкус CI распробовали (чему я офигенно удивлен, если честно). n>> Что такое CI?
AB>Continuous Integration (Непрерывная интеграция). Ночные билды, различные автотесты и т.д. и т.п. — очень гибкая практика, но, главное, без фанатизма.
Про Continuous Integration слышал, но в этой аббревиатуре не узнал.
В таком случае всё зависит только от качества покрытия тестами, а оно в принципе для динамики хуже. (Те же немерлисты возводят это ухудшение в абсолют, это уже перебор, но отрицать его нельзя.)
The God is real, unless declared integer.
Re[7]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Anton Batenev, Вы писали:
AB>Запустить автотесты в рамках CI после коммита и выявить все места — чего проще?
Меня искренне поражает вера людей в тесы.
Максимум что может поймать тест это регрессию. И то не гарантированно.
Каким тестом ты собрался искать include($_GET['a']) и подобное?
AB>Вон, даже Немерлисты вкус CI распробовали (чему я офигенно удивлен, если честно).
Немерлисты завели эту штуку исключительно по тому, что народ хочет получать свежие билды и не возиться со сборкой.
AB>Статическая типизация никак не поможет от инъекции левой строки, когда так же ожидается строка, и т.д.
Вот тут ты очень сильно ошибаешься.
Вот, например: http://www.impredicative.com/ur/
AB>Язык С/С++ — статически типизирован (не будем сильно придираться к кастованию void*), возможностей злоупотребления вагон и маленькая тележка. Рядом я приводил пример с загрузкой внешней so-шки в процесс с suid битом. Я очень сильно удивлюсь, если кому-то придет в голову не проверять по какому пути эта so-шка находится (впрочем, исключать тоже не буду, но тут на полную работает теория Дарвина).
Это по тому что в С/С++ можно:
1)Послать все типы нахрен.
2)Проехаться по памяти.
3)Весь код работает с правами процесса.
Если это устранить, то можно будет спокойно грузить любой код. При этом будучи уверенным что он не сделает ничего кроме того что ему разрешили делать явно.
Первые две проблемы можно вылечить этим: http://goto.ucsd.edu/~rjhala/liquid/
Причем без потери производительности и практически без дополнительных аннотаций.
Третью запрещением в языке глобальных переменных всех видов и дизайном стандартной библиотеки основанным на http://en.wikipedia.org/wiki/Capability-based_security .
Создание предметно ориентированных языков с предметно ориентированной системой типов снимает еще больше проблем.
Причем в этом случае еще и производительность можно довести до такого уровня, что руками пилить озвереешь.
Ссылку на тот же Ur/Web я уже дал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Anton Batenev, Вы писали:
AB>Запустить автотесты в рамках CI после коммита и выявить все места — чего проще? Вон, даже Немерлисты вкус CI распробовали (чему я офигенно удивлен, если честно). AB>Статическая типизация никак не поможет от инъекции левой строки, когда так же ожидается строка, и т.д.
Ну почему же. Поможет. Примеры такого типа есть даже у Спольского — он рассказывает про использование app hungarian notation, но можно распространить и на типы. Если ты не можешь передать в файловое API, формирование команды SQL и так далее тип "обычная строка", а можешь только тип "проверенная строка", то тебя не пустит скомпилировать код, где забыта конверсия.
С другой стороны, это возможно и с динамической типизацией — только проблема будет с заметной вероятностью поймана при запуске, а не сборке; а при более широких возможностях языка (интерпретация на ходу) можно будет явными методами обойти эту защиту.
d>> И кстати, насчёт include($_GET['a']) — это косяк прежде всего языка, а уж потом разработчика. Слабо на сервлетах такую же дыру организовать? Вот то-то же. А чем больше в языке возможностей злоупотребления, тем чаще эти злоупотребления будут встречаться, очевидно ж. AB>Язык С/С++ — статически типизирован (не будем сильно придираться к кастованию void*), возможностей злоупотребления вагон и маленькая тележка. Рядом я приводил пример с загрузкой внешней so-шки в процесс с suid битом. Я очень сильно удивлюсь, если кому-то придет в голову не проверять по какому пути эта so-шка находится (впрочем, исключать тоже не буду, но тут на полную работает теория Дарвина).
А не надо путать возможность злоупотребления, которую надо сотворить явно, с той, которая невольно возникает просто от недостаточного знания используемых средств.
The God is real, unless declared integer.
Re[11]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Anton Batenev, Вы писали:
k>> Это называется remote file inclusion aka RFI (WASC-05) и, по сути, ведет к выполнению произвольного PHP-кода на сервере с правами веб-сервера AB>Уф... Я уже хотел кастовать твое появление, чтобы все было "по науке" А почему только на PHP? На к-л других языках разве это невозможно?
На то, чтобы брюки именно легким движением руки превратились в шорты, способны только два известных мне динамических языка, по крайней мере, из семейства мейнстримовых. В остальных — это тоже возможно, особенно, если язык предусматривает возможность eval()'а собственного кода, но именно RFI в них достигается через кучу лишних теледвижения, на которые отваживаются только очень не ленивые разработчики, что и обуславливает практическое отсутствие подобных уязвимостей в коде на этих языках
P.S: Вторым языком является javascript. На практике, большинство уязвимостей в коде на нем допускается тогда, когда JSON, получаемый из недоверенного источника (либо формируемый на сервере на основе данных, полученных из недоверенного источника), обрабатывается легкодоступным в js eval()'ом. Ну и вариациями на эту тему.
Здравствуйте, netch80, Вы писали:
n> Про Continuous Integration слышал, но в этой аббревиатуре не узнал. n> В таком случае всё зависит только от качества покрытия тестами, а оно в принципе для динамики хуже.
На самом деле, статика или динамика значения не имеют. Вопрос лишь в доверии разработчика тестов к тем или иным вещам. Если разработчик тестов верит реализации библиотеки zlib 1.2.3.4, то он ее проверять не будет, если не верит, то будет вне зависимости от статики или динамики — это отличает хорошего тестера от плохого.
З.Ы. К сожалению, на RSDN отношение к тестерам как к обезьянкам, которые кликают мышкой и ни на что не способны.
Здравствуйте, netch80, Вы писали:
n> Наконец, кто сказал, что путь исполнения из внешнего мира "порочен по своей сути"? Например, если серверу типа апача (привычный нам обоим) передано вызвать /cgi-bin/zuka.cgi, то проверка идёт по наличию этого zuka.cgi в месте трансляции cgi-bin, и если кто-то положил туда левый скрипт, то его можно будет исполнять по запросу извне. И что — ты будешь считать, что это уже "паблик морозов"?
Нет, это уже взлом сервера под названием "кто-то положил левый скрипт" (Владимир, надеюсь, поправит, как это по научному называется). Поскольку чудес не бывает, то кто-то этот скрипт туда положил так или иначе.
Точно такая же ситуация и с perl и с ruby и с python или чем еще.
n> Если модуль лежит в конкретном каталоге, содержимое которого определяется сетапом утилиты — да, вызову. И ничего тут "бездумного" нет. Мало того, у меня есть живой пример такого: это wrapper из состава majordomo:
См. выделенное в твоем предложении. Почему для PHP мы допускаем другие условия?
n> И что, из-за этого надо рекламировать принципиально дырявые механизмы с недокументированными возможностями, увеличивая риск проблем и в без того бардачной среде???
Рекламировать не надо (как раз наоборот). Но опять же — это проблема не языка.
n> 1. POLA никто не отменял.
Ознакомлюсь, отвечу отдельно
n> 2. Как быть с тем, что очень плохо документировано или вообще не документировано (см. ссылки Qwazar'а)?
Здравствуйте, Qwazar, Вы писали:
Q> В том то и дело, что нет, в Java к примеру для запросов к бд используют PrepearedStatements или ORM, оба подхода исключают SQL инъекции
Владимира Кочеткова хочу в студию — он мозги лучше меня вправит.
Q> В то же время в PHP, до недавнего времени не было параметризованных запросов вообще, а для защиты от инъекций предлагалось использовать функции:
До недавнего времени, это сколько лет назад? Чем плохи приведенные выше функции для экранирования строк?
Q> Функция проверки ip адреса: Q> ip2long — на многих ОС обходится 1.1.1.1".chr(09)."'or'a'='a'/* , т.е. программист ожидает что в запрос к БД или в файл уйдёт IP адрес а там код с нагрузкой.
Как я писал выше, случаи намеренного вмешательства во входные данные я не рассматриваю:
1) Это относится не к языку, а к безопасности
2) Без анализа того, что передали из внешнего мира, рассуждения смысла не имеют.
Q> Десериализация позволяет переписывать приватные поля базовых классов, при записи переменных в сессию при некоторых условиях можно переписать все суперглобальные массивы, в инклудах можно отбрасывать расширения инклудящихся файлов при помощи символа %00 или большого кол-ва слешей, да много где в реализации функций встречаются подобные баги.
Я предложил ранее конструктивный подход — код-тест, что ожидалось, что получилось.
Здравствуйте, Qwazar, Вы писали:
AB>>Еще раз повторю свой тезис — проблема не в языке, проблема в квалификации и сопутствующих факторах (состояние рынка труда, низкий порог вхождения, etc).
Q>В том то и дело, что нет, в Java к примеру для запросов к бд используют PrepearedStatements или ORM, оба подхода исключают SQL инъекции, а составление запросов конкатенацией однозначный признак совсем совсем новичка.
В первом случае инъекции все же возможны в тех редких случаях, например, когда данные из параметров запроса конкатенируются в другой запрос, в ходе выполнения хранимой процедуры. Получается lSQLi (latent SQL injection). Использование ORM также не исключает инъекции, в общем случае, т.к. обычно предлагает разработчику собственный DSL для построения кастомных запросов, соответственно, как только появляется нефильтрованная конкатенация, так сразу получаем инъекцию. HSQLi в hibernate-приложениях наделали кучу шуму в 2008-2009 гг.
Здравствуйте, Anton Batenev, Вы писали:
AB>Нет, это уже взлом сервера под названием "кто-то положил левый скрипт" (Владимир, надеюсь, поправит, как это по научному называется).
Так и называется. Мы еще используем более обтекаемый и научно-обоснованный термин "хрень какая-то"
Если серьезно, то способ, которым положили на сервер этот файл (и который плавно обошел в формулировке netch80) и является уявзимостью, а описанный им дальнейший сценарий является лишь способом ее эксплутации.
KV>В первом случае инъекции все же возможны в тех редких случаях, например, когда данные из параметров запроса конкатенируются в другой запрос, в ходе выполнения хранимой процедуры. Получается lSQLi (latent SQL injection). Использование ORM также не исключает инъекции, в общем случае, т.к. обычно предлагает разработчику собственный DSL для построения кастомных запросов, соответственно, как только появляется нефильтрованная конкатенация, так сразу получаем инъекцию. HSQLi в hibernate-приложениях наделали кучу шуму в 2008-2009 гг.
Я выше писал, что за конкатенацию в запросах надо лупить линейкой по пальцам, и все программисты со средним опытом это знают. В пыхе проблемы в том, что баги есть даже тогда, когда код написан в хорошем стиле.
AB>Владимира Кочеткова хочу в студию — он мозги лучше меня вправит.
Мне не нравится ваш тон, это во первых, а во вторых — при нормальном стиле программирования (без конкатов) — багов не будет.
AB>До недавнего времени, это сколько лет назад? Чем плохи приведенные выше функции для экранирования строк?
С версии 5.1, т.е. с появления PDO в стандартной сборке, это раз. А эти функции частично не используют информацию о кодировке в бд это во первых, а во вторых без учёта информации о magic_quotes_gpc нагородят лишних слешей.
AB>Как я писал выше, случаи намеренного вмешательства во входные данные я не рассматриваю:
А какие тогда рассматривать? Язык абсолютно кривой с большим количеством лишних функций с одинаковой функциональностью, но разными багами.
AB>Я предложил ранее конструктивный подход — код-тест, что ожидалось, что получилось.
И что код-тест, предлагаете разработчикам самостоятельно профаззить все функции, что бы узнать что им разрабы PHP нагородили? М.б. лучше сразу отказаться от его использования?
Здравствуйте, Anton Batenev, Вы писали:
n>> Если модуль лежит в конкретном каталоге, содержимое которого определяется сетапом утилиты — да, вызову. И ничего тут "бездумного" нет. Мало того, у меня есть живой пример такого: это wrapper из состава majordomo: AB>См. выделенное в твоем предложении. Почему для PHP мы допускаем другие условия?
Нет, "мы" не допускаем. Но проблема в том, что контроль, который был бы работающим в случае необходимости проверки по простому условию, для PHP не работает. Например, проверять на то, что имя не содержит '/' (и автоматически и '\0', как в случае majordomo wrapper), внезапно (tm) недостаточно, и чтобы это узнать, надо слишком внимательно читать документацию.
n>> И что, из-за этого надо рекламировать принципиально дырявые механизмы с недокументированными возможностями, увеличивая риск проблем и в без того бардачной среде??? AB>Рекламировать не надо (как раз наоборот). Но опять же — это проблема не языка.
Именно что конкретного языка.
n>> 2. Как быть с тем, что очень плохо документировано или вообще не документировано (см. ссылки Qwazar'а)? AB>
Необходимость читать код (а не документацию) как раз и является признаком очень плохого средства.
The God is real, unless declared integer.
Re[8]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, netch80, Вы писали:
n> AB>Язык С/С++ — статически типизирован (не будем сильно придираться к кастованию void*), возможностей злоупотребления вагон и маленькая тележка. Рядом я приводил пример с загрузкой внешней so-шки в процесс с suid битом. Я очень сильно удивлюсь, если кому-то придет в голову не проверять по какому пути эта so-шка находится (впрочем, исключать тоже не буду, но тут на полную работает теория Дарвина). n> А не надо путать возможность злоупотребления, которую надо сотворить явно, с той, которая невольно возникает просто от недостаточного знания используемых средств.
Отлично! Осталось определить формально явное или не явное (от недостаточного знания) злоупотребление теми или иными возможностями. Еще раз напомню тезис, который лежит в корне спора: "PHP обычный язык, но его дискредитирует низкий порог входа и большое количество разработчиков с низкой квалификацией".
Здравствуйте, Anton Batenev, Вы писали:
n>> А не надо путать возможность злоупотребления, которую надо сотворить явно, с той, которая невольно возникает просто от недостаточного знания используемых средств.
AB>Отлично! Осталось определить формально явное или не явное (от недостаточного знания) злоупотребление теми или иными возможностями. Еще раз напомню тезис, который лежит в корне спора: "PHP обычный язык, но его дискредитирует низкий порог входа и большое количество разработчиков с низкой квалификацией".
Это с чего вдруг Вы считаете, что в основе спора лежит этот тезис? Я вот считаю, что тезисом как раз является не свойство массы разработчиков (оно вторично), а свойство самого языка — откровенно бездарная, бардачная и провокационная разработка. А уже она имеет следствием размножнение быдлокодеров (ибо нормальные в основном стараются от него уйти).
The God is real, unless declared integer.
Re[16]: Чем конкретно чревата разработка сложных проектов на
Здравствуйте, Qwazar, Вы писали:
AB>>Владимира Кочеткова хочу в студию — он мозги лучше меня вправит. Q>Мне не нравится ваш тон
Не обижайтесь, просто то, что я творил здесь с мозгами местных разработчиков (а они с моими) год-два назад, иначе и нельзя назвать. Так что тут — ничего личного, как мне кажется
Здравствуйте, Anton Batenev, Вы писали:
d>> Я по работе пишу на PHP, для себя — на scala. Квалификация нормальная. Так вот: на большом сложном проекте ситуация "отвинтили пупок — отвалилась задница" является вполне типичной. Scala её сводит почти на нет благодаря статической типизации, а в PHP приходится при рефакторинге каждой мелочи скурпулёзно и долго разными способами искать, где и как она используется.
AB>Запустить автотесты в рамках CI после коммита и выявить все места — чего проще?
Какая прелесть. И правда, чего проще? Подумаешь, написать и потом поддерживать (менять по мере изменений кода) с десяток тыщ автотестов (именно такой порядок количества тестов будет на моём нынешнем, не самом большом и сложном из виденных мною проектов, чтобы более-менее полностью его покрыть). Дальше не читал.
AV>Меня искренне поражает вера людей в тесы.
AV>Максимум что может поймать тест это регрессию. И то не гарантированно.
Все без исключения тесты подают на вход некоторого кода данные и сравнивают результат с эталоном.
Все что может сказать тест, это есть расхождения с эталоном или нет.
Те показать наличие или отсутствие регрессии.
Причем если регрессия появилась на данных, которые не проверяются ни одним тестом, то эта регрессия существующим тестом выявлена быть не может.
А теперь скажи, почему ты пытаешься спорить с фактами?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
AV>>Меня искренне поражает вера людей в тесы.
AV>>Максимум что может поймать тест это регрессию. И то не гарантированно.
WH>Все без исключения тесты подают на вход некоторого кода данные и сравнивают результат с эталоном. WH>Все что может сказать тест, это есть расхождения с эталоном или нет.
Да.
WH>Те показать наличие или отсутствие регрессии.
Да. Но вот ты забыл про слово "максимум" из исходного сообщения.
WH>А теперь скажи, почему ты пытаешься спорить с фактами?
Потому что до фактов еще очень далеко.
Спорить с тобой по поводу тестов не намерен. Ибо прекрасно знаю твое отношение к ним. Тестами, как и любым другим инструментом, надо уметь пользоваться. А не возмодить их в абсолют.
Здравствуйте, ambel-vlad, Вы писали:
AV>Да. Но вот ты забыл про слово "максимум" из исходного сообщения.
И что это меняет?
Все что могут тесты это находит регрессии.
Ничего другого они не умеют теоритически.
При этом даже нахождение регрессии не гарантированно.
WH>>А теперь скажи, почему ты пытаешься спорить с фактами? AV>Потому что до фактов еще очень далеко.
Как это? Я описал модель работы тестов.
Ты с ней согласился.
Я просто не могу понять, с чем ты споришь?
AV>Спорить с тобой по поводу тестов не намерен. Ибо прекрасно знаю твое отношение к ним. Тестами, как и любым другим инструментом, надо уметь пользоваться. А не возмодить их в абсолют.
У меня нет к тестам никакого отношения.
Моя позиция исключительно рациональна и основана на анализе модели тестов. С которой ты согласился.
При этом я не говорю, что тесты не нужны. Я говорю о том, что многие склонны сильно переоценивать их возможности.
В то же время любители динамической типизации очень сильно занижают возможности системы типов. И это при том, что если система типов проверяет некоторое свойство, то она это делает со 100%ным покрытием и на всех возможных входных данных. Развитые системы типов (например, liquid types) могут проверять очень широкий класс свойств программы, фактически убирая надобность в юнит-тестах полностью.
И что характерно почти каждый раз когда я читаю статьи по подобным системам типов в них есть упоминание того что авторы нашли ошибку в существующем, затестированным до дыр библиотечном коде на который они натравили свою систему типов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>А теперь скажи, почему ты пытаешься спорить с фактами? AV>>Потому что до фактов еще очень далеко. WH>Как это? Я описал модель работы тестов. WH>Ты с ней согласился.
Это была модель тестов? Ну ты силен. Я согласился лишь только с одним утверждением. И ничего более.
И позволю себе повторить. Спорить с тобой по поводу тестов не намерен. Ибо прекрасно знаю твое отношение к ним.
Здравствуйте, WolfHound, Вы писали:
WH>В то же время любители динамической типизации очень сильно занижают возможности системы типов. И это при том, что если система типов проверяет некоторое свойство, то она это делает со 100%ным покрытием и на всех возможных входных данных. Развитые системы типов (например, liquid types) могут проверять очень широкий класс свойств программы, фактически убирая надобность в юнит-тестах полностью.
А ну ка, на примере. Ниже юнит-тесты, как закрыть вопрос с помощью системы типов. Надеюсь из тестови примера использования понятно, что должно и как работать.
[TestClass()]
public class StateTest
{
private TestObject _obj;
[TestInitialize]
public void Init()
{
_obj = new TestObject();
}
[TestMethod()]
public void SelectedTest()
{
_obj.State.Selected = true;
Assert.IsTrue(_obj.State.Selected);
}
[TestMethod()]
public void SelectableTest()
{
_obj.State.Selected = true;
_obj.State.Selectable = false;
Assert.IsFalse(_obj.State.Selected);
Assert.IsFalse(_obj.State.Selectable);
}
[TestMethod()]
public void SelectableTest2()
{
_obj.State.Selected = false;
_obj.State.Selectable = true;
Assert.IsFalse(_obj.State.Selected);
Assert.IsTrue(_obj.State.Selectable);
}
[TestMethod()]
public void ClearCategoryTest()
{
_obj.State.SetCategory(0x100);
_obj.State.SetCategory(0x010);
_obj.State.SetCategory(0x001);
_obj.State.ClearCategory(0x010);
Assert.IsTrue(_obj.State.IsCategorySet(0x100));
Assert.IsFalse(_obj.State.IsCategorySet(0x010));
Assert.IsTrue(_obj.State.IsCategorySet(0x001));
}
/// <summary>
///A test for ClearAllCategories
///</summary>
[TestMethod()]
public void ClearAllCategoriesTest()
{
_obj.State.SetCategory(0x100);
_obj.State.ClearAllCategories();
Assert.IsFalse(_obj.State.IsCategorySet(100));
}
/// <summary>
///A test for SetCategory
///</summary>
[TestMethod()]
public void SetCategoryTest()
{
_obj.State.SetCategory(0x100);
_obj.State.SetCategory(0x010);
_obj.State.SetCategory(0x001);
Assert.IsTrue(_obj.State.IsCategorySet(0x111));
Assert.IsTrue(_obj.State.IsCategorySet(0x100));
Assert.IsTrue(_obj.State.IsCategorySet(0x010));
Assert.IsTrue(_obj.State.IsCategorySet(0x001));
}
[TestMethod()]
public void ThroughOrderTest()
{
var value1 = _obj.State.ThroughOrder;
_obj.State.SetCategory(ObjectCategories.Selected);
var value2 = _obj.State.ThroughOrder;
Assert.IsTrue(value1 != value2);
}
[TestMethod()]
public void ThroughOrderTest2()
{
var value1 = _obj.State.ThroughOrder;
_obj.State.ClearCategory(ObjectCategories.Selected);
var value2 = _obj.State.ThroughOrder;
Assert.IsTrue(value1 == value2);
}
[TestMethod()]
public void ThroughOrderTest3()
{
var value1 = _obj.State.ThroughOrder;
_obj.State.ClearCategory(ObjectCategories.Default);
var value2 = _obj.State.ThroughOrder;
Assert.IsTrue(value1 == value2);
}
}
пример исползования
Style GetStyle(IObject obj)
{
return StateToStyleMapper.Get(obj.State); // проверяем флажки которые влияют на стиль
}
Position GetZOrder(IObject obj)
{
return ZOrder.Get(obj.State); // проверяем флажки которые влияют на ZOrder
}
int GetPriority(IObject obj) // проверяею ThroughOrder
{
return Priority.Get(obj.State);
}
и еще кучка таких методов.
Т.е. идея простая — выход задаётся кучкой флажков, учитывается все комбинации этих флажков, самих флажков около 10-15. Style — стиль отрисовки, цвета, смешивание оных, форма и тд и тд. ZOrder — позиция на экране. Приоритет — оптимизация для ZOrder.
Хочется узнать, как система типов даст возможность отказаться от таких вот тестов.
Здравствуйте, Ikemefula, Вы писали:
I>А ну ка, на примере. Ниже юнит-тесты, как закрыть вопрос с помощью системы типов. Надеюсь из тестови примера использования понятно, что должно и как работать.
Те ты хочешь, чтобы я тебе сделал дизайн глядя на тесты?
Единственное что из этих тестов ясно это то, что они в несколько раз больше чем тот код, который они тестируют.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>А ну ка, на примере. Ниже юнит-тесты, как закрыть вопрос с помощью системы типов. Надеюсь из тестови примера использования понятно, что должно и как работать. WH>Те ты хочешь, чтобы я тебе сделал дизайн глядя на тесты?
Чуть ниже ты фактически показал, что ты не только в состоянии сделать это, но и знаешь приблизительное количество кода.
WH>Единственное что из этих тестов ясно это то, что они в несколько раз больше чем тот код, который они тестируют.
В строчках кода — так и есть. И все юнит-тесты обладают такой особенностью — код с тестами в несколько раз больше кода без этих тестов.
Вобщем, суммируя, тебе нечего сказать кроме голословного "фактически убирая надобность в юнит-тестах полностью". На этом можно и закончить.
Здравствуйте, Ikemefula, Вы писали:
WH>>Те ты хочешь, чтобы я тебе сделал дизайн глядя на тесты? I>Чуть ниже ты фактически показал, что ты не только в состоянии сделать это, но и знаешь приблизительное количество кода. Я показал, что могу оценить размер данного куска кода. И больше ничего.
Проблема в том, что переписать только данный кусок кода бесполезно.
Чтобы type driven design заработал нужно переписать все.
Иначе получится байда типа опциональной "статической типизации" в некоторых языках.
А для этого нужно знать исходную постановку задачи.
Ибо с большой вероятностью я вообще использую иную вычислительную модель. Т.к. императивное ООП почти всегда не адекватно.
I>В строчках кода — так и есть. И все юнит-тесты обладают такой особенностью — код с тестами в несколько раз больше кода без этих тестов.
А код с типами и код без типов почти одинаковый.
Посмотри, что народ творит: http://goto.ucsd.edu/~rjhala/liquid/
I>Вобщем, суммируя, тебе нечего сказать кроме голословного "фактически убирая надобность в юнит-тестах полностью". На этом можно и закончить.
Больше, похоже, что ты быстренько сбежал в кусты, когда понял что жареным запахло.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>Те ты хочешь, чтобы я тебе сделал дизайн глядя на тесты? I>>Чуть ниже ты фактически показал, что ты не только в состоянии сделать это, но и знаешь приблизительное количество кода. WH> Я показал, что могу оценить размер данного куска кода. И больше ничего.
Это ты в кусты маршем ?
WH>Проблема в том, что переписать только данный кусок кода бесполезно. WH>Чтобы type driven design заработал нужно переписать все.
Здесь сразу отлуп ибо АПИ трогать нельзя.
WH>Иначе получится байда типа опциональной "статической типизации" в некоторых языках. WH>А для этого нужно знать исходную постановку задачи. WH>Ибо с большой вероятностью я вообще использую иную вычислительную модель. Т.к. императивное ООП почти всегда не адекватно.
Эдак придется переписывать весь продукт надо которым работала добрая сотня людей примерно 7 лет.
I>>Вобщем, суммируя, тебе нечего сказать кроме голословного "фактически убирая надобность в юнит-тестах полностью". На этом можно и закончить. WH>Больше, похоже, что ты быстренько сбежал в кусты, когда понял что жареным запахло.
Не, в кусы ты сам полез когда начал спрыгивать на свои задачки.
Здравствуйте, Ikemefula, Вы писали:
WH>>Проблема в том, что переписать только данный кусок кода бесполезно. WH>>Чтобы type driven design заработал нужно переписать все. I>Здесь сразу отлуп ибо АПИ трогать нельзя.
При дизайне с нуля?
I>Эдак придется переписывать весь продукт надо которым работала добрая сотня людей примерно 7 лет.
Ну, так изначально выбрали кривой инструмент.
Теперь мучайтесь.
I>Не, в кусы ты сам полез когда начал спрыгивать на свои задачки.
Какие свои задачки?
Ты пойми одну простую вещь: Разница между типизацией в C# и например liquid types примерно такая же как разница между типизацией в жабаскрипте и в C#.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Ты пойми одну простую вещь: Разница между типизацией в C# и например liquid types примерно такая же как разница между типизацией в жабаскрипте и в C#.
Здравствуйте, Mamut, Вы писали:
WH>>Ты пойми одну простую вещь: Разница между типизацией в C# и например liquid types примерно такая же как разница между типизацией в жабаскрипте и в C#. M>http://rsdn.ru/forum/philosophy/4270550.aspx
в чистом виде
Вот весь ты в этом.
Разоряешься тут на тему цитируемых статей. А когда получаешь ссылку не только на статью но и на работающий код начинаешь скулить об элитизме.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>>>Ты пойми одну простую вещь: Разница между типизацией в C# и например liquid types примерно такая же как разница между типизацией в жабаскрипте и в C#. M>>http://rsdn.ru/forum/philosophy/4270550.aspx
в чистом виде WH>Вот весь ты в этом. WH>Разоряешься тут на тему цитируемых статей. А когда получаешь ссылку не только на статью но и на работающий код начинаешь скулить об элитизме.
Ты не понял Читай то, что я написал про элитизм еще раз, потом еще раз, а потом еще раз. Авось дойдет (хотя я уже сильно в этом сомневаюсь).
Когда с тобой начинаешь разговаривать о чем либо, ты всегда идешь по строго одному и тому же пути:
— максимально общее заявление
— на вопрос, а где это справедливо, ты сужаешь заявление до некоторого класса языков
— на вопрос, к каким языкам это применимо (или на справедливое замечание, что к существующим языкам это может быть неприменимо) ты показываешь ровно один экспериментальный язык, который обычно интересен только с академической точки зрения или просто никому не нужен даже даром (последние два таких языка — это Nemerle и Ur, а теперь к ним добавилась — академ-реализация liquid types для Haskell/OCaml).
При том, что, быть может, оно все и хорошо и прекрасно — но только и строго сугубо в теории. Теория хороша — но только в теории.
Здравствуйте, Mamut, Вы писали:
M>При том, что, быть может, оно все и хорошо и прекрасно — но только и строго сугубо в теории. Теория хороша — но только в теории.
Работающий компилятор это практика. И с этим ты ничего не сделаешь.
Ты тут всеми силами пытаешься защитить свои любимые язычки. Прим единственное, что ты можешь придумать, это повесить на другой язык ярлык типа: "экспериментальный язык, который обычно интересен только с академической точки зрения или просто никому не нужен даже даром".
Для человека, который требует рецензируемую статью для подтверждения любых слов, мягко говоря, странное поведение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Чем конкретно чревата разработка сложных проектов на PHP
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Ikemefula, Вы писали:
WH>>>Проблема в том, что переписать только данный кусок кода бесполезно. WH>>>Чтобы type driven design заработал нужно переписать все. I>>Здесь сразу отлуп ибо АПИ трогать нельзя. WH>При дизайне с нуля?
На это был даден ответ, чуть ниже.
I>>Эдак придется переписывать весь продукт надо которым работала добрая сотня людей примерно 7 лет. WH>Ну, так изначально выбрали кривой инструмент. WH>Теперь мучайтесь.
Да, и вся индустрия теперь мучается вместе с нами
I>>Не, в кусы ты сам полез когда начал спрыгивать на свои задачки. WH>Какие свои задачки?
Те, на которые ты дал ссылку.
WH>Ты пойми одну простую вещь: Разница между типизацией в C# и например liquid types примерно такая же как разница между типизацией в жабаскрипте и в C#.
На простых примерах, особенно АТД, все и ежу понятно. Потому если у тебя ничего кроме того, что по ссылке нет, можно и закончить.
M>>При том, что, быть может, оно все и хорошо и прекрасно — но только и строго сугубо в теории. Теория хороша — но только в теории. WH>Работающий компилятор это практика. И с этим ты ничего не сделаешь.
Уже лет тридцать, как работающий компилятор — это не повод для гордости.
WH>Ты тут всеми силами пытаешься защитить свои любимые язычки. Прим единственное, что ты можешь придумать, это повесить на другой язык ярлык типа: "экспериментальный язык, который обычно интересен только с академической точки зрения или просто никому не нужен даже даром".
Нет, я не защищаю «любимые языки». Твоя любимая фраза — «в статически типизированных языках то-то и то-то». А как спросишь тебя про C++/Java/C# — сразу начинается, то у них типы не те, то еще что-то не то, и все скатывается... правильно к каким-то теоретическим изысканиям в языках, которые никому даром не нужны.
WH>Для человека, который требует рецензируемую статью для подтверждения любых слов, мягко говоря, странное поведение.
Поведение абсолютно нормальное. В данном случае я просто описываю наблюдаемое поведение.
Здравствуйте, Mamut, Вы писали:
M>>>При том, что, быть может, оно все и хорошо и прекрасно — но только и строго сугубо в теории. Теория хороша — но только в теории. WH>>Работающий компилятор это практика. И с этим ты ничего не сделаешь. M>Уже лет тридцать, как работающий компилятор — это не повод для гордости.
То есть работающий компилятор это теория? Я тебя правильно понял?
M>Нет, я не защищаю «любимые языки». Твоя любимая фраза — «в статически типизированных языках то-то и то-то». А как спросишь тебя про C++/Java/C# — сразу начинается, то у них типы не те, то еще что-то не то, и все скатывается... правильно к каким-то теоретическим изысканиям в языках, которые никому даром не нужны.
Так я давно говорю, что динамисты способны защитить динамику только на фоне говностатики типа той что ты перечислил.
Как только показываешь вам, что-то более умное так сразу начинается скулеж на тему что это никому не нужно...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>>>При том, что, быть может, оно все и хорошо и прекрасно — но только и строго сугубо в теории. Теория хороша — но только в теории. WH>>>Работающий компилятор это практика. И с этим ты ничего не сделаешь. M>>Уже лет тридцать, как работающий компилятор — это не повод для гордости. WH>То есть работающий компилятор это теория? Я тебя правильно понял?
То есть гордится работающим компилятором для проверки каких-либо идей прекратили еще лет тридцать тому назад.
M>>Нет, я не защищаю «любимые языки». Твоя любимая фраза — «в статически типизированных языках то-то и то-то». А как спросишь тебя про C++/Java/C# — сразу начинается, то у них типы не те, то еще что-то не то, и все скатывается... правильно к каким-то теоретическим изысканиям в языках, которые никому даром не нужны. WH>Так я давно говорю, что динамисты способны защитить динамику только на фоне говностатики типа той что ты перечислил. WH>Как только показываешь вам, что-то более умное так сразу начинается скулеж на тему что это никому не нужно...
Не скулеж, а справедилвое замечание, что твои общие фразы про статику справедливы только для очень малого количества языков, исчесляемого от одного до трех.
Беганьем в кусты и скулежом занимаешься только ты. По схеме, описанной мной уже дважды (тут
Повторю: ты постоянно делаешь максимально общие заявления про статически типизированные языки вообще при ближайшем рассмотрении ты тут же поджимаешь хвост и начинаешь рассказывать про «нет, это все не так, вы все не понимаете, я говорил исключительно про Nemerle/Ur/академ. работы».
Вот если бы ты начинал свои заявления со слов «существуют/возможны такие реализации статически-типизированных языков, в которых справедливо то-то и то-то», тебе бы никто слова поперек не сказал.
I>Хочется узнать, как система типов даст возможность отказаться от таких вот тестов.
тесты заменяются на тотальную проверку инвариантов.
в данном случае видно, что тесты пытаются точечно проверить два инварианта:
1. флаги обрабатываются независимо друг от друга (или другими словами: изменение одного флага не меняет состояние других флагов),
2. все флаги обрабатываются единообразно(для массовых функций)
эти общие инварианты можно автоматически (или руками) уточнить до инварианта входа/выхода каждой функции.
замена тестов на инварианты позволяет:
во-первых, уменьшить объем тестового кода
во-вторых, добиться полноты проверки
в-третьих, ускорить время проверки валидности кода
