Вопрос к разработчикам. А почему бы не сделать клиент на Java. Зачем изобретать велосипед?
Чтобы убить коммерческий проект, достаточно перейти на Яву или .NET. Лучше такой совет дать нашим конкурентам.
Пункт 8 убивает все. Имея скорость практически (не нужно теоретических тестов от производителей) в десяток раз медленнее нативного кода (С++) и потребление ресурсов практически также в десяток раз больше С++ можно ставить крест на любом коммерческом проекте. Ибо он безбожно проиграет конкуренту, написанном на нативном коде. К тому же, речь идет о серьезных вычислительных задачах с огромным потреблением ресурсов даже с С++. Речь о практических вещах, а не теоретических рассуждениях.
Чтобы убить коммерческий проект, достаточно перейти на Яву или .NET. Лучше такой совет дать нашим конкурентам.
- Тесты были не от производителей, а независимыми. В принципе любой желающий может проверить - сие не столь сложно.
- На Java есть и коммерческие проекты и FreeWare. Здесь скорее вопрос
в том, а стоит ли тратить силы и время на разработку и отладку:
языка программирования , т.е. компилятора, редактора, отладчика
и пр. хозяйства или взять готовый уже давно изобретенный велосипед
(тем более, что давно уже пора переходить на ООП, а не топтаться
на месте с алгоритмическими языками). (Не знаю, как другим, а
мне например, уже порядком осточертели все эти глюки в новых
билдах. Один глюк пофиксят, десяток новых насажают). Тем паче,
что Java в отличие от .NET распространяется бесплатно, а посему
расходов и для разработчиков и для пользователей быть не может.
- К тому же предлагается перевести на Java только клиентскую часть, т.е. торговый терминал, который достается трейдерам путем элементарного скачивания.
Пользователи-то выбирают за функционал, скорость, простоту и тд, а не за язык программирования.
Ваще, не представляю, как на яве можно было бы реализовать тестер с потиковым моделированием или визуальный режим тестирования. Этот был бы, наверно, какой-нить тихий ужас! Нет, мне не надо ни яву, ни .net, MQL4 вполне устраивает. Очень нравится возможность подключения внешних DLL.
Ко всем негативным отзывам добавлю еще тот факт, что перевод
клиента на яву повлек бы за собой убийственное требование к
его пользователям: наличие установленной JVM. А это сразу куча
проблем: добавление ее к дистрибутиву клиента утяжелит последний
где-то на 25Мб; распространение клиента без JVM породит проблемы
со скачиванием и установкой JVM по отдельности; усложнится процедура
Live Update и т.д и т.п.
С таким же успехом можно было бы предложить перевести клиента
с C++ на Smalltalk или Ruby - вот уж где есть разгуляться ООП; и библиотек
тоже достаточно :)
Пишите свои вещи на Яве, никто вроде не мешает. Потом подключайте
как внешнюю DLL и будет "счастье" :)
Кстати вот это утверждение:
Reshetov:
JVM от Sun MicroSystems и IBM исполняют код гораздо быстрее, нежели если
он был скомпилирован на C за счет JIT компиляции
А разве С++ это не ООП?
to KimIV: А чам так плох .NET?
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
- Java язык С подобный
- Готовая реализация объектно-ориентированного программирования,
а следовательно там будут и классы, события, обработчики исключительных
ситуаций и прочие вкусности
- Советники можно было бы сделать в виде подгружаемых модулей,
написанный на Java
- У Java богатые библиотеки готовых классов
- Меньше будет глюков в билдах, ведь за Java следит консорциум разработчиков,
и глюки фиксят намного быстрее.
- Платформенная независимость. Многим, например, хотелось бы иметь
торговый терминал под Linux.
- Меньше было бы проблем с обращениями к разработчикам по поводу
того, что сделайте то или сделайте это. Я бы, например, основную
часть того, чего мне не хватает в торговой терминале, давно бы
уже сделал сам. Например, удаленное управление советниками.
Или событие по формированию нового бара.
- Высокая скорость исполнения. JVM от Sun MicroSystems и IBM исполняют код
гораздо быстрее, нежели если он был скомпилирован на C за счет
JIT компиляции. Правда при этом запуск приложений длится дольше,
поскольку перед ним весь Java перекомпилируется в код платформы
на которой все будет исполняться.
- Меньше было бы головной боли у разработчиков насчет распределения
памяти, а особенно ее утечки. В Java память выделяется автоматически,
как только создана переменная или объект. Зато обратный процесс,
т.е. освобождение неиспользуемой памяти уже выполняется так
называемым мусорщиком по мере необходимости или в фоновом режиме.
Т.е. если переменные или объекты не используются и на них нет
ни одной ссылки, то мусорщик автоматом все подчистит
- Меньше проблем было бы с редактором советников и индикаторов.
Например, я давно уже приспособил для MQL4 редактор JBuilder компании
Borland. Ведь советники и индикаторы очень схожи с Java апплетами,
т.е. имеют те же самые события init(), start() и deinit(). Алгоритмическая
часть та же самая. Единственное различие лишь в том, что в Java
переменные действительны в блоке, а в MQL в функции.
Могут возникнуть вопросы, относительно защиты программ, ведь Java очень запросто декомпилируется. Да в принципе и MQL тоже декомпилируется, насколько я убедился. Любой хакер скажет, что обход защиты - дело времени. Но обфускаторы для защиты кода от изучения в Java есть. Если необходимо будет защитить сам терминал от кражи интеллектуальной собственности другими разработчиками терминалов, то часть кода можно будет написать, например, на C и скомпилировать в native методы. Тогда появление такого кода в клиентской части конкурентов можно будет легко доказать, как кражу.