Alex, wäre es möglich den MT4 so aufzubohren, dass man "aus dem Chart" heraus handel könnte?

 

Ich stelle mir das etwa so vor:

 

1. Es gibt eine *.ini (oder etwas Vergleichbares) in der ich meine Settings festlege -z.B. die auszuführende Stückzahl

2. Dann gibt es eine "Ampel" - in der rudimentärsten Stufe wären das 2 Buttons für

OPEN SELL (rot) = Verkaufe zum Marktkurs

OPEN LONG (grün) = Kaufe zum Marktkurs

 

Wie das Schliessen funktionieren könnte, dessen bin ich mir noch nicht sicher. Da ich sehr oft mehrere Positionen in verschiedenen Richtungen offen habe, will ich die nicht alle per Panic Button liquidieren.

 

Deshalb ist die Frage genereller Natur. Was denkst du, ginge das leidige 3-Step System auf einen Schritt abzukürzen?

@all

@Krümel Mit welcher Programmiersprache wäre MQL4 am ehesten vergleichbar?

Irgendwie bissl wie C, aber mit mehr Einschränkungen, da man so nette Konzepte wie Pointer und Strukturen nicht hat (was aber vielleicht sogar besser ist, da man doch recht fiese Sachen damit machen kann , allerdings muss man auch recht tief in die Materie eintauchen, denn man kann leider auch viel falsch machen).

 

C++ ist es schon mal gleich gar nicht (wie ich anfangs beim ersten Blick vermutet/erhofft hatte), da man da zumindest Objektorientierung erwarten würde. Das ganze "moderne" Zeug wie Java, C# scheidet auch aus aus dem selben Grund.

das ändert sich aber mit der neuen Version 5

dann kommt MQL5 sehr dem C++ nahe... :)

C++ ist es schon mal gleich gar nicht

 

 

Was ist dann davon zu halten?

 

http://Meta-**der.de/metatrader-seminare.htm

das ändert sich aber mit der neuen Version 5

dann kommt MQL5 sehr dem C++ nahe... :)

Vermute ich auch. Ich denke, am Anfang wollten sie nur ne einfache Programmiersprache, die nicht so kompliziert ist wie C (daher die Vereinfachung mit dem string-Datentyp und das Weglassen der Pointer, die ja auch nicht zwingend für die Problem-Domäne nötig sind, und nur unangenehm auffallen, wenn man alte Windows-Dlls einbindet). Dass das mit dem Metatrader so gut läuft, haben die Entwickler anfangs nicht gedacht, denke ich mal. Und jetzt rüsten sie halt nach.

Was ist dann davon zu halten?

 

http://Meta-**der.de/metatrader-seminare.htm

Hmm, urteile selbst, wie seriös die Seite ist : http://www.tom-next.com/community/meta-traderde-t27493.html&hl=meta-trader

Ich verstehe nur die Hälfte von all dem, trotzdem verfolge ich die Entwicklungen mit großem Interesse. Danke für die Erläuterung.

Was ist dann davon zu halten?

 

 

Hmm, urteile selbst, wie seriös die Seite ist

 

Bedeutet das, selbst diese Beschreibung wäre falsch? Die hatte ich überhaupt nicht in Frage gestellt, da mir beim Lesen keinerlei Zweifel an der Korrektheit der dargestellten Informationen gekommen sind.

 

Abgesehen davon glaube ich nicht, dass man ohne jegliche Vorkenntnisse an einem Wochenende Programmieren lernen kann.

Nicht in dem Umfang, um selbst Handelssysteme zu entwickeln, die später im Derivatehandel fehlerfrei laufen.

 

Ich mag mir gar nicht erst vorstellen, wie Unkenntnis vom Produkt, fehlende Erfahrung im/ mit OTC Handel und fehlerhafter Programmierung zusammen für eine Mischung ergeben.

Bedeutet das, selbst diese Beschreibung wäre falsch? Die hatte ich überhaupt nicht in Frage gestellt, da mir beim Lesen keinerlei Zweifel an der Korrektheit der dargestellten Informationen gekommen sind.

Och, ich habe nur mittlerweile den Eindruck, Anbieter von Services jeglicher Art FÜR den Tradingbereich gibt es mehr bzw. sie verdienen besser damit als der "Endkunde".

