Discusión sobre el artículo "El lenguaje MQL como medio de marcado de la interfaz gráfica de programas MQL. Parte 1" - página 2
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
...
...como mql no tiene delegados, tuve que entender que es este plato y con que se come. Tuve que reescribir todas las clases estándar. Empecé por el principio, con CObject. Al final escribí una simple implementación de OnTradeTransaction, OnChartEvent, OnTimer procesamiento de eventos con la ayuda de "real" OOP....
.
.
con la mano en el corazón - CObject y"Standard Library" son todavía un legado de los años 90 :-))
hasta que no haya una STL similar que no requiera atributos adicionales de las instancias y/o la presencia de "adam" (gran clase/antepasado común) habrá problemas significativos - la parte visible de los cuales es la cantidad de código de los programas de aplicación. Son jodidamente enormes....
Con la mano en el corazón - CObject y"Standard Library" son un legado de los años 90 :-)
hasta que no haya una STL similar que no requiera atributos adicionales de las instancias y/o la presencia de "adam" (gran clase/antepasado común) habrá problemas significativos - la parte visible de los cuales es la cantidad de código de los programas de aplicación. Son jodidamente enormes....
CObject no es el punto aquí. OOP != Patrones, no confundas donde se usa el poder de los patrones y donde se usa el poder de la OOP. No hay ninguna necesidad especial de POO, y menos de patrones, al escribir expresso, y menos para crear un análogo de un delegado usando POO mientras haya punteros a funciones.
Por triste que sea, la broma sobre el "club de las víctimas de C++" se está haciendo realidad. Es extraño que la gente se amontone con todo tipo de chanchullos y lo considere codificación guay. Pero de hecho, un programador moderno ha degenerado en un enchufado de librerías.CObject no es lo principal aquí. OOP != Plantillas, no confundas donde se usa el poder de las plantillas y donde se usa el poder de la OOP. No hay ninguna necesidad especial de OOP, y mucho menos de plantillas, en expreso-escritura, y mucho menos crear un análogo de un delegado usando OOP mientras haya punteros de función.
Por triste que sea, el chiste sobre el "club de las víctimas de C++" se está haciendo realidad. Es extraño que la gente se amontone con todo tipo de chanchullos y lo considere codificación guay. De hecho, un programador moderno ha degenerado en un enchufado de librerías."¿cuál es el poder, hermano?"
los "library pluggers" deberían gobernar. En realidad es correcto cuando reduce el tamaño del código y el tiempo de desarrollo.
PS/ hasta ahora todos los artículos publicados (y sus desarrollos, que es más importante) son la antítesis de la programación - no aumentan la eficiencia.
"¿Cuál es el poder, hermano?"
library_plugins debería gobernar. En realidad es lo correcto cuando reduce el tamaño del código y el tiempo de desarrollo.
PD/ hasta ahora todos los artículos publicados (y sus desarrollos, que es más importante) son la antítesis de la programación - no aumentan la eficiencia.
El poder está en el conocimiento, y los artículos sólo dan conocimiento y nada más deberían dar. Aumentar la eficiencia es una cuestión personal de cada uno. Aumentar la eficiencia de la programación es ciertamente bueno, pero no cuando hace que el usuario del programa se sienta menos cómodo.
... De hecho, el programador moderno ha degenerado en un plugger de bibliotecas.
Pronto desaparecerá por completo, ya que será posible construir "objetos" (grupos de parámetros con nombre y vínculos predefinidos) de forma intuitiva y sin educación superior, con el apoyo de IDE "intelectualmente desarrollados", que "comprenderán" la esencia de la estructura lógica que se está construyendo a partir de "media palabra". El entorno espabilará y la era de los programadores especializados y la diversidad de lenguajes llegará a su fin. Todo el mundo será capaz de construir algoritmos leyendo las instrucciones del programa. Un proceso natural, nada de qué preocuparse..... Es extraño que no haya empezado antes, pero en cambio han proliferado los lenguajes que repiten un mismo concepto de diferentes maneras.
No habrá XML. Se trata de prescindir de MQL. El objetivo es hacer un sistema de marcado a nivel MVP "nativo" de MQL - sin florituras, pero lo suficientemente funcional y extensible para aquellos que lo necesiten. Será posible no entrar en la estructura interna. Sólo que normalmente es mejor tener una descripción del concepto y del dispositivo que no tenerla.
A mi tampoco me vuelve loco la librería estándar, pero no hay mucho donde elegir, así que es (por ahora) el mejor compromiso entre esas pocas librerías muy pequeñas y super lujosas que de todas formas tienen grandes interrogantes.
A las supuestas lumbreras de la programación y la creación de GUIs, que se declaran como tales a base de ingenuas manualidades, se les recomienda que demuestren su hat-trickery en sus propios hilos.
...
Se recomienda a las luminarias imaginarias de la programación y la creación de interfaces gráficas de usuario que se declararon como tales a base de ingenuos oficios que demuestren su habilidad con el sombrero en sus propios hilos.
Bingo.