На чем лучше писать сайт — на PHP или на Perl ? Понимаю что в такой постановке вопрос звучит немного по-дурацки. Попробую обрисовать задачу. Требования к сайту — база данных (скорее всего PostgreSQL), рассылка, предположительная посещаемость — 20-30 тысяч человек в день. Какие преимущества и недостатки обеих технологий? Есть ли какие-то вещи, которые можно сделать на Perl-е, но нельзя на PHP?
Просьба сильно не пинать, я чайник в сайтостроении.
Здравствуйте, Аноним, Вы писали:
А>На чем лучше писать сайт — на PHP или на Perl ? Понимаю что в такой постановке вопрос звучит немного по-дурацки. Попробую обрисовать задачу. Требования к сайту — база данных (скорее всего PostgreSQL), рассылка, предположительная посещаемость — 20-30 тысяч человек в день. Какие преимущества и недостатки обеих технологий? Есть ли какие-то вещи, которые можно сделать на Perl-е, но нельзя на PHP?
Всё можно...
Я бы лично взял RubyOnRails — с ним хотя бы хорошему можно научиться.
Sapienti sat!
Re[2]: PHP vs. Perl
От:
Аноним
Дата:
08.03.08 17:48
Оценка:
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, <Аноним>, Вы писали:
А>>Просьба сильно не пинать, я чайник в сайтостроении.
L>Поэтому лчше на PHP.
Но не до такой же степени.
Просьба обосновать, есть у PHP какие-нибудь преимущества кроме простоты изучения?
C>Я бы лично взял RubyOnRails — с ним хотя бы хорошему можно научиться.
Мне кажется, в деле веб-разработки ничему хорошему RoR не научит. Т.е., конечно. 20 — 30 тысяч посетителей в сутки это и не та цифра, что бы сильно напрягаться, но если уж учиться — то чему-то полезному, а?
C>>Я бы лично взял RubyOnRails — с ним хотя бы хорошему можно научиться.
dmz>Мне кажется, в деле веб-разработки ничему хорошему RoR не научит. Т.е., конечно. 20 — 30 тысяч посетителей в сутки это и не та цифра, что бы сильно напрягаться, но если уж учиться — то чему-то полезному, а?
dmz>>Мне кажется, в деле веб-разработки ничему хорошему RoR не научит. Т.е., конечно. 20 — 30 тысяч посетителей в сутки это и не та цифра, что бы сильно напрягаться, но если уж учиться — то чему-то полезному, а?
D>Почему не научат?
30 000 посетителей в сутки сделают не так много хитов, это будет работать даже на Руби. Но что дальше? Масштабирование, производительность, кэширование? Как оно там все работает, а? (в статье Rail Is A Ghetto примерно рассказано, как)
В какой момент возникнет вывод, что от фреймворков-все-в-одном с какого-то момента больше вреда, чем пользы, как это было с Яндексом, Джангой и сервисом "Куда-все-идут" (они не признаются, но выводы из истории-то очевидны, и я с удовлетворением подтвердил свои прогнозы, а так же поставил себе плюс за сознательный отказ от фреймворков в свое время)?
dmz>>>Мне кажется, в деле веб-разработки ничему хорошему RoR не научит. Т.е., конечно. 20 — 30 тысяч посетителей в сутки это и не та цифра, что бы сильно напрягаться, но если уж учиться — то чему-то полезному, а?
D>>Почему не научат?
dmz>30 000 посетителей в сутки сделают не так много хитов, это будет работать даже на Руби. Но что дальше? Масштабирование, производительность, кэширование? Как оно там все работает, а? (в статье Rail Is A Ghetto примерно рассказано, как)
Там очень много эмоций и очень трудно отделить зерна...
dmz>В какой момент возникнет вывод, что от фреймворков-все-в-одном с какого-то момента больше вреда, чем пользы, как это было с Яндексом, Джангой и сервисом "Куда-все-идут" (они не признаются, но выводы из истории-то очевидны, и я с удовлетворением подтвердил свои прогнозы, а так же поставил себе плюс за сознательный отказ от фреймворков в свое время)?
Ну так вывод то в том, что если пользуешься неким инструментом, то нужно хорошо его знать. Особенно нужно знать и понимать его слабые стороны, чтобы их обойти или нивелировать.
Плюсов от фреймворка всё равно больше и я бы именно решение на нем советовал.
dmz>>30 000 посетителей в сутки сделают не так много хитов, это будет работать даже на Руби. Но что дальше? Масштабирование, производительность, кэширование? Как оно там все работает, а? (в статье Rail Is A Ghetto примерно рассказано, как)
D>Там очень много эмоций и очень трудно отделить зерна...
Зерна вот: руби тормоз сам по себе и это ни для кого не секрет. Это раз.
Poor performance and bad implementation of nearly every feature from GC to IO to Threads means I’m not interested.
Это тоже скорее всего правда. История про ребуты каждые четыре минуты — тоже, скорее всего, правда. А еще в рельсы вбит ORM, эффективность которого тоже требует исследования. Конечно, наверняка им можно не пользоваться, но новичок им будет пользоваться скорее всего.
D>Ну так вывод то в том, что если пользуешься неким инструментом, то нужно хорошо его знать. Особенно нужно знать и понимать его слабые стороны, чтобы их обойти или нивелировать.
Вывод в том, что если речь идет про историю с "куда-все-идут", то едва ли есть много людей в нашей стране, которые знали бы Джангу лучше, чем фигуранты этой истории.
D>Плюсов от фреймворка всё равно больше и я бы именно решение на нем советовал.
Ну а я бы нет Чем фреймворк сложнее, чем в нем больше внутренних связей и договоренностей, тем больше пройдет времени между тем, как что-то сломается и возможностью починить. И тем больше требуется времени на его уверенное освоение. После десятка проектов по-прежему ничто не наводит на мысли, что это могло бы как-то окупиться.
В итоге на своем решении я уверен что оно 1) будет работать так, как я от него ожидаю 2) если что-то сломается, то мы быстро его починим без оглядки на всякие коммьюнити, и без вопросов, как наши патчи будут уживаться с веткой основных разработчиков коммьюнити.
Короче, я не спорю — я предупреждаю. Ruby я честно исследовал на возможность применения еще в самом начале своей нынешней деятельности (о чем тут сохранились даже посты с выводами), и ряд вещей мне там не понравился резко — например, откровенная неработоспособность некоторых базовых компонент, предполагаемых как стандартные, и невозможность их просто подогнать под свои требования. Про производительность и масштабируемость на том этапе даже не думал, меня отпугнул стиль "шаг в стону — расстрел на месте", который достаточно характерен для фреймворков.
Есть еще пачка соображений, но я не готов их пока кратко изложить — может, позже. В общем, имейте ввиду, что риски использования фреймворков — есть. И стреляют они очень смачно — как это произошло с питоньим сервисом у яндекса.
Здравствуйте, dmz, Вы писали:
dmz>Зерна вот: руби тормоз сам по себе и это ни для кого не секрет. Это раз.
dmz>
dmz>Poor performance and bad implementation of nearly every feature from GC to IO to Threads means I’m not interested.
dmz>Это тоже скорее всего правда. История про ребуты каждые четыре минуты — тоже, скорее всего, правда. А еще в рельсы вбит ORM, эффективность которого тоже требует исследования. Конечно, наверняка им можно не пользоваться, но новичок им будет пользоваться скорее всего.
Ну так новичку и надо чтобы его держали в рамках... Когда перестанет быть новичком, тогда поймет что использовать, а что нет.
dmz>Вывод в том, что если речь идет про историю с "куда-все-идут", то едва ли есть много людей в нашей стране, которые знали бы Джангу лучше, чем фигуранты этой истории.
Безусловно. Но проблема была локализирована очень быстро и достоинств джанги она не умоляет. И без фреймворка можно написать очень плохую систему и шанс этого выше.
D>>Плюсов от фреймворка всё равно больше и я бы именно решение на нем советовал.
dmz>Ну а я бы нет Чем фреймворк сложнее, чем в нем больше внутренних связей и договоренностей, тем больше пройдет времени между тем, как что-то сломается и возможностью починить. И тем больше требуется времени на его уверенное освоение. После десятка проектов по-прежему ничто не наводит на мысли, что это могло бы как-то окупиться.
А собственный велосипедный код, что не порождает проблем? Так ещё больше. А в фреймворке из-за большого комьюнити, многие острые углы уже сглажены к моменту, когда вы его начнете использовать. Тем более django вообще можно применять как неплохую реализацию WSGI стека и не завязываться на высокоуровневые абстракции.
dmz>В итоге на своем решении я уверен что оно 1) будет работать так, как я от него ожидаю 2) если что-то сломается, то мы быстро его починим без оглядки на всякие коммьюнити, и без вопросов, как наши патчи будут уживаться с веткой основных разработчиков коммьюнити.
Это своё решение надо заиметь и потратить на него ресурсы. И стоимость поддержки выше, поскольку коммьюнити нет. А для новичка так вообще смерть.
dmz>Короче, я не спорю — я предупреждаю. Ruby я честно исследовал на возможность применения еще в самом начале своей нынешней деятельности (о чем тут сохранились даже посты с выводами), и ряд вещей мне там не понравился резко — например, откровенная неработоспособность некоторых базовых компонент, предполагаемых как стандартные, и невозможность их просто подогнать под свои требования. Про производительность и масштабируемость на том этапе даже не думал, меня отпугнул стиль "шаг в стону — расстрел на месте", который достаточно характерен для фреймворков.
Но это ваш выбор, а другие приняли противоположное решение. И все правы. Каждый выбирает сам.
Ничего криминального ни в RoR, ни в Django нет. Только надо пользоваться с умом любым инструментом.
D>Безусловно. Но проблема была локализирована очень быстро и достоинств джанги она не умоляет. И без фреймворка можно написать очень плохую систему и шанс этого выше.
Когда знаешь как вообще писать такого рода системы — то нет. Но если ты новичок, и потратишь свое время на то, что бы изучать фреймворк (причем не вдаваясь реализацию, и не думаю, зачем то или иное сделано) — то окажешься в очень невыгодной ситуации.
D>А собственный велосипедный код, что не порождает проблем? Так ещё больше.
Собственный велосипедный код нужен, в частности, затем, что бы изолировать чужеродные компоненты и если что не так — то выкинуть и взять другие вместо них. Получится ли так поступить с фреймворком?
D>А в фреймворке из-за большого комьюнити, многие острые углы уже сглажены к моменту, когда вы его начнете D>использовать. Тем более django вообще можно применять как неплохую реализацию WSGI стека и не завязываться на D>высокоуровневые абстракции.
А джанга тогда зачем?
D>Но это ваш выбор, а другие приняли противоположное решение. И все правы. Каждый выбирает сам. D>Ничего криминального ни в RoR, ни в Django нет. Только надо пользоваться с умом любым инструментом.
Ну если в RoR упоминавшиеся вещи — это не криминал, то я уж не знаю, что такое криминал.
Относительно быстрый (относительно Ruby точно, без оговорок), под него очень много библиотек и компонентов, нет проблем с юникодами. Зрелый, особенно 2.5.
SO>А если добавить для сравнения ASP.NET?
Ну если вы знаете и ASP.NET и Python — то добавляйте. Я ASP.NET не знаю, но минусы которые мне сразу очевидны:
Либо платформы от MS (деньги! безопасность! администрирование! ради чего?!), либо "жалкое подобие левой руки" — Mono, зрелость и годность которого вообще под вопросом. Плюс стоимость разработчиков что .Net, что J2EE. В общем, что впаривать разработку крупным корпорациям — это самое то, а вот если себе что-то делать — то стоит подумать
О .Net я знаю достаточно мало, но если проводить параллели с J2EE, аналогом которой она где-то как-то является — то плюсы питона, которые лежат на поверхности — меньшее время разработки и скромнее требования к платформам.
SO>Где можно найти success stories о проектах на разных языках/платформах?
Не знаю. Но с другой стороны, на чем работает Amazon (и куда двигается), Yahoo, YouTube, Livejournal, Yandex, Rambler — хорошо известно. На чем Google — вроде бы тоже, но как-то более смутно (хотя я особо не рыл, может и не скрывается).
Надо сказать, что ASP.NET тут нигде не запалилось, да и Amazon c J2EE скорее всего слез (могу ошибаться — давно было)
Здравствуйте, dmz, Вы писали:
dmz>Когда знаешь как вообще писать такого рода системы — то нет. Но если ты новичок, и потратишь свое время на то, что бы изучать фреймворк (причем не вдаваясь реализацию, и не думаю, зачем то или иное сделано) — то окажешься в очень невыгодной ситуации.
А новичок знает как писать такие системы? Нет. Значит фреймворк может дать представление о мироустройстве для новичка. Да оно будет однобоким, но будет. А если новичок разумный и попробует не один фреймворк, если попробует разобраться как в них вращаются шестеренки, то поймет что есть хорошо, а что плохо. Т.е. говорить, что фреймворк это плохой выбор — некорректно. Надо уточнять, что выбор фреймворка не отрицает необходимость изучения низкоуровневых аспектов его работы, в том числе для поднятия навыка проектирования.
dmz>Собственный велосипедный код нужен, в частности, затем, что бы изолировать чужеродные компоненты и если что не так — то выкинуть и взять другие вместо них. Получится ли так поступить с фреймворком?
Да. В той же джанге можно отказаться от всего и использовать его, как я уже говорил, как WSGI стек. А можно отказаться от части функционала, заменить его своим или сторонним.
dmz>А джанга тогда зачем?
Каждый выберет сам какие её компоненты использовать. Новичок будет использовать все, но это не плохо. Со временем он поймет, что ему действительно нужно от фреймворка.
D>>Но это ваш выбор, а другие приняли противоположное решение. И все правы. Каждый выбирает сам. D>>Ничего криминального ни в RoR, ни в Django нет. Только надо пользоваться с умом любым инструментом.
dmz>Ну если в RoR упоминавшиеся вещи — это не криминал, то я уж не знаю, что такое криминал.
Ну я так понял, что RoR вы изучали по мнению других, да? Тогда согласитесь, что некорректно его в чем то обвинять, лично не попробовав на вкус. Тем более, что все популярные фреймворки быстро развиваются.
Platform
# PHP
# MySQL
# Shards
# Memcached for a caching layer.
# Squid in reverse-proxy for html and images.
# Linux (RedHat)
# Smarty for templating
# Perl
# PEAR for XML and Email parsing
# ImageMagick, for image processing
# Java, for the node service
# Apache
# SystemImager for deployment
# Ganglia for distributed system monitoring
# Subcon stores essential system configuration files in a subversion repository for easy deployment to machines in a cluster.
# Cvsup for distributing and updating collections of files across a network.
youtube
#
Platform
# Apache
# Python
# Linux (SuSe)
# MySQL
# psyco, a dynamic python->C compiler
# lighttpd for video instead of Apache
digg
#
Platform
# MySQL
# Linux
# PHP
# Lucene
# APC PHP Accelerator
# MCache
Amazon
# Linux
# Oracle
# C++
# Perl
# Mason
# Java
# Jboss
# Servlets
livejournal
#
Platform
# Linux
# MySql
# Perl
# Memcached
# MogileFS
# Apache
myspace
#
Platform
# ASP.NET 2.0
# Windows
# IIS
# SQL Server
вау. они это сделали. зачем-то
И так далее. в общем, на чем угодно можно сделать, даже на RoR. Так что осталось только найти, сколько это кому стоило.
dmz>>Ну если в RoR упоминавшиеся вещи — это не криминал, то я уж не знаю, что такое криминал.
D>Ну я так понял, что RoR вы изучали по мнению других, да? Тогда согласитесь, что некорректно его в чем то обвинять, лично не попробовав на вкус. Тем более, что все популярные фреймворки быстро развиваются.
Я же написал, что я его пытался использовать и потратил какое-то время на изучение. И сознательно отказался, теперь понял что это было правильно.
Здравствуйте, dmz, Вы писали:
SO>>Почему?
dmz>Относительно быстрый (относительно Ruby точно, без оговорок), под него очень много библиотек и компонентов, нет проблем с юникодами. Зрелый, особенно 2.5.
Гуд. А что со средствами разработки? Т.е. мне, как человеку долгое время работавшему с C++, как минимум хочется иметь отладчик. Добротная IDE так же приветствуется.
SO>>А если добавить для сравнения ASP.NET?
dmz>Ну если вы знаете и ASP.NET и Python — то добавляйте.
Здравствуйте, dmz, Вы писали:
D>>Почему не научат? dmz>30 000 посетителей в сутки сделают не так много хитов, это будет работать даже на Руби. Но что дальше? Масштабирование, производительность, кэширование? Как оно там все работает, а? (в статье Rail Is A Ghetto примерно рассказано, как)
Статья "Rail Is A Ghetto" — это во многом крики неудачника.
Зато RoR хотя бы научит нормальному разделению данных и кода, и вообще модели MVC в целом. Это очень пригодится потом, даже если писать на PHP или других системах (типа J2EE).
Да, и чтобы на лимиты масштабируемости RoR нарваться — это надо весьма постараться. Обычно лимитом станет база данных через некоторое время.
Здравствуйте, Cyberax, Вы писали:
C>Да, и чтобы на лимиты масштабируемости RoR нарваться — это надо весьма постараться. Обычно лимитом станет база данных через некоторое время.
Он же вроде в многопоточном варианте не умеет работать, поэтому приходится под каждый реквест запускать отдельный процесс.
разве это не может стать фактором, ограничивающим масштабируемость?
dmz>>Относительно быстрый (относительно Ruby точно, без оговорок), под него очень много библиотек и компонентов, нет проблем с юникодами. Зрелый, особенно 2.5.
SO>Гуд. А что со средствами разработки? Т.е. мне, как человеку долгое время работавшему с C++, как минимум хочется иметь отладчик. Добротная IDE так же приветствуется.
Говорят, что-то есть. Примочка к эклипсу для питона точно есть. Не смотрел. vim & debug printing will be enough for everyone (c) У нас еще есть html-ный отладчик — перехватывает исключения и можно смотреть стейтрейсы, переменные, исполнять код и т.п. Ставишь raise Exception() в любом месте и изучаешь.
Здравствуйте, Lloyd, Вы писали:
C>>Да, и чтобы на лимиты масштабируемости RoR нарваться — это надо весьма постараться. Обычно лимитом станет база данных через некоторое время. L>Он же вроде в многопоточном варианте не умеет работать, поэтому приходится под каждый реквест запускать отдельный процесс. L>разве это не может стать фактором, ограничивающим масштабируемость?
RoR прекрасно работает в виде FastCGI, так что создавать по интерпретатору на запрос совсем не нужно.
dmz># ASP.NET 2.0
dmz># Windows
dmz># IIS
dmz># SQL Server
dmz>вау. они это сделали. зачем-то
Где-то на highscalability лежит ссылка на описание, почему. Они уперлись в потолок Coldfusion'a (!) b? чтобы не тратить время на переход с платформы на платформу, остались в винде и постепенно начали переписывать все на ASP.NET. Причем еще до недавнего времени очень большие куски сайта у них продолжали крутиться на Coldfusion, который крутился не на родной яве, а на каком-то .net-овском эмуляторе
Здравствуйте, Аноним, Вы писали:
А>На чем лучше писать сайт — на PHP или на Perl ? Понимаю что в такой постановке вопрос звучит немного по-дурацки. Попробую обрисовать задачу. Требования к сайту — база данных (скорее всего PostgreSQL), рассылка, предположительная посещаемость — 20-30 тысяч человек в день.
При такой постановке задачи, всё равно на чём.
А>Есть ли какие-то вещи, которые можно сделать на Perl-е, но нельзя на PHP?
Их много. Другое дело, что ты, возможно, никогда не столкнёшься с этими вещами.
А>Просьба сильно не пинать, я чайник в сайтостроении.
Здравствуйте, dmz, Вы писали:
dmz>Вывод в том, что если речь идет про историю с "куда-все-идут", то едва ли есть много людей в нашей стране, которые знали бы Джангу лучше, чем фигуранты этой истории.
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, dmz, Вы писали:
dmz>>Вывод в том, что если речь идет про историю с "куда-все-идут", то едва ли есть много людей в нашей стране, которые знали бы Джангу лучше, чем фигуранты этой истории.
A>Что за история? Где почитать?
Здравствуйте, dmz, Вы писали:
dmz>В какой момент возникнет вывод, что от фреймворков-все-в-одном с какого-то момента больше вреда, чем пользы
А можно поподробней в этом месте?
(Успешно пользуюсь Zend Frameworkom'ом, но как раз ощущаю совсем противоположное чувство: намного больше пользы чем вреда. Он гибкий, разширяемый, и не особо навязывает, какой-то свой особенный замысловатый подход, парадигму: можно перемастерить, перестроить, ощущаеться сводоба выбора и польза этого несложного инструмента.).
Здравствуйте, Аноним, Вы писали:
А>На чем лучше писать сайт — на PHP или на Perl ? Понимаю что в такой постановке вопрос звучит немного по-дурацки. Попробую обрисовать задачу. Требования к сайту — база данных (скорее всего PostgreSQL), рассылка, предположительная посещаемость — 20-30 тысяч человек в день. Какие преимущества и недостатки обеих технологий? Есть ли какие-то вещи, которые можно сделать на Perl-е, но нельзя на PHP? А>Просьба сильно не пинать, я чайник в сайтостроении.
Apache + PHP + Eclipse (PDT) + XDebug + MySQL — довольно неплохой стандартный набор + комьюнити.
Руби на Рельсах? Ругают его много... Хотя идея красивая.
Питон + Джанго? Не видел, но хвалят.
АСП.НЕТ — для начинающего в самый раз: большие возможности + скорость + ide
а РНР надо уметь юзать, там достаточно косяков, ничего качественного может не получиться...
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, <Аноним>, Вы писали:
А>>Просьба обосновать, есть у PHP какие-нибудь преимущества кроме простоты изучения?
ДГ>Никаких. ДГ> ДГ>
Пессимистично, но РНР удобнее для веб, чем прел, правда?
Здравствуйте, int 13h, Вы писали:
I1>Apache + PHP + Eclipse (PDT) + XDebug + MySQL — довольно неплохой стандартный набор + комьюнити. I1>Руби на Рельсах? Ругают его много... Хотя идея красивая. I1>Питон + Джанго? Не видел, но хвалят. I1>АСП.НЕТ — для начинающего в самый раз: большие возможности + скорость + ide
О, да! А php с питоном напару — это конечно для мега-гуру.
Здравствуйте, anonymous, Вы писали:
C>>Я бы лично взял RubyOnRails — с ним хотя бы хорошему можно научиться. A>RoR — не язык программирования.
Я это знаю. И?
Здравствуйте, Cyberax, Вы писали:
C>>>Я бы лично взял RubyOnRails — с ним хотя бы хорошему можно научиться. A>>RoR — не язык программирования. C>Я это знаю. И?
Вопрос был про языки. PHP vs Perl не то же, что и, скажем, Smarty vs Catalyst. Впрочем, не важно.
Здравствуйте, int 13h, Вы писали:
I1>Здравствуйте, Аноним, Вы писали:
А>>На чем лучше писать сайт — на PHP или на Perl ? Понимаю что в такой постановке вопрос звучит немного по-дурацки. Попробую обрисовать задачу. Требования к сайту — база данных (скорее всего PostgreSQL), рассылка, предположительная посещаемость — 20-30 тысяч человек в день. Какие преимущества и недостатки обеих технологий? Есть ли какие-то вещи, которые можно сделать на Perl-е, но нельзя на PHP? А>>Просьба сильно не пинать, я чайник в сайтостроении.
I1>Apache + PHP + Eclipse (PDT) + XDebug + MySQL — довольно неплохой стандартный набор + комьюнити.
А как вам такая связка для разработки на php VS2005(VS2008) + PHP + MySql ну и Apache естественно?
Здравствуйте, DeZhavi, Вы писали:
DZ>Здравствуйте, int 13h, Вы писали:
I1>>Здравствуйте, Аноним, Вы писали:
А>>>На чем лучше писать сайт — на PHP или на Perl ? Понимаю что в такой постановке вопрос звучит немного по-дурацки. Попробую обрисовать задачу. Требования к сайту — база данных (скорее всего PostgreSQL), рассылка, предположительная посещаемость — 20-30 тысяч человек в день. Какие преимущества и недостатки обеих технологий? Есть ли какие-то вещи, которые можно сделать на Perl-е, но нельзя на PHP? А>>>Просьба сильно не пинать, я чайник в сайтостроении.
I1>>Apache + PHP + Eclipse (PDT) + XDebug + MySQL — довольно неплохой стандартный набор + комьюнити. DZ>А как вам такая связка для разработки на php VS2005(VS2008) + PHP + MySql ну и Apache естественно?
Здравствуйте, TheOldMan, Вы писали:
TOM>Здравствуйте, DeZhavi, Вы писали:
DZ>>Здравствуйте, int 13h, Вы писали:
I1>>>Здравствуйте, Аноним, Вы писали:
А>>>>На чем лучше писать сайт — на PHP или на Perl ? Понимаю что в такой постановке вопрос звучит немного по-дурацки. Попробую обрисовать задачу. Требования к сайту — база данных (скорее всего PostgreSQL), рассылка, предположительная посещаемость — 20-30 тысяч человек в день. Какие преимущества и недостатки обеих технологий? Есть ли какие-то вещи, которые можно сделать на Perl-е, но нельзя на PHP? А>>>>Просьба сильно не пинать, я чайник в сайтостроении.
I1>>>Apache + PHP + Eclipse (PDT) + XDebug + MySQL — довольно неплохой стандартный набор + комьюнити. DZ>>А как вам такая связка для разработки на php VS2005(VS2008) + PHP + MySql ну и Apache естественно?
TOM>не нравиться: только под windows
А мне нарвится, с учтом того что проекты и на ASo и на php очнь удобно
Здравствуйте, Mamut, Вы писали:
ДГ>>Перла я не знаю, но от словосочетания "PHP удобнее" меня блевать тянет. Домашние странички — да, удобнее, базару нет. Personal Home Page, блин. M>Чтобы не повторять: Re[4]: PHP vs. Perl
D>Безусловно. Но проблема была локализирована очень быстро и достоинств джанги она не умоляет. И без фреймворка можно написать очень плохую систему и шанс этого выше.
Главный минус этого “императивного” решения в том, что оно рушит барьеры абстракции. Вы не можете написать совершенно отвлеченную функцию, которая хочет писать в БД, и быть уверенными, что она работает всегда. Потому что если ее вызовет что-то в то время, когда активно слейв-соединение, она упадет.
За это меня все время ругает Андрей, и даже пророчит, что не пройдет и двух месяцев, как кто-нибудь наткнется на какой-нибудь трудноуловимый баг, связанный с этой императивностью. Теоретически, он прав. Но это единственное решение, которое я смог придумать, которое работает извне Джанго, не трогая ее код.
Перевожу: в рамках существующих фреймворков (Django и ORM) мы не нашли нормального решения данной проблемы и воткнули костыли, которые могут (и создадут!) проблемы в будущем — с управлением соединениями с базой вообще шутки плохи.
Дальше идут уже отмазки, почему все не так страшно и может быть это будет работать, потому что наша система на самом деле и т.п ...
Итого — гимора много. С какого то момента мы не получаем бонусы от фреймворка, а боремся с ним. Касается и джанги, и ORMа.
Re[9]: Почему я не люблю фреймворки
От:
Аноним
Дата:
18.03.08 15:48
Оценка:
Здравствуйте, dmz, Вы писали:
D>>Безусловно. Но проблема была локализирована очень быстро и достоинств джанги она не умоляет. И без фреймворка можно написать очень плохую систему и шанс этого выше.
dmz>Ага. А вот и "локализация проблемы": http://lenta.yandex.ru/read.xml?group=14
D>>Безусловно. Но проблема была локализирована очень быстро и достоинств джанги она не умоляет. И без фреймворка можно написать очень плохую систему и шанс этого выше.
dmz>Ага. А вот и "локализация проблемы": http://lenta.yandex.ru/read.xml?group=14
Мягко говоря проблема уже другая. И не проблема вовсе, а оптимизация.
dmz>Перевожу: в рамках существующих фреймворков (Django и ORM) мы не нашли нормального решения данной проблемы и воткнули костыли, которые могут (и создадут!) проблемы в будущем — с управлением соединениями с базой вообще шутки плохи.
А как добавить репликации в уже существующий код без костылей вы знаете? И сколько ресурсов потребовалось бы на разработку всей системы с нуля?
dmz>Итого — гимора много. С какого то момента мы не получаем бонусы от фреймворка, а боремся с ним. Касается и джанги, и ORMа.
Бонус от фреймворка уже получен — время разработки гипер короткое. Далее уже идут "хачу!", со всеми вытекающими. Решение получилось, не трогающее код фреймворка, и абсолютно стороннее — это хорошо. Тем более что Иван сразу знал, что начинает использовать инструмент где нет репликаций, а значит сделал этот осознано.
Саш, я бы, честно говоря, давно бросил спорить . Человек явно не готов менять свою точку зрения, и просто хочет победить в споре. Отсюда и эти выборочные цитаты, и разворачивание фактов удобной стороной... Например он благополучно не заметил, что производительность нам обеспечивает кеш, а не репликации. Продолжает твердить, что упал сервис из-за фреймворка, хотя из того поста понятно, что фреймворк ни при чем. Даже умудрился прицепиться к моему перфекционистскому бурчанию про императивный стиль кластерного бэкенда... Чудно .
D>А как добавить репликации в уже существующий код без костылей вы знаете?
Разрабатывать с нуля ничего не надо. Надо просто брать компоненты, которые делают что-то одно, но делают это хорошо. И делать так, что бы эти компоненты было легко переписать или заменить в случае чего.
Затем, надо выделять вещи очень важные и критичные — такие как работа с базой и коннекциями, которые влияют на вообще все, и сессии, которые при их наличии влияют масштабирование (есть сессии — нет масштабирования, гы-гы. шучу.)
Есть вещи менее важные — шаблонный движок, например, или middleware (хотя конкретно флуп тоже таит много открытий чудных)
Есть совсем маловажные — например, компонент, который отвечает за валидацию значений форм и возврат ошибочных значений ( хотя этого добра в питоне совсем немного, и нам пришлось написать свой, т.к. HtmlForms или как там его дюже мерзок)
Каждый компонент рассматривается отдельно, тестируется, оборачивается таким образом, что бы от него избавиться, не переделывая всей системы в целом.
Можно взять все оптом в виде джанги. Ну и получить то, что получили.
И не надо говорить, что можно или взять что-то от джанги, или там поменять в джанге ORM на что нибудь другое.
Никто этого в реальной жизни не делает, а как только начинает — то теряет то самое "гипер-короткое" время разработки напрочь совсем.
D>И сколько ресурсов потребовалось бы на разработку всей системы с нуля?
Ну это примерно известно. Был случай переписывания одной системы с web.py на TurboGears и с TG на набор компонентов с собственным glue. В общем-то очень немного по сравнению со временем написания системы, благодаря наличию выделенного слоя бизнес-логики, этот самый слой почти не пострадал. Хуже пришлось при выкидывании ORM, потому что он пускает свои метастазы между слоями...
Если бы писали сразу с нуля, то было бы вообще отлично. С нуля ведь это очень условно. Фактически, с нуля написан только валидатор форм и сериализаторы в xml и json, потому что те, которые есть не нравятся. Остальное все стандартное. Только обернутое. На всякий случай.
dmz>>Итого — гимора много. С какого то момента мы не получаем бонусы от фреймворка, а боремся с ним. Касается и джанги, и ORMа.
D>Бонус от фреймворка уже получен — время разработки гипер короткое.
Полгода, ага. И потом еще какое-то время, что бы работало. Собственно, данная история показывает именно этот сценарий, да? Возможно эти не все эти полгода ушли на программирование. Но тогда это "гипер" как-то теряет часть смысла.
И еще учтите, что "гипер" короткое оно у тех, кто хорошо знает. А чем сложнее фреймворк и чем больше связей — тем сложнее разбираться и больше на это надо времени.
D>Далее уже идут "хачу!", со всеми вытекающими. Решение получилось, не трогающее код фреймворка, и абсолютно стороннее — это хорошо.
Какие такие "хачу"? Мы говорим о базовых вещах, о нужности которых было известно заранее. Масштабирование там. Подразумевающее известно что.
D>Тем более что Иван сразу знал, что начинает использовать инструмент где нет репликаций, а значит сделал этот осознано.
Нет не "репликации". Нет управления соединениями.
Давайте мы абстрагируемся от личностей уже, ага? То, что получилось, это хороший и показательный кейс, и спасибо, что он рассказан честно. Выводы все заинтересованные сделают самостоятельно. Тут еще есть занятный пласт, связанный с навязанными джангой решениями (верстка, поддержка, etc), но это уже специфика конторы.
I>Саш, я бы, честно говоря, давно бросил спорить . Человек явно не готов менять свою точку зрения, и просто хочет победить в споре.
Мне менять точку зрения сейчас бессмысленно, потому что этот вопрос закрыт. Т.е. если считать плюсы и минусы, то получится вроде:
[+] Быстро писать
[-] Черный ящик с непредсказуемыми заранее особенностями
[-] Заставляет отказаться от хорошо зарекомендовавших себя практик в обмен на неизвестно что
I>Отсюда и эти выборочные цитаты, и разворачивание фактов удобной стороной...
Ну я не могу цитировать все, хотя может и стоило, т.к. очень интересно и познавательно.
I>Например он благополучно не заметил, что производительность нам обеспечивает кеш, а не репликации.
Вам. При этом тот факт что репликации, а точнее, управления коннекциями, отсутствуют. Для всех.
И когда выясниться, что кэш репликации не заменяет кому-то, то что?
I>Продолжает твердить, что упал сервис из-за фреймворка, хотя из того поста понятно, что фреймворк ни при чем.
Он упал из-за побочных эффектов применения джанги, а именно, особенности устройства сессий. В первый раз. Это не так?
В общем-то проблема не в том, что упал. Проблема в том, что бы быстро починить.
I>Даже умудрился прицепиться к моему перфекционистскому бурчанию про императивный стиль кластерного бэкенда... Чудно I>.
К стилю прицепился не только я, но еще некий Андрей, и сам автор данного решения. Я подозреваю с этим решением совершенно конкретные проблемы, но от спекуляций воздержусь, а проверить не имею возможности.
I>Ну не нравятся человеку фреймворки, пусть...
