Скачать MetaTrader 5

Вопрос к разработчикам. А почему бы не сделать клиент на Java. Зачем изобретать велосипед?

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Yury Reshetov
13491
Yury Reshetov  
Слухи про MQL5 уже распущены. Возникает естественный вопрос: а почему бы вместо того, чтобы изобретать велосипед, не сделать клиентскую часть MT на Java?

  1. Java язык С подобный
  2. Готовая реализация объектно-ориентированного программирования, а следовательно там будут и классы, события, обработчики исключительных ситуаций и прочие вкусности
  3. Советники можно было бы сделать в виде подгружаемых модулей, написанный на Java
  4. У Java богатые библиотеки готовых классов
  5. Меньше будет глюков в билдах, ведь за Java следит консорциум разработчиков, и глюки фиксят намного быстрее.
  6. Платформенная независимость. Многим, например, хотелось бы иметь торговый терминал под Linux.
  7. Меньше было бы проблем с обращениями к разработчикам по поводу того, что сделайте то или сделайте это. Я бы, например, основную часть того, чего мне не хватает в торговой терминале, давно бы уже сделал сам. Например, удаленное управление советниками. Или событие по формированию нового бара.
  8. Высокая скорость исполнения. JVM от Sun MicroSystems и IBM исполняют код гораздо быстрее, нежели если он был скомпилирован на C за счет JIT компиляции. Правда при этом запуск приложений длится дольше, поскольку перед ним весь Java перекомпилируется в код платформы на которой все будет исполняться.
  9. Меньше было бы головной боли у разработчиков насчет распределения памяти, а особенно ее утечки. В Java память выделяется автоматически, как только создана переменная или объект. Зато обратный процесс, т.е. освобождение неиспользуемой памяти уже выполняется так называемым мусорщиком по мере необходимости или в фоновом режиме. Т.е. если переменные или объекты не используются и на них нет ни одной ссылки, то мусорщик автоматом все подчистит
  10. Меньше проблем было бы с редактором советников и индикаторов. Например, я давно уже приспособил для MQL4 редактор JBuilder компании Borland. Ведь советники и индикаторы очень схожи с Java апплетами, т.е. имеют те же самые события init(), start() и deinit(). Алгоритмическая часть та же самая. Единственное различие лишь в том, что в Java переменные действительны в блоке, а в MQL в функции.
Могут возникнуть вопросы, относительно защиты программ, ведь Java очень запросто декомпилируется. Да в принципе и MQL тоже декомпилируется, насколько я убедился. Любой хакер скажет, что обход защиты - дело времени. Но обфускаторы для защиты кода от изучения в Java есть. Если необходимо будет защитить сам терминал от кражи интеллектуальной собственности другими разработчиками терминалов, то часть кода можно будет написать, например, на C и скомпилировать в native методы. Тогда появление такого кода в клиентской части конкурентов можно будет легко доказать, как кражу.
MetaQuotes
Админ
25430
Renat Fatkhullin  
Пункт 8 убивает все. Имея скорость практически (не нужно теоретических тестов от производителей) в десяток раз медленнее нативного кода (С++) и потребление ресурсов практически также в десяток раз больше С++ можно ставить крест на любом коммерческом проекте. Ибо он безбожно проиграет конкуренту, написанном на нативном коде. К тому же, речь идет о серьезных вычислительных задачах с огромным потреблением ресурсов даже с С++. Речь о практических вещах, а не теоретических рассуждениях.

Чтобы убить коммерческий проект, достаточно перейти на Яву или .NET. Лучше такой совет дать нашим конкурентам.
Yury Reshetov
13491
Yury Reshetov  
Renat:
Пункт 8 убивает все. Имея скорость практически (не нужно теоретических тестов от производителей) в десяток раз медленнее нативного кода (С++) и потребление ресурсов практически также в десяток раз больше С++ можно ставить крест на любом коммерческом проекте. Ибо он безбожно проиграет конкуренту, написанном на нативном коде. К тому же, речь идет о серьезных вычислительных задачах с огромным потреблением ресурсов даже с С++. Речь о практических вещах, а не теоретических рассуждениях.

