¿Qué puede hacer el código OOP que no pueda hacer el código procedimental? - página 4
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
¿Realmente esperas que alguien profesional publique una librería compex, sin más, como "prueba"? ;) Podría poner un enlace a algo que no se puede vender en el mercado aquí, pero Alain me va a dar una patada si lo hago ;) Puedes visitar mi perfil y echar un vistazo a la foto del muro para hacerte una idea o enviarme un correo electrónico.
¿Otra plataforma? No encontrarás ninguna otra plataforma con un compilador tan potente. En absoluto.
@James Cater - muchas gracias por tus comentarios.
Hay otras plataformas además de MT, en cuanto a que el compilador sea más o menos potente realmente no me importa mientras pueda escribir código simple.
Lo que te falta aquí es educación, todos seguimos aprendiendo, sólo que algunos están más avanzados que otros. Que yo sepa esto no es un concurso, más bien un lugar de intercambio de conocimientos y apoyo.
Y por cierto, no creo que nadie en este foro escriba un programa de un millón de líneas.
No has entendido el punto Dirk. La gente no especializada quiere ejemplos de código simples y claros, que de hecho era mi objetivo con este tema. Pero eso parece estar completamente fuera del alcance de los especialistas.
Los últimos lenguajes intentan simplificar las cosas para que las personas con menos conocimientos de codificación puedan sumarse al grupo de "codificadores". El mejor ejemplo es el pseudo lenguaje HTML. Y ese es el gran error. Cuando se desarrolló MT5 muchos "novatos" culparon al estilo OOP porque era difícil. Pero la verdad es que cada trabajo tiene sus profesionales. Si quieres mejorar una plataforma la tienes compleja. Más características, más flexibilidad. Dejar que gente sin conocimientos de codificación lo intente es como si alguien sin saber construir casas hiciera una. Será un desastre.
La longitud de los proyectos depende del programador. Mi biblioteca es de tamaño medio para el lenguaje MQL. Otros sólo necesitan pequeñas bibliotecas para crear herramientas. En mi caso prefiero gastar tiempo en crear framework para ahorrar tiempo y simplificar el desarrollo en un futuro. Si tienes que hacer UIs complejas o reutilizar código para otros proyectos es la manera más inteligente.
Los últimos lenguajes intentan simplificar las cosas para que las personas con menos conocimientos de codificación puedan sumarse al grupo de "codificadores". El mejor ejemplo es el pseudo lenguaje HTML. Y ese es el gran error. Cuando se desarrolló MT5 muchos "novatos" culparon al estilo OOP porque era difícil. Pero la verdad es que cada trabajo tiene sus profesionales. Si quieres mejorar una plataforma la tienes compleja. Más características, más flexibilidad. Dejar que gente sin conocimientos de codificación lo intente es como si alguien sin saber construir casas hiciera una. Será un desastre.
La longitud de los proyectos depende del programador. Mi biblioteca es de tamaño medio para el lenguaje MQL. Otros sólo necesitan pequeñas bibliotecas para crear herramientas. En mi caso prefiero gastar tiempo en crear framework para ahorrar tiempo y simplificar el desarrollo en un futuro. Si tienes que hacer UIs complejas o reutilizar código para otros proyectos es la manera más inteligente.
¿Así que la gente no puede adquirir conocimientos?
Procedimental vs OOP es un debate inútil, hace 3 años ya se discutió y mi respuesta es completamente válida, aquí no se ha dicho nada más :
Foro sobre trading, sistemas automatizados de trading y prueba de estrategias de trading
Programadores: Cual es tu perferencia: OOP vs Procedural
Alain Verleyen, 2013.06.11 13:11
A tu encuesta le falta una opción para los que no prefieren nada. Quiero decir, esto no es sólo una cuestión de preferencia, que no tiene sentido utilizar OOP para un pequeño script o incluso un simple EA. La POO siempre añade trabajo y sólo es ventajosa para proyectos complejos y reutilización de código (el mismo código utilizado en varios proyectos). Complejo no es lo mismo que grande, si alguien tiene un proyecto grande pero relativamente simple esto no significa automáticamente que deba usar POO .
Se puede ver el gran potencial de la POO con el MQL5 Wizard desarrollado por Metaquotes, sería muy difícil desarrollar una herramienta así con programación procedimental,aunque es factible.
La POO debe ser utilizada:
A partir de ahora no aceptaré ningún post que no sea concreto, sin ejemplo de código que demuestre por qué y cómo se debe utilizar mejor la POO en los casos anteriores.
Procedimental vs OOP es un debate inútil, hace 3 años ya se discutió y mi respuesta es completamente válida, no se ha dicho nada más aquí :
OOP debe ser utilizado :
A partir de ahora no aceptaré ningún post que no sea concreto, sin ejemplo de código que demuestre por qué y cómo OOP debe ser mejor utilizado en los casos anteriores.
He leído todo este tema, y me parece interesante, pero ¿el código máquina no es procedimental? Así que los lenguajes de alto nivel, y OOP incluido, todos ellos al final se traducen en procedural en el compilador, ¿no? Si todos los lenguajes se traducen a código máquina procedimental, entonces podemos decir que todo se puede hacer en procedimental, si el programador consigue las habilidades, por favor que alguien me corrija si me equivoco
Todo se puede hacer en procedural teóricamente. No es práctico.
Un ladrillo se construye con miles de miles de partículas de arena, así que se puede construir una casa sin ladrillos, sólo con arena.
Pero nadie lo intenta cuando tienes ladrillos.
Un avión se construye con piezas ya hechas: alas, ruedas, asientos, ordenadores, etc. Al final, todos están hechos de metal, plástico o vidrio. Pero nadie construirá un avión de puro cristal, plástico y metal.
Para el debate en general (en respuesta a Alain y los demás): Tome el CArrayObj - una matriz de objetos. Esto por sí solo es suficiente para responder a lo que es el poder de OO (que es mucho más que esto). Puede almacenar una matriz de cualquier objeto - como los indicadores, por ejemplo.
Y sin ningún esfuerzo, hacer cosas complejas para todos estos indicadores diferentes. Y si ahora quieres una nueva potencia a esto, por ejemplo quieres saber cuando se cruza el buffer de un indicador, sólo tienes que poner el método en CIndicator, eso es todo. Y así sucesivamente. ¿Cómo lo harías en procedural?
Y esto se puede hacer en todos los aspectos: estrategias, operaciones, transacciones, señales, lo que sea.
Todo se puede hacer en procedural teóricamente. No es práctico.
Un ladrillo se construye con miles de miles de partículas de arena, por lo que se puede construir una casa sin ladrillos, sólo con arena.
Pero nadie lo intenta cuando tienes ladrillos.
Un avión se construye con piezas ya hechas: alas, ruedas, asientos, ordenadores, etc. Al final, todos están hechos de metal, plástico o vidrio. Pero nadie construirá un avión de puro cristal, plástico y metal.
Para el debate en general (en respuesta a Alain y los demás): Tome el CArrayObj - una matriz de objetos. Esto por sí solo es suficiente para responder a lo que es el poder de OO (que es mucho más que esto). Puede almacenar una matriz de cualquier objeto - como los indicadores, por ejemplo.
Y sin ningún esfuerzo, hacer cosas complejas para todos estos indicadores diferentes. Y si ahora quieres una nueva potencia a esto, por ejemplo quieres saber cuando se cruza el buffer de un indicador, sólo tienes que poner el método en CIndicator, eso es todo. Y así sucesivamente. ¿Cómo lo harías en procedural?
Y esto se puede hacer en todos los aspectos: estrategias, operaciones, transacciones, señales, lo que sea.
Este tema fue intencionalmente provocativo, sin embargo la respuesta a la pregunta principal (qué puede hacer la POO que el código procedimental no puede) es NADA.
La POO no es ciertamente la única manera de construir y utilizar ladrillos. Hay al menos tantas formas de crear código malo en POO como en código procedimental (y muy probablemente más formas). Basta con mirar la "biblioteca estándar" proporcionada por Metaquotes, que en realidad está lejos de ser "estándar".
OOP versus procedimental es un debate inútil e interminable. Uno más útil debería ser "¿Cómo producir código de calidad? Con y sin POO, con y sin procedural, con y sin cualquier paradigma de programación". Si tu necesidad es construir una casa de madera, no necesitas ladrillos, pero necesitas que sea una casa buena, sólida y fiable.
Todo se puede hacer en procedimiento teóricamente. No es práctico.
Un ladrillo se construye con miles de miles de partículas de arena, así que puedes construir una casa sin ladrillos, sólo con arena.
Pero nadie lo intenta cuando tienes ladrillos.
Un avión se construye con piezas ya hechas: alas, ruedas, asientos, ordenadores, etc. Al final, todos están hechos de metal, plástico o vidrio. Pero nadie construirá un avión de puro cristal, plástico y metal.
Para el debate en general (en respuesta a Alain y los demás): Tome el CArrayObj - una matriz de objetos. Esto por sí solo es suficiente para responder a lo que es el poder de OO (que es mucho más que esto). Puede almacenar una matriz de cualquier objeto - como los indicadores, por ejemplo.
Y sin ningún esfuerzo, hacer cosas complejas para todos estos indicadores diferentes. Y si ahora quieres una nueva potencia a esto, por ejemplo quieres saber cuando se cruza el buffer de un indicador, sólo tienes que poner el método en CIndicator, eso es todo. Y así sucesivamente. ¿Cómo lo harías en procedural?
Y esto se puede hacer en todos los aspectos: estrategias, operaciones, transacciones, señales, lo que sea.
En tu ejemplo, cuando codificas OO y haces clic en compilar, se generará código máquina. ¿Pero este código máquina es procedimental o no? Realmente no sé la respuesta, ¿alguien aquí lo sabe? Si el código máquina es procedimental, entonces se puede llamar OO sólo un lenguaje de nivel superior, que hace más fácil de código sólo, pero nada especial, por lo que un programador de C hábil puede hacer el mismo trabajo que un programador de OO, de hecho, puede ser incluso mejor optimizado. Así que mi pregunta, ¿el código ex es prodedural o no?