![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Cosa stai dicendo di C++... Se non ti piace C++, prendi C#. L'ho specificatamente menzionato nel mio post originale e più avanti nelle discussioni l'ho sottolineato. Molte delle cose suggerite riguardano entrambi i linguaggi.
Quindi una delle due cose: o sei contro il progresso in linea di principio o semplicemente brontoli. Anche se entrambe le varianti sono anche possibili
...
MetaTrader è un buon terminale. Ma purtroppo, la stragrande maggioranza dei suoi utenti sono ancora perdenti e giocatori d'azzardo. MQ ha fatto un grande sforzo per entrare nella nicchia dello smart trading, ma non ha avuto successo. Gli scommettitori hanno solo bisogno di un "poke" MT4 con qualche "TrendLaser" multicolore sul grafico. A loro non interessano le strutture, le classi, le specialità con declinazione, ecc. Ma "un vello di una pecora sottile" - è così che viviamo. Quindi, in questa situazione, non è economicamente fattibile sviluppare le caratteristiche della lingua in MQL5. Ma sarebbe ragionevole flirtare con la folla, per esempio introdurre blocchi in MT5 o Open[0] invece di CopyRates.
In realtà, questo è un po' strano. Originariamente, MQL è stato creato come un linguaggio applicativo per scrivere strategie di trading. Pertanto, non conteneva tutto ciò che ha il C++. Ma col tempo, i compiti nel trading algoritmico sono diventati più complicati, e le persone cercano e aspettano le aggiunte al linguaggio. Così, tendono a mettere tutto ciò che non è stato aggiunto intenzionalmente. Così facendo, il numero di regole e il livello di complessità della lingua aumenteranno, diventando una barriera per se stessi. Ma, se sono disposti a superarli, non c'è modo di fermarli.
Per me, lo sviluppo consiste prima di tutto nel trovare il modo giusto e più semplice per implementare un pensiero. Come tale, le capacità del vecchio linguaggio sono abbastanza buone, ma i programmatori professionisti sentono la nostalgia del cumulo di regole e dei mucchi di sintassi. )) Beh, se dà loro l'ispirazione - perché no?
Allo stesso tempo, il numero di regole e il livello di complessità della lingua aumenteranno, diventando una barriera per loro.
Perché una barriera? L'aggiunta di nuove funzioni non impedisce loro di usare quelle vecchie. Di regola, nessuno è obbligato a usare queste "complessità".
Anche se ci sono stati certamente periodi in cui le regole stabilite sono state improvvisamente alterate senza pietà a beneficio del C++, ma quello era il periodo del suo rapido sviluppo. Ora il linguaggio ha quasi tutto e rimangono solo piccole modifiche.
A proposito, personalmente sento non solo la mancanza di miglioramenti, ma anche la riduzione delle caratteristiche della lingua nell'ultimo anno e mezzo. La build più funzionale e stabile è stata la 1554, datata 14 marzo 2017.Dopo di che c'è stata una riprogettazione radicale degli interni, e ci sono state build problematiche con un sacco di bug, alcuni dei quali non sono stati risolti fino ad oggi. Tuttavia, alcuni dei vecchi bug sono stati risolti. In generale, il livello dei bug delle build attuali è probabilmente leggermente migliore. Ma riguardo alla funzionalità...
Per esempio, ho già scritto del taglio della possibilità di lanciare gli array ai tipi di base. Un altro taglio è stato il divieto di lanciare strutture semplici tra di loro. Sì, sono state sostituite da unità, ma non coprono le possibilità date dal cast che permetteva di compensare gli svantaggi della funzionalità regolare. Dato che MQL non ha interfacce per le strutture (ne ho già scritto), questa soluzione era una buona alternativa:
Perché una barriera? L'aggiunta di nuove funzioni non impedisce di usare quelle vecchie. Di regola, quindi nessuno è costretto a usare queste "complessità".
Anche se naturalmente ci sono stati momenti in cui regole ben stabilite sono state improvvisamente riscritte senza pietà per il bene del C++, ma quella era l'epoca del suo rapido sviluppo. Ora abbiamo quasi tutto e rimangono solo piccole modifiche.
Intendevo una barriera per coloro che vogliono usare le nuove regole e la sintassi da soli. Dovranno scrivere i loro programmi più a lungo e impiegare più tempo per capirli. Questo renderà i loro programmi più efficienti? - Non proprio. Saranno in grado di risolvere un numero maggiore di compiti? - Non proprio.
Una volta ho proposto su un forum una soluzione molto semplice di un compito che tutti risolvevano con una montagna di codice. Era piccolo e veloce. Tuttavia, non è piaciuto a tutti. Non aveva quelle cose che piacevano a loro. Tutti i tipi ditemplate<typename T> evoid Func(IValueable<A> &a)
Mi è stato offerto di usarli tutti. Quando ho chiesto "perché?" nessuno ha spiegato niente di chiaro.
P.S. La spiegazione più chiara che ho ricevuto è stata: "Il tuo codice è brutto". E un'altra cosa: "Non capite il potere concettuale". Ma io sono uno sviluppatore. Ho bisogno di una bella soluzione, non di un bel codice.
Sì, sono stati sostituiti dalle unioni, ma non coprono le possibilità che sono state fornite dalla conversione, che ha permesso di compensare le carenze della funzionalità standard. Dato che MQL non fornisce interfacce per le strutture (ne ho già scritto), questa soluzione era una buona alternativa:
Questo compila.
Ma il risultato, ovviamente, è diverso.