Чтобы убить коммерческий проект, достаточно перейти на Яву или .NET. Лучше такой совет дать нашим конкурентам.
  1. Тесты были не от производителей, а независимыми. В принципе любой желающий может проверить - сие не столь сложно.
  2. На Java есть и коммерческие проекты и FreeWare. Здесь скорее вопрос в том, а стоит ли тратить силы и время на разработку и отладку: языка программирования , т.е. компилятора, редактора, отладчика и пр. хозяйства или взять готовый уже давно изобретенный велосипед (тем более, что давно уже пора переходить на ООП, а не топтаться на месте с алгоритмическими языками). (Не знаю, как другим, а мне например, уже порядком осточертели все эти глюки в новых билдах. Один глюк пофиксят, десяток новых насажают). Тем паче, что Java в отличие от .NET распространяется бесплатно, а посему расходов и для разработчиков и для пользователей быть не может.
  3. К тому же предлагается перевести на Java только клиентскую часть, т.е. торговый терминал, который достается трейдерам путем элементарного скачивания.
В принципе, что и и на чем разрабатывать - личное дело MQ. Наше дело предложить, а Ваше отказаться под тем или иным предлогом.
Alexandre
601
Alexandre  
<<Чтобы убить коммерческий проект, достаточно перейти на Яву или .NET.>>
++
"Чтобы убить любой проект, ... "
MetaQuotes
Админ
25430
Renat Fatkhullin  
Вот когда напишут на яве нечто хотя бы похожее на MS Word 6.0, тогда и можно будет говорить о практике, а не об теоретических рассуждениях. Правда это нечто получившееся уже никак не сможет ни с кем конкурировать. В любой зачетной характеристике программа на яве практически всегда проиграет нативной программе. Что и было доказано последними 10 годами попыток явы.

Пользователи-то выбирают за функционал, скорость, простоту и тд, а не за язык программирования.
Sceptic Philozoff
Модератор
17841
Sceptic Philozoff  
Юрий, а ты видел софтину от Доктора Дука (dukascopy.com) где-нибудь с год-полтора назад? Одной из причин, по которой я игрался с ней в общей сложности не более двух недель, а потом забросил, стала именно ее тормознутость. А реализована она как раз на Java. Может быть, за это время что-то поменялось, но тогда скорость ее выполнения была крайне низкой в сравнении с продуктом от MQ.
Alexey Lopatin
45671
Alexey Lopatin  
А зачем MQL переходить на ООП? Смысла в этом не видно.
Igor Kim
2739
Igor Kim  

Ваще, не представляю, как на яве можно было бы реализовать тестер с потиковым моделированием или визуальный режим тестирования. Этот был бы, наверно, какой-нить тихий ужас! Нет, мне не надо ни яву, ни .net, MQL4 вполне устраивает. Очень нравится возможность подключения внешних DLL.

Igor Malcev
2007
Igor Malcev  
На яве существуют терминалы например вот http://www.forex.com/ru/forex_support.html   желающие могут скачать и насладится  в полной мере тормозами и глюками этой платформы (особенно актуально для нашего "не очень скоростного интернета"). После него MetaTrader покажется идеалом :-)
Roman Kramar
742
Roman Kramar  

Ко всем негативным отзывам добавлю еще тот факт, что перевод клиента на яву повлек бы за собой убийственное требование к его пользователям: наличие установленной JVM. А это сразу куча проблем: добавление ее к дистрибутиву клиента утяжелит последний где-то на 25Мб; распространение клиента без JVM породит проблемы со скачиванием и установкой JVM по отдельности; усложнится процедура Live Update и т.д и т.п.

С таким же успехом можно было бы предложить перевести клиента с C++ на Smalltalk или Ruby - вот уж где есть разгуляться ООП; и библиотек тоже достаточно :)

Пишите свои вещи на Яве, никто вроде не мешает. Потом подключайте как внешнюю DLL и будет "счастье" :)

Кстати вот это утверждение:

Reshetov:
JVM от Sun MicroSystems и IBM исполняют код гораздо быстрее, нежели если он был скомпилирован на C за счет JIT компиляции

в корне неверно. Никакая JIT компиляция не может быть "гораздо быстрее" откомпилированного С/С++ кода. В лучшем (но очень маловероятном случае) такой код будет приближаться к производительности С/С++ кода. А косяки автоматической сборки "мусора" уж точно не следует выдавать за преимущества платформы. Для такой системы как MT прямое управление памятью настолько же важно, насколько и скорость обработки графической составляющей.
Пологовой Александр Юрьевич
118
Пологовой Александр Юрьевич  

А разве С++ это не ООП?
to KimIV: А чам так плох .NET?

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий