Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 111
GoDaddy (крупнейший регистратор и хостер) в прошлом году перевел огромное количество припаркованных доменов на серверы с Windows. Этим и обусловлено такое перераспределение сил.
Скачки IIS, на фоне некоторой стабильности, похоже связаны с выходами новых версий .NET Framework.
Думаю, это связано от части с тем, что Apache, как бы там ни было — это просто очень крутой сервер, а у MS готовые решения для бизнеса и т.п.
У меня друг перешел работать в оутсорсинговую фирму ,которая пишет электронные магазины для англичан. 1 программист и треть дизайнера делают магазин за 1 месяц. и все это под .NET. Конечно у них написана своя CMS для таких магазинов, но все равно получается очень низкая себестоимость. В среднем в таких магазинах делается по 10 покупов в день. И заказчики хотят иметь все навароты но тратить мало денег. Для таких решений майкрософт лучший на сегодняшний день.
Вы бредите. Внешние источники... Платформы... Магазины для англичан...
Элементарный дэнвер, один администратор сервер, один php-программист, НЕСКОЛЬКО дизайнеров и размещение в стабильном дата-центре. И пшол .NET куда подальше. Не ради 10 покупок пер сутки стоит с .NET заморачиваться... От .NET пахнет ханжеством и лицемерием...
Элементарный дэнвер, один администратор сервер, один php-программист, НЕСКОЛЬКО дизайнеров и размещение в стабильном дата-центре. И пшол .NET куда подальше. Не ради 10 покупок пер сутки стоит с .NET заморачиваться... От .NET пахнет ханжеством и лицемерием...
От .NET пахнет:
- лучшей средой разработки, из тех что я видел за 10 лет
- замечательной (снова хотел написать лучшей) платформой для создания и сопровождения кода при заказных разработках
И я тоже работаю на британском рынке и .NET решения там востребованы.
P.S. Хотя LAMP - тоже замечательная платформа и прекрасно используется, но за .NET преимущество создания с нуля как объектной платформы приложений.
- лучшей средой разработки, из тех что я видел за 10 лет
- замечательной (снова хотел написать лучшей) платформой для создания и сопровождения кода при заказных разработках
И я тоже работаю на британском рынке и .NET решения там востребованы.
P.S. Хотя LAMP - тоже замечательная платформа и прекрасно используется, но за .NET преимущество создания с нуля как объектной платформы приложений.
От .NET пахнет Java и ничем другим. Просто сравните их. Проблема в том что квалифицированные программисты под java дороже под .NET, т.к. зарубежом на Java строят действительно сложные и нагруженные проекты.
PS redhummer PHP зло. Это очень плохой язык.
PS redhummer PHP зло. Это очень плохой язык.
Просто сравниваю .NET и Java и не вижу преимуществ Java.
Хороший спец по Prolog вообще бешеных денег стоит :)
а на .NET и LAMP выходит не строят? :)
Хороший спец по Prolog вообще бешеных денег стоит :)
зарубежом на Java строят действительно сложные и нагруженные проекты
а на .NET и LAMP выходит не строят? :)
Просто сравниваю .NET и Java и не вижу преимуществ Java.
Не видите ? :) В .NET есть полный аналог J2EE? У .NET есть кроссплатформенность?
а на .NET и LAMP выходит не строят? :)
На .NET может быть, но не думаю что это сильно загруженные проекты. На LAMP однозначно нет, очень много геммороя.
Не видите ? :) В .NET есть полный аналог J2EE? У .NET есть кроссплатформенность?
а на .NET и LAMP выходит не строят? :)
На .NET может быть, но не думаю что это сильно загруженные проекты. На LAMP однозначно нет, очень много геммороя.
В .NET есть полный аналог J2EE?
Смотря что понимать под "полный аналог J2EE"? В .NET есть все, что нужно для серверных приложений приложений любой архитектуры. Я конечно не работал плотно с java-проектами, но не знаю чего-то уникального в J2EE, аналогов чему нет в .NET.
У .NET есть кроссплатформенность?
А она кому-то нужна? Без маркетинговых деклараций, а в реальных проектах :)
На .NET может быть, но не думаю что это сильно загруженные проекты?
Не знаю, что вы имете ввиду под "сильно нагруженными". Сильно нагруженные пишут на Си.
А на .NET пыхтит MySpace.com, хоть и частично. Да и сам Microsoft.com.
Вообще тут всё упирается в "на чем начали писать" и "сколько есть денег на сервера".
P.S. Кстати, я вообще что-то последние лет 5 про серверную Java ничего не слышал. Не в смысле "а не померла ли", а в смысле развития и расширения рынка.
Смотря что понимать под "полный аналог J2EE"? В .NET есть все, что нужно для серверных приложений приложений любой архитектуры. Я конечно не работал плотно с java-проектами, но не знаю чего-то уникального в J2EE, аналогов чему нет в .NET.
J2EE. Я говорю не про SE (Standart Edition), а про EE (Enterprise Edition). Инструментарий. Вот гляньте http://www.oreillynet.com/pub/a/oreilly/…
А она кому-то нужна? Без маркетинговых деклараций, а в реальных проектах
Вот это вообще глупый вопрос. Т.е. то что к примеру проект сначала использовал PC с Linux, а потом PC с Solaris, а потом начали использовать Sparc с Solaris вами не учитывается? В случае .NET происходит ограничение только платформой PC и Windows. На что-то другое перейти нельзя. Просто нарастить мощность сменой платформы нельзя. Много мы чего получаем нельзя. Да еще вопрос если .NET так привязана к Windows платформе на кой делать виртуальную машину и байткод?
А на .NET пыхтит MySpace.com, хоть и частично. Да и сам Microsoft.com.
Вообще тут всё упирается в "на чем начали писать" и "сколько есть денег на сервера".
На java работает sun.com, ibm.com, ebay.com (там правда частично используется C на opennet.ru недавно пробегала ссылка на используюему там архитектуру). Упирается то конечно все в сервера, но в случае .NET это могут быть крупные суммы даже по сравнению с серверами для java.
Кстати, я вообще что-то последние лет 5 про серверную Java ничего не слышал. Не в смысле "а не померла ли", а в смысле развития и расширения рынка.
Для серверной java требуются серьезные разработчики. А сайчас развитие веба идет в сфере мелкого и среднего бизнеса. Они же по большей части берут то что им удобнее и понятнее. Обычно их IT-инфраструктура построена на продуктах Windows. В этом случае .NET выгодна и удобно. Особенно учитывая что она была скопирована с java :)
J2EE. Я говорю не про SE (Standart Edition), а про EE (Enterprise Edition). Инструментарий. Вот гляньте http://www.oreillynet.com/pub/a/oreilly/…
А она кому-то нужна? Без маркетинговых деклараций, а в реальных проектах
Вот это вообще глупый вопрос. Т.е. то что к примеру проект сначала использовал PC с Linux, а потом PC с Solaris, а потом начали использовать Sparc с Solaris вами не учитывается? В случае .NET происходит ограничение только платформой PC и Windows. На что-то другое перейти нельзя. Просто нарастить мощность сменой платформы нельзя. Много мы чего получаем нельзя. Да еще вопрос если .NET так привязана к Windows платформе на кой делать виртуальную машину и байткод?
А на .NET пыхтит MySpace.com, хоть и частично. Да и сам Microsoft.com.
Вообще тут всё упирается в "на чем начали писать" и "сколько есть денег на сервера".
На java работает sun.com, ibm.com, ebay.com (там правда частично используется C на opennet.ru недавно пробегала ссылка на используюему там архитектуру). Упирается то конечно все в сервера, но в случае .NET это могут быть крупные суммы даже по сравнению с серверами для java.
Кстати, я вообще что-то последние лет 5 про серверную Java ничего не слышал. Не в смысле "а не померла ли", а в смысле развития и расширения рынка.
Для серверной java требуются серьезные разработчики. А сайчас развитие веба идет в сфере мелкого и среднего бизнеса. Они же по большей части берут то что им удобнее и понятнее. Обычно их IT-инфраструктура построена на продуктах Windows. В этом случае .NET выгодна и удобно. Особенно учитывая что она была скопирована с java :)
J2EE. Я говорю не про SE (Standart Edition), а про EE (Enterprise Edition). Инструментарий. Вот гляньте
Глянул. И чего не хватает в .NET? Да и статья за 2000 год. Сейчас уже и 2006 и .NET Framework 3.0 в релизе.
Вот это вообще глупый вопрос...
Точно глупый. Linux на Solaris и т.д. - это скорее миграции и перекомпиляции (не накидывайтесь, Solaris для меня тот же *nix :) ).
Я не спорю, что кросплатформенность замечательная штука, но она нужна уж очень редко. Начали на Java, потом она и помогает по *nix-ам перемещаться. А перескачить вдруг на другой сервер приложений или на совсем другую платформу - всё равно геммороя и затрат куча будет, а не по "нажатию кнопки".
Просто нарастить мощность сменой платформы нельзя
Если это "просто нарастить мощность", то снимаю перед вами шляпу :)
Да еще вопрос если .NET так привязана к Windows платформе на кой делать виртуальную машину и байткод?
А на то, что под .NET вы можете на многих языках писать. И на Java в том числе.
Да и есть реализация .NET для Unix, но Microsoft не её поддерживает и пока там все так себе.
Упирается то конечно все в сервера, но в случае .NET это могут быть крупные суммы даже по сравнению с серверами для java.
Ну вот и давайте не будем про крупные суммы. Что Microsoft не бесплатный, что сервера приложений для Java. И всем одинакого мощности нужны.
Для серверной java требуются серьезные разработчики
Серьезность разработчика не определяется теми языками и платформами, которые он знает. Не вижу чего такого сложного в Java, чтобы Java-разработчики были "серьезнее" других разработчиков. Ценится голова и опыт.
А сайчас развитие веба идет в сфере мелкого и среднего бизнеса. Они же по большей части берут то что им удобнее и понятнее. Обычно их IT-инфраструктура построена на продуктах Windows. В этом случае .NET выгодна и удобно
Web развивается всеми видами бизнеса. Я думаю дело в ограниченияе Java в доступности. Для Java надо поднимать только свой сервер. Для LAMP или .NET тебе пожалуйста и shared и dedicated и начиная от 5 долларов в месяц.
Особенно учитывая что она была скопирована с java
А такие выпады в стиле маркетологов и пиарщиков Sun-а или Micrоsoft-а делать не обязательно ;)
Глянул. И чего не хватает в .NET? Да и статья за 2000 год.
Сравните количество инструментария. В J2EE на данный момент больше.
Сейчас уже и 2006 и .NET Framework 3.0 в релизе.
А JDK 6 у
же вышло :)
Точно глупый. Linux на Solaris и т.д. - это скорее миграции и перекомпиляции (не накидывайтесь, Solaris для меня тот же *nix :) ).
Это не требует перекомплиции :)
Я не спорю, что кросплатформенность замечательная штука, но она нужна уж очень редко.
Если она вам не нужна это не означает, что она не нужна другим.
Начали на Java, потом она и помогает по *nix-ам перемещаться. А перескачить вдруг на другой сервер приложений или на совсем другую платформу - всё равно геммороя и затрат куча будет, а не по "нажатию кнопки".
В случае java и смены только аппаратной платформы и ОС, но не программной платформы (т.е. сервера приложений) именно и будет нажатие "одной кнопки".
Ну вот и давайте не будем про крупные суммы. Что Microsoft не бесплатный, что сервера приложений для Java. И всем одинакого мощности нужны.
Resin один из самых неплохих серверов стоит 500$. Сервер от Sun как и их ОС бесплатны. Плата идет только за поддержку. Так что далеко не факт что решение на базе .NET будет дешевле. А насчет мощности это вы зря. Windows как серверная платформа слаба.
Серьезность разработчика не определяется теми языками и платформами, которые он знает.
Не платформами и языками, а технологиями которыми он владеет. Языки и платформы вторичны, технологии первичны.
Не вижу чего такого сложного в Java, чтобы Java-разработчики были "серьезнее" других разработчиков. Ценится голова и опыт.
В java используется очень большое число довольно сложных технологий, которые в других языках и не используются во все. Для их эффективного использования требуется хорошая подготовка.
Web развивается всеми видами бизнеса. Я думаю дело в ограниченияе Java в доступности. Для Java надо поднимать только свой сервер. Для LAMP или .NET тебе пожалуйста и shared и dedicated и начиная от 5 долларов в месяц.
По этому я и говорил про мелкий и средний бизнес.
А такие выпады в стиле маркетологов и пиарщиков Sun-а или Micrоsoft-а делать не обязательно ;)
Ага взяли вот из воздуха все и придумали. И то что многое в .NET сделано как в Java так случайное совпадение. Только вот совпадений сильно много.
Сравните количество инструментария. В J2EE на данный момент больше.
Сейчас уже и 2006 и .NET Framework 3.0 в релизе.
А JDK 6 у
же вышло :)
Точно глупый. Linux на Solaris и т.д. - это скорее миграции и перекомпиляции (не накидывайтесь, Solaris для меня тот же *nix :) ).
Это не требует перекомплиции :)
Я не спорю, что кросплатформенность замечательная штука, но она нужна уж очень редко.
Если она вам не нужна это не означает, что она не нужна другим.
Начали на Java, потом она и помогает по *nix-ам перемещаться. А перескачить вдруг на другой сервер приложений или на совсем другую платформу - всё равно геммороя и затрат куча будет, а не по "нажатию кнопки".
В случае java и смены только аппаратной платформы и ОС, но не программной платформы (т.е. сервера приложений) именно и будет нажатие "одной кнопки".
Ну вот и давайте не будем про крупные суммы. Что Microsoft не бесплатный, что сервера приложений для Java. И всем одинакого мощности нужны.
Resin один из самых неплохих серверов стоит 500$. Сервер от Sun как и их ОС бесплатны. Плата идет только за поддержку. Так что далеко не факт что решение на базе .NET будет дешевле. А насчет мощности это вы зря. Windows как серверная платформа слаба.
Серьезность разработчика не определяется теми языками и платформами, которые он знает.
Не платформами и языками, а технологиями которыми он владеет. Языки и платформы вторичны, технологии первичны.
Не вижу чего такого сложного в Java, чтобы Java-разработчики были "серьезнее" других разработчиков. Ценится голова и опыт.
В java используется очень большое число довольно сложных технологий, которые в других языках и не используются во все. Для их эффективного использования требуется хорошая подготовка.
Web развивается всеми видами бизнеса. Я думаю дело в ограниченияе Java в доступности. Для Java надо поднимать только свой сервер. Для LAMP или .NET тебе пожалуйста и shared и dedicated и начиная от 5 долларов в месяц.
По этому я и говорил про мелкий и средний бизнес.
А такие выпады в стиле маркетологов и пиарщиков Sun-а или Micrоsoft-а делать не обязательно ;)
Ага взяли вот из воздуха все и придумали. И то что многое в .NET сделано как в Java так случайное совпадение. Только вот совпадений сильно много.
Сравните количество инструментария. В J2EE на данный момент больше.
Под инструментарием вы что понимаете? Среды разработки?
Так что далеко не факт что решение на базе .NET будет дешевле
Я не говорил, что обязательно будет дешевле. Я не согласился с Вами, что .NET будет дороже.
Windows как серверная платформа слаба
С такими высказываниями и спорить не хочется.
В java используется очень большое число довольно сложных технологий, которые в других языках и не используются во все. Для их эффективного использования требуется хорошая подготовка.
Джависты круче всех :)
Ага взяли вот из воздуха все и придумали. И то что многое в .NET сделано как в Java так случайное совпадение. Только вот совпадений сильно много.
А Java снизошла божественным прозрением и ни на чем не основывается?
Cоздателям .NET не ставилась задача "скопируйте нам Java", а требовалось создать конкурента Java во всех сегментах рынка. Что у них и успешно получилось. Java завоевала мобильники.
Под инструментарием вы что понимаете? Среды разработки?
Программные платформы и стандартные тулкиты.
Я не говорил, что обязательно будет дешевле. Я не согласился с Вами, что .NET будет дороже.
Зависит от приложения и нагрузки. Опять же серверная Windows масштабируется и держит нагрузки хуже Solaris и Linux.
С такими высказываниями и спорить не хочется.
А в чем она сильна? Масштабируемость у нее хуже чем у Solaris.
Джависты круче всех :)
У языка Java довольно высокий уровень вхождения. А если касаться еще всех тонкостей J2EE то потребуется высокая квалификация. В .NET конечно если писать на С# уровень тоже требуется не маленький.
А Java снизошла божественным прозрением и ни на чем не основывается?
Большая часть была придумана именно разработчиками. Да часть вещей заимствовалась уже из существующих языков.
Cоздателям .NET не ставилась задача "скопируйте нам Java", а требовалось создать конкурента Java во всех сегментах рынка. Что у них и успешно получилось. Java завоевала мобильники.
Не все сегменты рынка, а конкурента java только на их платформах. На их платформах получилась очень удобная штука. Но эта штука удобна только для их платформ. И дальше собственно Windows не уйдет. Естественно оно получилось довольно хорошим т.к. делалось с оглядкой на java и хорошей интерграцией с Windows, но вот я до сих пор не могу понять зачем им потребовалась виртуальная машина. Разве что только для работы .NET приложений под КПК.
PS Кстати мой знакомый программист писал для КПК ПО на .NET работало оно мягко говоря не быстро. Когда же он переписал его на Java оно почему-то работало заметно быстрее. Как так? :)
Программные платформы и стандартные тулкиты.
Я не говорил, что обязательно будет дешевле. Я не согласился с Вами, что .NET будет дороже.
Зависит от приложения и нагрузки. Опять же серверная Windows масштабируется и держит нагрузки хуже Solaris и Linux.
С такими высказываниями и спорить не хочется.
А в чем она сильна? Масштабируемость у нее хуже чем у Solaris.
Джависты круче всех :)
У языка Java довольно высокий уровень вхождения. А если касаться еще всех тонкостей J2EE то потребуется высокая квалификация. В .NET конечно если писать на С# уровень тоже требуется не маленький.
А Java снизошла божественным прозрением и ни на чем не основывается?
Большая часть была придумана именно разработчиками. Да часть вещей заимствовалась уже из существующих языков.
Cоздателям .NET не ставилась задача "скопируйте нам Java", а требовалось создать конкурента Java во всех сегментах рынка. Что у них и успешно получилось. Java завоевала мобильники.
Не все сегменты рынка, а конкурента java только на их платформах. На их платформах получилась очень удобная штука. Но эта штука удобна только для их платформ. И дальше собственно Windows не уйдет. Естественно оно получилось довольно хорошим т.к. делалось с оглядкой на java и хорошей интерграцией с Windows, но вот я до сих пор не могу понять зачем им потребовалась виртуальная машина. Разве что только для работы .NET приложений под КПК.
PS Кстати мой знакомый программист писал для КПК ПО на .NET работало оно мягко говоря не быстро. Когда же он переписал его на Java оно почему-то работало заметно быстрее. Как так? :)
Зависит от приложения и нагрузки. Опять же серверная Windows масштабируется и держит нагрузки хуже Solaris и Linux.
Понятно что зависит. Можно какие-то объективные цифры увидеть или ссылку?
Зачем виртуальная машина - писал. И в .NET она не совсем та виртуальная, что и в Java.
Кстати мой знакомый программист писал...
Уж писал бы тогда на Си. А так все равно зависит от целей и задач.
Довольно старый тест:
http://www.citforum.ru/programming/java/…
Но любопытный.
Зачем виртуальная машина - писал.
Когда я смотрел, то автор свел к тому что не все Windows одинаковы и чтобы везде все работало одинаково код запихнули еще в один отдельный слой абстракции. Но если они сделают Singularity и туда сделают .NET это будет очень интересная штука.
И в .NET она не совсем та виртуальная, что и в Java.
Читал. Мне вот идея со стеком немного сомнительно показалась. не будет ли оно интенсивно жрать память на сложном коде?
Уж писал бы тогда на Си. А так все равно зависит от целей и задач.
Насколько помню у его уже была часть кода на .NET и он просто хотел перенести его на КПК.
http://www.citforum.ru/programming/java/…
Но любопытный.
Зачем виртуальная машина - писал.
Когда я смотрел, то автор свел к тому что не все Windows одинаковы и чтобы везде все работало одинаково код запихнули еще в один отдельный слой абстракции. Но если они сделают Singularity и туда сделают .NET это будет очень интересная штука.
И в .NET она не совсем та виртуальная, что и в Java.
Читал. Мне вот идея со стеком немного сомнительно показалась. не будет ли оно интенсивно жрать память на сложном коде?
Уж писал бы тогда на Си. А так все равно зависит от целей и задач.
Насколько помню у его уже была часть кода на .NET и он просто хотел перенести его на КПК.
В общем, возвращаясь к началу дискуссии,
Не видите ? :) В .NET есть полный аналог J2EE? У .NET есть кроссплатформенность?
Преимуществ при выборе ".NET или Java" я так и не увидел.
Если выбор "только не Windows", то согласен, на *nix Java - единственная аналогичная платформа разработки.
Если вам требуется переносимый проект с заделом на хорошую масштабируемость то однозначно Java. Если же первичная платформа Windows и требуется интеграция с ПО под нее то только .NET
В двух словах:
.NET
- нет кросплатфрменности (работаем тока под виндой).
- хорошо работает только с MSSQL.
Java
- есть кросплатформенность
- отличная интеграция с большинством СУБД в том числе oracler
- если считать началом проекта 1991 г. то мы имеем 16-и летний труд и отлично вылизаный код.
- поддержка со стороны сторонних разработчиков в том числе oracle и IBM
.NET
- нет кросплатфрменности (работаем тока под виндой).
- хорошо работает только с MSSQL.
Java
- есть кросплатформенность
- отличная интеграция с большинством СУБД в том числе oracler
- если считать началом проекта 1991 г. то мы имеем 16-и летний труд и отлично вылизаный код.
- поддержка со стороны сторонних разработчиков в том числе oracle и IBM
+1
Подписываюсь под каждым словом
Подписываюсь под каждым словом
Mamba.ru знаете? Работает Nginx + PHP (FastCGI) + Memcached. Кое-что написано на C. Так что не надо ляля... При грамотной архитектуре практически на любой платформе можно построить решение под высокие нагрузки.
А все эти ".Net круче", "Java лучше", "LAMP лучше" полная религиозная херня которая вас характеризует как начинающего программиста, но не как не как профессионального разработчика.
А все эти ".Net круче", "Java лучше", "LAMP лучше" полная религиозная херня которая вас характеризует как начинающего программиста, но не как не как профессионального разработчика.
Работает Nginx + PHP (FastCGI) + Memcached. Кое-что написано на C. Так что не надо ляля...
Ага уберите два костыля в виде FastCGI и memcached и получите полную хрень. Вы к примеру знаете что есть реализация PHP на Java которая работает в два раза быстрее нативной?
При грамотной архитектуре практически на любой платформе можно построить решение под высокие нагрузки.
На каком угодно языке можно написать что угодно. Вопрос только в трудоемкости процесса. Я не думаю, что если бы сейчас они бы писали этот сервис с нуля с учетом такой нагрузки то выбрали PHP.
А все эти ".Net круче", "Java лучше", "LAMP лучше" полная религиозная херня которая вас характеризует как начинающего программиста, но не как не как профессионального разработчика.
Профессиональный разработчик в первую очередь должен уметь оценивать на чем стоит делать проект. PHP же для нагруженных проектов достаточно большой гемморой.
Ага уберите два костыля в виде FastCGI и memcached и получите полную хрень. Вы к примеру знаете что есть реализация PHP на Java которая работает в два раза быстрее нативной?
При грамотной архитектуре практически на любой платформе можно построить решение под высокие нагрузки.
На каком угодно языке можно написать что угодно. Вопрос только в трудоемкости процесса. Я не думаю, что если бы сейчас они бы писали этот сервис с нуля с учетом такой нагрузки то выбрали PHP.
А все эти ".Net круче", "Java лучше", "LAMP лучше" полная религиозная херня которая вас характеризует как начинающего программиста, но не как не как профессионального разработчика.
Профессиональный разработчик в первую очередь должен уметь оценивать на чем стоит делать проект. PHP же для нагруженных проектов достаточно большой гемморой.
Я вот любому своему клиенту про Java скажу в любом случае - гемморой ;)
а что в PHP появилась нормальная объектная модель? И сервера стали в стандартной комплектации держать нагрузку ? :)
Да я вообще-то .NET люблю :)
А PHP - ну вот такой уж кривенький есть. Уж лучше Perl-а :)
А PHP - ну вот такой уж кривенький есть. Уж лучше Perl-а :)
PHP это хорошая вещь для проектов не превышающих 500кб кода и не более 100 одновременных посетителей. Если происходит выход за эти рамки начинаются радости жизни с PHP. :)
Ага уберите два костыля в виде FastCGI и memcached
Вы что, какие костыли ? FastCGI реализует более разумную модель
приложения, чем mod_php. Без лишних копий. В-принципе, если (бы) иметь на входе другой разумный сериализатор, то можно было (бы) иметь и mod_php backend.
А, извините, memcached реализует то, что в любом случае придется реализовывать руками - кэширование в памяти тех данных, которые там нужны.
PHP же для нагруженных проектов достаточно большой гемморой.
Нагруженные проекты сами по себе большой геморой
Вы что, какие костыли ? FastCGI реализует более разумную модель
приложения, чем mod_php. Без лишних копий. В-принципе, если (бы) иметь на входе другой разумный сериализатор, то можно было (бы) иметь и mod_php backend.
А, извините, memcached реализует то, что в любом случае придется реализовывать руками - кэширование в памяти тех данных, которые там нужны.
PHP же для нагруженных проектов достаточно большой гемморой.
Нагруженные проекты сами по себе большой геморой
Нагруженные проекты сами по себе большой геморой
похоже, имелось ввиду, что php не обладает достаточной масштабируемостью, для больших проектов
и, черт возьми, я с этим абсолютно согласен
действительно, написать небольшой сайтец, несложный движок - на php очень быстро и удобно. подключать тяжелую артиллерию в виде с#/java смысла нету
но серьезный веб-сайт разрабатывать (я говорю пока только про разработку) чисто на php - огромный гемор.
похоже, имелось ввиду, что php не обладает достаточной масштабируемостью, для больших проектов
и, черт возьми, я с этим абсолютно согласен
действительно, написать небольшой сайтец, несложный движок - на php очень быстро и удобно. подключать тяжелую артиллерию в виде с#/java смысла нету
но серьезный веб-сайт разрабатывать (я говорю пока только про разработку) чисто на php - огромный гемор.
похоже, имелось ввиду, что php не обладает достаточной масштабируемостью, для больших проектов
Именно. ООП там есть, но оно довольно странное и что самое плохое его реализация работает не слишком быстро. К тому же по умолчанию присутсвуют детские болезни в виде отсутствия нормальной поддержки уникода и абстрактного слоя работы с СУБД. В связи с чем все это реализуется каждым фреймворком по своему. Помоему уже пора завязывать изобретать велосипед :).
Именно. ООП там есть, но оно довольно странное и что самое плохое его реализация работает не слишком быстро. К тому же по умолчанию присутсвуют детские болезни в виде отсутствия нормальной поддержки уникода и абстрактного слоя работы с СУБД. В связи с чем все это реализуется каждым фреймворком по своему. Помоему уже пора завязывать изобретать велосипед :).
Писец... С каких это пор ООП стало синонимом маштабируемости?
Нет нормальной поддержки уникода? Что не замечал, хоть делаю все под UTF-8...
Абстрактный слой к СУБД? Нафига?
Мне кажется, ребята, вы там со своими патернами совсем ушли от реальной жизни... Да, я видел "красивые" реализации с использованием ООП на той же Java с десятком интерфейсов и абстрактных вызовов прежде чем дойдет до исполнения реального кода... Красиво, он долгооооо...
Я знаю что такое ООП, а Java считаю лучшим языком с которым мне приходилось иметь дело. Я проводил тесты и знаю где Java дает фору PHP, я разрабатывал распределенные нагруженные проекты на Java с мегабайтами кода, но я никогда не скажу что Java == маштабируемость, а PHP != маштабируемость.
И, если захочется дальше продолжить разговор, расскажите мне про маштабируемость, опишите что это такое и как эта задача будет реализована на Java или C#, или на любом другом языке, хоть на Фортране, хоть на Erlang, в примерах, а я вам расскажу как ее можно реализовать на PHP.
Нет нормальной поддержки уникода? Что не замечал, хоть делаю все под UTF-8...
Абстрактный слой к СУБД? Нафига?
Мне кажется, ребята, вы там со своими патернами совсем ушли от реальной жизни... Да, я видел "красивые" реализации с использованием ООП на той же Java с десятком интерфейсов и абстрактных вызовов прежде чем дойдет до исполнения реального кода... Красиво, он долгооооо...
Я знаю что такое ООП, а Java считаю лучшим языком с которым мне приходилось иметь дело. Я проводил тесты и знаю где Java дает фору PHP, я разрабатывал распределенные нагруженные проекты на Java с мегабайтами кода, но я никогда не скажу что Java == маштабируемость, а PHP != маштабируемость.
И, если захочется дальше продолжить разговор, расскажите мне про маштабируемость, опишите что это такое и как эта задача будет реализована на Java или C#, или на любом другом языке, хоть на Фортране, хоть на Erlang, в примерах, а я вам расскажу как ее можно реализовать на PHP.
Писец... С каких это пор ООП стало синонимом маштабируемости?
Ни с каких. Но сложные проекты требующие хорошей масштабируемости и модульности проще писать с использованием ООП и паттернов.
Нет нормальной поддержки уникода? Что не замечал, хоть делаю все под UTF-8...
Нету. Обещают только в 6 версии PHP.
Абстрактный слой к СУБД? Нафига?
за тем чтобы не писать три раза одно и тоже для трех разных СУБД. К примеру в любом языке обладающем такой абстракцией мне при переходе на другую СУБд достаточно померять код касающийся подключения к СУБД. Т.е. изменить драйвер и может быть параметры подключения.
Мне кажется, ребята, вы там со своими патернами совсем ушли от реальной жизни... Да, я видел "красивые" реализации с использованием ООП на той же Java с десятком интерфейсов и абстрактных вызовов прежде чем дойдет до исполнения реального кода... Красиво, он долгооооо...
За все надо платить. И еще надо взвешивать надо ли. Если приложение не сильно большое, то может и не надо. Насчет долго не скажите. Нормально оно работает. К тому же если что-то там потребуется изменить или дополнить это будет делаться левой ногой.
Я знаю что такое ООП, а Java считаю лучшим языком с которым мне приходилось иметь дело. Я проводил тесты и знаю где Java дает фору PHP
тогда объясните мне почему эта реализация PHP на java
http://caucho.com/resin-3.1/doc/quercus.…
работает быстрее mod_php в 4 раза и быстрее mod_php с акселератором APC в 2 раза ?
я разрабатывал распределенные нагруженные проекты на Java с мегабайтами кода, но я никогда не скажу что Java == маштабируемость, а PHP != маштабируемость.
Java более удобна для масштабируемых проектов чем PHP хотя бы потому, что там есть сборщик мусора, она не является интерпретируемым языком (сначала один раз производится компиляция байткода, а затем производится запуск в VM), у нее нормальное ООП, а не то кхм неподобающее хз что в PHP, у нее есть типизация типов, чего нет в PHP. У java в конце-концов есть обширный стандартный инструментарий. Да можно конечно реализовывать одинаковые по масштабируемости проекты на PHP, но в случае PHP вы огребете много проблем именно из-за ограничений и огрехов языка и вам возможно прийдется дописывать большое количество библиотек и интерфейсов.
И, если захочется дальше продолжить разговор, расскажите мне про маштабируемость, опишите что это такое и как эта задача будет реализована на Java или C#, или на любом другом языке, хоть на Фортране, хоть на Erlang, в примерах, а я вам расскажу как ее можно реализовать на PHP.
Ну давайте возьмем распределенную систему вычислений с использованием RMI и центральным сервером использующим СУБД для предоставления данных вычислительным узлам. Масштабируемость в данном контексте будет подразумевать возможность наращивания количества используемых узлов, а так же возможность наращивания мощности центрального сервера и использование новых мощностей.
PS Вы что действительно делаете какие-то серьезные проекты на PHP без использования ООП?
Ну давайте возьмем распределенную систему вычислений с использованием RMI и центральным сервером использующим СУБД для предоставления данных вычислительным узлам. Масштабируемость в данном контексте будет подразумевать возможность наращивания количества используемых узлов, а так же возможность наращивания мощности центрального сервера и использование новых мощностей.
Это постановка заначи, а где ваше решение на вашем любимом языке? Я не вижу вообще никакиех проблем реализовать его на том же PHP. И не вижу зачем там нужно ООП, RMI и т.п.
PS Вы что действительно делаете какие-то серьезные проекты на PHP без использования ООП?
Вы мне напоминаете меня лет эдак 10 назад, когда у меня тоже был подростковый максимализм и я считал что ООП всех победит и т.д. и т.п. Это пройдет. С опытом пройдет.
ЗЫ: я не хотел вас никак обидеть или задеть. Мне кажется что нам стоит прекратить это спор потому как он не имеет смысла, вы меня пока просто не понимаете, да и lexa сказал тут много того что я вам просто повторю.
ЗЫЫ: мир? :)
Это постановка заначи, а где ваше решение на вашем любимом языке?
Вам уже готовую софтину надо дать и вы ее будете реализовывать на PHP? Ну давайте тогда возьмем очень простую штуку jetty. И с чего вы взяли что мой любимый язык java? Мне не нравится конкретный язык PHP. Из того что я лично видел это самый неудачный язык.
Я не вижу вообще никакиех проблем реализовать его на том же PHP. И не вижу зачем там нужно ООП, RMI и т.п.
Что будете использовать в замен RMI? Замечу что это стандартная фича в java и ничего дополнительно реализовывать не требуется. ООП можно использовать для повышения модульности и гибкости решения. Можно использовать и процедурную парадигму, но чем больше у вас будет использоваться различных структур данных и алгоритмов их обработки тем более трудоемко ее будет использовать.
Вы мне напоминаете меня лет эдак 10 назад, когда у меня тоже был подростковый максимализм и я считал что ООП всех победит и т.д. и т.п. Это пройдет. С опытом пройдет.
Ага и использование UML пройдет и использование паттернов пройдет все пройдет. Стоит ли использовать или не использовать ООП зависит от задачи. Естественно применять ООП на простой утилитке не имеет смысла, но на проектах имеющих сложные взаимосвязи ой как имеет.
я не хотел вас никак обидеть или задеть. Мне кажется что нам стоит прекратить это спор потому как он не имеет смысла, вы меня пока просто не понимаете.
Что-то вы опустили тут всю мою писанину относительно чем лучше java PHP. Видимо аргументов против этого нет? Но зато сказать, что вообще я ничего не понимаю в том числе что великий гуру пришел и начал мне увещевать какой PHP хороший язык и что на нем можно писать аналогичные проекты что и на java. Да конечно можно, но какова целесообразность этой затеи?
да и lexa сказал тут много того что я вам просто повторю.
Извините, но lexa четко аргументировал свою позицию и обходился без "я тут вот кодил", хотя кодил он больше вас.
мир? :)
Маленькая просьба если вы уж влезли, то аргументируйте свою позицию, а "не да я!".
Со стороны это выглядит не сильно призентабельно.
Вам уже готовую софтину надо дать и вы ее будете реализовывать на PHP? Ну давайте тогда возьмем очень простую штуку jetty. И с чего вы взяли что мой любимый язык java? Мне не нравится конкретный язык PHP. Из того что я лично видел это самый неудачный язык.
Где я сказал что ваш любимый язык java? Я написал что вы можете представить решение любом любимом вами языке.
Что будете использовать в замен RMI? Замечу что это стандартная фича в java и ничего дополнительно реализовывать не требуется. ООП можно использовать для повышения модульности и гибкости решения. Можно использовать и процедурную парадигму, но чем больше у вас будет использоваться различных структур данных и алгоритмов их обработки тем более трудоемко ее будет использовать.
Для этой задачи я бы ничего особенного не использовал. Просто apache (nginx,...), PHP (mod_php, FastCGI,...), mysql (mssql, oracle, text files,...). Простой вызов с сервера по HTTP для раздачи заданий и получение решения ввиде ответов. Зачем мне тут RMI?
Что-то вы опустили тут всю мою писанину относительно чем лучше java PHP. Видимо аргументов против этого нет? Но зато сказать, что вообще я ничего не понимаю в том числе что великий гуру пришел и начал мне увещевать какой PHP хороший язык и что на нем можно писать аналогичные проекты что и на java. Да конечно можно, но какова целесообразность этой затеи?
Вы бы не передергивали, я себе великим гуру не считаю, есть люди гораздо грамотнее. И я никого не призывал переходить с java на php или отказаться от использования ООП, патернов или UML. Я говорил о том что маштабируемость и ООП не связаны, что можно написать маштабируемое высоконагруженное приложения и на php, а вы мне постоянно про UML, ООП, патерны и т.п. Я вам не запрещаю их использовать, используйте, но только не надо утверждать что для написания больших проектов жизненно необходимо все это.
Извините, но lexa четко аргументировал свою позицию и обходился без "я тут вот кодил", хотя кодил он больше вас.
Вы со свечкой стояли? Вы знаете сколько и на чем я кодил? Я писал что я кодил на Java, использовал и использую ООП, UML и т.п. для того, чтобы вы не подумали что я php-фанатик, что я знаю о чем я говорю.
Где я сказал что ваш любимый язык java? Я написал что вы можете представить решение любом любимом вами языке.
Там же где я сказал что ООП синоним масштабируемости.
Для этой задачи я бы ничего особенного не использовал. Просто apache (nginx,...), PHP (mod_php, FastCGI,...), mysql (mssql, oracle, text files,...). Простой вызов с сервера по HTTP для раздачи заданий и получение решения ввиде ответов. Зачем мне тут RMI?
А зачем городить дополнительно вебсервер?
Вы бы не передергивали, я себе великим гуру не считаю, есть люди гораздо грамотнее.
Тоже самое могу сказать и вам.
И я никого не призывал переходить с java на php или отказаться от использования ООП, патернов или UML. Я говорил о том что маштабируемость и ООП не связаны, что можно написать маштабируемое высоконагруженное приложения и на php, а вы мне постоянно про UML, ООП, патерны и т.п.
Написать конечно можно. Только вот целесообразность этого какова? На Prolog тоже можно писать интефрейс пользователя только это не слишком эффективно. И говорю я про то, что PHP менее эффективно для написания масштабируемых и нагруженных приложений чем java.
Я вам не запрещаю их использовать, используйте, но только не надо утверждать что для написания больших проектов жизненно необходимо все это.
вам никто не запрещает не использовать UML и ООП. Только если у вас большой проект не будет ли более эффективно их использовать?
Вы со свечкой стояли?
Могу задать точно такой же вопрос.
Вы знаете сколько и на чем я кодил? Я писал что я кодил на Java, использовал и использую ООП, UML и т.п. для того, чтобы вы не подумали что я php-фанатик, что я знаю о чем я говорю.
И я тоже знаю о чем говорю и говорю про то что предпочтительнее использовать с моей точки зрения. С моей точки зрения для больших проектов использовать java или python или C/C++ или perl хотя бы (хотя перл тоже не всегда), но не как не PHP.
PS У каждого свое понимание как надо.
похоже, имелось ввиду, что php не обладает достаточной масштабируемостью, для больших проектов и, черт возьми, я с этим абсолютно согласен
А я - не согласен. Т.е. я на PHP ничего никогда не делал, но вижу "на нем" большие проекты (Бегун, Мамба - как примеры).
PHP - это такой язык программирования + небольшой фреймворк. Немного странный, кривой и косой, ну а что прямое ?
Большие же проекты бывают двух видов
а) дофига кода т.к. сложная функциональность
б) дофига обращений и при этом дофига данных
(может быть оба сразу)
И это все - не проблема выбора языка программирования. Программировать вообще пофигу на чем (я вот обратно полюбил фортран после 20-летнего перерыва) и если кода много, то проблемы его организации примерно одинаковы во всех процедурных языках позволяющих использовать локальные переменные.
А при большой нагрузке/больших данных - это все проблема аккуратного проектирования БД, создания множества серверов БД (например, популярное сейчас single writer/multiple readers), кэширования нужных данных в памяти и т.п. Ну вот вы никак не отдадите 200 запросов в секунду из БД, какая бы она не была. И совершенно пофигу на каком языке их отдавать из памяти.
У PHP есть одно огромное достоинство и один небольшой недостаток и на них и следует ориентироваться
а) "специалистов" по PHP много. Они, конечно, преимущественно в кавычках, но есть из кого выбрать, чтобы затем учить
б) в проекте кроме вебовской функциональности обычно есть и другая обвязка (command-line). Делать ее на PHP глупо, что автоматически заводит в проекте еще один язык.
А я - не согласен. Т.е. я на PHP ничего никогда не делал, но вижу "на нем" большие проекты (Бегун, Мамба - как примеры).
PHP - это такой язык программирования + небольшой фреймворк. Немного странный, кривой и косой, ну а что прямое ?
Большие же проекты бывают двух видов
а) дофига кода т.к. сложная функциональность
б) дофига обращений и при этом дофига данных
(может быть оба сразу)
И это все - не проблема выбора языка программирования. Программировать вообще пофигу на чем (я вот обратно полюбил фортран после 20-летнего перерыва) и если кода много, то проблемы его организации примерно одинаковы во всех процедурных языках позволяющих использовать локальные переменные.
А при большой нагрузке/больших данных - это все проблема аккуратного проектирования БД, создания множества серверов БД (например, популярное сейчас single writer/multiple readers), кэширования нужных данных в памяти и т.п. Ну вот вы никак не отдадите 200 запросов в секунду из БД, какая бы она не была. И совершенно пофигу на каком языке их отдавать из памяти.
У PHP есть одно огромное достоинство и один небольшой недостаток и на них и следует ориентироваться
а) "специалистов" по PHP много. Они, конечно, преимущественно в кавычках, но есть из кого выбрать, чтобы затем учить
б) в проекте кроме вебовской функциональности обычно есть и другая обвязка (command-line). Делать ее на PHP глупо, что автоматически заводит в проекте еще один язык.
А я - не согласен. Т.е. я на PHP ничего никогда не делал, но вижу "на нем" большие проекты (Бегун, Мамба - как примеры).
А кто вам сказал что там действительно большой объем PHP кода и он сложный?
PHP - это такой язык программирования + небольшой фреймворк. Немного странный, кривой и косой, ну а что прямое ?
Что прямое? .NET, Java, Django (Python). Можно еще много чего наперечислять, что прямее PHP. К тому же вдумайтесь PHP задумывался как язык программирования именно динамических страниц в вебе. Тогда почему для того чтобы на нем что-то нормально писать требуется дополнительный фреймоворк?
Большие же проекты бывают двух видов
а) дофига кода т.к. сложная функциональность
б) дофига обращений и при этом дофига данных
(может быть оба сразу)
a) не подходит в силу убогой реализации ООП.
б) не подходит т.к. плохо масштабируется и для масштабирования будут требоваться сторонние средства.
И это все - не проблема выбора языка программирования.
в любом случае при разработке мы набрасываем хоть какое-то тех. задание и уже на базе его выбираем средства. И выбирать для чего-то сложного и нагруженного все не рекомендуется.
и если кода много, то проблемы его организации примерно одинаковы во всех процедурных языках позволяющих использовать локальные переменные.
Использование UML и паттернов при проектировании и ООП на стадии реализации спасет отца русской демократии :)
А при большой нагрузке/больших данных - это все проблема аккуратного проектирования БД, создания множества серверов БД (например, популярное сейчас single writer/multiple readers), кэширования нужных данных в памяти и т.п. Ну вот вы никак не отдадите 200 запросов в секунду из БД, какая бы она не была.
200 запросов в секунду при какой загрузке?
И совершенно пофигу на каком языке их отдавать из памяти.
Зато совершенно не пофигу как осуществляется взаимодействие с СУБД и какие средства предоставляет язык для упрощения этих операций.
У PHP есть одно огромное достоинство и один небольшой недостаток и на них и следует ориентироваться
а) "специалистов" по PHP много. Они, конечно, преимущественно в кавычках, но есть из кого выбрать, чтобы затем учить
Учить должны технологиям и в университетах. :) Как вы сами говорили глубоко пофиг на каком языке писать. А обучить человека языку, который не владеет языком, но владеет технологиями гараздо проще чем человека который "владеет" языком но не владеет технологиями ;)
б) в проекте кроме вебовской функциональности обычно есть и другая обвязка (command-line). Делать ее на PHP глупо, что автоматически заводит в проекте еще один язык.
Эээ накой ?
А кто вам сказал что там действительно большой объем PHP кода и он сложный?
PHP - это такой язык программирования + небольшой фреймворк. Немного странный, кривой и косой, ну а что прямое ?
Что прямое? .NET, Java, Django (Python). Можно еще много чего наперечислять, что прямее PHP. К тому же вдумайтесь PHP задумывался как язык программирования именно динамических страниц в вебе. Тогда почему для того чтобы на нем что-то нормально писать требуется дополнительный фреймоворк?
Большие же проекты бывают двух видов
а) дофига кода т.к. сложная функциональность
б) дофига обращений и при этом дофига данных
(может быть оба сразу)
a) не подходит в силу убогой реализации ООП.
б) не подходит т.к. плохо масштабируется и для масштабирования будут требоваться сторонние средства.
И это все - не проблема выбора языка программирования.
в любом случае при разработке мы набрасываем хоть какое-то тех. задание и уже на базе его выбираем средства. И выбирать для чего-то сложного и нагруженного все не рекомендуется.
и если кода много, то проблемы его организации примерно одинаковы во всех процедурных языках позволяющих использовать локальные переменные.
Использование UML и паттернов при проектировании и ООП на стадии реализации спасет отца русской демократии :)
А при большой нагрузке/больших данных - это все проблема аккуратного проектирования БД, создания множества серверов БД (например, популярное сейчас single writer/multiple readers), кэширования нужных данных в памяти и т.п. Ну вот вы никак не отдадите 200 запросов в секунду из БД, какая бы она не была.
200 запросов в секунду при какой загрузке?
И совершенно пофигу на каком языке их отдавать из памяти.
Зато совершенно не пофигу как осуществляется взаимодействие с СУБД и какие средства предоставляет язык для упрощения этих операций.
У PHP есть одно огромное достоинство и один небольшой недостаток и на них и следует ориентироваться
а) "специалистов" по PHP много. Они, конечно, преимущественно в кавычках, но есть из кого выбрать, чтобы затем учить
Учить должны технологиям и в университетах. :) Как вы сами говорили глубоко пофиг на каком языке писать. А обучить человека языку, который не владеет языком, но владеет технологиями гараздо проще чем человека который "владеет" языком но не владеет технологиями ;)
б) в проекте кроме вебовской функциональности обычно есть и другая обвязка (command-line). Делать ее на PHP глупо, что автоматически заводит в проекте еще один язык.
Эээ накой ?
Я вот отвечу только на несколько, там где можно кратко, нет сил растекаться мыслею
не подходит в силу убогой реализации ООП.
ООП - вообще не догма. Нету никакой необходимости в ООП.
Использование UML и паттернов при проектировании и ООП на стадии реализации спасет отца русской демократии
Наивная вера в UML и паттерны выдает теоретика. Есть еще много страшных слов: CORBA, RMI, EJB. К реальной жизни крупного веб-проекта они относятся очень слабо.
200 запросов в секунду при какой загрузке?
Вопрос теоретика. Значение имеет размер данных, я действительно забыл указать. 200 запросов по HTTP из базы данных, индексы которой не влезают в RAM.
Зато совершенно не пофигу как осуществляется взаимодействие с СУБД и какие средства предоставляет язык для упрощения этих операций.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху. Какую хотите, хоть объектную, хоть еще какую. Будете миллион-первым.
Понимаете, все вот эти пляски вокруг выбора языка - они происходят в предположении, что собственно кодирование занимает какое-то значимое время. А это совсем не так, основное время уходит на пере-проектирование и тестирование (даже не на отладку). В вебе же всегда moving target. А сколько у вас уйдет на кодирование - 10% времени или 20 - нет никакой разницы.
А вот рисование стрелочек в начале проекта и наложение на них визиторов, синглетонов и прочих функторов приведет затем к крайне интересному эффекту, когда выяснится, что иерархия объектов на самом деле совсем другая.
не подходит в силу убогой реализации ООП.
ООП - вообще не догма. Нету никакой необходимости в ООП.
Использование UML и паттернов при проектировании и ООП на стадии реализации спасет отца русской демократии
Наивная вера в UML и паттерны выдает теоретика. Есть еще много страшных слов: CORBA, RMI, EJB. К реальной жизни крупного веб-проекта они относятся очень слабо.
200 запросов в секунду при какой загрузке?
Вопрос теоретика. Значение имеет размер данных, я действительно забыл указать. 200 запросов по HTTP из базы данных, индексы которой не влезают в RAM.
Зато совершенно не пофигу как осуществляется взаимодействие с СУБД и какие средства предоставляет язык для упрощения этих операций.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху. Какую хотите, хоть объектную, хоть еще какую. Будете миллион-первым.
Понимаете, все вот эти пляски вокруг выбора языка - они происходят в предположении, что собственно кодирование занимает какое-то значимое время. А это совсем не так, основное время уходит на пере-проектирование и тестирование (даже не на отладку). В вебе же всегда moving target. А сколько у вас уйдет на кодирование - 10% времени или 20 - нет никакой разницы.
А вот рисование стрелочек в начале проекта и наложение на них визиторов, синглетонов и прочих функторов приведет затем к крайне интересному эффекту, когда выяснится, что иерархия объектов на самом деле совсем другая.
ООП - вообще не догма. Нету никакой необходимости в ООП.
Есть необходимость, урощает понимание кода. Как раз в больших проектах.
Или не программируете или не понимаете парадигму ООП. Извините что так грубо говорю.
А вы конец последнего абзаца читали ? :)
Ну зачем же обижать. Уже 22 года программирую, со школы. Вот в школе и научили, что алгоритмы + структуры данных = программы. Но вот нужность объединения алгоритмов и структур данных в одно целое для меня под вопросом.
ООП - прекрасная штука, если иерархия объектов и их функциональность - очевидны. Да и то.
Вот представим себе объекты, которые идеально подходят под парадигму ООП - линейная алгебра, скаляры, векторы и матрицы. Вектор - это набор скаляров, матрица - вектор векторов, правильно ? Все операции тоже прекрасно определены, можем писать D = A*B + C*scalar, правильно ?
И такие штуки были очень модными лет 15 назад, когда появился C++. А потом мода сошла и все вернулись к основам: CALL DGEMM(....)
А знаете почему ? Потому что если вы все инкапсулируете и элемент результата будете представлять как скалярное произведение двух векторов, то работать все будет. И код будет понимаемым. Только вот скорость будет на пару порядков меньше, чем при использовании знаний об реальной внутренней организации данных , архитектуре процессора, его кэшах и все такое прочее.
А это абсолютно тривиальный пример, прекрасно ложащийся на ООП.
ООП - прекрасная штука, если иерархия объектов и их функциональность - очевидны. Да и то.
Вот представим себе объекты, которые идеально подходят под парадигму ООП - линейная алгебра, скаляры, векторы и матрицы. Вектор - это набор скаляров, матрица - вектор векторов, правильно ? Все операции тоже прекрасно определены, можем писать D = A*B + C*scalar, правильно ?
И такие штуки были очень модными лет 15 назад, когда появился C++. А потом мода сошла и все вернулись к основам: CALL DGEMM(....)
А знаете почему ? Потому что если вы все инкапсулируете и элемент результата будете представлять как скалярное произведение двух векторов, то работать все будет. И код будет понимаемым. Только вот скорость будет на пару порядков меньше, чем при использовании знаний об реальной внутренней организации данных , архитектуре процессора, его кэшах и все такое прочее.
А это абсолютно тривиальный пример, прекрасно ложащийся на ООП.
Ну зачем же обижать. Уже 22 года программирую, со школы…
Прошу прощения.
norguhtar тоже дал мне понять где ошибаюсь.Сентиментально среагировал. :(
Использовать ООП в численных методах право не стоит :) Как и в линейной алгебре. Поскольку это действительно не даст прироста производительности и само по себе взаимодействие объектов достаточно простое. А использовать или не использовать ООП надо решать до написания кода.
Прекрасно. Значит договорились, что для объектов с очевидной иерархией ООП не нужно.
Неужели с неочевидной будет лучше ?
ООП переносит фокус на проектирование и это прекрасно. Но если потом потребовалась смена функциональности, то чем крепче была иерархия объектов, тем больше она нас поимеет.
Неужели с неочевидной будет лучше ?
ООП переносит фокус на проектирование и это прекрасно. Но если потом потребовалась смена функциональности, то чем крепче была иерархия объектов, тем больше она нас поимеет.
Что же упрощает поддержку кода и рефакторинг, если не ООП?
ООП - в том виде, в каком я его регулярно встречаю - ужасно затрудняет рефакторинг.
И чем хардкорнее был ОО в исходной программе, тем хуже.
И чем хардкорнее был ОО в исходной программе, тем хуже.
Может мы говорим о разных видах проектов.
По моему опыту коммерческий проект (заказная разработка), без четких уровней и без классов внутри уровней, очень сложно и, в итоге, дорого поддержить. А еще если и разработчики меняются...
В общем абстрактное обсуждение скатывается в обсуждение парадигм программирования.
И скоро у меня окно ответа станет шириной в 50 пикселей.
По моему опыту коммерческий проект (заказная разработка), без четких уровней и без классов внутри уровней, очень сложно и, в итоге, дорого поддержить. А еще если и разработчики меняются...
В общем абстрактное обсуждение скатывается в обсуждение парадигм программирования.
И скоро у меня окно ответа станет шириной в 50 пикселей.
P.S. И приятно повысить карму человеку, который уже делал русский Апач, когда я еще разбирался, как Интернет работает )
Прекрасно. Значит договорились, что для объектов с очевидной иерархией ООП не нужно.
Неужели с неочевидной будет лучше?
Когда количество объектов системы с очевидной иерархией перевалит где-то за 10-20 и они будут иметь достаточно сложные связи между собой... то стоит подумать о ООП. Хотя это будет уже ближе к неочевидной.
ООП переносит фокус на проектирование и это прекрасно. Но если потом потребовалась смена функциональности, то чем крепче была иерархия объектов, тем больше она нас поимеет.
А вот для того чтобы она нас не поимела надо использовать паттерны, паттерны, и еще раз паттерны! :)
Неужели с неочевидной будет лучше?
Когда количество объектов системы с очевидной иерархией перевалит где-то за 10-20 и они будут иметь достаточно сложные связи между собой... то стоит подумать о ООП. Хотя это будет уже ближе к неочевидной.
ООП переносит фокус на проектирование и это прекрасно. Но если потом потребовалась смена функциональности, то чем крепче была иерархия объектов, тем больше она нас поимеет.
А вот для того чтобы она нас не поимела надо использовать паттерны, паттерны, и еще раз паттерны! :)
ООП - вообще не догма. Нету никакой необходимости в ООП.
Процедурное программирование рулит? :) В ООП необходимость есть особенно в сложных проектах. Так как является удобной степенью абстракции. Да и в простых оно может быть полезно т.к. положительно сказывается на их архитектуре и дальнейшем повторном использовании кода.
Наивная вера в UML и паттерны выдает теоретика.
Конечно зачем ими пользоваться и вообще проектировать? Зачем? давайте лучше писать сразу код. Ну не получится не велика беда переделаем. Да этот подход неплохо работает на небольших проектах, которые целиком укладываются в голове. Как только они перестают укладываться тут то все вспоминают про UML и паттерны.
Есть еще много страшных слов: CORBA, RMI, EJB. К реальной жизни крупного веб-проекта они
относятся очень слабо.
Первые два вообще не имеют никакого отношения к вебу. Второй имеет, но используется в сложных и масштабных проектах.
Вопрос теоретика. Значение имеет размер данных, я действительно забыл указать. 200 запросов по HTTP из базы данных, индексы которой не влезают в RAM.
Если не влезают в RAM, то с этим надо что-то делать. Решение в лоб это нарастить память чтоб влезало или же делать прекешинг того что наиболее часто используется.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху.
А зачем?
Понимаете, все вот эти пляски вокруг выбора языка - они происходят в предположении, что собственно кодирование занимает какое-то значимое время. А это совсем не так, основное время уходит на пере-проектирование и тестирование (даже не на отладку).
Основное время уходит на проектирование и тестирование вы это верно заметили, но вы еще забыли, что перед этим желательно выбрать инструментарий с учетом того что указано в техническом задании. Если вы выберете плохой инструментарий время кодирования увеличится.
А вот рисование стрелочек в начале проекта и наложение на них визиторов, синглетонов и прочих функторов приведет затем к крайне интересному эффекту, когда выяснится, что иерархия объектов на самом деле совсем другая.
Извините это не вы говорили в самом начале что ООП не догма? :)
Процедурное программирование рулит? :) В ООП необходимость есть особенно в сложных проектах. Так как является удобной степенью абстракции. Да и в простых оно может быть полезно т.к. положительно сказывается на их архитектуре и дальнейшем повторном использовании кода.
Наивная вера в UML и паттерны выдает теоретика.
Конечно зачем ими пользоваться и вообще проектировать? Зачем? давайте лучше писать сразу код. Ну не получится не велика беда переделаем. Да этот подход неплохо работает на небольших проектах, которые целиком укладываются в голове. Как только они перестают укладываться тут то все вспоминают про UML и паттерны.
Есть еще много страшных слов: CORBA, RMI, EJB. К реальной жизни крупного веб-проекта они
относятся очень слабо.
Первые два вообще не имеют никакого отношения к вебу. Второй имеет, но используется в сложных и масштабных проектах.
Вопрос теоретика. Значение имеет размер данных, я действительно забыл указать. 200 запросов по HTTP из базы данных, индексы которой не влезают в RAM.
Если не влезают в RAM, то с этим надо что-то делать. Решение в лоб это нарастить память чтоб влезало или же делать прекешинг того что наиболее часто используется.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху.
А зачем?
Понимаете, все вот эти пляски вокруг выбора языка - они происходят в предположении, что собственно кодирование занимает какое-то значимое время. А это совсем не так, основное время уходит на пере-проектирование и тестирование (даже не на отладку).
Основное время уходит на проектирование и тестирование вы это верно заметили, но вы еще забыли, что перед этим желательно выбрать инструментарий с учетом того что указано в техническом задании. Если вы выберете плохой инструментарий время кодирования увеличится.
А вот рисование стрелочек в начале проекта и наложение на них визиторов, синглетонов и прочих функторов приведет затем к крайне интересному эффекту, когда выяснится, что иерархия объектов на самом деле совсем другая.
Извините это не вы говорили в самом начале что ООП не догма? :)
Основное время уходит на проектирование и тестирование
У вас прямо идеальные проекты :)
В моём опыте все проекты - быстрое выяснение потребностей и быстрое начальное проектирование, потом длительная фаза итерационной разработки, потом сравнительное коротенькое финальное тестирование и запуск.
Так выполняются все заказные разработки для "среднего бизнеса".
И тут .NET идеально подходит, как и Java.
Так называемая водопадная модель. В случае небольших проектов в которых первоначальные требования понятны допустима. Кстати большая часть не сложного ПО с открытыми исходниками используют аналогичную модель. К тому же накопленный на текущий момент инструментарий позволяет собирать проекты из крипичков программируя только логику работы ПО.
Опять только на куски, чтобы не растекаться. Детей пора гулять.
Процедурное программирование рулит? :) В ООП необходимость есть особенно в сложных проектах
ООП - это очень хорошо, пока target не переместилась и не выяснилось, что наша иерархия объектов перестала отражать предметную область.
За последние 16 лет я такое наблюдал регулярно.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху.
А зачем?
А если не нравится ? Это же один эпизод среди человеко-годов в проекте.
Если не влезают в RAM, то с этим надо что-то делать. Решение в лоб это нарастить память чтоб влезало или же делать прекешинг того что наиболее часто используется.
Ну а я о чем говорю ? Ровно о том, что из памяти отдать даже несколько тысяч запросов/сек с одного тазика - не бог весть какая задача. А из базы, точнее с диска, при реальной latency миллисекунд в 20 - ничего не выйдет.
Извините это не вы говорили в самом начале что ООП не догма? :)
То, что я не считаю ООП догмой не означает, что я незнаком с инструментарием.
Процедурное программирование рулит? :) В ООП необходимость есть особенно в сложных проектах
ООП - это очень хорошо, пока target не переместилась и не выяснилось, что наша иерархия объектов перестала отражать предметную область.
За последние 16 лет я такое наблюдал регулярно.
Вот это, как раз, абсолютно пофигу. Не нравятся средства языка - ну напишите один раз нашлепку сверху.
А зачем?
А если не нравится ? Это же один эпизод среди человеко-годов в проекте.
Если не влезают в RAM, то с этим надо что-то делать. Решение в лоб это нарастить память чтоб влезало или же делать прекешинг того что наиболее часто используется.
Ну а я о чем говорю ? Ровно о том, что из памяти отдать даже несколько тысяч запросов/сек с одного тазика - не бог весть какая задача. А из базы, точнее с диска, при реальной latency миллисекунд в 20 - ничего не выйдет.
Извините это не вы говорили в самом начале что ООП не догма? :)
То, что я не считаю ООП догмой не означает, что я незнаком с инструментарием.
ООП - это очень хорошо, пока target не переместилась и не выяснилось, что наша иерархия объектов перестала отражать предметную область.
За последние 16 лет я такое наблюдал регулярно.
А какая парадигма программирования от этого спасет? Если учитывать, что если меняется иерархия объектов то меняется и логика из работы и взаимодействия.
А если не нравится ? Это же один эпизод среди человеко-годов в проекте.
Предварительно надо подумать нужна ли вообще такая абстракция или лучше выбрать другой уровень абстракции.
А из базы, точнее с диска, при реальной latency миллисекунд в 20 - ничего не выйдет.
В случае если у вас не помещаются индексы в памяти или даже есть но выборка достаточно большая то конечно.
То, что я не считаю ООП догмой не означает, что я незнаком с инструментарием.
В таком случае какой парадигмы программирования придерживаетесь?
За последние 16 лет я такое наблюдал регулярно.
А какая парадигма программирования от этого спасет? Если учитывать, что если меняется иерархия объектов то меняется и логика из работы и взаимодействия.
А если не нравится ? Это же один эпизод среди человеко-годов в проекте.
Предварительно надо подумать нужна ли вообще такая абстракция или лучше выбрать другой уровень абстракции.
А из базы, точнее с диска, при реальной latency миллисекунд в 20 - ничего не выйдет.
В случае если у вас не помещаются индексы в памяти или даже есть но выборка достаточно большая то конечно.
То, что я не считаю ООП догмой не означает, что я незнаком с инструментарием.
В таком случае какой парадигмы программирования придерживаетесь?
А какая парадигма программирования от этого спасет? Если учитывать, что если меняется иерархия объектов то меняется и логика из работы и взаимодействия.
На самом деле, loose-иерархия объектов, причем желательно без ограничения прав доступа - это очень хорошо. Я за последние лет 5 несколько раз занимался расширением функциональности ООП-программ. И это было мучительно, обычно приходится протаскивать какие-то дополнительные параметры/данные/whatever на очень низкий уровень иерархии, а потом столь же мучительно выносить результаты назад.
А если бы алгоритмы были бы отделены от данных - ничего этого бы не было.
Любая парадигма/техника ценна не сама по себе, а только когда не мешает. Если мешает - на помойку.
Предварительно надо подумать нужна ли вообще такая абстракция или лучше выбрать другой уровень абстракции
Так если не нравится - значит надо чинить.
В таком случае какой парадигмы программирования придерживаетесь?
Думать надо верхней жопой. Вот и вся парадигма.
На самом деле, loose-иерархия объектов, причем желательно без ограничения прав доступа - это очень хорошо. Я за последние лет 5 несколько раз занимался расширением функциональности ООП-программ. И это было мучительно, обычно приходится протаскивать какие-то дополнительные параметры/данные/whatever на очень низкий уровень иерархии, а потом столь же мучительно выносить результаты назад.
А если бы алгоритмы были бы отделены от данных - ничего этого бы не было.
Любая парадигма/техника ценна не сама по себе, а только когда не мешает. Если мешает - на помойку.
Предварительно надо подумать нужна ли вообще такая абстракция или лучше выбрать другой уровень абстракции
Так если не нравится - значит надо чинить.
В таком случае какой парадигмы программирования придерживаетесь?
Думать надо верхней жопой. Вот и вся парадигма.
На самом деле, loose-иерархия объектов, причем желательно без ограничения прав доступа - это очень хорошо. Я за последние лет 5 несколько раз занимался расширением функциональности ООП-программ.И это было мучительно, обычно приходится протаскивать какие-то дополнительные параметры/данные/whatever на очень низкий уровень иерархии, а потом столь же мучительно выносить результаты назад.
Это плата за гибкость. Зато это позволяет вносить изменения в одном месте не затрагивая прочие.
А если бы алгоритмы были бы отделены от данных - ничего этого бы не было.
Алгоритмы зависят от данных, так что если мы изменяем их (я про формат) то приходится изменять и алгоритмы.
Любая парадигма/техника ценна не сама по себе, а только когда не мешает. Если мешает - на помойку.
И эта штука выбирается под конкретный проект.
Думать надо верхней жопой. Вот и вся парадигма.
В цитатник надо :)
Это плата за гибкость. Зато это позволяет вносить изменения в одном месте не затрагивая прочие.
А если бы алгоритмы были бы отделены от данных - ничего этого бы не было.
Алгоритмы зависят от данных, так что если мы изменяем их (я про формат) то приходится изменять и алгоритмы.
Любая парадигма/техника ценна не сама по себе, а только когда не мешает. Если мешает - на помойку.
И эта штука выбирается под конкретный проект.
Думать надо верхней жопой. Вот и вся парадигма.
В цитатник надо :)
Что вы понимаете под большими проектами и сложными сайтами?
FastCGI реализует более разумную модель
приложения, чем mod_php. Без лишних копий. В-принципе, если (бы) иметь на входе другой разумный сериализатор, то можно было (бы) иметь и mod_php backend.
FastCGI естественно реализует лучшую модель чем mod_php. Но по умолчанию пользователю предлагается именно mod_php.
А, извините, memcached реализует то, что в любом случае придется реализовывать руками - кэширование в памяти тех данных, которые там нужны.
Почитайте про ORM :) Технологий автоматизации таких вещей существует большое множество. Начиная от упомянутого ORM заканчивая сереализацией и пулами подключений.
Нагруженные проекты сами по себе большой геморой
Это естественно, но выбор средств которые сами по себе для этого не преднозначены этот гемморой увеличивают.
приложения, чем mod_php. Без лишних копий. В-принципе, если (бы) иметь на входе другой разумный сериализатор, то можно было (бы) иметь и mod_php backend.
FastCGI естественно реализует лучшую модель чем mod_php. Но по умолчанию пользователю предлагается именно mod_php.
А, извините, memcached реализует то, что в любом случае придется реализовывать руками - кэширование в памяти тех данных, которые там нужны.
Почитайте про ORM :) Технологий автоматизации таких вещей существует большое множество. Начиная от упомянутого ORM заканчивая сереализацией и пулами подключений.
Нагруженные проекты сами по себе большой геморой
Это естественно, но выбор средств которые сами по себе для этого не преднозначены этот гемморой увеличивают.
FastCGI естественно реализует лучшую модель чем mod_php. Но по умолчанию пользователю предлагается именно mod_php
А для странички на виртуальном хостинге этого достаточно. А если мы все еще про большие проекты, то у них есть разработчики снабженные умом.
Почитайте про ORM
Ну почитал. А толку то ? Вот простая задача: 5 заголовков новостей на морде Яндекса. Есть разумное решение: пушить эти 5 заголовков в кэши в памяти на фронтендах. Пушить будет, естественно, модуль который эти top5 рассчитывает. Проактивное, так сказать, кэширование.
Все остальные решения - неразумные.
А для странички на виртуальном хостинге этого достаточно. А если мы все еще про большие проекты, то у них есть разработчики снабженные умом.
Почитайте про ORM
Ну почитал. А толку то ? Вот простая задача: 5 заголовков новостей на морде Яндекса. Есть разумное решение: пушить эти 5 заголовков в кэши в памяти на фронтендах. Пушить будет, естественно, модуль который эти top5 рассчитывает. Проактивное, так сказать, кэширование.
Все остальные решения - неразумные.
А для странички на виртуальном хостинге этого достаточно. А если мы все еще про большие проекты, то у них есть разработчики снабженные умом.
Угу только вот в Java и в вроде .NET это уже реализовано на уровне сервера по умолчанию.
Ну почитал. А толку то ? Вот простая задача: 5 заголовков новостей на морде Яндекса. Есть разумное решение: пушить эти 5 заголовков в кэши в памяти на фронтендах. Пушить будет, естественно, модуль который эти top5 рассчитывает. Проактивное, так сказать, кэширование.
Чем вам ORM не ку? Так же кешит.
Угу только вот в Java и в вроде .NET это уже реализовано на уровне сервера по умолчанию.
Ну почитал. А толку то ? Вот простая задача: 5 заголовков новостей на морде Яндекса. Есть разумное решение: пушить эти 5 заголовков в кэши в памяти на фронтендах. Пушить будет, естественно, модуль который эти top5 рассчитывает. Проактивное, так сказать, кэширование.
Чем вам ORM не ку? Так же кешит.
Угу только вот в Java и в вроде .NET это уже реализовано на уровне сервера по умолчанию.
Что это ? Снабжение разработчика умом ?
Сейчас Java(EJB)/Net в той же позиции, что и несколько лет VB - быстрое написание каких-то вебовских приложений.
А когда вам нужно не "какое-то", а единственное уникальное и посидеть недельку подумать - это экономия пары десятков серверов или $100k - язык уже имеет минимальное значение.
Чем вам ORM не ку? Так же кешит.
"Автоматически" ? Или на чтении ? Кэширование на чтении на крупных проектах не подходит. А автоматическое proactive-кэширование требует телепатии от средств разработки, пока нету.
Что это ? Снабжение разработчика умом ?
Сейчас Java(EJB)/Net в той же позиции, что и несколько лет VB - быстрое написание каких-то вебовских приложений.
А когда вам нужно не "какое-то", а единственное уникальное и посидеть недельку подумать - это экономия пары десятков серверов или $100k - язык уже имеет минимальное значение.
Чем вам ORM не ку? Так же кешит.
"Автоматически" ? Или на чтении ? Кэширование на чтении на крупных проектах не подходит. А автоматическое proactive-кэширование требует телепатии от средств разработки, пока нету.
Сейчас Java(EJB)/Net в той же позиции, что и несколько лет VB - быстрое написание каких-то вебовских приложений.
ну зачем так-то обижать. Java(EJB)/.Net - это программные платформы промешленного уровня, изначальное объектные, со сборщиками мусора и прочими удобными прибамбасами.
И позволяют они действительно быстро разрабатывать качественные приложения.
Яндекс - это не промышленная разработка. Это долгое творчество гениальных людей :)
И если говорить об обычных средних проектах, то никаких цифр в $100K и десятков серверов там и рядом нет.
Что это ? Снабжение разработчика умом ?
Аналог FastCGI. И вся технология jsp/servlets построена вокруг ее и учитывает ее особенности.
Сейчас Java(EJB)/Net в той же позиции, что и несколько лет VB - быстрое написание каких-то вебовских приложений.
Вы забыли одно слово промышленных веб приложений.
А когда вам нужно не "какое-то", а единственное уникальное и посидеть недельку подумать - это экономия пары десятков серверов или $100k - язык уже имеет минимальное значение.
Проектирование не зависит от самого языка. Но важно имеет ли выбранная программная платформа необходимый инструментарий или прийдется что-то дописывать для себя. Java не панацея от плохого проектирования, но в ней инструментарий значительно лучше чем в PHP.
"Автоматически" ? Или на чтении ? Кэширование на чтении на крупных проектах не подходит.
А вот это как настроите.
А автоматическое proactive-кэширование требует телепатии от средств разработки
ORM - вещь настраиваемая и ее надо использовать с умом, а не воткнули и стали работать.
Аналог FastCGI. И вся технология jsp/servlets построена вокруг ее и учитывает ее особенности.
Сейчас Java(EJB)/Net в той же позиции, что и несколько лет VB - быстрое написание каких-то вебовских приложений.
Вы забыли одно слово промышленных веб приложений.
А когда вам нужно не "какое-то", а единственное уникальное и посидеть недельку подумать - это экономия пары десятков серверов или $100k - язык уже имеет минимальное значение.
Проектирование не зависит от самого языка. Но важно имеет ли выбранная программная платформа необходимый инструментарий или прийдется что-то дописывать для себя. Java не панацея от плохого проектирования, но в ней инструментарий значительно лучше чем в PHP.
"Автоматически" ? Или на чтении ? Кэширование на чтении на крупных проектах не подходит.
А вот это как настроите.
А автоматическое proactive-кэширование требует телепатии от средств разработки
ORM - вещь настраиваемая и ее надо использовать с умом, а не воткнули и стали работать.
Кстати, спасибо за интересные подробности про Мамбу.
P.S. Что-то вспомнился БобрДобр :) Он, по словам создателей, на Java жил недолго.
P.S. Что-то вспомнился БобрДобр :) Он, по словам создателей, на Java жил недолго.
На LAMP однозначно нет, очень много геммороя.
Yahoo использует FreeBSD/Apache/PHP/MySQL
Не совсем LAMP, но почти.
Yahoo использует FreeBSD/Apache/PHP/MySQL
Не совсем LAMP, но почти.
Все что угодно можно сделать на чем угодно. Вопрос стотит только в затраченных усилиях. Потом я не думаю что они используют mod_php.
Яху утверждает, что выбор был осознанным :)
http://public.yahoo.com/~radwin/talks/ph…
А причем тут вообще mod_php я совсем не понял.
http://public.yahoo.com/~radwin/talks/ph…
А причем тут вообще mod_php я совсем не понял.
Про java мне понравилось. Все конечно хорошо... но использовать ее без нитей как-то не хорошо.. у нас FreeBSD и в ней нет хорошей поддержки нитей :)
А причем тут вообще mod_php я совсем не понял
Я про то в чем крутится php. Учитывая использование акселератора и уже наличия в yahoo аналогичной скриптовой приоретарной технологии равносильно замены своего шила на открытое шило :)
А причем тут вообще mod_php я совсем не понял
Я про то в чем крутится php. Учитывая использование акселератора и уже наличия в yahoo аналогичной скриптовой приоретарной технологии равносильно замены своего шила на открытое шило :)
1) Платформа Microsoft изначально проприетарная. Платного и бесплатного много. Есть и бесплатная IDE от Microsoft, конечно урезанная.
2) Ваше дело и дело ваших клиентов.
3) IDEA не видел, но думаю они близки по функциональности с VS 2005. VS 2005 - да, стоит денег, но есть разные редакции. Если работаете - покупаете. И платит обычно не разработчик.
4) Переписывать ничего не надо. Были некоторые изменения, которые требовали использования мастера импорта при переходе на 2.0. Но дивиденды от миграции были гораздо больше.
И количество вакансий говорит о количестве вакансий. В чем связь с дискуссией о преимуществах серверных .NET и Java - не знаю.
2) Ваше дело и дело ваших клиентов.
3) IDEA не видел, но думаю они близки по функциональности с VS 2005. VS 2005 - да, стоит денег, но есть разные редакции. Если работаете - покупаете. И платит обычно не разработчик.
4) Переписывать ничего не надо. Были некоторые изменения, которые требовали использования мастера импорта при переходе на 2.0. Но дивиденды от миграции были гораздо больше.
И количество вакансий говорит о количестве вакансий. В чем связь с дискуссией о преимуществах серверных .NET и Java - не знаю.
1) Просто не знаю, что имеется ввиду под "где Free & OpenSource решений используется обычно под сотню". Библиотеки?
2) Если не секрет, что у вас за клиенты/отрасли используют в основном Java
3) "Выливается в стоимости" - а она везде выливается. Считать надо. Я по опыту знаю, что "если MS - зачит дорого" - заблуждение. (что-то опять себя продавцом MS чувствую)
4) Про клиетские приложения - отдельный разговор. Про сервера - это скорее просто особенность.
2) Если не секрет, что у вас за клиенты/отрасли используют в основном Java
3) "Выливается в стоимости" - а она везде выливается. Считать надо. Я по опыту знаю, что "если MS - зачит дорого" - заблуждение. (что-то опять себя продавцом MS чувствую)
4) Про клиетские приложения - отдельный разговор. Про сервера - это скорее просто особенность.
1) Просто не знаю, что имеется ввиду под "где Free & OpenSource решений используется обычно под сотню". Библиотеки?
Jboss www.jboss.org
Jboss www.jboss.org
С картинкой глюк потому, что она в оргинале имеет прозрачный фон, а при чтении в память GDLib по умолчанию делает черный фон, а не белый.
Два факторо роста платформы Microsoft:
1) .NET
2) значительное снижения цен на shared и dedicated Windows-хостинг
3) Windows Server 2003 и SQL Server 2005 (как повышение стабильности так и новая лицензионная политика, что отразилось на пункте 2)
1) .NET
2) значительное снижения цен на shared и dedicated Windows-хостинг
3) Windows Server 2003 и SQL Server 2005 (как повышение стабильности так и новая лицензионная политика, что отразилось на пункте 2)
Не видно куда делся 1.1%
Многие сейчас отключают выдачу - на чем работает сервер..
January 2007 -> February 2007
Apache -1.47%
Microsoft +0.31
Sun +0.06
Zeus -0.03
Многие сейчас отключают выдачу - на чем работает сервер..
January 2007 -> February 2007
Apache -1.47%
Microsoft +0.31
Sun +0.06
Zeus -0.03
Было бы интересно увидеть также распределение по версиям апача - 1.3, 2.0, 2.2
Начнем с того, что почти все крупные проекты скрываются, в лучше случае пишут ZX Spectrum, что просто смешно, а чаще — пишут совсем левое что-то. Второй способ — по урлам (смотрим на суффиксы) тоже часто не катит. Тот же самый Бегун много где выглядит как Java, хотя её там нет. Иногда проект мигрирует. А иногда используется связка nginx/apache/fcgi_php и ещё Бог знает что.
Давайте признаем, что адекватного способа оценить крупные проекты (подчеркну — крупные) не существует.
Средние и мелкие проекты оценить проще, там обычно используют массовые хостинги, где на одном сервере может хоститься сотня магазинчиков и спамовых страничек. Но появляется вопрос: что оценивать? Нагенеренные домены или IP-адреса? Думаю, что совершенно не ясно, по крайней мере ни одно из чисел ничего не будет обозначать. Да и статистику подпортить там может любой спаммер, который в день генерирует по миллиону сайтов.
Подобные отчёты — не более чем "средняя температура по больнице".
Давайте признаем, что адекватного способа оценить крупные проекты (подчеркну — крупные) не существует.
Средние и мелкие проекты оценить проще, там обычно используют массовые хостинги, где на одном сервере может хоститься сотня магазинчиков и спамовых страничек. Но появляется вопрос: что оценивать? Нагенеренные домены или IP-адреса? Думаю, что совершенно не ясно, по крайней мере ни одно из чисел ничего не будет обозначать. Да и статистику подпортить там может любой спаммер, который в день генерирует по миллиону сайтов.
Подобные отчёты — не более чем "средняя температура по больнице".
[прочитав очень интересные дискуссии выше]
девелоперы хабра, аауууууу, сделайте нормальное отображение длинных лестниц комментариев!!!1
единственная реальная ценность хабра (в том числе и вам) - это наличие таких живых дискуссий, *так дайте же их нормально почитать!*
пожа
луй
ст
а
!
:
)
девелоперы хабра, аауууууу, сделайте нормальное отображение длинных лестниц комментариев!!!1
единственная реальная ценность хабра (в том числе и вам) - это наличие таких живых дискуссий, *так дайте же их нормально почитать!*
пожа
луй
ст
а
!
:
)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сервер Apache сильно сдал позиции