Lo que me gustaría del "terminal" como programador profesional. Otro hilo con deseos para MQL5.
Ese es un enfoque constructivo, no es un pecado apoyarlo.
No me gusta, no me gusta :-)
Supongo que no han encontrado una alternativa a la MT y han decidido contribuir a su mejora. :-)
Ese es un enfoque constructivo, no es un pecado apoyarlo.
Si no, no me gusta, no me gusta :-)
Supongo que no han encontrado una alternativa a la MT y han decidido contribuir a su mejora. :-)
Es una extraña forma de pensar... A veces es sorprendente.
Que no me guste la calidad de la pintura de Mercedes, no significa que no me guste la marca DB. No soy el tipo de persona que "le gusta todo" en lo suyo y "no le gusta todo" en lo ajeno. No soy un fanático sólo soy un programador, y puedo decir que la calidad del compilador en MT simplemente apesta - ¡¡¡así se escriben los compiladores!!! ¿Y qué? ¿Qué diferencia hay? El editor de texto es una mega pesadilla para el 2008. Y qué. Como programador, es sólo mi apreciación. Porque _yo_ escribiría mejor. Pero el producto me gusta o no me gusta no por nimiedades, sino por lo principal.
Y el hecho de que las personas que propusieron esta arquitectura-idea - "sin APIs y todo propio". Se equivocan al 100% en el concepto de marketing y de negocio. Y sólo por pereza nadie hace su "clon", que sería ligeramente mejor y que simplemente dividiría el mercado, si se lanzara. Y no está claro quién saldrá... Están cortando la rama en la que están sentados. PERO ESTO es sólo mi opinión profesional personal. Al no dar el API están estimulando la creación de un clon. Es importante entender esto. Pero eso no significa que piense que MT es el producto más lamentable del mundo. ¿De dónde has sacado eso? Seré sincero: he visto productos mejores. Pero todos ellos son para los CORREDORES. Mucho mejor. Pero sus servidores están lejos y el ping es alto.
1. Crear gráfico. Esto sería demasiado bueno, pero probablemente innecesario.
2. Debería ser posible exportar a archivos metastock y omega, como en todos los terminales, sin ningún truco adicional hecho por uno mismo. Y debería ser posible enviar comandos comerciales a la terminal desde programas externos. Olvídate de la posibilidad de que el broker prohíba o permita el trabajo de los Asesores Expertos en el lado del cliente... No diré ni una palabra. En mi humilde opinión, el broker debería evaluar sólo el número de transacciones del trader por unidad de tiempo y bloquear su trabajo en base a este valor.
En general, apoyo a MProgrammer.
En mi opinión MQ ha tomado la dirección correcta - AutoTrading. Y el futuro, en mi opinión, está en los autómatas y semiautomáticos... cosechadoras y analizadores, apuntadores con asesores - configurables a voluntad del comerciante. Por lo tanto, la programación, por supuesto, debe estar al día. La API está pitando como debe ser. Cómo comercializar el programa (bueno, a eso se llega) si tiene cara de DOS:(
En general, apoyo a MProgrammer.
En mi opinión MQ ha tomado la dirección correcta - AutoTrading. Y el futuro, en mi opinión, está en los autómatas y semiautomáticos... cosechadoras y analizadores, apuntadores con asesores - configurables según la voluntad del comerciante. Por lo tanto, la programación, por supuesto, debe estar al día. La API está pitando como debe ser. Cómo promocionar el programa en el mercado (bueno, vamos a hacerlo de todos modos), si tiene cara de DOS:(
Buenos pensamientos expresados por MProgrammer
Sí, por supuesto, una API completa sería genial.
¡La integración sería mucho más fácil de hacer!
pero aquí entiendo perfectamente la reticencia de los DESARROLLADORES a dar la API...
para no engendrar "magos" que creen sus propios terminales... "toma el conjunto de DLL y no necesitas nada más"...
se obtiene una conexión y solicitudes de pedidos en forma de API
Muchos comenzarán a escribir sus terminales o programas para el comercio automatizado ... sin usar un terminal en absoluto ...
dibujar sus propios gráficos en C++, VB, Delphi, gestionar pedidos por supuesto que hay una forma de combatirlo... lástima que el método sea la falta de API
pero aquí entiendo perfectamente a los DESARROLLADORES, con una reticencia a dar API...
Muchos comenzarán a escribir sus propios terminales o programas - para el comercio automatizado ... no utilizar el terminal en absoluto
Estoy casi 1000% seguro, :))) Si no pudiéramos hacer ningún terminal, los chicos de MT estarían muy contentos. :)) Pero aquí, por desgracia, es difícil vender sólo servidores. :))... Es una pena, ¿no?
Tal vez el autotrading sea ya muy presente detrás de él :)
Entiendo que los desarrolladores intenten hacer todo en un solo paquete, su propio lenguaje, compilador y editor. Tal vez el lenguaje truncado, comparado con C, se deba al miedo a los errores, porque todo puede ser primitivo, pero se garantiza que funcione. Creo que este es el enfoque correcto para un sistema de comercio porque el precio de un error es alto aquí.
Creo que deberíamos desarrollar un enfoque de integración con programas externos. De todos modos, no voy a escribir nada serio en MQL4, ya que creo que no es realista.
Voy a hacer todo el análisis en programas externos y utilizaré el Asesor Experto para conectar con ellos. Y esta conexión, según veo, puede ser sólo las llamadas a la función de la DLL externa.
Sugiero complementar estos métodos.
Sobre el editor. Entiendo que un buen editor es difícil de hacer. Así que nos dan la oportunidad de utilizar un editor externo, de modo que cuando un cambio externo al archivo, se vuelve a cargar, así, como en todo el editor normal se hace.
Los que gritan que no les gusta algo siempre están llenos de los que no gritan sino que simplemente hacen (un perro ladra y una caravana corre), bien o mal, pero hacen y corrigen errores que son inevitables, porque sabes que sólo el que no hace nada no se equivoca. Muchos pueden argumentar que escribiría mejor , pero en la práctica no muestran nada que merezca la pena, sólo de boquilla.
> Y lagente que sugirió esta idea de arquitectura - "no hay API y todo es propio" - está 100% equivocada en el marketing.Se equivocan al 100% en el concepto de marketing y de negocio.
A juzgar por esta afirmación, ¿se considera usted también un mercadólogo? :-)
Creo que se sobreestima :-)
En cuanto al producto en sí, todo el mundo conoce sus deficiencias sin necesidad de que tú las conozcas, y haz sugerencias para su mejora.
Pero atención: - "sugerencias de mejora" y no críticas desnudas e innecesarias. Eso es lo que escribí en el post anterior.
Los que gritan que no les gusta algo siempre están llenos de los que no gritan sino que simplemente hacen (un perro ladra y una caravana corre), bien o mal, pero hacen y corrigen errores que son inevitables, porque sabes que sólo el que no hace nada no se equivoca. Dicen que escribirán mejor , pero no demuestran nada bueno en la práctica, sólo de boquilla.
+1 ))))) Sólo el que no hace nada se equivoca.
Siempre hay muchos gritones que no les gusta algo y no gritan sino que simplemente hacen, (Un perro ladra, una caravana corre), bien o mal, pero hacen, corrigen errores que son inevitables, porque sabemos que sólo el que no hace nada no se equivoca. Muchos pueden argumentar que escribiría mejor , pero en la práctica no muestran nada que merezca la pena, sólo de boquilla.
> Y lagente que sugirió esta idea de arquitectura - "no hay API y todo es propio" - está 100% equivocada en el marketing.Se equivocan al 100% en el concepto de marketing y de negocio.
A juzgar por esta afirmación, ¿se considera usted también un mercadólogo? :-)
Creo que se sobreestima :-)
En cuanto al producto en sí, todo el mundo conoce sus deficiencias sin necesidad de que tú las conozcas, y haz sugerencias para su mejora.
Pero atención: - "sugerencias de mejora" y no críticas desnudas e innecesarias. Eso es lo que escribí en el post anterior.
¿No estaba discutiendo contigo? No. Y te pido que te abstengas de decir "me estoy sobreestimando"...
Ya he escrito antes, expreso mi punto de vista. Y no con la expectativa de que la suya cambie. Espero que quede claro.
Si no entiendes que tengo razón en términos de negocios, entonces probablemente sea tu problema, porque digo cosas generalmente triviales que no son de hecho controvertidas.
Así que te sugiero que te guardes tu valoración sobre mí.
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
He estado leyendo el hilo de los deseos de MQL5, pero es muy amateur, lo siento, en algunas partes. Sólo quería crear este tema...
La esencia de lo que me gustaría ver en el nuevo sistema, la esencia misma, la idea misma... No hay muchos detalles...
Está claro que MT tiene su propia visión de lo que hace y probablemente ya ha pasado a mejor vida, y probablemente mi visión de "lo que necesitamos" no se verá reflejada en esta versión, pero aun así quería decir exactamente: "lo que necesitan los programadores". Es muy probable que los no programadores también lo necesiten, pero no lo saben.
Así que - me gustaría ver un núcleo - un análogo de la terminal actual. Y la posibilidad de crear programas que dibujen gráficos. Podría adjuntar topes de indicadores a la clase Chart y dibujarlos en su ventana... La ventana debe tener algunos botones estándar, propiedades estándar y otras cosas estándar. Pero la ventana debe ser libre, no una subventana en el terminal. PERO también me gustaría poder tener una ventana como subventana del terminal. ¿Por qué lo necesito? En primer lugar, porque las ventanas "libres" las puedo organizar con más flexibilidad.
En segundo lugar, no me gustaría cargar a los programadores de MT con el desarrollo de mega editores de código fuente, porque es esencialmente una invención de la bicicleta. Y utilizar por ejemplo el estudio. Pero lo importante es que los programas escritos incluso en studio, por ejemplo en C#, utilizarían algún tipo de clase gestora, a través de la cual podría dar salida a los gráficos en la ventana de gráficos.
En tercer lugar, si no queremos dar la API para el comercio - que sea completamente dentro de la terminal, y el intercambio de datos con el mundo exterior se haría sólo a través de algunos datos - por lo que tendríamos más comida para los lobos y las ovejas ... Pues bien, es necesario dibujar los gráficos y disponer de los datos históricos en programas externos, y crear estos programas en entornos profesionales. Y ahora puedes tener los datos, pero tienes que dibujarlos tú mismo, y no es una tarea fácil.
Eso es todo en pocas palabras...