Preguntas sobre POO en MQL5 - página 25
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
Hay estadísticas detalladas aquí https://githut.info/, pero es el año 14.
Estadísticas frescas en github https://madnight.github.io/githut/#/pull_requests/2019/2
Creo que todo el mundo se beneficiaría de leer la opinión profesional de este artículo.
Buena suerte
Creo que todo el mundo se beneficiaría de leer la opinión profesional de este artículo.
todas las conclusiones (totalmente tendenciosas) del artículo se compensan con una simple pregunta.
FP ha existido durante mucho tiempo, ¿por qué sigue teniendo un nicho tan pequeño si es tan impresionante?
No quiero decir en absoluto que OOP sea el mejor concepto o que OP sea una mierda.
todas las conclusiones (totalmente tendenciosas) del artículo se nivelan con una simple pregunta.
La FP existe desde hace mucho tiempo, ¿por qué sigue teniendo un nicho tan pequeño si es tan impresionante?
El artículo tiene la respuesta a esa pregunta. No lo has leído con atención.
El artículo tiene una respuesta a esta pregunta.
Totalmente tendencioso y sobre nada.
Hay desarrolladores que realmente escriben el código. Hay directivos que pueden no saber programar en absoluto.
Así que la pila tecnológica no es necesariamente elegida por los desarrolladores. Y si una determinada pila permite a un equipo resolver un problema de forma más eficiente, no es necesario conocer y poseer la tecnología para entenderla.
¿Sigue pensando que el artículo responde a la pregunta?
Creo que todo el mundo se beneficiaría de leer la opinión profesional de este artículo.
Buena suerte
Esto es lo habitual. Puntos de vista extremos. Es como una discusión sobre qué es mejor: un martillo o un mazo.
No escribirás buenas herramientas en C# pero en C puro te cansarás de describir y depurar cadenas lógicas ramificadas en una aplicación seria.
Así que este artículo no sirve de nada.
Siempre es así. Puntos de vista extremos. Es como una discusión sobre qué es mejor: un martillo o un mazo.
No escribirás buenas herramientas en C# pero en C puro te cansarás de describir y depurar cadenas lógicas ramificadas en una aplicación seria.
Así que este artículo no trata de nada.
Hay, por supuesto, algo de verdad en el artículo... al menos, que la herencia "tire" de los métodos y campos que no son realmente necesarios, pero por desgracia, usted tiene que pagar por todo - se ahorra tiempo, pero puede aumentar el uso de la memoria o el rendimiento general de una solución, pero cinco no todos tan triste, el nivel de los compiladores y la optimización del código es muy empinada ahora, por lo que la salida a menudo resulta en una buena solución para un corto tiempo de desarrollo
sobre C #, así, como si el propósito que tiene otros, es puramente un "lenguaje de Windows" para obtener rápidamente los resultados en un PC en particular o un grupo limitado de PC, incluso si no se instalan las actualizaciones .Net puede causar errores críticos en los PC que no tienen acceso, y la captura de este es bastante caro - escribió un panel para el comercio en C # ya lo comprobó en una máquina virtual, si no se instala todo el "parche" en las actualizaciones, el proyecto no puede predecir rebote ;) Por supuesto, usted puede tratar de escribir para la versión más joven de .Net, pero hay un problema - todas las noticias en GitHub publicado bajo las nuevas construcciones de .Net - es decir, que se limitará sólo a sus desarrollos
En general, como en otros lugares - la innovación es "doloroso y largo y triste", usted tiene que seguir las tendencias establecidas por los gigantes de TI, entonces todo está escrito rápidamente y sin problemas, así Microsoft escribió todo lo que podía en el estilo OOP, usted tiene que utilizar todo o va a escribir desde cero todos sus WinForm, etc miles de toneladas y terabytes de código escrito desde Win-95))
ciertamente hay un poco de verdad en el artículo...
¿Un poco? ) En realidad es así. Sin embargo, el autor no revela la verdad, es una especie de cosas obvias (al menos para mí). Pensé que cualquier programador con experiencia llega a la misma comprensión de los problemas de cambio de estado. Por cierto, hace poco he visto un artículo muy parecido pero más corto. Pero, quizás, es el eterno debate entre los funcionalistas y los programadores de código abierto )
Pero de hecho nadie te impide utilizar correctamente la POO. Incluso el autor menciona que puedes utilizar objetos inmutables. Y el 99% de los problemas descritos desaparecen inmediatamente. Así que todo depende sólo de la cuestión de las manos rectas y la cabeza sobre los hombros, no del paradigma que se utilice.
Aunque, por supuesto, el hecho de que los lenguajes de programación orientada a objetos populares no proporcionen los medios para controlar la variabilidad de los objetos, complica el proceso. Por lo tanto, sería realmente genial tener la palabra claveinmutable en lugar de const/readonly.
En cuanto a las razones de la impopularidad de los lenguajes funcionales, no estoy de acuerdo con el autor aquí. En primer lugar, es más complicada la percepción de dicho código, según me parece. No se trata sólo de una oposición de OOP y FP, sino de una oposición de enfoques imperativos y funcionales. El primero es más cercano e intuitivo para la mayoría de la gente a entender, en mi opinión. Sólo conozco los lenguajes funcionales por correspondencia, así que no puedo juzgarlos objetivamente, pero cuando, por ejemplo, veo código sobrecargado con lambda, me produce una disonancia cognitiva) Es demasiado complicado e intrincado. Y probablemente la mayoría de la gente también lo piensa )
Además, los lenguajes funcionales no están pensados para una serie de tareas relacionadas con la interacción con el entorno externo, como por ejemplo la interfaz gráfica de usuario. Cuando de una forma u otra se necesita almacenar el estado globalmente cambiado entre eventos.
¿Un poco? ) En realidad, ese es exactamente el caso. Sin embargo, el autor no está revelando las Américas, estas cosas son un poco obvias (al menos para mí). Pensé que cualquier programador con experiencia llega a la misma comprensión de los problemas de un estado cambiante. Por cierto, hace poco he visto un artículo muy parecido pero más corto. Pero, quizás, es el eterno debate entre los funcionalistas y los programadores de código abierto )
Pero de hecho nadie te impide utilizar correctamente la POO. Incluso el autor menciona que puedes utilizar objetos inmutables. Y el 99% de los problemas descritos desaparecen inmediatamente. Así que todo depende sólo de la cuestión de las manos rectas y la cabeza sobre los hombros, pero no del paradigma utilizado.
Aunque, por supuesto, el hecho de que los lenguajes OOP populares no proporcionen un medio para controlar la variabilidad de los objetos, complica el proceso. Sería genial tener la palabra clave inmutable en lugar de const/readonly.
En cualquier caso nada cambiará en un futuro próximo, los gigantes de la informática apoyan este paradigma, puede ser beneficioso para obligar a los desarrolladores de software a hacer implementaciones complejas que requerirán un hardware más potente para funcionar, así como para presentar su documentación para los SO o compiladores con bibliotecas ya hechas en forma de POO, lo que obliga a los desarrolladores .... y así hasta el infinito ;)
Podemos considerar esta historia de OOP como un conocimiento obligatorio del latín por parte de los médicos - no era necesario, pero como medio de comunicación a nivel profesional era necesario utilizarlo ;)