Welke heeft uw voorkeur: Metatrader (MQL) of cTrader (cAlgo)?
Page 1 of 632 12 LastLast
Results 1 to 10 of 13

Thread: Welke heeft uw voorkeur: Metatrader (MQL) of cTrader (cAlgo)?

  1. #1
    Ik ben gewoon benieuwd naar jullie mensen daar. Gebruikt iemand hier echt veel MetaTrader (om MQL te schrijven), maar slechts weinigen gebruiken cTrader (cAlgo)?

    Afgezien van de voordelen die de makelaar te bieden heeft, ben ik van mening dat MetaTrader niet het beste platform is om EA's te bouwen. MQL = C , ze gebruiken C als hun basiscode. Het staat op hun documentatiepagina:
    https://www.mql5.com/en/docs
    Terwijl cTrader (cAlgo) C# als basiscode gebruikt.

    Ik ben een fulltime technisch adviseur, applicatieontwikkelaar, beginnend webdesigner en ken de meeste recente technologie voor applicatieontwikkeling. Ik doe dit al meer dan 10 jaar en ontdekte dat C# en Java beide sterke concurrenten zijn. Beiden werden genoemd in de top 10 van meest populaire programmeertalen, samen met Javascript, Scala, Go, Phyton. Maar geen van hen is C . Naar mijn ervaring (na het schrijven van 3 EA's), is MQL gewoon moeilijk. Als uw logica zo simpel is als iets berekenen en vervolgens lopende orders of posities cre�ren op basis van de markt, is MQL net genoeg. Maar als je eenmaal op complexere idee�n ingaat, is MQL gewoon niet genoeg... sorry om te zeggen.


    Neem bijvoorbeeld een van mijn EA, Tunnel Martingale (TM). Als je mijn topic volgt (
    https://www.aforexa.com/trading-syst...ivots-win.html) in het commerci�le gedeelte, is het eigenlijk gebouwd met MQL. Omdat de logica eenvoudig is! Start willekeurig een marktpositie, plaats dan een lopende order in de tegenovergestelde richting, zodra de lopende order is bereikt/uitgevoerd, plaats dan een andere lopende order in de tegenovergestelde richting, enz..etc. Een strategie is maar een strategie, mislukt, de investering droog gezogen en dan weer terug naar de tekentafel.
    Naarmate idee�n om te verbeteren net iets verder komen, wordt het coderen met MQL alleen maar moeilijker. Een van de idee�n om te verbeteren is, in plaats van de Martingale-serie onbeperkt en voor onbepaalde tijd uit te voeren, kunnen we het tijdsbestek beperken tot alleen op een specifieke datum en tijd voor alleen een specifiek interval/duur. Nu is hier de vangst.
    De manier waarop C met datum en tijd omgaat, gebruikt momenteel het oude gegevenstype dat is gebaseerd op een geheel getal dat teken vertegenwoordigt die zijn berekend sinds 1 januari 1970! Dat is zoiets als prehistorisch spul. Dus nu begrijp ik dat als ik een specifieke datum en tijd van A naar B wil defini�ren, ik de vinkweergave van die datum moet weten.

    Dus als ik wil schrijven dat de TM begint op 31 maart 2020 12:00:00, moet ik 637212528000000000 schrijven in een parameter, variabele of een andere communicatiemethode tussen mezelf als gebruiker van de EA. Dat is het niet, DateTime-functies zijn zeer beperkt in MQL.

    Nu is een andere uitdaging dat ik een object voor de datums wil introduceren in de invoerparameter. Zowel MQL als cAlgo kunnen op geen enkele manier complexe invoerparameters defini�ren. Maar dat kan door een bestandsconfiguratie te introduceren, zoiets als JSON of XML. In MQL zijn er enkele regels nodig om een ??????bestand te lezen. U moet het concept van de aanwijzer begrijpen, u moet controleren of de bestandshandle gesloten is, indien niet gesloten, moet u de handgreep sluiten, zo niet, dan zal het vastlopen enz. enz.
    In cAlgo kan deze taak worden uitgevoerd door een functie aan te roepen en deze vervolgens toe te wijzen aan een variabele. Slechts 1 regel.

    Nu, praat over het object in de programmeerwereld, zodra we het configuratiebestand hebben gelezen, kunnen we de configuratie benaderen met behulp van OOP, waarin binnenin het object ook een array van een ander object etc..etc is. OOP in C is gewoon tijdverspilling. Dit is waarom:Je kunt XML of JSON niet zomaar inlezen in een object in C . Er zijn te veel stappen om dit te bereiken, terwijl in cAlgo minimaal in 2 regels kan worden gedaan. Je kunt niet zomaar een reeks objecten sorteren (en dit is gewoon dom). U kunt sorteren als het te sorteren gegevenstype het getal is (int, long, short), niet met een ander gegevenstype zoals datum/tijd. En het sorteren is net zo eenvoudig, er is geen andere functie. Men moet zijn eigen sorteerfunctie cre�ren, en door dit te doen, verspilt u gewoon veel tijd. Alleen om die 2 redenen heb ik mijn kansen opgegeven en ben ik overgestapt op cTrader.

    Het is niet dat ik geen MQL wil leren. Maar goed, het schrijven van EA's zou net zoiets moeten zijn als het schrijven van een zakelijke applicatie, het moet robuust, snel, snel, eenvoudig zijn, zodat de minder belangrijke dingen op gang komen. Tenzij, als u code schrijft voor een machine, robotachtige dingen of gaming, of code die snellere toegang tot de machinetaallaag nodig heeft, dan is C de beste keuze.

    Stelt u zich eens voor, u wilt van uw standplaats nu in Hawaii naar New York uw bestemming. Met C# (of cTrader/cAlgo) hoeft u alleen maar elk beschikbare vervoermiddel te gebruiken (of te kopen), auto's, veerboottickets, vliegtuigtickets, bussen, treinen, alles om uw bestemming snel te bereiken. Met MQL heb ik het gevoel in het jaar 1781 te leven, waar we met onze handen een boot moeten bouwen om daar te komen.

    Dus, hoe is je ervaring, mensen?

  2. #2
    Quote Originally Posted by ;
    {citaat} Juist. En om dezelfde reden als jij (net het tegenovergestelde). Toen ik 10 jaar geleden begon, ergerde ik me aan het gebrek aan framework-functionaliteit in MQL en besloot ik het framework zelf te schrijven (zie Github). Nu heb ik de meeste functies die ik nodig heb en het zou enorm veel tijd en moeite kosten om alles naar een ander platform te porten. Dat is mijn grootste zorg met betrekking tot cTrader, ik heb er in het algemeen niets op tegen. De ondersteuning van makelaars is nog niet zo goed, maar sommige betere makelaars ondersteunen het al. Uw mijlpaal zal vari�ren. Doe wat het beste bij je past....
    ja, kerel. Het enige is dat 10 jaar geleden cTrader er niet was.
    Quote Originally Posted by ;
    {quote} Elk configuratiemechanisme dat gegevensstructuren kan uitdrukken, is voldoende. U gebruikt JSON en heeft een JSON-parser nodig. Prima. Ik gebruik gewone .ini-bestanden en heb een .ini-parser nodig. Ik schreef mijn eigen. Zo is het leven van een ontwikkelaar. :-) {afbeelding}
    Ik heb al heel lang geen INI-bestanden meer gehoord. Dit geeft ook een betere structuur.

  3. #3
    1 Bijlage(n)
    Quote Originally Posted by ;
    {quote}...Ik moet nog steeds de lijst met datums en tijden zien om in de EA te taggen. Ik ben op zoek naar een handelssysteem dat volledig geautomatiseerd kan worden, minder controle, minder emotie in het spel, af en toe kijken en dan vergeten. Met dat in gedachten heb ik een aantal complexe configuraties nodig, precies zoals deze:{image}
    Elk configuratiemechanisme dat gegevensstructuren kan uitdrukken, is voldoende. U gebruikt JSON en heeft een JSON-parser nodig. Prima. Ik gebruik gewone .ini-bestanden en heb een .ini-parser nodig. Ik schreef mijn eigen. Zo is het leven van een ontwikkelaar. :-)

  4. #4

    Quote Originally Posted by ;
    {quote} Oh, misschien heb je cAlgo wel eens gezien (of geprobeerd), maar heb je niet veel ontdekt sinds ik veronderstel? n deze discussie gaande houden...?
    Juist. En om dezelfde reden als jij (net het tegenovergestelde). Toen ik 10 jaar geleden begon, ergerde ik me aan het gebrek aan framework-functionaliteit in MQL en besloot ik het framework zelf te schrijven (zie Github). Nu heb ik de meeste functies die ik nodig heb en het zou enorm veel tijd en moeite kosten om alles naar een ander platform te porten. Dat is mijn grootste zorg met betrekking tot cTrader, ik heb er in het algemeen niets op tegen. De ondersteuning van makelaars is nog niet zo goed, maar sommige betere makelaars ondersteunen het al. Uw mijlpaal zal vari�ren. Doe wat het beste bij uw behoeften past. :-)

  5. #5
    1 Bijlage(n)
    Quote Originally Posted by ;
    Deze eisen beperken onze mogelijkheden. Java (mijn voorkeurstaal) en C# zijn misschien niet zo mooi maar geautomatiseerd handelen (retail) is er niet mee mogelijk. Dus als ik een geautomatiseerde handelaar ben, heb ik minder opties met betrekking tot frameworks. Als ik een discretionaire handelaar ben, is C# met lokale aangepaste indicatoren (mogelijk cTrader) prima.
    Mijn eis is misschien te hoog, dat komt omdat ik TE LU ben.
    Ik wil wel volledig geautomatiseerd handelen, maar het lijkt semi-automatisch te gaan. Omdat ik nog steeds de lijst met datums en tijden moet zien om in de EA te taggen. Ik ben op zoek naar een handelssysteem dat volledig geautomatiseerd kan worden, minder controle, minder emotie in het spel, af en toe kijken en dan vergeten. Met dat in gedachten heb ik een aantal complexe configuraties nodig, precies zoals deze:

  6. #6
    Quote Originally Posted by ;
    Met cAlgo heb je inderdaad een zeer schone ontwikkelomgeving, maar toch loop je bij bijna elke stap tegen muren aan. Nog niet jouw tijd cAlgo, nog niet...
    Oh, misschien heb je cAlgo gezien (of geprobeerd), maar niet veel ontdekt sinds ik veronderstel? In cAlgo kan het gewoon met het handelsplatform worden geschreven, net als MQL, de code compileren, het *.algo-bestand produceren, precies hetzelfde! Maar er is een functie genaamd Open in Visual Studio en Visual Studio IDE is gratis (
    https://visualstudio.microsoft.com/vs/community/). En elke keer dat u een EA maakt (cAlgo is de exacte naam), wordt het exacte Visual Studio-project gemaakt. Je kunt het eruit halen, de klas uitbreiden naar een andere, zelfs nog een bibliotheek toevoegen, enz. Dus tot hier zie ik geen muren. Ik kan alles coderen wat ik wil, beginnend met het plaatsen van een twitterbericht als ik wil, een andere webservice oproepen, webhooks, zelfs IoT-dingen, integreren met Azure en zo.
    Quote Originally Posted by ;
    Dus een perfect platform bestaat alleen voor mensen met een serieus budget (bijvoorbeeld een voor Deltix) en onze retailtaak is om het beste uit deze imperfecte retailwereld te halen. {quote} Wat u zoekt, bestaat, maar u moet ervoor betalen. Zo loopt het konijn. (Dus l�uft der Hase) :-) {image}
    Ik zie de PDF al, ze gebruiken ook C# en .NET Framework. Ik heb al gevonden wat ik zoek.
    Hoe dan ook, goede discussie en goed je te kennen, man! Misschien kunnen we deze discussie gaande houden...?

  7. #7

    Quote Originally Posted by ;
    ...Misschien was ik in de war toen ik dacht dat MQL C is...
    Ik snap je punt helemaal. Misschien moet je meer denken vanuit het oogpunt van een applicatieontwikkelaar. Gebruikersinvoer wordt altijd ingevoerd via scalaire waarden. Ik ken geen enkele toepassing ter wereld waar gebruikersinvoer wordt ingevoerd via een objectinstantie. Objectinstanties kunnen via parameters worden doorgegeven, maar niet als gebruikersinvoer. Hoe dan ook, de benadering van het vergelijken van talen zal niet echt iets opleveren, omdat vaardigheden en smaken gewoon te verschillend zijn om ons allemaal te bedienen. Imho is het beter om typische gebruiksgevallen te vergelijken. Dat isdiscretionaire handel met naakte grafieken discretionaire handel met aangepaste indicator ondersteuning discretionaire handel met externe signaalgeneratie volledig geautomatiseerde handel (remote) Voor al deze gebruikssituaties zullen er verschillende vereisten zijn voor het platform/de taal/het raamwerk, en hier moeten we een beslissing nemen wat het beste bij ons past. Het zijn niet alleen beschikbare bibliotheken voor XML of JSON. Het is ook interactie met de gebruiker en/of andere systemen zoals mail, logging, monitoring, messaging, remote control etc. Deze vereisten beperken onze mogelijkheden. Java (mijn voorkeurstaal) en C# zijn misschien niet zo mooi maar geautomatiseerd handelen (retail) is er niet mee mogelijk. Dus als ik een geautomatiseerde handelaar ben, heb ik minder opties met betrekking tot frameworks. Als ik een discretionaire handelaar ben, is C # met lokale aangepaste indicatoren (mogelijk cTrader) prima.

  8. #8
    Quote Originally Posted by ;
    De taak is om op een eenvoudige manier handelslogica uit te drukken. EasyLangugae in Tradestation is bijvoorbeeld veel beter dan MQL, maar de functionaliteit in vergelijking met MQL is beperkt. Dat is met een reden en met opzet. Als u volledige programmeerondersteuning nodig heeft met alle functies die u gewend bent van reguliere applicatieontwikkeling, dan kunt u eenvoudig overschakelen naar een andere taal en een brug slaan tussen beide. In MQL gebeurt dat door het gebruik van DLL's (C/C , Pascal, C#) en dit is het grote voordeel van MQL. Van alle beschikbare handelsplatforms/talen heeft MQL de gemakkelijkste...
    Ik heb in het verleden onderzoek gedaan naar dit, dat, de zogenaamde overbruggingstaal tussen MQL en een andere programmeertaal. Maar voor alle componenten die er zijn, gebruiken ze gewoon hetzelfde: een netwerkaansluiting openen, deze laten communiceren met de bridge vanuit de andere taal via netwerkpakketten. Dit is cool als je codeert voor iets dat 1 bestelling op een bepaald moment is. Het is niet cool als je meerdere transacties moet openen en dat niveau van responsiviteit moet eisen om daar hetzelfde te zijn als wanneer je MQL codeert. Omdat het in wezen via een netwerkaansluiting praat. Je moet wachten op de handdruk, het commando van het ene uiteinde wordt omgezet in een gemeenschappelijk commando dat van beide kanten begrijpelijk is en via de socket wordt overgedragen, en als het eenmaal het andere uiteinde bereikt, wordt het in wezen omgezet in MQL-code. Ik heb destijds een reeks discussies gehad met de MT4API-ontwikkelaar om te begrijpen hoe het werkt. MT4API, omdat het gratis is! Anderen die niet gratis zijn, gebruiken blijkbaar ook een netwerkaansluiting om te communiceren. Je kunt dus voorspellen wat het resultaat is.
    Quote Originally Posted by ;
    MQL is zo goed vanwege die eenvoudige API, het hoeft niet alle functies te ondersteunen die je mist. Probeer hetzelfde te doen op elk ander handelsplatform (noem maar op) en u zult begrijpen wat ik bedoel.
    Welnu, als MQL de gemakkelijkste is, betekent dit niet dat het complexe scenario's kan ondersteunen zoals ik heb.
    Het heeft echt geen uitgebreide functie nodig. Maar als iemand het nodig heeft, moeten ze ofwel betalen voor een overbruggingscomponent tussen MQL en C#, of volledig overstappen op cTrader. MAAR, ik ben het helemaal met je eens dat MQL de gemakkelijkste is als je wilt coderen voor een EA.

    Quote Originally Posted by ;
    De meest ontbrekende stukjes zijn exception handling en een COM-interface zoals in EasyLanguage. Maar de grootste pijn in de kont is niet de beperkte functionaliteit. Het is bugginess van vele functies.
    Ik weet niets van EasyLanguage. Maar ik zie dat de IDE naar mijn mening veel erger is dan MQL. Maar we snappen het punt waar deze dingen er waren om iedereen tegemoet te komen die handelaar is maar niet weet hoe te coderen.

  9. #9
    Misschien was ik in de war toen ik dacht dat MQL C is. Maar mijn focus zou meer op MQL zelf liggen dan op C .
    Quote Originally Posted by ;
    Een datum als 31 maart 2020 12:00:00 wordt niet uitgedrukt als een geheel getal maar als D'2020.03.31 12:00:00'. Het is moeilijk om je iets gemakkelijkers voor te stellen.
    DateTime IS uitgedrukt als een geheel getal, ik had het mis over de vinkjes omdat het het aantal seconden vertegenwoordigt, maar je begrijpt het punt. Citaat van:
    https://docs.mql4.com/dateandtimeeen geheel getal dat het aantal seconden vertegenwoordigt dat is verstreken vanaf 0 uur op 1 januari 1970. Mijn doel is niet alleen de datum te gebruiken zoals hij is. Maar om te manipuleren (dagen, minuten, uren toevoegen, converteren naar tekst en vice versa). Dus dit bericht is een van mijn redenen om me te ontmoedigen om MQL te blijven gebruiken:
    https://www.mql5.com/en/forum/101178. Dat zijn gewoon te veel routes om zomaar een dag toe te voegen.
    Quote Originally Posted by ;
    Een datetime-invoerparameter ondersteunt de native DateTime-kiezer die door het besturingssysteem wordt geleverd. Iets beters is moeilijk voor te stellen.
    Ik ben het ermee eens, het wordt ondersteund. Maar ik heb talloze tijd gehad om MQL te verkennen om te zien dat het op een of andere manier een reeks DateTime kan ondersteunen als een van de invoerparameters van EA, het kan niet aan mijn verwachting voldoen. Ik bedoel, ik heb een invoerparameter nodig die slechts een object met verschillende typen is, die ook eigenschappen en een reeks andere objecten binnen het object bevat die ook een reeks (zo complex) zijn, in plaats van alleen platte ongestructureerde invoerparameters geleverd door MQL zoals we zie nu. Maar er is een tijdelijke oplossing, gebruik een bestandspad als invoerparameter. Alleen al het lezen van het bestand kost me regels code (om nog maar te zwijgen van het sluiten van de bestandshandle en zo). Nu zie ik geen ingebouwde functies die JSON of XML ondersteunen. Er zijn een aantal bibliotheken op de markt, maar nogmaals, het voldoet niet aan de robuustheid zoals in C #, vooral het kan niet eenvoudiger dan dit:
    https://www.newtonsoft.com/json/help...lizeObject.htmwaarvan de kernregel code slechts 2 regels is. De rest is om de waarde en de klasse zelf te dumpen.

  10. #10
    Quote Originally Posted by ;
    {quote} Enkele punten over uw bericht die bij mij opkomen (onvolledige lijst): De meeste van uw voorbeelden wijzen op problemen die worden veroorzaakt door het verwarren van een programmeertaal en een toepassingsframework. MQL is geen C . MQL is een scripttaal die veel meer lijkt op C. Door de ondersteuning van klassen en structs lijkt het op C , maar C/C zijn echte talen en MQL is dat niet. MQL wordt gecompileerd tot byte-code en wordt uitgevoerd door een interpreter, meer vergelijkbaar met JavaScript. De beschikbare ingebouwde functies omvatten een aantal functies die beschikbaar zijn in C.
    Bedankt. Eindelijk de C -expert
    Ik ben niet onderlegd in C en MQL, maar ik denk dat ik ervoor kies om niet dieper te gaan. Dit maakt mijn veronderstelling duidelijk dat MQL zoiets is als MEF in dotnet, dat ongeveer als een add-on werkt. Ik denk dat dit de reden is waarom (naar mijn mening) cAlgo nog steeds veel beter is omdat het gecompileerd is, niet ge�nterpreteerd. Het erft precies hetzelfde als C#, omdat het C# is. Dit verklaart dus ook waarom MQL moeilijk is om met mijn idee�n te werken.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.