Thread: Qual você prefere: Metatrader (MQL) ou cTrader (cAlgo)?

Estou apenas curioso sobre vocês lá fora. Alguém aqui realmente usa muito o MetaTrader (para escrever MQL), mas muito poucos usam o cTrader (cAlgo)?

Além das vantagens que o corretor tem a oferecer, sinto que o MetaTrader não é a melhor plataforma para construir EAs. MQL = C , eles estão usando C como código base. Está escrito na página de documentação deles:
https://www.mql5.com/en/docs
Enquanto cTrader (cAlgo) usa C# como seu código base.

Sou consultor técnico em tempo integral, desenvolvedor de aplicativos, web designer novato, conheço a maioria das tecnologias recentes de desenvolvimento de aplicativos. Faço isso há mais de 10 anos e descobri que C# e Java são concorrentes fortes. Ambos foram nomeados entre as 10 linguagens de programação mais populares, juntamente com Javascript, Scala, Go, Phyton. Mas nenhum deles é C . Para minha experiência (depois de escrever 3 EAs), MQL é apenas difícil. Se sua lógica é tão simples quanto calcular algo, crie ordens ou posições pendentes com base no mercado, MQL é o suficiente. Mas uma vez que você entra em ideias mais complexas, MQL simplesmente não é suficiente... desculpe dizer.


Tomemos como exemplo um dos meus EA, Tunnel Martingale (TM). Se você seguir meu tópico (
https://www.tradingintuitivo.com/tra...ivots-win.html) na seção comercial, na verdade foi construído usando MQL. Porque a lógica é simples! Inicie uma posição de mercado aleatoriamente, depois coloque a ordem pendente na direção oposta, uma vez que a ordem pendente seja alcançada/executada, coloque outra ordem pendente na direção oposta, etc. etc. Uma estratégia é apenas uma estratégia, falhou, sugou o investimento e depois voltou para a prancheta novamente.
À medida que as ideias para melhorar avançam um pouco, a codificação com MQL está ficando cada vez mais difícil. Uma das ideias para melhorar é, em vez de executar a série martingale por tempo ilimitado e indefinidamente, poderíamos limitar o período de tempo apenas em uma data e hora específicas apenas para um intervalo/duração específico. Agora aqui está o problema.
A maneira como o C lida com data e hora está usando atualmente o tipo de dados antigo que é baseado em número inteiro que representa ticks calculados desde 1º de janeiro de 1970! Isso é como algumas coisas pré-históricas. Então, agora eu entendo que se eu quiser definir uma data e hora específica de A a B, eu tenho que saber a representação do tick dessa data.

Portanto, se eu quiser escrever que a TM começa em 31 de março de 2020 12:00:00, tenho que escrever 637212528000000000 em um parâmetro, variável ou qualquer método de comunicação entre mim como usuário para o EA. Não é isso, as funções DateTime são muito limitadas em MQL.

Agora, outro desafio é que quero introduzir um objeto para as datas, no parâmetro de entrada. Não há como, tanto o MQL quanto o cAlgo, definir parâmetros de entrada complexos. Mas pode-se fazer isso introduzindo uma configuração de arquivo, algo como JSON ou XML. Em MQL, são necessárias algumas linhas apenas para ler um arquivo. Você precisa entender o conceito do ponteiro, você precisa verificar se o filehandle está fechado, se não estiver fechado, você deve fechar o handle, caso contrário, ele ficará preso etc. etc.
No cAlgo, essa tarefa pode ser feita apenas chamando uma função e depois atribuindo-a a uma variável. Apenas 1 linha.

Agora, falando sobre o objeto no mundo da programação, uma vez que lemos o arquivo de configuração, podemos acessar a configuração usando OOP, em que dentro do objeto também tem algum array de outro objeto etc..etc. OOP em C é apenas uma perda de tempo. Aqui está o porquê:Você não pode simplesmente ler XML ou JSON em um objeto em C . Existem muitas etapas para conseguir isso, enquanto no cAlgo pode ser feito em 2 linhas no mínimo. Você não pode simplesmente ordenar uma matriz de objetos (e isso é estúpido). Você pode classificar se o tipo de dados a ser classificado for o número (int, long, short), não com outro tipo de dados, como data e hora. E a classificação é simples assim, não há outra função. É preciso criar sua própria função de classificação, e fazer isso apenas desperdiçando muito meu tempo. Apenas essas 2 razões, eu desisti das minhas chances e mudei para a cTrader.

Não é que eu não queira aprender MQL. Mas ei, escrever EAs deveria ser como escrever um aplicativo de negócios, deve ser robusto, rápido, rápido, simples, mantendo as coisas menos importantes ao longo do caminho. A menos que, se você estiver escrevendo código para uma máquina, coisas robóticas ou jogos, ou código que precise de acesso mais rápido à camada de linguagem de máquina, então C é a melhor escolha.

Imagine, você quer ir de seu lugar de pé agora no Havaí para Nova York, seu destino. Com C# (ou cTrader/cAlgo), você só precisa usar (ou comprar) qualquer meio de transporte disponível por aí, carros, passagem de balsa, passagem de avião, ônibus, trem, qualquer coisa para chegar rápido ao seu destino. Com o MQL, tenho vontade de viver no ano de 1781, onde precisamos construir um barco com as mãos para chegar lá.

E aí, como está sua experiência, pessoal?

{quote} Correto. E pelo mesmo motivo que você (pelo contrário). Quando comecei, 10 anos atrás, fiquei incomodado com a falta de funcionalidade do framework em MQL e decidi escrever o framework sozinho (veja Github). Agora eu tenho a maioria dos recursos de que preciso e levaria muito tempo e esforço para portar tudo para outra plataforma. Essa é a minha principal preocupação em relação ao cTrader, não tenho nada contra isso em geral. O suporte do corretor ainda não é tão bom, mas alguns corretores melhores já o suportam. Seu marco irá variar. Faça o que melhor se adapta às suas necessidades....

sim cara. A única coisa é que há 10 anos a cTrader não estava lá.

{quote} Qualquer mecanismo de configuração capaz de expressar estruturas de dados serve. Você usa JSON e precisa de um analisador JSON. Multar. Eu uso arquivos .ini simples e preciso de um analisador .ini. Eu escrevi o meu. Assim é a vida do desenvolvedor. :-) {imagem}

