Autoaprendizaje del lenguaje MQL5 desde cero - página 17
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
¡Lo opuesto a ti!
Lo más importante en la programación es conocer el lenguaje al nivel más bajo posible.
Para los principiantes, un nivel bajo es la sintaxis del lenguaje sin envolturas de código adicionales.
Lo que tiene la descomposición, como tú dices, es la comprensión de cómo se componen los organigramas.
Por eso se valora a un programador no por sus fantasías filosóficas, sino por su conocimiento práctico del lenguaje.
¿Cómo se puede fantasear sin los fundamentos de la lengua? ¿Dónde está la simple lógica?
Equivalente al lenguaje de un ingeniero electrónico, que es el autor de este hilo, primero suministra voltajes a la placa, y luego se pregunta por qué la placa se quemó ))
No estoy de acuerdo. Cuando se fija un objetivo, no es necesario conocer el idioma, sólo hay que entender sus posibilidades. Pero a la hora de establecer un objetivo, resolverlo, seleccionar algoritmos y codificar, en todas estas etapas es necesario. Plantear un problema sin conocer la sintaxis del lenguaje es a veces un gran problema de aplicación))
... Equivalente, en lenguaje electrónico, que es el autor de este hilo, a aplicar primero tensiones a la placa, y luego preguntarse por qué se quemó la placa ))
¡Hola, Roman! Gran comparación. Ahora estoy en la programación al mismo nivel de ingeniero electrónico, cuando pasé de conocer los principios de los transistores a aprender los principios de los circuitos digitales K155.
Sin embargo, muchos de mis colegas en 1983 se las arreglaron para reparar ordenadores de la serie EU sin entender cómo funcionaban los transistores. Sólo necesitaban conocer el álgebra de la lógica. Fue una digresión: ¡la nostalgia de los tiempos soviéticos!
Saludos, Vladimir.
No estoy de acuerdo. Para fijar un objetivo, no es necesario conocer el idioma, sino comprender sus capacidades. Pero en el planteamiento del problema, la resolución del mismo, la selección del algoritmo y la codificación, todas estas etapas son necesarias. Plantear un problema sin conocer la sintaxis del lenguaje es a veces un gran problema de aplicación))
Entonces, ¿cómo vas a entender las posibilidades si no las conoces?)
La definición de problemas, es la etapa extrema del dominio de los fundamentos del lenguaje, cuando ya entiendes qué es una variable, qué tamaños puede tener, el alcance, etc.
También me encontraba en una encrucijada, cuando no sabía por dónde empezar, qué idioma aprender y entender todo. Fue una agonía, porque probé varios idiomas para encontrar la verdad.
Pero cuando finalmente me di cuenta de que mql era un lenguaje similar a C, empecé a aprender C de forma orientada, empezando por lo más básico.
Y cuando he terminado de estudiarlo de forma básica, me he sorprendido al comprobar que prácticamente ya conozco mql, y me queda todo claro, sólo hay que mejorar la sintaxis y las particularidades de los docks, es una característica de mql.
Habiendo entendido el enfoque procedimental de la programación, comencé a adentrarme en la POO después de un año. Durante mucho tiempo, no me quedó claro, debido a otros nombres de la misma cosa.
Por ejemplo, método y función, cuál es la diferencia )) variable y miembro de la clase )) etc.
Pero para llegar allí, es necesario entender la base misma del enfoque procedimental, y cuando se empieza a entender gradualmente la terminología de la POO, la comprensión se abre al instante.
Esa es la diferencia, la elección del camino de aprendizaje inicial. ¿Cómo se puede escribir en ruso sin conocer las letras y los signos de puntuación?
Recuerda dónde empezaste, con ganchos y palos.
¡Lo opuesto a ti!
El factor determinante en la programación es el conocimiento del lenguaje, ¡a un nivel tan bajo como sea posible!
¿Qué se consigue con ello? Conoce el idioma a un nivel muy bajo. Sabes qué comandos de ensamblador se sustituyen por if, cómo se convierte el bucle for en goto. Ya conoces el ensamblador. ¿Dónde está el beneficio en eso? Fíjate en los programadores de Python. No saben nada de esto. Pero son muy buenos en el manejo de funciones, saben cómo Map/Reduce. Son capaces de componerlos y de introducirlos entre ellos. ¿Y dónde está MQL ahora que no se escribe tanto en él en comparación con Python?
¿Cómo se puede fantasear sin los fundamentos de la lengua? ¿Dónde está la simple lógica?
Es similar a la lengua electrónica, que es el autor de este hilo, en primer lugar para suministrar tensiones a la placa, y luego se preguntan por qué la placa se quemó ))
En su comprensión de la lógica simple, es un procedimiento de venta libre. A mi modo de ver, es como el lenguaje de montaje: "lo que veo es lo que canto". No hay ninguna lógica en eso, sólo es una tontería de la escritura. Un mecanógrafo puede hacerlo tras un curso de formación de dos semanas. Eso no es programar.
En cuanto a la descomposición, tal y como lo planteas, es entender cómo se componen los organigramas.
¿Y cuál sería el beneficio de tal conocimiento? Conoce el idioma a un nivel muy bajo. Sabes qué comandos de ensamblador sustituyen al if, cómo se convierte el bucle for en goto. Ya conoces el ensamblador. ¿Dónde está el beneficio en eso? Fíjate en los programadores de Python. No saben nada de esto. Pero son muy buenos en el manejo de funciones, saben cómo Map/Reduce. Son capaces de componerlos y de introducirlos entre ellos. ¿Y dónde está MQL hoy en día donde no escriben tanto como en Python?
En su comprensión de la lógica simple, es algo terriblemente procedimental. En mi forma de entender la lógica es como en el ensamblador: "lo que veo, eso canto". No hay ninguna lógica en eso, sólo es una tontería de mecanografía. Un mecanógrafo puede hacerlo tras un curso de formación de dos semanas. No se trata de programar.
Un diagrama de flujo es un diagrama para JD de procedimiento. "Aquí está el bucle for, aquí está el bucle if". Hoy en día no escriben en lenguajes procedimentales. Esto no tiene sentido para que una aplicación de usuario elija, por ejemplo, C o Pascal. Para el núcleo de un SO o algún otro lenguaje procedimental es el mejor. Pero se trata de un porcentaje muy pequeño de tareas y está claramente fuera del alcance de la tarea en cuestión.¿Y cuál sería el beneficio de tal conocimiento? Conoce el idioma a un nivel muy bajo. Sabes qué comandos de ensamblador sustituyen al if, cómo se convierte el bucle for en goto. Ya conoces el ensamblador. ¿Dónde está el beneficio en eso? Fíjate en los programadores de Python. No saben nada de esto. Pero son muy buenos en el manejo de funciones, saben cómo Map/Reduce. Son capaces de componerlos y de introducirlos entre ellos. ¿Y dónde está MQL hoy en día donde no escriben tanto como en Python?
En su comprensión de la lógica simple, es algo terriblemente procedimental. En mi forma de entender la lógica es como en el ensamblador: "lo que veo, eso canto". No hay ninguna lógica en eso, sólo es una tontería de la escritura. Un mecanógrafo puede hacerlo tras un curso de formación de dos semanas. No se trata de programar.
Un diagrama de flujo es un esquema para lenguajes procedimentales. "Aquí está el bucle for, aquí está el bucle if". Hoy en día nadie escribe en lenguajes procedimentales. Esto no tiene sentido para que una aplicación de usuario elija, por ejemplo, C o Pascal. Para el núcleo de un sistema operativo o algún otro lenguaje procedimental es el mejor. Pero se trata de un porcentaje muy pequeño de tareas y está claro que no entra en el ámbito de la tarea.Para que te hagas una idea, Python está escrito en C.
Y Python fue diseñado para facilitar la escritura de código. Pero al haberse convertido en un lenguaje popular por su aparente sencillez, los conocimientos de los programadores siguen estando al nivel de Python.
Y sólo los programadores que saben C escriben bibliotecas y cosas adicionales a él. Son programadores y no codificadores.
Ese es el punto en el que una simple mecanógrafa de código ganará a los codificadores con su comprensión del tema.
Tú sólo eres un C#-nik, por eso tienes esa apariencia, pero ni siquiera piensas en qué lenguaje está escrito este lenguaje C#))
Entonces, ¿cómo vas a entender las posibilidades si no las conoces?)
El planteamiento de problemas es la etapa extrema del dominio de los fundamentos de un lenguaje, cuando ya entiendes qué es una variable, qué tamaños puede tener, los ámbitos, etc.
También me encontraba en una encrucijada, cuando no sabía por dónde empezar, qué idioma aprender y entender todo. Fue una agonía, porque probé varios idiomas para encontrar la verdad.
Pero cuando finalmente me di cuenta de que mql era un lenguaje similar a C, empecé a aprender C de forma orientada, empezando por lo más básico.
Y cuando he terminado de estudiarlo de forma básica, me he sorprendido al comprobar que prácticamente ya conozco mql, y me queda todo claro, sólo hay que mejorar la sintaxis y las particularidades de los docks, es una característica de mql.
Habiendo entendido el enfoque procedimental de la programación, comencé a adentrarme en la POO después de un año. Durante mucho tiempo, no me quedó claro, debido a otros nombres de la misma cosa.
Por ejemplo, método y función, cuál es la diferencia )) variable y miembro de la clase )) etc.
Pero para llegar allí, es necesario entender la base misma del enfoque procedimental, y cuando se empieza a entender gradualmente la terminología de la POO, la comprensión se abre al instante.
Esa es la diferencia, la elección del camino de aprendizaje inicial. ¿Cómo se puede escribir en ruso sin conocer las letras y los signos de puntuación?
Piensa en el punto de partida, con anzuelos y palos.
No sé qué decir. Cada uno tiene su propia manera, supongo. No insisto. Pero los objetivos pueden resolverse en diferentes idiomas, y uno puede no conocer la sintaxis a la hora de elegir un objetivo, sino sólo las posibilidades. Hay bibliotecas para sitios web en python, y el sitio se puede hacer en python, pxp, jumla, html o cualquier otro, es una cuestión de precio y la disponibilidad de la funcionalidad listo (scripts), y esto es una declaración de problemas y requiere un conocimiento más profundo de la lengua. Podemos seleccionar los siguientes scripts para trabajar con series: MKL, Python, R y Matlab. El MCL nativo será suficiente para la fijación de órdenes por parte de los MA.
Todo tiene que estar en armonía. Conocer la mecánica del coche no es lo mismo que conducirlo bien. Pero no conocer el mecanismo es malo para las averías en la carretera).
Y a cada uno lo suyo, a menudo un buen codificador no es un buen algoritmo y viceversa. Si estas cualidades son buenas juntas, es genial y caro normalmente, pero no tan a menudo.))))
¿Y qué lograría ese conocimiento? Conoce el idioma a un nivel muy bajo. Sabes qué comandos de ensamblador sustituyen al if, cómo se convierte el bucle for en goto. Ya conoces el ensamblador. ¿Dónde está el beneficio en eso? Fíjate en los programadores de Python. No saben nada de esto. Pero son muy buenos en el manejo de funciones, saben cómo Map/Reduce. Son capaces de componerlos y de introducirlos entre ellos. ¿Y dónde está MQL hoy en día donde no escriben tanto como en Python?
En su comprensión de la lógica simple, es algo terriblemente procedimental. En mi forma de entender la lógica es como en el ensamblador: "lo que veo, eso canto". No hay ninguna lógica en eso, sólo es una tontería de escritura. Un mecanógrafo puede hacerlo tras un curso de formación de dos semanas. No se trata de programar.
Un diagrama de flujo es un diagrama de flujo para lenguajes procedimentales. "Aquí está el bucle for, aquí está el bucle if". Hoy en día nadie escribe en lenguajes procedimentales. Esto no tiene sentido para que una aplicación de usuario elija, por ejemplo, C o Pascal. Para el núcleo de un sistema operativo o algún otro lenguaje procedimental es el mejor. Pero se trata de un porcentaje muy pequeño de tareas y está claro que no entra en el ámbito de la tarea.Es mucho, es la forma correcta de hacer las cosas. Lo ideal es que el cliente sea un buen codificador)) Cuántos nervios se ahorrarían)))
Conocer un lenguaje de bajo nivel no invalida el conocimiento de los lenguajes de alto nivel, y sólo te da una comprensión más profunda de cómo funciona el programa. Y si sabe cómo funcionan los bucles go-to y cuánta memoria consumen, puede optimizarlos si es necesario. No más que eso.
Para ser sincero, no entiendo el sentido de la discusión.
...
Y francamente no entiendo el sentido de la discusión.