Выбор языка(ов) для разработки

Под все пункты подходит CL

тут не давно гтк портировали на веб... :-/

имхо java + gwt http://code.google.com/intl/en/webtoolkit/

Не флейма ради: на С. (а вообще - на любом языке - все равно в итоге у вас получится CGI, который и будет обеспечивать доступ к функционалу - а GUI будет реализоваться в браузере).

> все равно в итоге у вас получится CGI

Хм, все дороги ведут к CGI? Интересно, почему?

Java, Python, Mono(C#)

>Под все пункты подходит CL
Тролль детектед.

имхо java + gwt

Java - вариант. Вот только как-то слишком ругаются на скорость GUI на десктопе. Интерфейс изобилует графикой, эффектами. Прототип реализован на встроенном в приложение браузере (все устроило, кроме скорости работы с большим количеством объектов). Возможно, на десктопе придется использовать OpenGL.

Не флейма ради: на С. (а вообще - на любом языке - все равно в итоге у вас получится CGI, который и будет обеспечивать доступ к функционалу - а GUI будет реализоваться в браузере).

Есть что-то на почитать про использование С в такого рода приложении. и в связке с чем его использовать в вэбе?

Бери Java. А для для того, чтобы узнать какие именно инструменты использовать, создай отдельную тему и напиши там более подробно про специфику проекта.

> Java
уже написал про нее. вариант неплохой. но вопрос с ГУИ остается открытым

Python

А не загнется ли он под нагрузками?
Вариант нравится, хоть и не особо верю в большие проекты на языках с дин.типизацией.

Mono

Не задавит ли МС патентами в какой-то момент времени?
Пациент вообще жив? можно ли его использовать уже в крупных нагруженных решениях или пока в стадии развития? Сам язык, C#, нравится больше Java (по крайней мере тенденция развития). И здесь тоже вопрос с ГУИ открыт. WPF - тормознутое УГ (по крайней мере из того, что видел).
то, что гуй VS2010 написан на WPF не показатель - там ничего сложного нет..

так я не понял десктоп с сетью работает тоже? зачем тогда 2 апликухи, тонкий клиент чо

не то что бы это совсем сказки про тормаза gui java, но это больше про Swing, в SWT все значительно лучше. такое большое приложение как eclipse, на моем древненьком железе чувствует себя просто отлично.

> так я не понял десктоп с сетью работает тоже? зачем тогда 2 апликухи, тонкий клиент чо

Приложения имеют схожий функционал (как бы общее ядро +дополнения, которые возможны для вэба/десктопа).
Приложения умеют взаимодействовать (в пассивном режиме): экспорт, импорт, общий аккаунт, работа с одним и тем же проектом.

не то что бы это совсем сказки про тормаза gui java, но это больше про Swing, в SWT все значительно лучше. такое большое приложение как eclipse, на моем древненьком железе чувствует себя просто отлично.

У меня сейчас 6-ядерный Феном 2, 4Гб ОЗУ, да, Eclipse работает нормально, но ГУИ у него-то не назовешь сложным. требования к моему ГУИ сопоставимы не формочками на делфи, а с сайтом (по сложности элементов). Поэтому необходима гибкость фреймворка, на котором будет реализован ГУИ

>> Java - вариант. Вот только как-то слишком ругаются на скорость GUI на десктопе. Интерфейс изобилует графикой, эффектами. Прототип реализован на встроенном в приложение браузере (все устроило, кроме скорости работы с большим количеством объектов). Возможно, на десктопе придется использовать OpenGL.

Посмотри на Vuze, TuxGuitar, Lotus Symphony, SweetHome3d и тогда у тебя сложится полная картина о джаве на десктопе.

Под все пункты подходит CL

Тролль детектед.

То есть ты не рассматриваешь CL в качестве варианта, потому что это лисп? В сабже совершенно нет условий, которые мешают выбрать этот язык, поэтому его и предложил, ведь это известный факт: если нет причин не использовать лисп, то глупо его не использовать.

Есть что-то на почитать про использование С в такого рода приложении. и в связке с чем его использовать в вэбе?

Да ничем особым от других видов CGI это не отличается. Пишете себе программку, передачу данных реализуете, к примеру, через POST-запросы.

Просто я, кроме С, никаких языков, к стыду своему, почти и не знаю. Вот и делаю весь server-side на сях, а client-side - на html+javascript. Работает - и ладно. А для ускорения можно fastCGI прикрутить.

Хм, все дороги ведут к CGI? Интересно, почему?

Потому что это просто. Еще вариант - пыхпых (а из него запускаете серверные приложения). Но для меня пыхпых - темный лес.

А если ни то, ни другое - придется вам городить свой собственный сервер, ломать голову над клиентским приложением - в общем, заниматься лишней работой, когда уже есть уйма браузеров для клиента и всякие апачи/нджинксы и т.п. для сервера.

http://www.webtoolkit.eu/wt - C++, MVC, пишется и отлаживается тяжело, но производителен (относительно)

> То есть ты не рассматриваешь CL в качестве варианта
Недавно смотрел видео лекций (которые по SICP) в МИТе 198х год.
В общем, да, не рассматриваю я его, как вариант. Как минимум потому, что: стоимость разработки, поддержка, кадры. не учитываем либы и плюшки, которых наверняка просто нет

Вот и делаю весь server-side на сях, а client-side - на html+javascript

Вариант рассматривается, но очень не нравится. Не хватает здесь прослойки на Языке, который для этого предназначен, для работы в вэбе. С, ИМХО - модуль для того самого Языка, который выполняет отдельную часть работы быстро. Но связывать все эти кусочки нужно на чем-то более удобном.
Вот, собственно, и в поисках альтернатив..

Не хватает здесь прослойки на Языке, который для этого предназначен, для работы в вэбе

server-side Javascript?

Ну, не знаю, как вам, а мне С кажется очень даже удобным для разработки веб-приложений. Тем более, что так можно почти любую консольную утилиту «легким движением руки» модифицировать для работы с веб.

> server-side Javascript?
нет, конечно же. я про Питон, Руби и т.д. На них программируется логика работы, контроллеры, работа с Видом, а расчеты выносятся в Си модули.

http://www.webtoolkit.eu/wt - C++, MVC, пишется и отлаживается тяжело, но производителен (относительно)

Как раз смотрел на этот вариант. но слишком много вопросов. это может сгодиться для небольшого проекта. но в какой-то момент туда придется добавлять mpi?
И немного не понял с версткой. если что-то будет не кроссбраузерно, я это уже никак не смогу поменять?

Если нужна кластеризация и она действительно будет, то джава для серверной части. Если кластеризация нужна, а на деле будет один ПеКа, то С++, С. Делаешь XMLRPC-костыль на сокетах. Далее - фронтэнд к этому чуду на Пайтоне, с использованием twisted, например, или чего ещё.
Веб - pyramid, pylons, django. Можно и минималистичное из микро-фреймворков, если функционала от «фронтэнда» требуется не много.
Прикладное - идеал вообще, можно хоть что юзать.

Но задача странноватая при том, что есть предложение сделать несколько версий ядра(хотя если машинок овер дофига...).

Wt это скорее просто HTML-фреймворк на С++.

почему бы тебе не сделать одно приложение и не запускать его в браузере (хоть без контролов, например) и на десктопе? даже стартуя локальный сервер, может быть ?

Ты забыл:
(((((+)
))+-('=
3<-))))
Ща тебя лисперы покусают.

