Обычно запихал всё в БД, и клиентом тягаешь и напольняешь, а тут понадобиться серверную часть писать. Понятно, что быстрей на С будет, но неизвестна толком платформа, куда занёсёт, да и с перекомпиляцией возиться не охота, так что неверно на скриптовых языках придётся. Что Perl, что Python всё равно при перевом проходе компилируются, но вот кто всё таки побыстрее будет? Или есть ещё варианты?

QUOTE (deadman @ Aug 11 2003, 10:25 ) Обычно запихал всё в БД, и клиентом тягаешь и напольняешь, а тут понадобиться серверную часть писать. Понятно, что быстрей на С будет, но неизвестна толком платформа, куда занёсёт, да и с перекомпиляцией возиться не охота, так что неверно на скриптовых языках придётся. Что Perl, что Python всё равно при перевом проходе компилируются, но вот кто всё таки побыстрее будет? Или есть ещё варианты?

---

можно извратиться с библиотекой реализующей интерфейс с ОС, а всю логику писать на c/c++

причём я уверен что вышеозначеные библиотеки для реализации интерфейсов с различными ОСями уже есть на соурсфордже, причём не в единственном экземпляре

а быстродействие нетипизированого языка уровня перла мне даже представить страшно, пускай даже с учётом компиляции

QUOTE (Tot @ Aug 11 2003, 11:29 ) можно извратиться с библиотекой реализующей интерфейс с ОС, а всю логику писать на c/c++

причём я уверен что вышеозначеные библиотеки для реализации интерфейсов с различными ОСями уже есть на соурсфордже, причём не в единственном экземпляре

а быстродействие нетипизированого языка уровня перла мне даже представить страшно, пускай даже с учётом компиляции

---

Согласен. А если совсем извратиться, то можно найти компилятор Java в машинный код, т.е. обычную программу.
И под винды и как примочка к gcc под Linux.

Угу, про джаву в машинных кодах я как то не подумал. Надо помозговать будет. Уж больно не хочется возвращаться к C от более человеческих языков :(

QUOTE (deadman @ Aug 11 2003, 11:25 ) но неизвестна толком платформа, куда занёсёт, да и с перекомпиляцией возиться не охота, так что неверно на скриптовых языках придётся. Что Perl, что Python всё равно при перевом проходе компилируются, но вот кто всё таки побыстрее будет? Или есть ещё варианты?

---

Первое место - у PHP и Perl.
Если загрузка будет в основном вычислительная, то Perl быстрее, примерно вдвое, чем PHP. Если связка с базой данных, то PHP выдаёт данные по mysql_query+mysql_fetch_* в 5..10 раз быстрее, чем Perl через DBI.

А в среднем - они довольно близки по скорости.

Потом с отставанием в несколько раз - Python.

Потом, с отставанием раз в 10 от PHP/Perl идёт Ruby.

Больше популярных переносимых скриптовых языков не знаю :)

А, вообще, если изучение нового языка трудности не составляет, то рекомендую посмотреть в сторону, скажем, OCaml. Скорость обычно не хуже, а часто и лучше, чем у лучших компиляторов C++, при этом язык может выступать в роли функционального, объектного, имеет всякие фишки типа сборки мусора, строгой типизации (жалко только, что не ленивый), реализован под массу платформ, может компилировать как в нативный код, так и в переносимый байткод (понятно, с падением эффективности) и т.п.

Э нет. PHP для серверной части эт ты зря. Программулина сложная будет, надо ООП будет использовать. С Perl-ом то трудности будут. Плоховато там сделано, не удобняк, с Python-ом попроще.
Чтобы Ruby использовали в Рассеи я ещё не видел, так что..
А языки новые, так это ещё вопрос, с кем работать будешь. Мне положим не сильно сложно язык новый разобрать, если в тонкости, или машиннозависимость не лезть, но кто ж в команде со мной тогда работать будет? Так что вопрос популярности сильно действует.

QUOTE (deadman @ Aug 11 2003, 12:41 ) Э нет. PHP для серверной части эт ты зря.

---

Ну... А что, кто-то на PHP делает и клиентскую часть? :D Все они работают на сервере. Впрочем, если речь идёт и демоне, то да, PHP подходит хуже.


QUOTE Программулина сложная будет, надо ООП будет использовать. С Perl-ом то трудности будут.

---

ИМХО, ООП на PHP немного правильнее, чем на Perl. Но Perl лучше подходит для демона.

QUOTE Плоховато там сделано, не удобняк, с Python-ом попроще.

---

Тем более, что есть такая фишка, как Zope.

QUOTE Так что вопрос популярности сильно действует.

---

Тогда - точно, PHP :D Популярнее его сейчас только C/C++ и Java. Perl, например, по количству проектов на sourceforge отстаёт почти вдвое.

Кроме того, новички нередко на Perl пишут просто безобразно...

А если нужно, чтобы как можно больше ошибок отлавливалось ещё на этапе компиляции, то сегодня лидер по этому параметру - Haskell :) И сервер web-приложений на нём какой-то есть... Но это - совсем туго для мозгов, извращённых императивным подходом (для моих, например :))

QUOTE (Balancer @ Aug 11 2003, 13:28 ) Ну... А что, кто-то на PHP делает и клиентскую часть? :D Все они работают на сервере. Впрочем, если речь идёт и демоне, то да, PHP подходит хуже.

---

В том то и дело, что цги скрип это просто, так и мыслим, а если нужно взаимодействие пользователей? Может я не совсем технологию прорубаю, но...
Чтобы вспомнить в пример...
Ну хотя бы www.combats.ru. Там же люди люди заходят, регистирируются, но внутренняя жизнь то идёт? Какой -то демон управляет взаимодействием тех бойцов, выдавая только сообщения клиентам?
Где то хранится и осчитывается взаимодействие? Ну не скриптом же с базой? или я что-то не совсем прорубаю...