Eu não ouço arquivos INI há muito tempo. Isso também dá uma estrutura melhor.

1 Anexo(s)

{quote}...Ainda preciso ver a lista de datas e horários para inserir tags no EA. Estou procurando um sistema de negociação que possa ser totalmente automatizado, menos monitoramento, menos emoção no jogo, olhar de vez em quando e depois esquecer. Com isso em mente, preciso de uma série de configurações complexas como esta:{image}

Qualquer mecanismo de configuração capaz de expressar estruturas de dados servirá. Você usa JSON e precisa de um analisador JSON. Multar. Eu uso arquivos .ini simples e preciso de um analisador .ini. Eu escrevi o meu. Assim é a vida do desenvolvedor. :-)

{quote} Ah, talvez você tenha visto (ou tentado) cAlgo, mas não explorando muito desde que suponho? n continuar esta discussão...?

Correto. E pelo mesmo motivo que você (pelo contrário). Quando comecei, 10 anos atrás, fiquei incomodado com a falta de funcionalidade do framework em MQL e decidi escrever o framework sozinho (veja Github). Agora eu tenho a maioria dos recursos de que preciso e levaria muito tempo e esforço para portar tudo para outra plataforma. Essa é a minha principal preocupação em relação ao cTrader, não tenho nada contra isso em geral. O suporte do corretor ainda não é tão bom, mas alguns corretores melhores já o suportam. Seu marco irá variar. Faça o que melhor se adapta às suas necessidades. :-)

1 Anexo(s)

Esses requisitos limitam nossas opções. Java (minha linguagem preferida) e C# podem não ser tão agradáveis, mas o comércio automatizado (varejo) não é possível com ele. Então, se eu sou um trader automatizado, tenho menos opções em relação aos frameworks. Se eu sou um trader discricionário, C# com indicadores personalizados locais (possivelmente cTrader) estão bem.

Minha exigência é muito alta, talvez, porque eu sou muito preguiçoso.
Eu quero alcançar uma negociação totalmente automatizada, mas parece ser semiautomatizada. Porque ainda preciso ver a lista de datas e horários para marcar no EA. Estou procurando um sistema de negociação que possa ser totalmente automatizado, menos monitoramento, menos emoção no jogo, olhar de vez em quando e depois esquecer. Com isso em mente, preciso de algumas séries de configurações complexas como esta:

Com o cAlgo, você realmente tem um ambiente de desenvolvimento muito limpo, mas ainda esbarra em paredes em quase todas as etapas. Ainda não é o seu tempo cAlgo, ainda não...

