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

 
Алексей Тарабанов:

¿En Istok?

No. Un instituto numerado, ahora no recuerdo el número.

Y ni siquiera entonces diría :-)

 
:)
 
Реter Konow:

Por interés, puedes inventar y mostrar aquí el código que debes escribir para replicar mi ventana y comparamos con mi versión.

Tienes un extraño espíritu competitivo :)

Sólo por interés, ¿podría utilizar su gui para crear un análogo de dicho programa?


El programa se escribió en dos meses en 2013, con otro proyecto paralelo aún en curso.

El programa se compiló por última vez en 2014, por lo que es posible que haya algún percance :)

Es mejor ejecutar el programa en instrumentos cotizados.

Aclaración para los moderadores: este programa no está en el mercado.

Archivos adjuntos:
IShift.ex5  3312 kb
 
Yury Kulikov:

El programa se redactó en dos meses en 2013, con otro proyecto paralelo aún en curso.

Aclaración para los moderadores: este programa no está en el mercado.

¡es de alta calidad y tiene un aspecto decente! Me gusta especialmente que haya un manual - esto también es un trabajo en curso

Pero además, hay que hacerlo de forma profesional o no hacerlo, es decir, que habiendo escrito ese código, hay que seguir escribiéndolo y vendiéndolo en el Marketplace, porque si no la carga de trabajo es muy alta.

¿Cuál es la demanda de estos programas? - ¿Se venden al menos 5 piezas al mes?

 
Igor Makanu:

¿Cuál es la demanda de estos programas? - ¿Venden al menos 5 al mes?

Sólo se han comprado 8 en probablemente tres años.

 
Yury Kulikov:

Sólo se compraron 8 piezas, probablemente en 3 años.

sadly....

de eso se trata toda esta discusión, a mi como interesado en los mercados, me basta con conectar la .dll en 3 clics y luego en el diseñador de formularios, puedo hacer todos los trucos, es decir, la herramienta estándar de MT me basta y todo lo que me parezca laborioso lo haré en software de terceros

Si eres un desarrollador, tienes que poner en el mercado no un "libro para colorear con calendarios", sino un producto totalmente funcional que pueda generar beneficios o ser una herramienta analítica eficaz - como ejemplo@Yury Kulikov

¿Alguien entendió lo que@Peter Konow quiere monetizar?

 
¿Por qué no haces lo mismo usando OOP? No entiendo por qué no utilizas sus posibilidades y ni siquiera intentas comprender los principios de la POO. La profesión de informático implica que este mismo especialista se dedique constantemente a la autoformación. Como las tecnologías no se quedan quietas, aparecen nuevos lenguajes de programación y las capacidades de los ordenadores crecen. En general, el progreso no se detiene. Pero tú con tu estilo de programación te has quedado en el nivel del 2000 y sugieres a los demás programadores que vuelvan al nivel de aquellos años de trapo. Lo he dicho muchas veces y lo repetiré una vez más. Intenta hacer todo esto usando el RPF.
 

Lo que Pedro tiene en mente es ciertamente algo bueno. Pero para fabricar un motor así, se necesitan recursos humanos inteligentes.

Y no habrá mucha demanda, porque en MQL para crear paneles, personalmente conozco 3 formas: objetos MQL simples, objetos estándar y Canvas.

Y para los usuarios sencillos no se necesitan paneles enormes, con numerosos parámetros y posibilidades. Y esto es lo que se necesita:





P.D. Este robot aún no está a la venta en el mercado, pero en cuanto salga, quitaré el vídeo.

 
Алексей Тарабанов:

Aquí es donde no estoy de acuerdo. La negociación semiautomatizada implica una negociación semiautomatizada, no la posibilidad de pulsar un botón de "compra-venta" o cualquier otro.

Muy a mi pesar, el autor se empecina en dar un mecanismo para generar estos botones, y eso es todo.

