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 3
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
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. Es sólo que normalmente es mejor tener una descripción del concepto y del dispositivo que no tenerla.
...
No hay usuarios de librerías gráficas, lenguaje de marcas o editor visual de hecho (quizá los haya, pero no se ven). Hay gente con ganas de aprender. Si los artículos no tienen un concepto de lenguaje de marcado, no tienen sentido. Escribe un concepto. Buena suerte.
No hay usuarios de bibliotecas gráficas, lenguaje de marcas o editor visual (quizá los haya, pero no los ves). Hay gente que intenta aprender. Si los artículos no tienen un concepto de lenguaje de marcado , no tienen sentido. Escribe un concepto. Buena suerte.
Significado. ¿No hay lenguaje en el artículo, ni siquiera el concepto mismo?
¿Significado? ¿No es que no haya lenguaje en el artículo, ni siquiera está ausente el propio concepto?
El autor no describe cómo funciona el lenguaje de marcado. Haz la pregunta"¿cómo funciona el lenguaje de marcado?" y encuentra una respuesta detallada en el artículo. No la hay.
El autor no ha descrito cómo funciona el lenguaje de marcas. Haz la pregunta"¿cómo funciona el lenguaje de marcado?" y encuentra una respuesta detallada en el artículo. No la hay.
Probablemente estará en la próxima edición.
Probablemente aparecerá en el próximo número.
Yo también pensaba que estaría en el siguiente. No somos simplones aquí. Todo el mundo lo entiende.
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. Es sólo que normalmente es mejor tener una descripción del concepto y del dispositivo que no tenerla.
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 sobre las que de todas formas tengo grandes dudas.
A las supuestas lumbreras de la programación y la creación de GUI que se declararon como tales a base de ingenuos oficios se les aconseja que demuestren sus hat-trickery en sus propios hilos.
¿A quién se refiere exactamente? Sobre todo porque está en plural, y aquí no somos muchos. Si fuera en singular, habría pensado que se refería a Pedro... pero está en plural. Plantea preguntas.
¿Por qué no usas tu nombre de pila? Así no surgen preguntas innecesarias. ¿O no puedes patear el aire?
Al tema del artículo. Por quinta vez lo he releído todo con atención, neutralidad y la mayor objetividad posible. Y esto es lo esencial
1. Al principio del artículo, el autor discute clara y lúcidamente con el lector las cuestiones de relevancia de la GUI en los programas. Habla de las herramientas gráficas disponibles de MQL: objetos MT, bibliotecas e incluso un editor de vistas. Afirma que la GUI es más bien necesaria que no. Esta es una parte clara y agradable del artículo.
2. Comienza la aceleración. El autor da un ejemplo de código de librería estándar y lo critica merecidamente - es largo, inconveniente, ineficiente cuando se construye una GUI. Las simpatías están de su parte.
3. A continuación, el autor pasa a la discusión de las GUI en otros lenguajes, donde señala correctamente que la descripción del diseño está sabiamente separada del código del programa y representa una rama independiente que simplifica el diseño rutinario de las interfaces. Enumera las ventajas. Esta vez, el autor utiliza frases generales y referencias a la literatura, la plataforma .Net, Android, XML.... Dice que allí, al igual que aquí, todo está en "un solo flacon" y la jerarquía es visible, y también se definen "controladores únicos". No lo aclara, simplemente sigue. Para los no ilustrados, la claridad se acaba y todo se hunde en la niebla. Dónde, qué, por qué....
4- El autor "vuela" y el diálogo con el lector se convierte en un monólogo de alta velocidad. Desaparece la secuencia clara de presentación: preguntas/temas/soluciones/ejemplos/códigos... todo se mezcla. Por supuesto, no es difícil para los telépatas, pero los demás lo pasamos mal. Parece que el autor está pensando soluciones para un nuevo lenguaje sobre la marcha y va a terminarlo todo para el final del artículo. En plan"¡no te metas, que ya lo hago yo todo!". A un ritmo frenético, van pasando retazos de pensamientos, códigos, nombres de variables y métodos (quizá conocidos por alguien...). Los saltos son cada vez más frecuentes y mi cabeza no da abasto para buscar enlaces entre frases. Se hace realmente difícil de leer.
5. El diálogo con el lector se perdió tras los dos primeros capítulos y seguir leyendo no me aclaró nada. Aunque lo intenté con todas mis fuerzas. La pregunta seguía siendo: "¿y qué sugiere exactamente el autor?".
Cerré el artículo y no pude recordar nada excepto el ejemplo con las manchas y los primeros párrafos. Todo lo demás se disolvió en la niebla.
Esperemos que en el próximo número el autor continúe el diálogo con el lector y mantenga la estructura narrativa hasta el final del artículo.
Gracias.
Dmitry Fedoseyev, aunque ofensivo, muy divertido inserción de vídeo. Me he reído un buen rato. Cuando leí lo que resaltabas, me di cuenta de que parecía realmente estúpido. Sería más exacto decir no reescrito, sino mejorado y complementado. He leído muchos de tus artículos durante los cinco años de tu presencia en este sitio, y no dudo que tus conocimientos son muchos más que los míos, pero no estoy de acuerdo contigo en que no sea necesaria la programación orientada a objetos en la escritura exprés. Ya que en programas complejos, que usan interfaces gráficas, que combinan varios TS en un EA, que llevan estadísticas, etc, la POO ayuda mucho, a estructurar mejor el código del programa, y los patrones de diseño (aunque todavía estoy muy al principio de su estudio) aumentan muchas veces la potencia de la POO. Por supuesto, esto no significa que usted debe empujar en un pequeño EA, donde se puede hacer con los procedimientos ordinarios, y la velocidad de su escritura será muchas veces mayor. Si va a ser interesante voy a describir un ejemplo en el que he aplicado la programación orientada a objetos y una plantilla, y cómo se simplificó mi vida. Y si no es demasiado difícil Dmitry, ¿podría mostrar sus palabras"y más aún en la creación de un análogo de un delegado utilizando OOP mientras que hay punteros a funciones" en un ejemplo. O en que artículo se puede encontrar información sobre punteros a funciones. Gracias de antemano.
Todo está en la documentación, estúdiala, úsala.