Ah, talvez você tenha visto (ou tentado) cAlgo, mas não explorando muito desde que suponho? No cAlgo, ele pode ser escrito apenas com a plataforma de negociação como MQL, compilar o código, produzir arquivo *.algo, exatamente o mesmo! Mas há um recurso chamado Open in Visual Studio, e o Visual Studio IDE é gratuito (
https://visualstudio.microsoft.com/vs/community/). E, toda vez que você cria um EA (cAlgo é o nome exato), ele cria o projeto Visual Studio exato. Você pode tirá-lo, estender a classe para outra, até adicionar outra biblioteca, etc. Então, até aqui, não vejo paredes. Posso codificar o que quiser, começando por postar mensagens no Twitter, se quiser, chamar outro serviço da Web, webhooks, até coisas de IoT, integrar com o Azure e tudo mais.

Portanto, uma plataforma perfeita existe apenas para pessoas com um orçamento sério (por exemplo, um para Deltix) e nossa tarefa de varejo é tirar o melhor proveito desse mundo imperfeito do varejo. {quote} O que você está procurando existe, mas você tem que pagar por isso. É assim que o coelho corre. (So ​​läuft der Hase) :-) {imagem}

Eu já vejo o PDF, eles também estão usando C# e .NET Framework. Já encontrei o que procuro.
Enfim, boa discussão e bom conhecê-lo, cara! Talvez possamos manter essa discussão...?

...Talvez eu estivesse confuso ao pensar que MQL é C ...

Eu entendo totalmente o seu ponto. Talvez você devesse pensar mais do ponto de vista do desenvolvedor de aplicativos. A entrada do usuário é sempre inserida por meio de valores escalares. Não conheço nenhum aplicativo no mundo em que a entrada do usuário seja inserida por meio de uma instância de objeto. Instâncias de objetos podem ser passadas por meio de parâmetros, mas não como entrada do usuário. De qualquer forma, a abordagem de comparar idiomas não renderá nada, pois habilidades e gostos são muito diferentes para atender a todos nós. Imho é melhor comparar casos de uso típicos. Isso énegociação discricionária com gráficos nus negociação discricionária com suporte a indicador personalizado negociação discricionária com geração de sinal remoto negociação totalmente automatizada (remoto) Para todos esses casos de uso, haverá requisitos diferentes para a plataforma/idioma/estrutura, e é aqui que temos que decidir o que melhor nos convém. Não são apenas bibliotecas disponíveis para XML ou JSON. É também a interação com o usuário e/ou outros sistemas como correio, registro, monitoramento, mensagens, controle remoto etc. Esses requisitos limitam nossas opções. Java (minha linguagem preferida) e C# podem não ser tão agradáveis, mas o comércio automatizado (varejo) não é possível com ele. Então, se eu sou um trader automatizado, tenho menos opções em relação aos frameworks. Se eu sou um trader discricionário, C# com indicadores personalizados locais (possivelmente cTrader) está bem.

