![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
Se vi ricordate Borland, la GUI veniva assemblata in un editor visuale, la disposizione dei controlli veniva messa in una barra degli strumenti, e poi si scrivevano i gestori.
Se ME avesse una tale caratteristica grafica per costruire layout in modalità visiva, renderebbe la costruzione di applicazioni grafiche molto più facile.
Poiché la maggior parte dei programmatori moderni, che hanno studiato la costruzione di GUI, si sono abituati (così gli è stato insegnato) all'editor visivo di GUI,
E costruire un layout di un'applicazione grafica su puro codice in stile C è di scarso interesse per loro. Dal momento che è già hardcore C-style.
Abbiamo bisogno di un editor visivo per costruire un'applicazione grafica, e poi le persone saranno desiderose di impararlo, e quelli che hanno lavorato in VS o RadStudio, anche rapidamente padroneggiano l'editor visivo.
Qui, c'era già un prototipo di un tale editor visivo in MQL. Tuttavia, la gente era veementemente contraria. Hanno detto che non era necessario nel commercio.
In generale, si demoralizzavano come meglio potevano. Pertanto, non so di cosa abbia veramente bisogno la comunità.
Sostengo pienamente la necessità di avere la possibilità di raccogliere...
Ma se sia necessario o meno è un'altra questione.
Mi chiedo se gli stessi sviluppatori vedono il terminale come uno strumento di trading o uno strumento di programmazione?
Potrei sbagliarmi a questo punto, ma ho sempre pensato che ME è stato progettato per implementare esattamente la funzionalità di cui l'utente ha bisogno per il trading. Esattamente il commercio!
Ma al giorno d'oggi la profondità della programmazione in ME è andata in aree in cui è davvero necessario essere in grado di "costruire" dadi e avere una comprensione molto seria della programmazione....
E a cosa porta questo alla fine? Questo porta al fatto che gli strumenti di trading avanzati diventano disponibili solo per i programmatori esperti!
Cioè, se non sei un programmatore, non hai niente da fare nel trading... Ma questo è assurdo.
ME è solo un assistente per riempire la funzionalità mancante, che sarebbe stata più correttamente costruita nel terminale stesso (diverse procedure guidate).
E infatti ME si sta evolvendo come un nuovo ambiente di sviluppo, che richiede sempre più conoscenze da parte degli utenti.
Sulla base di questa conclusione, gli strumenti di visualizzazione sono necessari, ma il loro uso dovrebbe essere disponibile per gli utenti che non hanno una profonda conoscenza della programmazione.
Solo in questo caso saranno richiesti.
Questa è solo la mia opinione e non la impongo a nessuno.
Se si considera la classe CCanvas, ci sono circa 20 funzioni di disegno di primitive grafiche. Supponiamo che un utente li conosca tutti e conosca le regole e la sintassi di OOP. Tuttavia, è troppo poco fino alla visualizzazione più semplice dei suoi dati. Per non parlare della creazione del controllo più semplice: un pulsante. Cioè, è relativamente facile disegnare primitive sulla tela, ma usare queste primitive per creare visualizzazioni o GUI è molto più difficile. E non si può fare qui senza conoscenza - non si può fare qui senza il talento dello sviluppatore. Ma quante persone ce l'hanno? Questo è il problema chiave.
Per utilizzare il potenziale della classe Kanvas è necessario essere in grado di combinare primitivi grafici in oggetti più complessi (controlli), di legare il loro funzionamento con il modello event-driven, di scrivere le relazioni con funzioni... Oppure, convertire i dati digitali in diverse curve grafiche... Questo è un lavoro per utenti di talento e molto laboriosi. Infatti, non gli utenti, ma gli sviluppatori.
Qui, c'era già un prototipo di un tale editor visivo in MQL. Tuttavia, la gente era veementemente contraria. Hanno detto che non era necessario nel commercio.
In generale, si demoralizzavano come meglio potevano. Pertanto, non so di cosa abbia realmente bisogno la comunità.
Wow, quindi c'è un prototipo.
Quindi forse gli sviluppatori dovrebbero riconsiderare le opinioni superficiali della comunità? E rilanciare il piano per sviluppare una modalità visiva.
Un po' strano, naturalmente, demoralizzare una caratteristica essenzialmente molto ricercata.
Ci sono pochissimi posti ora dove insegnano come costruire un'interfaccia grafica in stile C, se mai lo insegnano ancora.
Ora a tutti viene insegnato a lavorare in IDE con la modalità visiva, e dal momento che MT5 è andata da tempo oltre la sola piattaforma di trading,
la modalità visiva di costruire applicazioni grafiche sarebbe molto richiesta.
Onestamente sono scioccato che gli sviluppatori abbiano ascoltato le persone miopi che erano contrarie.
Se consideriamo la classe CCanvas, ci sono circa 20 funzioni per disegnare primitive grafiche. Supponiamo che l'utente li conosca tutti e che conosca le regole e la sintassi OOP. Tuttavia, fino alla visualizzazione più semplice dei suoi dati - è troppo poco. Per non parlare della creazione del controllo più semplice: un pulsante. Cioè, è relativamente facile disegnare primitive sulla tela, ma usare queste primitive nella creazione di visualizzazioni o GUI è molto più difficile. E non si può fare qui senza conoscenza - non si può fare qui senza il talento dello sviluppatore. Ma quante persone ce l'hanno? Questo è il problema chiave.
Per utilizzare il potenziale della classe Kanvas è necessario essere in grado di combinare primitivi grafici in oggetti più complessi (controlli), di legare il loro funzionamento con il modello event-driven, di scrivere le relazioni con funzioni... Oppure, convertire i dati digitali in diverse curve grafiche... Questo è un lavoro per utenti di talento e molto laboriosi. Infatti, non gli utenti, ma gli sviluppatori.
Peter, tu dici le parole giuste!
Quindi sostengo la creazione di tali librerie che sarebbero intuitivamente comprensibili anche per i programmatori che non hanno familiarità con OOP.
E questo vale non solo per la GUI.
Nella libreria standard e in quella di Anatoly ci vorrebbe molto sforzo per costruire un semplice modulo! Per davvero! Un passo a destra o a sinistra degli esempi e basta, non funziona niente, bisogna capire tutti i dettagli.
In tutti i linguaggi, naturalmente, la GUI è anche costruita su librerie, ma c'è un importante MA! C'è un set iniziale di controlli, che a livello di nucleo della libreria sono completamente "legati" insieme, tutti i gestori di eventi di base sono "cablati", tutto ciò che rimane è sottoscriverli se si vuole cambiare il comportamento o la presentazione.
In sostanza, l'architettura della libreria standard è molto ben pensata e potrebbe essere usata come base per una libreria più avanzata.
Wah, quindi c'è un prototipo disponibile.
Quindi forse gli sviluppatori dovrebbero riconsiderare le opinioni superficiali della comunità? E rilanciare il piano per sviluppare una modalità visiva.
È strano, naturalmente, che abbiano demoralizzato una caratteristica essenzialmente molto ricercata.
Dopo tutto, pochi posti ora insegnano come costruire un'interfaccia grafica in stile C, se mai viene ancora insegnato.
Ora insegnano a lavorare in IDE con la modalità visiva, e poiché MT5 non è più solo una piattaforma di trading,
allora il modo visivo di costruire applicazioni grafiche sarebbe molto richiesto.
Ad essere onesti sono scioccato che gli sviluppatori abbiano ascoltato le persone miopi che erano contrarie.
Ci sono altri fattori sorprendenti: gli indicatori sono visivi al 100%, gli EA sono visivi all'80% e gli script al 20%. Comunque lo si voglia chiamare, tutto è visivo e la comprensione di questo sta in superficie. Tuttavia, c'è uno sviluppo sull'integrazione con altri ambienti di sviluppo, e ciò che è in superficie....
A quanto pare tutti gli altri utenti del terminale chiedono python e sql.
Roman, Peter, Nikolai... gli sviluppatori del terminale hanno la loro visione, sono gli autori e i proprietari del prodotto software. Immagino che lo sviluppo delle funzionalità di ME e del terminale nel suo insieme sia basato su ricerche di mercato.
Ma nessuno ci impedisce di parlare :)
Ci sono altri fattori sorprendenti: gli indicatori sono visivi al 100%, gli EA sono visivi all'80% e gli script al 20%. C'è visualità in ogni cosa e la comprensione di questo si trova in superficie. Tuttavia, c'è uno sviluppo sull'integrazione con altri ambienti di sviluppo, e ciò che è in superficie....
A quanto pare tutti gli altri utenti del terminale chiedono python e sql.
Roman, Peter, Nikolay... Gli sviluppatori del terminale hanno la loro visione, sono gli autori e i proprietari del prodotto software. Penso che lo sviluppo delle funzionalità di ME e del terminale in generale sia basato su ricerche di mercato.
Ma nessuno ci impedisce di parlare :)
Proprio così.
La mia opinione è: l'interfaccia visiva degli EA permetterà di accumulare strategie in una sola applicazione, il che influenzerà negativamente le vendite sul mercato. Se tutti possono creare facilmente Expert Advisors con un insieme dinamico di strategie (la GUI lo permette), la loro rotazione attuale nel mercato scenderà, il che influenzerà le vendite. Gli Expert Advisors che integrano e modificano le strategie internamente verranno alla ribalta ed elimineranno i cloni che differiscono solo nelle impostazioni o in alcune condizioni. Sarà un bene per il mercato? Non lo so. Ma il livello degli Expert Advisors aumenterà e diventerà molto più interessante esaminarli nella vetrina.
Forse la maggior parte degli utenti vuole che CCanvas, CGrafic e CCanvas3D siano applicazioni che producono le visualizzazioni richieste, piuttosto che classi che richiedono la conoscenza dei principi e della sintassi OOP. E non solo per sapere, ma essenzialmente per costruire il proprio sistema di visualizzazione, come fa Nicholas.
Qual è il principio di oop che dovete conoscere? Mettere un punto e scegliere un metodo dalla lista?
Una domanda successiva: quante e quali delle funzioni MQL "più potenti" e "più semplici"
è sufficiente per scrivere un Expert Advisor completamente funzionale e potenzialmente il più redditizio per qualsiasi
delle principali coppie di valute del mondo?
E quale funzione R o Python, di cui tutti qui hanno perso la testa, è sufficiente scrivere...? E guarda, lo sgabello su cui sei seduto - è adatto a questo...?
Beh, se vi ricordate Borland, la GUI era assemblata in un editor visuale, si metteva il layout del controllo sul pannello e poi si scrivevano i gestori.
Se ME avesse una tale capacità grafica di costruire i layout visivamente, semplificherebbe enormemente la costruzione di applicazioni grafiche.
Poiché la maggior parte dei programmatori moderni, che hanno studiato la costruzione di GUI, si sono abituati (così gli è stato insegnato) all'editor visivo di GUI,
E costruire un layout di un'applicazione grafica su puro codice in stile C è di scarso interesse per loro. Dal momento che è già hardcore C-style.
Abbiamo bisogno di un editor visivo per costruire un'applicazione grafica, e poi le persone saranno desiderose di impararlo, e quelli che hanno lavorato in VS o RadStudio, anche rapidamente padroneggiano l'editor visivo.
Perché sono necessari qui?
Proprio così.
La mia opinione è: l'interfaccia visiva degli EA permetterà di accumulare strategie in una sola applicazione, il che avrà un impatto negativo sulle vendite del mercato. Se tutti possono creare facilmente Expert Advisors con un insieme dinamico di strategie (la GUI lo permette), la loro rotazione attuale nel mercato scenderà, il che influenzerà le vendite. Gli Expert Advisors che integrano e modificano le strategie internamente verranno alla ribalta ed elimineranno i cloni che differiscono solo nelle impostazioni o in alcune condizioni. Sarà un bene per Marketplace? Non lo so. Ma il livello degli EA crescerà e diventerà molto più interessante guardarli sulla vetrina.
Assolutamente un problema inverosimile.
L'interfaccia visiva per la raccolta di strategie non è necessaria, se avete bisogno di dadi, andate su tslab.
E ho visto programmi per generare codice mql che raccolgono strategie con cubi in modalità visiva.
Non abbiamo bisogno della modalità visiva per lo sviluppo di strategie di trading e indicatori, è davvero inutile.
Ma per le applicazioni grafiche modulari, la modalità visiva, come hai mostrato nella gif, sarebbe utile.