на данном этапе требуется только очень навороченный ГУИ, нагрузка большого кол-ва посещений. но на втором этапе добавляется большая нагрузка на железо (расчеты), так что кластер там появится в какой-то момент.

Но задача странноватая при том, что есть предложение сделать несколько версий ядра(хотя если машинок овер дофига...).

это про функциональное ядро. и вопрос стоял: одно и то же по функциональности ядро написать 2 раза на разных языках (со всеми последствиями) или 1 раз на одном языке и использовать в обоих приложениях

Я в домике и мне не страшен серый лиспер!

Как минимум потому, что: стоимость разработки, поддержка, кадры. не учитываем либы и плюшки, которых наверняка просто нет

Тогда java, тут даже думать и спрашивать не надо.

Тогда можно написать ядро на сях, гуй соответственно на qt, а джаву присобачить через jni.

> (((((+)
Мне интереснее было бы поработать на лиспе, но я не вижу аргументов за конкретно в этой задаче.

почему бы тебе не сделать одно приложение и не запускать его в браузере (хоть без контролов, например) и на десктопе? даже стартуя локальный сервер, может быть ?

1. десктоп приложение будет еще более нагружено в ГУИ части
2. нужен доступ к локальным данным пользователя, которые через браузер так просто не получить

Тогда сама архитектура Клиент-Сервер(хотя может быть и очередь...) как-бы шепчет.
Ядро для расчётов пусть будет на джаве, ибо потом она окажется выгоднее остальных языков за счёт производительности на большом кластере.
Функциональное ядро... вот здесь трудно сказать что делать, ибо не понятно что именно нужно от него.
Если просто нужно было бы обрабатывать данные из бд, которые оставило основное ядро и добавлять/удалять задания, например, то это даже не ядро, а просто набор моделей для БД. Их достаточно просто делать везде.
Конечно, в прикладном ПО сложнее из-за того, что ORM преимущественно для веба созданы, но на пайтоне таких проблем нет. Для SQL - SQLAlchemy, для mongodb - MongoKit.
Вообще продумай как будет сделано само управление: через очередь или поток(сокеты). От этого уже будет проще плясать.

> Вообще продумай как будет сделано само управление: через очередь или поток(сокеты). От этого уже будет проще плясать.
Приложения работают параллельно (это одно и то же приложение). к примеру, как office и office 360 (т.е. одно и то же, только на десктопе есть определенные преимущества, и наоборот).

По поводу сложности ГУИ
сопоставимо с http://www.fiberdownload.com/Screenshots/Microsoft-Expression-Studio/19553
нагруженность именно холста по обработке кол-ва элементов (к сожалению, на этом скрине не видно того, что может быть)

кстати, конкретно эту программу смотрел - тупит ужасно.. WPF

По поводу сложности ГУИ сопоставимо с http://www.fiberdownload.com/Screenshots/Microsoft-Expression-Studio/19553

Решается комбинацией html, SVG и JavaScript. Ничего там сложного нет.

Просто это WPF.
На JS тоже будет тормозить ваше решение. Считайте это предсказанием.
Главное - прикладное ПО. Здесь вопрос сложный. Вам может хватить пайтона для всего, но если интерфейс будет очень сильно нагружен... не знаю.
Одно скажу точно: всё зависит от того, как напишешь. На C++ можно написать чтобы работало медленнее, чем на пайтоне. При этом это не из разряда «фантастики индусокода».
Одно и то же приложение? Распределённые вычисления? Вилродни, ты?

1. жаба сервером приложений

2. веб-часть (ту, что работает на сервере) также на жабе, чтобы коннектилась с сервером приложений

3. клиентскую часть (классическое приложение) на жабе. Слухи про тормознутость жабы в GUI сильно преувеличены. Автоматом получаешь кроссплатформенность

4. веб-клиент - да уже как бы и пофиг

> Решается комбинацией html, SVG и JavaScript. Ничего там сложного нет.
в вэбе все понятно. там вариантов особо нет.
а вот кроссплатформенное ГУИ десктоп приложение..

На JS тоже будет тормозить ваше решение

но это будет упираться в потолок всех вэб-технологий, а не в мои кривые руки.

Одно скажу точно: всё зависит от того, как напишешь.

мы ведь рассматриваем идеальный случай? ))


На данный момент есть прототип на С++. в связке Python + C++ какие минусы есть? какие технологии используют для распределения нагрузки между серверными мощностями (и конкретно для питона и плюсов)?

> 1. жаба сервером приложений

....

Как бы 2 варианта, в целом и остается:
1. Java
2. C++ + Python

а вот кроссплатформенное ГУИ десктоп приложение..

Что-то про десктоп я не углядел... Да и тема была насчет клиент-серверной архитектуры. Если хотите «чисто» десктопное, да еще и кроссплатформенное... Кажется, планы у вас наполеоновские :)

> Что-то про десктоп я не углядел... Да и тема была насчет клиент-серверной архитектуры. Если хотите «чисто» десктопное, да еще и кроссплатформенное... Кажется, планы у вас наполеоновские :)

