На чем лучше писать сайт — на 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 — то добавляйте.