Und bei der angegebenen Seite stören mich weiterführende Links wie www.tradenwiedieprofies.de (

Und um das Thema "Software testen" mach ich lieber nen Bogen, denn DAS ist das Hauptproblem bei der ganzen Hackerei.

Ich mache es gerne, aber nur 'gezielt' und in einem kleinen Team... (natürlich nicht Dutzende EA's).

Ich mache es gerne, aber nur 'gezielt' und in einem kleinen Team... (natürlich nicht Dutzende EA's).

 

Testen, so wie ich es meinte ( http://de.wikipedia.org/wiki/Softwaretest) != EAs "testen"/vergleichen und ist eine der ungeliebten Aufgaben (neben Dokumentation schreiben) von Programmierern. Ne Daumenregel sagt, das 20% Programmierung sind, 80% Testen und Dokumentation.

Problem in der Praxis: die meisten Programmierer sind (wie ich auch) Spielkinder und suchen sich nur die Fun-Parts raus. Getestet so wie es sein sollte, wird kaum/nie. In Firmen wie Microsoft gibt es riesige Abteilungen, die speziell für Qualitätssicherung usw. da sind, denn Testen liegt nicht in der "Natur" der Programmierers und muss eher reingeprügelt werden in die Leute (symbolisch). Manche sehen es auch ein, dass es nötig ist, nachdem mal gravierende Probleme deswegen entstanden sind:

 

Beispiel - Intel Pentium Divisionsfehler Im Spätsommer 1994 fand ein amerikanischer Professor beim Intel Pentium Prozessor einen Divisionsfehler. Beim Chip-Hersteller Intel war der Fehler bereits seit Mitte des Jahres bekannt – das Problem wurde heruntergespielt und als unwichtig beurteilt. Nach Protest-Publikationen imInternet am 30. Oktober 1994 verbreitete sich die Nachricht wie eine Lawine über mehrereNewsgroups hinweg, bis sie zu den Massenmedien im November 1994 fand. Als Stellungnahme kam von Intel, dass man ihnen beweisen müsse, dass der Fehler relevant sei und man nur dannzum Austausch bereit sei. IBM als einer der Kunden von Intel startete daraufhin interne Tests und kam auf das Resultat, dass der Fehler durchschnittlich alle 24 Tage auftreten könnte, im Gegensatz zur Behauptung von Intel: „einmal in 27000 Jahren“. Am 24. Dezember 1994 stellte IBM einen Austauschplan auf und es wurde versichert, dass keine dieser fehlerhaften Chips bei IBM mehreingebaut wurden. Die Folge war, dass die Aktien von Intel um mehrere Prozentpunkte fielen, undder Handel kurzfristig ausgesetzt wurde. Eine Entschuldigung von Intel war die Folge und es wurde ein kostenloser Austausch „auf Wunsch“ angeboten, um die Kunden zu beruhigen. Der Verlust betrug ungefähr „nur“ 400 Millionen Dollar, da viele vom Angebot nicht Gebrauchmachten. In weiterer Folge wurde am Image gearbeitet, und neuen Fehlereinmeldungen kam man mit Kommunikation und Kooperation entgegen anstatt die Meldungen zu ignorieren

 

siehe HIER

 

Ich selbst habe auch eine (naturgegebene) Abneigung gegens systematische Testen, da es recht aufwendig ist, unspannend bis zum Abwinken und auch keine sichtbaren Erfolge produziert (lediglich Vertrauen in die selbstgeschriebenen Programme wächst etwas, aber ne andere Regel sagt ja auch, dass man selbst durch die aufwendigsten Tests nie alle Fehler findet).

 

Da ich auch ausreichend andere Programmierer/Informatiker kenne und weiß wie die drauf sind (und darunter sind einige, die schon zumindest das Wissen über Softwaretests haben und auch etwas Einsicht über die Notwendigkeit zu testen) und SELBST DIE testen in der Praxis kaum....was soll ich da bei EAs vermuten, die in der Regel von Hobby-Programmierern oder Spielkindern geschrieben wurden ? 80% ungetestete EAs ist als Zahl wahrscheinlich noch zu wenig.

 

Problem sind ja auch nicht die Fehler, die zu Programmabstürzen führen (findet man selbst sehr schnell und nimmt sie natürlich raus, wenn man kann), sondern subtile Fehler wie der obige Divisionsfehler im Intel-Prozessor, der nur alle 24 Tage (im Schnitt) einmal beim Kunden auftaucht.

 

Von daher warne ich an dieser Stelle vor dem Einsatz von mir geschriebenen Codes, den ich hier poste, denn ich teste quick-hacks/Spaßprogramme ebenfalls nicht. Aber EAs, die ich im Livekonto laufen ließe mit echtem Geld... da würde ich definitiv über meinen Schatten springen und diese bis zum Exzess TESTEN, denn ich hab schon die fiesesten Fehler in der Praxis gesehen, da kommt man als Normal-User nicht drauf, dass es sowas überhaupt gibt.

Problem in der Praxis: die meisten Programmierer sind (wie ich auch) Spielkinder und suchen sich nur die Fun-Parts raus. Getestet so wie es sein sollte, wird kaum/nie. In Firmen wie Microsoft gibt es riesige Abteilungen, die speziell für Qualitätssicherung usw. da sind, denn Testen liegt nicht in der "Natur" der Programmierers und muss eher reingeprügelt werden in die Leute (symbolisch). Manche sehen es auch ein, dass es nötig ist, nachdem mal gravierende Probleme deswegen entstanden sind:

 

Krümel bringt es auf den Punkt.

 

Das was wir hier machen, hat nur Ansatzweise etwas mit Softwaretesten im professionellen Sinne zu tun.

Ich war in mehreren Projekten beteiligt, in denen verschiedene (auch Tradingsysteme/ Front- und Backend) Applikationen Tests unterzogen wurden. Das ist ein Knochenjob und kostet richtig Geld, wenn das Team etwas übersieht.

Bedauerlicherweise haben meistens die Marketingabteilungen das Sagen und legen die Termine für den Launch fest. Das ist dann auch oft der Grund dafür, warum man von Bananenware spricht: Software reift beim Kunden.

Ich mache es gerne, aber nur 'gezielt' und in einem kleinen Team... (natürlich nicht Dutzende EA's).

 

 

Da du das Thema jetzt bereits mehrfach angesprochen hast, möchte ich noch einmal kurz darauf eingehen.

 

Ecart, wir sind kein Entwicklerforum, was passiert, passiert weil die Leute Spass dran haben oder weil gezielt Support gegeben wird.

Bedingungen stellen ist aus meiner Sicht nicht erforderlich. Wer sich einbringen will, bringt sich ein, wer nicht der nicht.