Нет, немного не о том тема была. тема как раз про то, как делать приложение с одинаковым функциональным ядром, но для сервера и для кроссплатформенного десктопа.

Да, планы такие.

Кстати, по поводу шарпа написали только пару раз. неужели настолько там все плохо? ведь он круче развивается уже, чем джава.

тема как раз про то, как делать приложение с одинаковым функциональным ядром, но для сервера и для кроссплатформенного десктопа.

Сложную вы себе задачу поставили... Одно дело - сделать общее ядро для сервера и линуксового десктопа (по сути, это одна задача - сделать серверное ядро и клиентскую веб-морду). А другое - для кроссплатформенного...

Хотя, можно, конечно, написать общее ядро, реализующее нужный функционал, а все UI реализовать отдельно (т.е. графические локальные морды и прослойку между этим ядром и сервером для реализации сетевого интерфейса). Ядро можно писать хоть на кутях, хоть на яве (если тормоза не страшат),... Морды - на тех же кутях/gtk/openGL и т.п. Прослойки - C, питон, перл, etc.

Кстати, по поводу шарпа написали только пару раз. неужели настолько там все плохо? ведь он круче развивается уже, чем джава.

Его огороженность вас не смущает?

Сервер на жабе, гуй на C++/Qt. Веб морду на gwt можно. Взаимодействие между клиентом и сервером через REST/JSON