QUOTE (deadman @ Aug 11 2003, 13:47 ) В том то и дело, что цги скрип это просто, так и мыслим, а если нужно взаимодействие пользователей? Может я не совсем технологию прорубаю, но...
Чтобы вспомнить в пример...
Ну хотя бы www.combats.ru. Там же люди люди заходят, регистирируются, но внутренняя жизнь то идёт? Какой -то демон управляет взаимодействием тех бойцов, выдавая только сообщения клиентам?
Где то хранится и осчитывается взаимодействие? Ну не скриптом же с базой? или я что-то не совсем прорубаю...

---

Ну, это как раз всё очень просто. Есть база данных (и не важно даже, SQL это или plain/text) и каждое обращение пользователя к серверу что-то из неё запрашивает, что-то в ней меняет...

Скажем, этот форум - чем не взаимодействие пользователей? А это чистый PHP+MySQL :) Или, к примеру, PHP-чат какой-нибудь - там даже онлайновое взаимодействие идёт.

Другое дело, что существует редкий класс задач, когда твой скрипт на сервере должен висеть резидентом и обрабатывать внешние события, не связанные с запросами или иной активностью пользователей. Вот тут, обычно, лучше подходит Perl. Хотя, возможно, это скорее дань традиции :)

QUOTE (Balancer @ Aug 11 2003, 14:06 ) Ну, это как раз всё очень просто. Есть база данных (и не важно даже, SQL это или plain/text) и каждое обращение пользователя к серверу что-то из неё запрашивает, что-то в ней меняет...

---

Один крендель вешает другому пендаль, в зависимости от параметро отвешивается дамаг. Расчёт прадлагаешь на jscript свалить?
И заводять временную таблицу для хранения боя? А если масса народу подвалила, это ж какая нагрузка на БД ляжет, если всё через таблицы.
Да и не хотелось бы на клинета jscript вешать, вон тот же www.combats.ru кроме как под эксплорер не работает.

QUOTE (deadman @ Aug 11 2003, 13:13 ) QUOTE (Balancer @ Aug 11 2003, 14:06 ) Ну, это как раз всё очень просто. Есть база данных (и не важно даже, SQL это или plain/text) и каждое обращение пользователя к серверу что-то из неё запрашивает, что-то в ней меняет...

---

Один крендель вешает другому пендаль, в зависимости от параметро отвешивается дамаг. Расчёт прадлагаешь на jscript свалить?
И заводять временную таблицу для хранения боя? А если масса народу подвалила, это ж какая нагрузка на БД ляжет, если всё через таблицы.
Да и не хотелось бы на клинета jscript вешать, вон тот же www.combats.ru кроме как под эксплорер не работает.

---

http://msdn.microsoft.com/library/default....vicesanchor.asp

2Tot
Меня не реализация сейчас уже волнует, меня волнует общая концепция таких приложение. Как оптимально их делать? Может вообще как надстройку над jabber забабахать можно, или на zope действительно созадть. Чем не хранилище? Объеты создавать и пусть взаимодействуют сами.

QUOTE (deadman @ Aug 11 2003, 14:13 ) Один крендель вешает другому пендаль, в зависимости от параметро отвешивается дамаг. Расчёт прадлагаешь на jscript свалить?

---

Нет. Смотри. В самой идеологии HTTP-протокола отсутствует понятие сессии. Т.е. ты можешь послать запрос с определёнными параметрами и получить ответ. Точка. Если тебе нужно динамеческое взаимодействие исключительно через браузер, не используя иных клиентов, то его можно получить или через Java (что сейчас не очень хорошо, т.к. MS по дефолту Яву уже не ставит и клиентам придётся её доустанавливать) или периодически генерить заросы (при компактной и оптимальной проработке - хоть каждую секунду, ни трафика ни загрузки большой это не даст)

QUOTE И заводять временную таблицу для хранения боя? А если масса народу подвалила, это ж какая нагрузка на БД ляжет, если всё через таблицы.

---

Понятие "масса" - относительно. У меня на форуме 200тыс. записей в MySQL, 240Мб база и выдача одной страницы, генерящая ~7..10запросов, нередко достаточно сложных, занимает 0.1..0.3 сек. Т.е. если нагрузка будет ~5 "больших" страниц в секунду (300 страниц в минуту, 18тыс. страниц в час - ИМХО, в России такое бывает только на крупных новостийных сайтах во времена глобальных катастроф типа 9-11), то это максимум, который потянет мой сервер. Более лёгких страниц можно выдать гораздо больше... Пиковая скорость отдачи данных скриптом у меня достигает десятков мегабайт в секунду. Раньше канал ляжет :)

Для "оперативных" данных можно очень эффективно использовать, например, механизм сессий в PHP.

QUOTE Да и не хотелось бы на клинета jscript вешать, вон тот же www.combats.ru кроме как под эксплорер не работает.

---

Просто криво написали, значит. JS есть под всеми популярными нынешними браузерами :)

Deadman, if I were you, I'd use Java Servlets.

1) Platform-independent(!!!);
2) Cgi functionality;
3) Inbuilt DB support from Java;
4) Client and server communication is easier to write because it's all in the same language (AND it's OOP);
5) Easy as all get out;
6) Handle cookies and/or sessions for you.

QUOTE (IceQueen @ Aug 11 2003, 16:20 ) Deadman, if I were you, I'd use Java Servlets.

---

Всё бы хорошо, но не слишком шустро, менее надёжно и труднее в отладке. Кстати, скорость разных решений на http://www.softerra.ru/net/20814/ можно сравнить.