[web] на чем пишут большие системы?
Вопрос, конечно, банальный, но всё-таки - что такое "серьезная логика"?
ICQ.com вон на PHP сделан вроде бы
ICQ.com вон на PHP сделан вроде бы
Не набор статических страничек, а, скажем, рабочее место.
Например - хотя бы кассира в салоне моб связи, его начальника и т.п...
Какая-нибудь системы управления предприятием и т.п.
Например - хотя бы кассира в салоне моб связи, его начальника и т.п...
Какая-нибудь системы управления предприятием и т.п.
"понятно что не PHP" - мнение человека, не разбирающегося в PHP
спасибо. 
а теперь полазь по ссылке, и найдешь не только мое мнение.
и вопрос перечитай
т.е. понятно что маленькие проекты PHP потянет. но уж дальше будет
а теперь полазь по ссылке, и найдешь не только мое мнение.
и вопрос перечитай
т.е. понятно что маленькие проекты PHP потянет. но уж дальше будет
тебе 2002 год в названии ссылки ни о чём не говорит? В курсе, что PHP5 вышел? Что Zend Engine 2 появился? Zend Encoder & Zend Optimizer?
ASP.NET - как я понимаю, Microsoft?
А под Unix?
А под Unix?
Perl, Python, Java
NET или JAVA
Java!
http://www.i2r.ru/static/536/out_9289.shtml
но погуглив (по аглицки, ессно:) ) что-то не нашел у Perl неприятностей
Java (как я ее понимаю) - язык очень переносимый, для работы на утюгах, чайниках и т.п.
Излишняя громоздкость, обусловленная как раз переносимостью, мешает на вполне адекватных платформах.
В сравнении с Perl - Python как язык ему совершенно равномощен, но избавлен от великого множества неприятностей и неудобств, присущих Perl.и т.п.
но погуглив (по аглицки, ессно:) ) что-то не нашел у Perl неприятностей
Java (как я ее понимаю) - язык очень переносимый, для работы на утюгах, чайниках и т.п.
Излишняя громоздкость, обусловленная как раз переносимостью, мешает на вполне адекватных платформах.
Излишняя громздкость при работе на чайниках мешать будет, а не нормальных платформах -)
Как раз наоборот, на чайниках нет всяких EJB.
Не надо валить в одну кучу J2EE, J2SE и J2ME.
> В каких технологиях пишутся web-интерфейсы (и сервисы?) с серьезной логикой?
win-связка: Asp.Net + MS Sql
nix-связка: JSP + Oracle
win-связка: Asp.Net + MS Sql
nix-связка: JSP + Oracle
Не JSP, а JAVA
И ее часто используют под винды в связке с SQL'м
И ее часто используют под винды в связке с SQL'м
> Не JSP, а JAVA
Голая Java? почему?
а JSP(Java server pages) почему не используется?
Голая Java? почему?
а JSP(Java server pages) почему не используется?
JSP используется, но писать на нем систему не получится
Бизнес логику пишут просто на JAVA, а JSP используют только для отображения.
Бизнес логику пишут просто на JAVA, а JSP используют только для отображения.
я не совсем понимаю, почему ты противопоставляешь друг другу JSP и Java-у?
разве они до сих пор так сильно разделены?
разве они до сих пор так сильно разделены?
Перекрестись -
> Перекрестись -
не въехал.
не въехал.
А что на счет JSF, не юзают массово пока?
Как насчет Ruby on Rails? Кто-нибудь сталкивался/читал/понял?
Честно говоря, я не разобрался в чем преимущество Ruby перед Perl,Python и Java.
Почитал синтаксис, немного отзывов...
Честно говоря, я не разобрался в чем преимущество Ruby перед Perl,Python и Java.
Почитал синтаксис, немного отзывов...
Ruby - это язык, а не "платформа"
большие системы на голом языке писать - утопия.
большие системы на голом языке писать - утопия.
есть у нас в конторе такой интересный продукт как Web Librarian
Ядро написано на С++, интерфейс Java Applet`s, данные хранятся в самописных БД, извлекаются драйверами написанными на Delphi и все это хозяйство крутится под самописным application сервером 
Ядро написано на С++, интерфейс Java Applet`s, данные хранятся в самописных БД, извлекаются драйверами написанными на Delphi и все это хозяйство крутится под самописным application сервером
слово Framework и платформа - это совсем разные вещи.
платформа - это что-то типа объединения:
язык
библиотеки
"стандартная" работа с основными текущими технологиями windows и/или *nix-а
наличие сильного разностороннего сообщества разработчиков
компилируемость
среда разработки
возможность создания web приложений
возможность создания desktop приложений
возможность создания консольных приложений
подключение библиотек на других языках
и т.д.
платформа - это что-то типа объединения:
язык
библиотеки
"стандартная" работа с основными текущими технологиями windows и/или *nix-а
наличие сильного разностороннего сообщества разработчиков
компилируемость
среда разработки
возможность создания web приложений
возможность создания desktop приложений
возможность создания консольных приложений
подключение библиотек на других языках
и т.д.
Ты меня с кем-то перепутал
Про платформу я упоминал только в связи с Java.
Тем не менее:
Поэтому 6,8 - отпадает.
5 отпадает просто потому что неправда.
Остальное - есть. Насколько я его понял. И есть хороший популярный framework.
Про платформу я упоминал только в связи с Java.
Тем не менее:
Я говорил о web-технологиях для написания приложений со сложной логикой.
1. язык
2. библиотеки
3. "стандартная" работа с основными текущими технологиями windows и/или *nix-а
4. наличие сильного разностороннего сообщества разработчиков
5. компилируемость
6. среда разработки
7. возможность создания web приложений
8. возможность создания desktop приложений
9. возможность создания консольных приложений
10. подключение библиотек на других языках
Поэтому 6,8 - отпадает.
5 отпадает просто потому что неправда.
Остальное - есть. Насколько я его понял. И есть хороший популярный framework.
> Я говорил о web-технологиях для написания приложений со сложной логикой.
В заголовке оригинального вопроса у тебя написано про большие приложения, а не просто про сложную логику.
а большие приложения как раз и тянут за собой и компилируемость, и desktop-приложения, и среду разработки.
компилируемость нужна - потому что,
1)на большие системы очень высокая нагрузка, и ключевые точки хочется вылизать как можно лучше
2)в больших системах часто есть задачи, которые требуют компилятора, например, обработка больших двоичных или строковых потоков(свои парсеры, генераторы и т.д.)
Среда разработки - одно дело когда ты без среды разработки код в два раза медленнее пишешь для 10 исходников, другое дело - когда 500. В одном случае - теряешь часы, в другом - уже месяцы.
desktop-приложения - опять же на больших системах часто есть задачи, которые не вписываются в тонкого клиента (web-интерфейс) по тем или иным причинам, поэтому и нужна легкая возможность вынести часть функционала в desktop-приложение.
В заголовке оригинального вопроса у тебя написано про большие приложения, а не просто про сложную логику.
а большие приложения как раз и тянут за собой и компилируемость, и desktop-приложения, и среду разработки.
компилируемость нужна - потому что,
1)на большие системы очень высокая нагрузка, и ключевые точки хочется вылизать как можно лучше
2)в больших системах часто есть задачи, которые требуют компилятора, например, обработка больших двоичных или строковых потоков(свои парсеры, генераторы и т.д.)
Среда разработки - одно дело когда ты без среды разработки код в два раза медленнее пишешь для 10 исходников, другое дело - когда 500. В одном случае - теряешь часы, в другом - уже месяцы.
desktop-приложения - опять же на больших системах часто есть задачи, которые не вписываются в тонкого клиента (web-интерфейс) по тем или иным причинам, поэтому и нужна легкая возможность вынести часть функционала в desktop-приложение.
компилируемость нужна - потому что,подключи C.
1)на большие системы очень высокая нагрузка, и ключевые точки хочется вылизать как можно лучше
2)в больших системах часто есть задачи, которые требуют компилятора, например, обработка больших двоичных или строковых потоков(свои парсеры, генераторы)
desktop-приложенияредкость. Либо поддерживается (обычно либо подключается что-то еще: это же отдельное приложение к БД.
Среда разработки - одно дело когда ты без среды разработки 10 файлов кода медленее в два раза пишешь, другое дело - когда 500. В одном случае - теряешь часы, в другом - уже месяцы.Поэтому используются высокоуровневые языки. А среду разработки... Emacs? Или будем GUIшно запихивать input в form?
Для приложений с ЛОГИКОЙ, а не GUI, какая нужна среда кроме текстового редактора?
> подключи C.
ты уверен, что Ruby поддерживает бесшовное подключение C?
часто бывает, что потерях на швах больше, чем выгода от подключения более низкоуровневого языка.
> Для приложений с ЛОГИКОЙ, а не GUI, какая нужна среда кроме текстового редактора?
Debugger, Intellisence, Refactoring, визуальный редактор web/win-форм
ты уверен, что Ruby поддерживает бесшовное подключение C?
часто бывает, что потерях на швах больше, чем выгода от подключения более низкоуровневого языка.
> Для приложений с ЛОГИКОЙ, а не GUI, какая нужна среда кроме текстового редактора?
Debugger, Intellisence, Refactoring, визуальный редактор web/win-форм
> подключи C.
в реальном мире - это доп. деньги, т.к. требуется еще один разработчик, который уже знает C.
> Либо поддерживается (обычно либо подключается что-то еще: это же отдельное приложение к БД.
опять доп. деньги - т.к. придеться дублировать функционал.
в реальном мире - это доп. деньги, т.к. требуется еще один разработчик, который уже знает C.
> Либо поддерживается (обычно либо подключается что-то еще: это же отдельное приложение к БД.
опять доп. деньги - т.к. придеться дублировать функционал.
> подключи C
не уверен, что это надо
стандартные компоненты и так написаны на C или на другом достаточно хорошем языке: СУБД, всякие XML-приблуды и т.п.
сдаётся мне, что подобные приложения большую часть времени проводят внутри этих библиотек
не уверен, что это надо
стандартные компоненты и так написаны на C или на другом достаточно хорошем языке: СУБД, всякие XML-приблуды и т.п.
сдаётся мне, что подобные приложения большую часть времени проводят внутри этих библиотек
большие системы на голом языке писать - утопия.Привет из утопии!
в реальном мире у больших компаний, а также у правительств, полно лишних денег, потому и процветают всякие enterprise buzzword-compiant solutions
ну, бывают же счетные штуки.
тот же биллинг. хотя. думается мне, он все же на уровне БД реализован.
тот же биллинг. хотя. думается мне, он все же на уровне БД реализован.
сдаётся мне, что в биллинге считать не так уж много нужно
просто потому, что в мире не так уж много денег обращается, чтобы производительность современных процессоров экономить
потому и процветают всякие чудовищно неэффективные (по меркам прошлого века) технологии
просто потому, что в мире не так уж много денег обращается, чтобы производительность современных процессоров экономить
потому и процветают всякие чудовищно неэффективные (по меркам прошлого века) технологии
сдаётся мне, что подобные приложения большую часть времени проводят внутри этих библиотекСкажем PHP основное время тратит (в большинстве случаев) на работу с памятью, освобождение, перераспределение и т.п. Какой-нибудь массив не очень хитрой структуры из нескольких сотен тысяч небольших элементов может уничтожаться несколько секунд на хорошо оптимизированном сервере...
Ужас...
> Скажем PHP основное время тратит (в большинстве случаев)
На этом форуме основное время тратится сервером БД, например.
Насколько мне известно, это типичная ситуация.
Кстати, компиляторы (прозрачные) для PHP таки есть.
> на работу с памятью, освобождение, перераспределение и т.п.
Это всё функции стандартной библиотеки, и они написаны на C, не так ли?
На этом форуме основное время тратится сервером БД, например.
Насколько мне известно, это типичная ситуация.
Кстати, компиляторы (прозрачные) для PHP таки есть.
> на работу с памятью, освобождение, перераспределение и т.п.
Это всё функции стандартной библиотеки, и они написаны на C, не так ли?
> Скажем PHP основное время тратит (в большинстве случаев)Смотря в каких задачах... В некоторых случаях гоняются большие объёмы данных,
На этом форуме основное время тратится сервером БД, например.
Насколько мне известно, это типичная ситуация.
которые пользователь может модифицировать, без промежуточного сохранения в БД.
Возможно, это и достаточно экзотическая ситуация, но для меня - вполне реальная.
> на работу с памятью, освобождение, перераспределение и т.п.Проблема скорее в том, что php любит слишком активно то выделять какие-то куски памяти, то их освобождать... Если я сам управляю выделением памяти, как в C, то я могу это контролировать, а вот с php - сначала долго искать, в каком таком невинном месте идут жуткие тормоза, потом разбираться из-за чего, а потом думать, как это перебороть... Причём если бы дело было в алгоритмах, а не в такой банальщине... Поэтому я и согласен, что для проектов, оперирующих большими с сложными данными php не пригоден, хотя сам пишу на нём, в том числе подобные проекты...
Это всё функции стандартной библиотеки, и они написаны на C, не так ли?
> В некоторых случаях гоняются большие объёмы данных,
> которые пользователь может модифицировать, без промежуточного
> сохранения в БД.
Ты инфраструктуру для этого писал сам?
Если да, то это утопия, по словам .
Если нет, то использовалась стандартная библиотека, которая должна быть уже оптимизирована.
> Проблема скорее в том, что php любит слишком активно то выделять какие-то куски памяти, то их освобождать...
Может быть, но с вопросом компилируемости это никак не связано, а связано с качеством рантайма.
> которые пользователь может модифицировать, без промежуточного
> сохранения в БД.
Ты инфраструктуру для этого писал сам?
Если да, то это утопия, по словам .
Если нет, то использовалась стандартная библиотека, которая должна быть уже оптимизирована.
> Проблема скорее в том, что php любит слишком активно то выделять какие-то куски памяти, то их освобождать...
Может быть, но с вопросом компилируемости это никак не связано, а связано с качеством рантайма.
Если да, то это утопия, по словам .Что делать - жизнь тяжёлая... А кому сейчас легко?
> Проблема скорее в том, что php любит слишком активно то выделять какие-то куски памяти, то их освобождать...Да, согласен - это скорее не проблема языка, а проблема интерпретаторов/компиляторов и т.п. Но мне, как разработчику на php от этого не легче...
Может быть, но с вопросом компилируемости это никак не связано, а связано с качеством рантайма.
:Java - компилируемый язык или нет? А ведь большие системы именно на Java сейчас в основном пишутся...
скомпилируемость нужна - потому что,
1)на большие системы очень высокая нагрузка, и ключевые точки хочется вылизать как можно лучше
2)в больших системах часто есть задачи, которые требуют компилятора, например, обработка больших двоичных или строковых потоков(свои парсеры, генераторы и т.д.)
Perl, Python и Ruby давно уже не интерпретируются и от Java отличаются в основном качеством JIT-компиляторов.
В каких технологиях пишутся web-интерфейсы (и сервисы?) с серьезной логикой?На клиенте ECMAScript, на сервере J2EE для поддержки веб-интерфейса, а для серьёзной логики движок BPM. Ну и за всем этим естественно стоит СУБД.
на сервере J2EE для поддержки веб-интерфейсасобственно, это меня удивляет.
если говорить о скорости, то Java достаточно тормозит. Всё равно придется C использовать, если скорость критична.
если об удобстве разработки - ей далеко до скриптовых языков. И тот же Jython компилируется в java байт-код.
она достаточно универсальна, поэтому не очень удобна. имхо конечно.
Т.е. берем на сервере:
frontend - Perl-Python-Ruby
backend - C/C++ (если надо).
У Java есть преимущества (кроме "раскрученности") перед таким подходом?
Тебе показалось
Вообще впервые такую комбинацию букв слышу -
Джава компилируется.
Что значит тормозит. Там как таковая скорость мало кого интересует, важна маштабируемость. А это уже в первую очередь зависит от архитектуры решения самой задачи, на что влияет используемая платформа (в смысле на "плохой" платформе сложнее сделать "правильное" решение). Потом всегда можно поставить рядом второй веб-сервер.
Что значит тормозит. Там как таковая скорость мало кого интересует, важна маштабируемость. А это уже в первую очередь зависит от архитектуры решения самой задачи, на что влияет используемая платформа (в смысле на "плохой" платформе сложнее сделать "правильное" решение). Потом всегда можно поставить рядом второй веб-сервер.
Джава компилируется.уже было. и обсудили.
Там как таковая скорость мало кого интересует, важна маштабируемость. А это уже в первую очередь зависит от архитектуры решения самой задачи, на что влияет используемая платформаВот я и говорю, что скриптовые языки гораздо удобней. Они высокоуровневые (если считаете Java высокоуровневым, то Python будет сверхвысокоуровневым
). Разработка, сопровождение, изменение кода и архитектура системы лучше выглядит именно на скриптовых языках.Джава компилируется. Что значит тормозит. Там как таковая скорость мало кого интересует, важна маштабируемость. А это уже в первую очередь зависит от архитектуры решения самой задачи, на что влияет используемая платформа (в смысле на "плохой" платформе сложнее сделать "правильное" решение). Потом всегда можно поставить рядом второй веб-сервер.Буду цитировать подчеркнутое.
А вот , кстати в первой компании использовалась джава.
Ну, так я и говорю, что чистая скорость, типа Java vs ASM, рассматривать не имеет смысла. А маштабируемость зависит от архитектуры конкретного решения. А в случае веб программирования имеено маштабируемость будет основным показателем.
А я уже практически из первой компании
Там, где достаточно пары фронтэндов на Линуксе (httpd+tomcat будет крутиться вебсфера как минимум на 6 серверах под AIX. Просто потому что заказчик так хочет.
Там, где достаточно пары фронтэндов на Линуксе (httpd+tomcat будет крутиться вебсфера как минимум на 6 серверах под AIX. Просто потому что заказчик так хочет.
Язык по сути мало что решает. Важна вся платформа: движок, билиотеки, тулы, язык(и). В случае богатых на синтаксис языков, есть опасность что будут выезжать за счет языка, а остальные аспекты платформы пострадают (пример, пхп -- слабый движок, вытягивают язык и библиотеки, при этом очень легко писать "плохо", asp.net -- от языка мало требуется, не думаю, что более богатый скриптовый язык даст что-то большее, чем C#).
Ты меня не понял. Первая контора написала масштабируемый продукт на джава. Он умел распараллеливаться по N фронтендов. Это круто, т.к. в случае чего компания просто добавляла машины в кластер. Однако, производительность продукта была такова, что для такого чтобы "расмасштабироваться" до скажем 10 тясяч клиентов ей пришлось бы иметь тысячу машин.
Язык по сути мало что решаетСкорость, качество и стоимость разработки. Легкость сопровождения, модифицирования. Нет?
Остальное вообще не понял.
Я говорю, что язык -- это только один аспект, который влияет на все то, что ты перечислил.
кстати в первой компании использовалась джава.А во второй?
mod_perl + XS?
> А во второй?
mod_perl, но в самом конце. До него еще есть акселераторы и много других собственных наработок.
mod_perl, но в самом конце. До него еще есть акселераторы и много других собственных наработок.
Т.е. берем на сервере:Кхе. Извини, конешно, ты видел хоть одну большую прикладную серверную систему написанную на С?
frontend - Perl-Python-Ruby
backend - C/C++ (если надо).
У Java есть преимущества (кроме "раскрученности") перед таким подходом?
Требования к быстродействию надо в первую очередь рассматривать с точки зрения потенциальных bottlenecks. Написав систему на ассемблере, ты оптимизируешь только CPU.
Хм.
Извини, конешно, ты видел хоть одну большую прикладную серверную систему написанную на С?Если я правильно понял 'a, то "слышал".
Оставить комментарий
pilot
Вопрос такой:В каких технологиях пишутся web-интерфейсы (и сервисы?) с серьезной логикой?
Т.е. что находится на сервере?
Apache+СУБД и т.п...
язык? framework?
ЗЫ: понятно что не PHP, но что? Perl, Python, Ruby, etc?
Поделитесь мнением