> Его огороженность вас не смущает?
Mono? MS поддерживает пока проект, насколько я знаю. Но не слышал ничего об успешном использовании.

Хотя, можно, конечно, написать общее ядро, реализующее нужный функционал

Одним из вариантов было написание MVP и к нему 2 View прикрутить.. Т.е. MP монолитное

> Сервер на жабе, гуй на C++/Qt. Веб морду на gwt можно. Взаимодействие между клиентом и сервером через REST/JSON

Ядро на чем писать-то? клиент не использует сервер для работы, у него продублирован функционал (может быть ограничен, но, в целом, тот же)

А так... Сложная ситуация. Я бы писал на жаве. А гуй на JavaFX попробовал бы.

хоть на яве (если тормоза не страшат)

Жаба на сервере не тормозит. Только памяти жрет много.

хоть на яве (если тормоза не страшат)

Жаба на сервере не тормозит. Только памяти жрет много.

Почему, исходя из обсуждения лучшим вариантом является Java, а реальные примеры никак не на яве написаны.
конечно, не совсем та ниша, но все же
http://www.insight-it.ru/masshtabiruemost/arkhitektura-youtube/
http://www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/

netscalar + python (Zope не может быть использован вместо netscalar, или совсем другое?)

ядро на С++ будет биндиться питоном, на десктопе Qt

или

все полностью на Java. JavaFx тормознутое УГ (у них даже мелкие демки на сайте тормозят жестко).

сервер на php, клиента на actionscript (flash) - не прогадаешь!

клиента на actionscript (flash)

И все, не использующие флеш, пролетят...

я так и не понял почему не тонкий клиент

Потому что в ТЗ такого не было.

> сервер на php, клиента на actionscript (flash) - не прогадаешь!
да пхп как-то просто неинтересно. особых выгод перед питоном нет, поэтому и причин его использования тоже нет. в то время, как питон больше нравится как язык
Флеш еще жив? похоронили ведь его с приходом HTML5+CSS3+OpenGL, нет?

В общем пока такие плюсы/минусы:


JAVA, SWT:
+ынтырпрайз
+искоробочность распределния нагрузки
+статическая типизация
+кроссплатформенность искоробки на десктопе
+все на одном языке
-медленный ГУИ на десктопе
-огромная махина

Python, Qt, C++:
+прототип уже есть на С++
+быстрый ГУИ на десктопе
+быстрая работа
++разные языки подразумевают более корректную архитектуру (в том числе связка с фронт-ендом)
-хз, как все это в кучу собрать на сервере
-хз с распределением нагрузки
-питон с динамической типизацией (большой проект тяжело будет сопровождать)


лень писать еще что-то.. в целом получается выбор, или сервер удобнее, или десктоп удобнее писать.