A tarefa é expressar a lógica de negociação de uma maneira fácil. Por exemplo, o EasyLangugae no Tradestation é muito melhor que o MQL, mas sua funcionalidade em comparação com o MQL é limitada. Isso é por uma razão e intencional. Se você precisar de suporte completo à programação com todos os recursos com os quais está acostumado no desenvolvimento regular de aplicativos, poderá alternar facilmente para outro idioma e fazer a ponte entre ambos. Em MQL isso é feito através do uso de DLLs (C/C , Pascal, C#) e aqui está a grande vantagem do MQL. De todas as plataformas/linguagens de negociação disponíveis, o MQL tem o mais fácil...

Eu fiz pesquisas no passado, avaliando isso, aquilo, a chamada linguagem de ponte entre MQL e outra linguagem de programação. Mas em todos os componentes lá fora, eles estão usando apenas a mesma coisa: abrir um soquete de rede, deixá-lo se comunicar com a ponte do outro idioma por meio de pacotes de rede. Agora, isso é legal se você codificar algo que é 1 pedido em um determinado momento. Não é legal se você tiver que abrir várias negociações e exigir que esse nível de resposta esteja lá da mesma forma que quando você codifica MQL. Porque essencialmente está falando através de um soquete de rede. Você precisa esperar pelo handshake, o comando de uma extremidade convertido em um comando comum que é compreensível de ambas as extremidades e será transferido através do soquete, então, quando chegar à outra extremidade, ele será convertido essencialmente em código MQL. Eu tive uma série de discussões com o desenvolvedor MT4API naquela época, para entender como funciona. MT4API, porque é grátis! Outros que não são gratuitos, aparentemente também usam um soquete de rede para se comunicar. Assim você pode prever qual é o resultado.

O MQL é tão bom por causa dessa API fácil, que não precisa oferecer suporte a todos os recursos que você está perdendo. Tente fazer o mesmo em qualquer outra plataforma de negociação (você escolhe) e você entenderá o que quero dizer.

Bem, se o MQL for o mais fácil, não significa que pode suportar cenários complexos como o que tenho.
Realmente não precisa de um recurso extensivo. Mas se alguém precisar, eles terão que pagar por um componente de ponte entre MQL e C# ou passar completamente para o cTrader. MAS, CONCORDO totalmente com você que o MQL é o mais fácil e simples se alguém quiser codificar para um EA.

As peças que mais faltam são o tratamento de exceções e uma interface COM como no EasyLanguage. Mas a maior dor na bunda não é a funcionalidade limitada. É bugginess de muitos recursos.

Eu não sei sobre EasyLanguage. Mas eu vejo o IDE, é muito pior que o MQL na minha opinião. Mas chegamos ao ponto em que essas coisas estavam lá para acomodar qualquer um que é trader, mas não sabe codificar.

Talvez eu estivesse confuso ao pensar que MQL é C . Mas meu foco seria mais no próprio MQL, em vez do C .

Uma data como 31 de março de 2020 12:00:00 não é expressa como um número inteiro, mas como D'2020.03.31 12:00:00'. É difícil imaginar algo mais fácil.

DateTime é expresso como um inteiro, eu estava errado sobre os ticks, pois representa o número de segundos, mas você entendeu. Citado de:
https://docs.mql4.com/dateandtimeum número inteiro que representa o número de segundos decorridos desde 0 horas de 1º de janeiro de 1970 Meu objetivo não é apenas usar a data como ela é. Mas para manipular (adicionar dias, minutos, horas, converter em texto e vice-versa). Então este post é um dos meus motivos que me desencoraja a continuar usando MQL:
https://www.mql5.com/en/forum/101178. São muitas rotas para adicionar apenas um dia.

Um parâmetro de entrada datetime oferece suporte ao seletor DateTime nativo fornecido pelo sistema operacional. É difícil imaginar algo melhor.

Concordo, é suportado. Mas eu tive incontáveis ​​tempo explorando em MQL para ver de alguma forma que ele pode suportar uma matriz de DateTime como um dos parâmetros de entrada do EA, não pode atender às minhas expectativas. Quero dizer, eu preciso de um parâmetro de entrada que seja apenas um objeto com vários tipos, que também contenha propriedades e array de outros objetos dentro do objeto que também seja um array (tão complexo), em vez de apenas parâmetros de entrada simples e não estruturados fornecidos pelo MQL como nós veja agora mesmo. Mas há uma solução alternativa, use um caminho de arquivo como parâmetro de entrada. Ler apenas o arquivo me leva linhas de código (sem mencionar o fechamento do filehandle e todos os outros enfeites). Agora, não vejo funções internas que suportem JSON ou XML. Existem algumas bibliotecas no mercado por aí, mas, novamente, não atende a robustez como em C#, especialmente não pode ser mais simples que isso:
https://www.newtonsoft.com/json/help...lizeObject.htmqual a linha principal de código é de apenas 2 linhas. O resto é despejar o valor e a própria classe.

{quote} Alguns pontos sobre sua postagem que me vêm à mente (lista incompleta): A maioria de seus exemplos aponta para problemas causados ​​por confundir uma linguagem de programação e uma estrutura de aplicativo. MQL não é C . MQL é uma linguagem de script muito mais parecida com C. O suporte de classes e structs faz com que pareça similar a C , mas C/C são linguagens reais e MQL não é. O MQL é compilado em byte-code e executado por um interpretador, mais semelhante ao JavaScript. As funções internas disponíveis cobrem algumas funcionalidades disponíveis em C.

Obrigado. Finalmente o especialista em C
Não sou experiente em C e MQL, mas acho que escolho não ir mais fundo. Isso elimina minha suposição de que MQL é algo como MEF em dotnet, que funciona praticamente como um complemento. Eu acho que é por isso que (na minha opinião) cAlgo ainda é muito melhor porque é compilado, não interpretado. Ele herda exatamente a mesma coisa que C#, porque é C#. Então, isso também explica por que MQL é difícil de trabalhar com minhas ideias.