Urgence au MICEX RTS. Un robot de trading frénétique - page 7
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Qu'est-ce qui (concernant les opérations commerciales) ne peut pas être mis en œuvre sur celui-ci ?
Pour travailler avec des tableaux, il faut s'habituer à l'indexation.
ZS : Eh bien, si tout ce qui concerne les opérations commerciales peut être réalisé, alors à quel point est-ce nul ? J'ai un bon langage avec ses propres caractéristiques, ne voulez pas l'utiliser, écrivez vos dlls en C++ et vous serez heureux)
Pour travailler avec des tableaux, il faut s'habituer à l'indexation.
ZS : Eh bien, si tout ce qui concerne les opérations commerciales peut être réalisé, alors à quel point est-ce nul ? Si vous ne voulez pas l'utiliser, écrivez vos dlls en C++ et vous serez heureux).
Java et C# sont bien meilleurs.
On ne peut pas discuter des goûts, on aime ce qu'on aime.
La vitesse de développement en C# et Java est plusieurs fois supérieure.
Lalisibilité du code est plusieurs fois plus rapide.
Le code est plusieurs fois plus fiable.
Ça me fait grimacer quand je dois écrire en C++. Mais maintenant je passe à une solution alternative, en utilisant les dlls C#.
Ce n'est pas une discussion sur les goûts, c'est une déclaration.
Les vitesses de développement en C# et Java sont plusieurs fois plus rapides.
Lalisibilité du code est plusieurs fois plus rapide.
Le code est plusieurs fois plus fiable.
Ça me fait grimacer quand je dois écrire en C++. Mais maintenant je passe à une solution alternative, utiliser les dlls C#.
La vitesse du code est plusieurs fois plus lente. Et ce qui est plus élevé est discutable.
http://www.linux.org.ru/forum/development/4147618
http://www.opennet.ru/opennews/art.shtml?num=31114
http://shootout.alioth.debian.org/u64q/benchmark.php?test=nbody&lang=all
Pour travailler avec des tableaux, il faut s'habituer à l'indexation.
SZY : Eh bien, si tout ce qui concerne les opérations commerciales peut être réalisé, alors à quel point est-ce nul ? Si vous ne voulez pas l'utiliser, écrivez vos dlls en C++ et vous serez heureux).
Eh bien, vous pouvez appeler tout type de langage complet de Turing un langage normal de cette façon. Même une sorte d'encéphalogramme. =)
J'ai essayé de m'y habituer. Mais quand on voit avec quelle facilité et quelle commodité on peut le faire dans d'autres langues, on s'en rend compte. Quoi qu'il en soit, maintenant j'en utilise le minimum et je suis heureux. Et même sans DLL. Une béquille à travers les dossiers, oui, mais c'est ma propre béquille. =)
Si nous rêvons, nous aimerions avoir un terminal de trading comme celui-ci http://wiki.freeswitch.org/wiki/Languages_for_Call_Control. Il dispose d'une API en 8 langues - choisissez votre préférée (plutôt qu'un oiseau "avec ses propres caractéristiques") et travaillez. Ou vous pouvez brancher votre propre langue 9. Ce qui est également possible !
La vitesse du code est plusieurs fois plus lente, et ce qui est supérieur est en question.
Ne vous battez pas, les Finlandais sexy.
Il ressort clairement de cette discussion que chacun d'entre vous souhaite une sorte de langage 1. favori et bien étudié 2. suffisamment courant dans la nature, et non pas "oiseux" pour une génération d'un seul terminal commercial. Mais un billet de cinq dollars est arrivé et a apporté un nouveau langage des oiseaux. =)
Ne vous battez pas, les Finlandais sexy.
Il ressort clairement de cette discussion que chacun d'entre vous souhaite une sorte de langage 1. favori et bien étudié 2. suffisamment courant dans la nature, et non pas "oiseux" pour une génération d'un seul terminal commercial. Mais un billet de cinq dollars est arrivé et a apporté un nouveau langage des oiseaux. =)
Facilité d'écriture de programmes dans un langage ou un autre, bugs potentiels, etc. - C'est une chose subjective et cela dépend du professionnalisme du programmeur, vous pouvez argumenter jusqu'à ce que vous ayez la diarrhée. Personnellement, j'aime MQL5, j'en suis fou.
Mais la vitesse d'exécution du code est un élément indiscutable - c'est une caractéristique objective, et C# et Java ne font pas partie des leaders dans ce domaine.
Pour travailler avec des tableaux, il faut s'habituer à l'indexation.
SZY : Eh bien, si vous pouvez mettre en œuvre tout ce qui concerne les opérations commerciales, alors à quel point est-ce nul ? Je ne dis pas que ce n'est pas un mauvais langage, utilisez simplement C + + dlls et tout ira bien).
Je suis d'accord avec Sank.
Pour parler de la misère du langage, il suffit de répondre à deux questions :
1. Quel logiciel est écrit dans ce langage pour une tâche réelle ?
2. Quelles parties de ce logiciel étaient difficiles ou impossibles à mettre en œuvre dans ce langage ?
Si la réponse à la question 1 est "il n'a pas été écrit" ou "il est en train d'être écrit", alors tous les arguments concernant la question 2 n'ont aucun sens et ne sont que du charabia.
Personnellement, j'ai un conseiller expert à très long terme, qui est écrit en mcl4 :
- il fonctionne en mode entièrement automatique
- il fonctionne de manière rentable
- ouvre et maintient jusqu'à 100 ordres par jour et par symbole (pas un Pips, moyen terme)
- un seul et même Expert Advisor fonctionne simultanément avec 2 symboles (auparavant il fonctionnait avec 4)
- en plus de la maintenance des opérations commerciales - calcule et affiche rapidement certaines informations statistiques et de reporting sur le graphique
- le commerce est réel et le montant n'est pas de 100 $.
Et pendant tout le temps qu'il a duré :
- rien n'a été trouvé pour suggérer que le langage MQL4 est pauvre ou limité (pour cette classe de tâches)
- rien n'a été trouvé pour suggérer une vitesse insuffisante de traitement des données (pour cette classe de problème)