Mt4 Fin de soporte. - página 11
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
Vladimir:
¿Tal vez para organizar la interfaz con el usuario? Así, los Asesores Expertos y los scripts están diseñados para sustituir a los humanos en el ordenador, esta interfaz contradice directamente su propósito, no es necesaria. Es decir, está en el camino. Al igual que los elementos innecesarios en una navaja. O un clavador en el extremo del mango de acero de un martillo universal: no sólo raya, sino que desplaza el centro de gravedad del percutor al mango.
No estoy de acuerdo con usted en este punto en particular.
Una interfaz gráfica puede ser necesaria para los algotraders que entienden que un EA totalmente automatizado es, de lejos, mucho menos eficaz que uno semiautomatizado. La combinación de operaciones automatizadas y manuales puede ser más profesional y rentable desde el punto de vista de las operaciones. Cuando la gente se dé cuenta de esto, sus robots necesitarán definitivamente una interfaz.
1. graph_id puede ser leído por una persona de habla rusa más rápidamente que m_chart_id.
2. Si hay cientos de variables en un programa, el idioma ruso proporciona un apoyo indispensable.
Todo esto se puede comprobar en un experimento.
La velocidad de lectura y comprensión del código en la lengua materna siempre será más rápida y la memorización será mejor.
Sólo tienes que conocer las reglas de denominación de las variables en ruso. En lugar de "variable_to_store_general_profit_position, sólo: general_profit.
Si hay cientos de variables en un programa, la mayoría de ellas probablemente puedan combinarse mediante estructuras. Además, no te olvides de utilizar las funciones.
Muchas variables no tienen ningún significado, porque son contadores, almacenamientos temporales de datos intermedios, y se utilizan detrás de un montón de paréntesis. Y lo mejor de todo es que detrás de todos los paréntesis podemos volver a utilizar las mismas variables, pero de nuevo entre paréntesis {....}
O bien escribir inicialmente en OOP.
Me parece que la esencia de su rechazo a la OOP radica en esto. Podría estar equivocado, por supuesto, pero suelo sentir a la gente.
En mi opinión, el problema de la mayoría de los que no son OOB es una resistencia interna a "limitar los derechos legales".
Un programador de la vieja escuela está acostumbrado a tener acceso completo a cualquier dato, cualquier bloque, cualquier entidad del programa en cualquier momento. Y el enfoque OOP implica lo contrario - la máxima limitación de los derechos, cuando usted - tiene acceso a una parte muy pequeña de los datos y acciones del programa.
Según recuerdo, no me gustó mucho. En los primeros días de Windows, recuerdo que me disgustaba mucho el acceso a la memoria protegida: no puedo acceder a la dirección que me gusta, ¿y qué si está en el núcleo del sistema? Incluso podría querer leerlo desde un programa o cambiarlo en absoluto. Incluso programé un controlador de acceso directo a la memoria, que enviaba datos a la "zona permitida" desde la "zona prohibida", saltándose las restricciones del sistema.
Pero, con el tiempo, realmente aprecié todas estas restricciones. Un acceso "innecesario" siempre puede convertirse en un error. Así que es muy inteligente trasladar el trabajo de control de acceso - al compilador.Restringir el acceso aquí resulta ser "a prueba de tontos", no de "violación de sus derechos". Si necesitas un acceso que no tienes, sólo significa que has diseñado mal el sistema: deberías haberlo previsto si lo necesitabas.
Y ahora, por el contrario, siempre limito el acceso al máximo. En cualquier punto debe haber acceso sólo a las entidades que sean necesarias. Todas las demás entidades deben ser inaccesibles. Esto le protege de errores con el acceso a lugares que no debería, y también le acostumbra a una determinada secuencia de desarrollo del sistema, en la que cada operación se realiza en un lugar, y ningún otro lugar se ve afectado.
Por ejemplo, odio los inludes en forma de librerías, sólo porque no sé lo que ponen ahí y cómo puede ayudarme, es más fácil escribir una docena de funciones más
similar a lo que estoy acostumbrado con Re-Tag Konow.
¿Y por qué?
Una misma función se requiere en muchos lugares - ¿por qué copiar funciones cuando se puede tener todo en las bibliotecas, y no abarrotar el código principal con bloques innecesarios?
¿Y por qué?
Una misma función es necesaria en muchos lugares: ¿por qué copiar funciones cuando se puede tener todo en bibliotecas y no abarrotar el código principal con bloques innecesarios?
Se te da bien encontrar argumentos, Nikolai).
También la abuela puede asimilar todo sin problemas. Simplemente, inconscientemente, no quiere que ninguna baratija arrastre su mente asentada en un ciclo de información innecesaria. Con razón).
Peter, así que resulta que eres una abuela.
Hola
Tal vez pueda recibir ayuda aquí. Tengo una pregunta para los desarrolladores de MT4. Dónde se puede expresar. Si es en este foro, ¿en qué hilo? ¿O en otro lugar? Si lo sabes, por favor, dímelo.
No estoy de acuerdo con usted en este punto en particular.
Una interfaz gráfica puede ser necesaria para los algotraders que se dan cuenta de que un EA totalmente automatizado es, con mucho, mucho menos eficaz que uno semiautomatizado. La combinación de operaciones automatizadas y manuales puede ser más profesional y rentable desde el punto de vista de las operaciones. Cuando la gente se dé cuenta de esto, sus robots necesitarán definitivamente una interfaz.
Apoyas totalmente a quien dice que mql sólo debe tener funciones de acceso al servidor, y todo lo demás mediante muletas debe ser programado por herramientas de desarrollo de terceros. No te desvíes de la línea del partido. Sé coherente: vuelca todos tus desarrollos en mql y haz un puente -en el estudio, por ejemplo- o donde vayas a escribir tus lienzos... Entonces informa de tu próxima victoria sobre el molino.
Por ejemplo, odio los inludes en forma de librerías, sólo porque no sé lo que ponen ahí y cómo puede ayudarme, es más fácil escribir una docena de funciones más
similar a la de Retrog Konow.
Bueno, la ley de conservación de la energía: ¿para qué descompilar la biblioteca y entenderla si todo funciona sin ella?
P.D.
¿Has visto mi top sobre los alces?
Cuando sus códigos comienzan a desbordar 10, 20, 30, ... , 100 mil líneas, luego vuelve y dime cómo copias tus códigos en tal volumen.
En mi opinión, el problema de la mayoría de los que no son OOB es una resistencia interna a "limitar los derechos legales".
Un programador de la vieja escuela está acostumbrado a tener acceso completo a cualquier dato, cualquier bloque, cualquier entidad del programa en cualquier momento. Y el enfoque OOP implica lo contrario - la máxima limitación de los derechos, cuando usted - tiene acceso a una parte muy pequeña de los datos y acciones del programa.
Según recuerdo, no me gustó mucho. En los primeros tiempos de Windows, recuerdo que me disgustaba mucho el acceso a la memoria protegida: no puedo acceder a la dirección que me gusta, ¿y qué si está en el núcleo del sistema? Incluso podría querer leerlo desde un programa o cambiarlo en absoluto. Incluso programé un controlador de acceso directo a la memoria, que enviaba datos a la "zona permitida" desde la "zona prohibida", saltándose las restricciones del sistema.
Pero, con el tiempo, realmente aprecié todas estas restricciones. Un acceso "innecesario" siempre puede convertirse en un error. Así que es muy inteligente trasladar el trabajo de control de acceso - al compilador.Restringir el acceso aquí resulta ser "a prueba de tontos", no de "violación de sus derechos". Si necesitas un acceso que no tienes, sólo significa que has diseñado mal el sistema: deberías haberlo previsto si lo necesitabas.
Y ahora, por el contrario, siempre limito el acceso al máximo. En cualquier momento, sólo deben estar disponibles las entidades a las que es necesario acceder. Todos los demás objetos deben ser inaccesibles. Esto le protege de errores con el acceso a lugares que no debería, y también le acostumbra a una determinada secuencia de desarrollo del sistema, en la que cada operación se realiza en un lugar, y ningún otro lugar se ve afectado.
Has dado un buen ejemplo de lo que puede repeler la OOP.
En mi caso fue un poco diferente. Me propuse aprender POO, pero llegó un momento en que dejé de verle utilidad práctica. A día de hoy, eso no ha cambiado. Todo porque formé mi enfoque, que empujó a la OOP fuera de mi práctica.
Esta afirmación -que la limitación de acceso es una protección necesaria que salva de los errores- es algo que no puedo entender en absoluto. Si los nombres de las variables coinciden en diferentes partes del programa, por supuesto que sí. Pero si hay una memoria global común de todas las variables globales principales en un array, no necesitas restricciones y no habrá confusión.