Bien, ¿dónde está la interactividad de un EA cuando uno de sus niveles principales se ha movido repentinamente a una nueva ubicación de inicio, donde fue movido por un usuario (él está a cargo); dónde está el seguimiento de nuevas (o -sólo, principales) líneas de tendencia, que el EA no ha creado antes?

En la negociación semiautomatizada, parte del trabajo lo realiza el Asesor Experto (este trabajo es siempre rutinario), la otra parte la realiza el trader (genera información en base a la visión - no confundir con el insider). Después de eso, el Asesor Experto recoge el resultado del proceso interactivo de la actividad conjunta y lo lleva a su finalización, permaneciendo constantemente listo para la intervención repetida del comerciante y la corrección repetida de sus acciones.

¿Dibujamos las balas o automatizamos la actividad?

Peter parece sugerir exactamente la biblioteca GUI para tal Asesor Experto semiautomático.

Es decir, el semiautomático es que lo escribes tú mismo. Y la biblioteca de Peter - sólo le ayudan más fácil (¿es más fácil?) para mostrar los controles de usuario.

Ya lo he dicho muchas veces: para el público al que va dirigido, la biblioteca es suficientemente buena. Pero el problema está en la extrema estrechez de este mismo público objetivo. Todas las críticas a Peter aquí son de personas que no forman parte del público objetivo - son todos programadores que, aunque tengan "semiautomáticos" (de hecho, autómatas con un poco de adición manual) - no requieren mucho control, y estas personas prefieren escribir programas para ellos mismos. Peter necesita gente que sepa programar, pero que prefiera el comercio manual - es decir, la entrada manual, el ajuste y la transferencia de paradas manual, el cierre manual. Los asesores expertos sólo proporcionan información de forma práctica.

Todavía no he encontrado ninguna persona así entre los críticos, y estoy seguro de que hay muy pocos.

Peter afirma que "creará una capa de estas personas" - lo dudo mucho. ¿Enseñar a un programador a operar manualmente y luego demostrarle que la operación manual en una máquina semiautomática es mejor? No es realista. Pero, veamos, tal vez me equivoque.

 
Vitalii Ananev:
¿Por qué no haces tú, Peter, lo mismo utilizando la POO? No entiendo por qué no usas sus características y ni siquiera intentas entrar en los principios de la POO. La profesión de informático implica que este mismo especialista se dedique constantemente a la autoformación. Como las tecnologías no se quedan quietas, aparecen nuevos lenguajes de programación y las capacidades de los ordenadores crecen. En general, el progreso no se detiene. Pero tú con tu estilo de programación estás estancado en el nivel del 2000 y propones a los demás programadores volver al nivel de aquellos años rasgados. Lo he dicho muchas veces y lo repetiré una vez más. Intenta hacerlo todo con el RPF.

Vitaly, el problema es que Pedro es un titán de la memorización. No olvida dónde y qué índices tiene, qué significan, qué conexiones tienen y dónde.

Con una memoria tan impresionante las mejoras de OOP son sólo gestos innecesarios, y una cierta degradación del rendimiento. ¿Para qué?

OOP es para aquellos que no recordarán en una semana por qué pueden cambiar la variable en un lugar determinado y no en el vecino. Ellos son los que necesitan encapsulación, secciones de clases públicas, protegidas y prevertidas, interfaces virtuales, polimorfismo... Y cuando se tiene todo en memoria, como en un ordenador, es mucho más fácil acceder a cada objeto directamente, sin necesidad de mejoras de POO.

Sugerir a Peter una clase de smartpointers, que tenga en cuenta el número de referencias al pasar los objetos, y luego, cuando nadie se refiera a ellos, ¡borrarlos! Peter se sorprenderá, recuerda bien cuándo se crea cada objeto, cuántos usuarios tiene, cuánto tiempo debe existir y cuándo debe eliminarse. ¿Qué sentido tiene utilizarlos?


No, también puedes hacerlo así. La única pregunta que tengo es ¿para QUIÉN? Peter afirma que "creará una capa de usuarios de este tipo". Bueno, bueno... Ya veremos.

Razón de la queja: