T.R.O.N: PHP... Этим он привлекает очень много, особенно начинающих.
По-моему это замечательный ответ на вопрос ООП или функции :)
T.R.O.N: те кто не слышал о настоящем ASP, были "шокированы" возможностью пыхи иметь серверный код внутри html текста
Меня это шокирует до сих пор. Но это уже другой холивар :)
T.R.O.N: понимаете разницу между надстройкой, которая нужна и надстройкой
Неа. Если что-то сделано оно уже кому-то нужно. А если этим пользуется несколько сотен тысяч разработчиков - то тем более оно нужно. Хотя можно конечно и обойтись.
Brim.ru: - все остальные, популярные на данный момент в web-разработке языки программирования, объектные и там функциональное программирование это особое извращение попирающее самую суть используемого языка, а в PHP можно писать в разном стиле, отсюда и дискуссия.
Либо девушка, либо не девушка. Либо пользоваться надстройкой на С(С++/ассеблер. Не знаю на чем PHP написан и знать не хочу) либо рассуждать об извращенности и неэффективности надстроек. А если уж не девушка, так почему бы не воспользваться наработками ZEND или каким другими типа Cake, CI, Cohana, YII.... Ну в крайнем случае PHPClasses.
Почему у всех прочих вопрос о необходимости ООП не возникает, а у php-программистов до сих пор дискутируется?
Если здесь пробежит Т.R.O.N. он обязательно всплывет относительно надстроек над JS. Он это любит :)
T.R.O.N: Если какой-либо модуль работает на 1-2 проектах с посещаемостью в 2-3 к в сутки в течении нескольких месяцев , это дает 99% уверенности что все ок.
У вас баг на форме сообщения об ошибках :)
burunduk: T.R.O.N использование того же jQuery только ради одной/двух функции не разумно
соотношение числа функций/разумности - вопрос времени. ТРОН до сих пор уверен что нет такого функционала ради которого нужно использовать стандартные средства разработки, А у вас планка дошла до 4+ функций.
Такие изыскания были в моде лет 5-10 назад. Потом поисковики поняли что их дурят и Footer/header/menu стали определять не по тому где они расположены в верстке, а по наличию повторяющегося/уникального контента на странице.
Влияние может и оказывает, но на фоне ссылочного ранжирования - оно нулевое.
T.R.O.N: А на возможные собственные баги натягивать еще и баги чужие - зачем?
При прочих равных, количество багов - это производная от интенсивности тестирования. Я нисколько не сомневаюсь в вашей квалификации, или квалификации большинства остальных критиков jQuery/Prototype, но самописные фреймворки как правило тестируются на много порядков менее интенсивно чем продукты массовые - типа jQuery. Поэтому вероятность нарваться на баг с использованием массового продукта намного ниже. К тому же известный баг - это не баг. Это фича.
T.R.O.N: конечно. По невменяемости тягаться тяжело. Пусть будет ИМХО
Ну да. А код сгенерированный .NET или запросы построенные через ORM вменяемые? Их тоже в топку? Или все-же цена разработки и сопровождения на первом месте?
T.R.O.N: Если так, то для Вас, скорее всего, фреймворки
Да не для меня. фреймворки - основной вектор развития. В ASP или Ruby он был с самого начала, В PHP и JS он просочился 3-4 года назад.
T.R.O.N: достойный функционал и без сложного GU интерфейса
Я плохо представляю надобность сложного js-функционала без наличия взаимодействия пользователя с интерфейсом. Придумать симулякр конечно можно, но если использовать готовые решения он будет дешевле и в разработке и в сопровождении.
T.R.O.N: естественно. Кто же против. Ведь сам .NET основан на фрейворках. Вот с этим соглашусь.
Так ведь и php-программисты медленно но верно, переходят на опенсорсовские фреймворки. А там тоже самое - встраивают prototype и jquery (Например yii)
Теv кто сидит на Phyton и Ruby проще - у них фреймворки практически с самого начала были.
T.R.O.N: И еще, говоря о сопровождении, почему-то почти все имеют ввиду простенькие скрипты
Такие сайты вообще мало кто сопровождает.
T.R.O.N: Если же скрипт в своем функционале имеет интересные новые идеи, для которых интерфейс это только вспомогательная часть
Я всегда считал, что интерфейс всегда первичен. Все остальное - клиентские скрипты или серверные - вторичны. В конце концов асинхронные запросы можно выполнять без всякого Ajax.
T.R.O.N: то при уходе программера наступают те-же проблемы, при всей огромности документации на фреймворки. Если же программер нормальный, и делает все "как для себя", то и в самом коде и в построении интерфейса разобраться будет не сложно.
Если бы это было так параллельно аббревиатуре RTFM была бы аббревиатура RTFСode
Даже если в договоре есть пункт о составлении докуменатции, документация написанная среднестатистическим программистом никогда не сравнится с мануалами, и учебниками, которая сопровождает наиболее ходовые фреймворки типа jquery/prototype
T.R.O.N: потому что именно от непонимая принципов, появляются желание использовать эти очень кривые (ИМХО для больших поклонников) фреймворки.
желание использовать фреймворки аналогичны желанию использовать языки высокого уровня, и RAD-средств, вместо написания велосипедов на ассемблере.
Кроме скорости разработки (и соответственно снижению цены), фреймворки так же дают снижение стоимости сопровождения. ловить баги и модифицировать ассемблерный код, давно уволившегося программиста, существенно сложнее чем код написанный на языке высокого уровня с хорошо документированными библиотеками.
Хотя по эффективности кода они проигрывают. Если код небольшой, программист высококвалифицированный, и пишет не с нуля, а использует свой собственный фреймворк, который в сто раз лучше и безглючнее опенсорсовского, или MS/Yahoo/Google
T.R.O.N: для тех, кто не знает JavaScript(Richard Cornford)
К счастью на Richard Cornford свет клином не сошелся. Например MS интегрировали jQuery в состав .NET. Теперь у .NET разработчиков есть альтернатива более старой и родной ajax-библиотеки Atlas. Которая три года назад была страшно кривой. А сейчас говорят почти без багов.
PHP... Этим он привлекает очень много, особенно начинающих.
По-моему это замечательный ответ на вопрос ООП или функции :)
те кто не слышал о настоящем ASP, были "шокированы" возможностью пыхи иметь серверный код внутри html текста
Меня это шокирует до сих пор. Но это уже другой холивар :)
понимаете разницу между надстройкой, которая нужна и надстройкой
Неа. Если что-то сделано оно уже кому-то нужно. А если этим пользуется несколько сотен тысяч разработчиков - то тем более оно нужно. Хотя можно конечно и обойтись.
Больше того любителей именно так ее настроить сразу после установки - навалом! :)
В древних версиях оперы она по дефолту представлялась MSIE.
- все остальные, популярные на данный момент в web-разработке языки программирования, объектные и там функциональное программирование это особое извращение попирающее самую суть используемого языка, а в PHP можно писать в разном стиле, отсюда и дискуссия.
Либо девушка, либо не девушка. Либо пользоваться надстройкой на С(С++/ассеблер. Не знаю на чем PHP написан и знать не хочу) либо рассуждать об извращенности и неэффективности надстроек. А если уж не девушка, так почему бы не воспользваться наработками ZEND или каким другими типа Cake, CI, Cohana, YII.... Ну в крайнем случае PHPClasses.
Почему у всех прочих вопрос о необходимости ООП не возникает, а у php-программистов до сих пор дискутируется?
Если здесь пробежит Т.R.O.N. он обязательно всплывет относительно надстроек над JS. Он это любит :)
Любопытно почему такой вопрос применительно к WEB однозначно ассоциируется с PHP?
Если какой-либо модуль работает на 1-2 проектах с посещаемостью в 2-3 к в сутки в течении нескольких месяцев , это дает 99% уверенности что все ок.
У вас баг на форме сообщения об ошибках :)
T.R.O.N использование того же jQuery только ради одной/двух функции не разумно
соотношение числа функций/разумности - вопрос времени. ТРОН до сих пор уверен что нет такого функционала ради которого нужно использовать стандартные средства разработки, А у вас планка дошла до 4+ функций.
Такие изыскания были в моде лет 5-10 назад. Потом поисковики поняли что их дурят и Footer/header/menu стали определять не по тому где они расположены в верстке, а по наличию повторяющегося/уникального контента на странице.
Влияние может и оказывает, но на фоне ссылочного ранжирования - оно нулевое.
А на возможные собственные баги натягивать еще и баги чужие - зачем?
При прочих равных, количество багов - это производная от интенсивности тестирования. Я нисколько не сомневаюсь в вашей квалификации, или квалификации большинства остальных критиков jQuery/Prototype, но самописные фреймворки как правило тестируются на много порядков менее интенсивно чем продукты массовые - типа jQuery. Поэтому вероятность нарваться на баг с использованием массового продукта намного ниже. К тому же известный баг - это не баг. Это фича.
конечно. По невменяемости тягаться тяжело. Пусть будет ИМХО
Ну да. А код сгенерированный .NET или запросы построенные через ORM вменяемые? Их тоже в топку? Или все-же цена разработки и сопровождения на первом месте?
Если так, то для Вас, скорее всего, фреймворки
Да не для меня. фреймворки - основной вектор развития. В ASP или Ruby он был с самого начала, В PHP и JS он просочился 3-4 года назад.
достойный функционал и без сложного GU интерфейса
Я плохо представляю надобность сложного js-функционала без наличия взаимодействия пользователя с интерфейсом. Придумать симулякр конечно можно, но если использовать готовые решения он будет дешевле и в разработке и в сопровождении.
естественно. Кто же против. Ведь сам .NET основан на фрейворках.
Вот с этим соглашусь.
Так ведь и php-программисты медленно но верно, переходят на опенсорсовские фреймворки. А там тоже самое - встраивают prototype и jquery (Например yii)
Теv кто сидит на Phyton и Ruby проще - у них фреймворки практически с самого начала были.
И еще, говоря о сопровождении, почему-то почти все имеют ввиду простенькие скрипты
Такие сайты вообще мало кто сопровождает.
Если же скрипт в своем функционале имеет интересные новые идеи, для которых интерфейс это только вспомогательная часть
Я всегда считал, что интерфейс всегда первичен. Все остальное - клиентские скрипты или серверные - вторичны. В конце концов асинхронные запросы можно выполнять без всякого Ajax.
то при уходе программера наступают те-же проблемы, при всей огромности документации на фреймворки. Если же программер нормальный, и делает все "как для себя", то и в самом коде и в построении интерфейса разобраться будет не сложно.
Если бы это было так параллельно аббревиатуре RTFM была бы аббревиатура RTFСode
Даже если в договоре есть пункт о составлении докуменатции, документация написанная среднестатистическим программистом никогда не сравнится с мануалами, и учебниками, которая сопровождает наиболее ходовые фреймворки типа jquery/prototype
потому что именно от непонимая принципов, появляются желание использовать эти очень кривые (ИМХО для больших поклонников) фреймворки.
желание использовать фреймворки аналогичны желанию использовать языки высокого уровня, и RAD-средств, вместо написания велосипедов на ассемблере.
Кроме скорости разработки (и соответственно снижению цены), фреймворки так же дают снижение стоимости сопровождения. ловить баги и модифицировать ассемблерный код, давно уволившегося программиста, существенно сложнее чем код написанный на языке высокого уровня с хорошо документированными библиотеками.
Хотя по эффективности кода они проигрывают. Если код небольшой, программист высококвалифицированный, и пишет не с нуля, а использует свой собственный фреймворк, который в сто раз лучше и безглючнее опенсорсовского, или MS/Yahoo/Google
для тех, кто не знает JavaScript(Richard Cornford)
К счастью на Richard Cornford свет клином не сошелся. Например MS интегрировали jQuery в состав .NET. Теперь у .NET разработчиков есть альтернатива более старой и родной ajax-библиотеки Atlas. Которая три года назад была страшно кривой. А сейчас говорят почти без багов.