Mi enfoque. El núcleo es el motor. - página 20

 
Реter Konow:

Bueno, ese es el tipo de respuesta que supuse. Sin embargo, ¿por qué no ha creado un lenguaje de marcas? Llevas mucho tiempo haciendo gráficos y no has hecho un lenguaje en un fin de semana).

No es relevante para mí, y tengo en mi haber tanto compiladores como intérpretes implementados en ensambladores. Pero me temo que eso no te dice nada.

 
Реter Konow:

Por lo que tengo entendido, sus ventanas utilizan la biblioteca gráfica estándar (a juzgar por su aspecto).

¿Cuánto crees que tardarías en crear tu propia biblioteca gráfica desde cero?

Utilizo mi propia biblioteca, la base se hizo en un mes aproximadamente. Y luego fue evolucionando lentamente a medida que surgían nuevas necesidades. Hay que tener en cuenta que las nuevas funcionalidades se añaden normalmente en menos de un día de trabajo.

 
Yury Kulikov:

Esto no es relevante para mí, y tengo en mi haber tanto compiladores como intérpretes implementados en ensambladores. Pero me temo que eso no te dice nada.

No intento menospreciar tus logros (a diferencia de ti). Es sólo, - es una experiencia diferente.

El primer tema que inicié en el foro fue sobre la creación de un estudio visual en MT4. Curiosamente, el objetivo no ha cambiado con los años.

Por muy geniales que sean sus compiladores e intérpretes, no resuelven los problemas de algotrading.

Me propuse un objetivo: ampliar las capacidades de algotrader. Ha estado caminando hacia esa meta todos estos años.

Y ya no niego la OOP. Estoy de acuerdo en que es necesario y útil.

Sólo quiero mostrar lo que he conseguido con mi enfoque.

 
Реter Konow:

No intento menospreciar sus logros (a diferencia de usted). Es sólo, - es una experiencia diferente.

El primer hilo que inicié en el foro fue sobre la creación de un estudio visual en MT4. Curiosamente, el objetivo no ha cambiado con los años.

Por muy geniales que sean sus compiladores e intérpretes, no resuelven los problemas de algotrading.

Me propuse un objetivo: ampliar las capacidades de algotrader. Ha estado caminando hacia esa meta todos estos años.

Y ya no niego la OOP. Estoy de acuerdo en que es necesario y útil.

Sólo quiero mostrar lo que he conseguido con mi enfoque.

Aquí no está claro de qué manera su desarrollo resolverá el problema del algotrading. ¿Y cuál es la esencia de este problema? Ya escribí anteriormente en este capítulo que lo más importante para los operadores es tener beneficios. La cuestión es cómo sacar provecho del mercado utilizando su metodología.

 

Y así, Anatoly tardó un año y medio en crear su biblioteca. (A Yuri Kulikov sólo le llevó un mes).

He tardado tres años en crear mi entorno gráfico. Lo he creado completamente desde cero. Usando sólo mis propios códigos. Sin ninguna ayuda del exterior.

Pregunta: ¿Cuál es la diferencia entre una biblioteca gráfica y un lenguaje de marcas?

La diferencia es ésta:

El lenguaje de marcado reduce el nivel de usuario requerido.


Esta propiedad es la que permite la distribución masiva. Visual Studio reduce aún más el nivel de formación requerido por el usuario.

Pasar de una biblioteca gráfica a un lenguaje de marcado es un camino largo y difícil.

Pero nunca he creado una biblioteca. He creado Visual Studio desde el principio. Y el lenguaje de marcado surgió por accidente).

El enfoque en sí mismo también surgió por accidente. Fue creado y forjado por la necesidad de resolver el problema.

Es decir, mi planteamiento es el resultado de una persistencia y una determinación infinitas, al margen de cualquier dogma o norma (aunque sea correcta).

El enfoque absorbió sólo lo necesario para desarrollar el programa con rapidez.

Y en tres años, creé un lenguaje de marcas y un motor con el enfoque. Y también estuvo a punto de crear Wiz.Studio.

Por lo tanto, la eficacia del enfoque es incuestionable. Al fin y al cabo, se creó y pulió tratando de resolver una tarea irreal para una persona.

 
Vitalii Ananev:

No está claro cómo su desarrollo va a resolver el problema de algotrading? ¿Y cuál es la esencia de este problema? Ya he escrito en este hilo que lo más importante para los operadores es obtener beneficios. Por eso quiero saber cómo tomar ganancias del mercado usando su metodología.

El problema del algotrading no es el beneficio de los operadores. Es el entusiasmo por el algotrading.

 
Vitalii Ananev:

No está claro cómo su desarrollo va a resolver el problema de algotrading? ¿Y cuál es el quid del problema?

¿Qué tal esto? Aquí está:

Retag Konow:

...quiero exponer la escala del problema en el que tuve que probar el enfoque.

Es decir, hay que plantear algún problema de "escala" (exactamente plantearlo) y luego resolverlo heroicamente durante años:

Retag Konow:

Por muy buenos que sean los compiladores y los intérpretes de ensamblador, no resuelven los problemas de algotrading.

Me puse como objetivo potenciar a los algotraders. Ha ido hacia esta meta todos estos años.

Y no es realmente importante si el problema existe en la realidad o sólo en la imaginación. Lo principal es resolverlo, sin sentido y sin piedad durante muchos años. Bueno, por qué no, si tienes mucho tiempo y alguien trae la comida a casa.

p.d. Lo siento, Peter. Realmente eres un buen hombre, no quiero ofenderte. Pero sólo necesitas algunas críticas desde el exterior. Yo mismo he cometido errores similares en algún momento.

 
Реter Konow:

Hay una razón en particular:

DESARROLLO DE PROGRAMAS.

....

Para que se puedan añadir nuevas funciones con unas pocas líneas de código.

Mi enfoque es superior a la POO para resolver este problema en particular.

Hmmm...

Sería interesante ver cómo se puede conseguir el DESARROLLO "con unas pocas líneas de código" ?

Con unas pocas líneas de código puedes añadir una nueva ventana a partir de lo que ya tienes. Pero, eso equivale a que yo añada un sistema de la Liga TC, de los más de 500 que tengo. Yo también, añadiendo sólo una línea de código - estoy añadiendo un TS totalmente funcional, ya depurado, probado en el historial, y trabajando durante algún tiempo en la demo. ¿Pero es un "desarrollo"?

En mi opinión, el "desarrollo" - es, en mi caso, la adición de un nuevo TS. Por ejemplo, hace dos meses añadí a los dos tipos de TS con entradas por cruce de precio y media móvil y por toque de límite de canal el tercer tipo, entradas por órdenes pendientes en topes de zigzag.

En su caso - entiendo que "desarrollo" es añadir un nuevo TIPO de ventanas o control. Algo que no estoy seguro de que añadir un nuevo tipo de control se pueda hacer con una sola línea. Además, añadir un nuevo control complejo le dará muchos dolores de cabeza, que serían muy difíciles de resolver con su enfoque, mientras que con la POO sería mucho más fácil. Por ejemplo, ¿hay un control como "cuadrícula" en su motor? ¿Algo como una tabla de Excel? ¿Con posibilidades de hacer clic en los botones situados encima de las columnas o filas para ordenar? ¿Cuánto esfuerzo supondría añadir un control de este tipo a la biblioteca?

 
Реter Konow:

El problema del algotrading no son los beneficios de los operadores. Es la propia pasión por el algotrading.

Por cierto, Peter, este tema es exactamente lo que yo llamo la "dramatización de una idea". Es cierto que la dramatización se basa sobre todo en conversaciones y no en ejemplos vívidos, pero, sin embargo, como se puede ver, el tema está de moda.

Además, si se presenta la prueba de que su sistema permite DESARROLLAR y DAR el producto más fácilmente que cuando se utiliza OOP (recuerde sobre el control de la cuadrícula) - será un argumento muy fuerte para el uso de su biblioteca por los usuarios.

 
No querría decepcionarse después de muchos años. Sobrestimas la importancia del gui. Pedro, si hicieran una consola, quizás la usaría yo (aunque tampoco sufro sin ella), pero me da igual el gui.