Hablando de la OLP en el salón - página 21

 
Nikolai Semko:
Ignorantes militantes: qué preciso y sucinto. Voy a añadir a mi vocabulario. :))
Resulta que este término fue utilizado por mis queridos Elena Ivanovna y Konstantin Nikolaevich Roerich.
Nada cambia en este mundo...
 
Andrei:

No, la cuestión es diferente. Hay un plátano que hay que comer según la lógica del programa, pero hay que comer la palma y la tierra negra con el estiércol junto con ella.

Pues no.

No se ve ni una palmera, ni tierra negra, ni abono, ni un mono. Todo está encapsulado y no se tiene acceso a él.

¡A eso me refiero! Es sólo en el enfoque funcional - usted tiene que arrastrar todo EXTREMADAMENTE detrás de usted para conseguir un plátano. En el enfoque OOP, el compilador lo arrastrará por ti. Tú - obtienes el "plátano" a través de una interfaz acordada, y no sabes de dónde viene. Puedes averiguarlo si tienes un acceso adecuado.

Ese es el sentido de la OOP - sólo lo que necesitas, en este caso el plátano, debe estar disponible para ti. No hay cacahuetes de palma a su disposición. Existen (si no, de dónde salió el plátano), pero no tienes acceso a él, y con toda tu voluntad no podrás cortar una palmera ni matar al mismísimo mono que está arrancando tu plátano.

 
Andrei:

Lo que es un tormento para la gente normal es una alegría para los masoquistas... :)

¿Es un tormento para la gente normal limitarse a usar un cuchillo? ¿Es un tormento para la gente normal limitarse a las normas de circulación?
 
Creo que los autores de los dos artículos citados son personas profundamente infelices que se han pasado la vida haciendo las cosas mal. Esto, por desgracia, es lo que ocurre a menudo. Deberían haber sido escritores, no programadores. Obviamente, expresaron su disgusto por el trabajo que no les gustaba atacando a la OOP. Supongo que uno puede entenderlos de una manera puramente humana :)) Al fin y al cabo, el paradigma de la programación orientada a objetos sólo puede ser entendido por verdaderos programadores enamorados de su oficio.
 

Podrías imaginar que la OLP es tu casa, con sus propias reglas. Hay cosas que son comunes a todos. Se trata de sillas de mesa, tenedores, cucharas, etc. Pero hay cosas que ni siquiera están disponibles para los residentes de esta casa. Por ejemplo, objetos personales, una caja fuerte, etc.

El propietario de la caja fuerte puede dar acceso a la misma. Los extraños no tienen derecho a entrar en esta casa sin permiso.

Puedes usar una clase para describir esta casa, lo que hay en ella con ciertas funciones de cada uno. Y la casa en sí es un objeto.

La OOP es como nuestra vida. Tiene el aspecto de una persona y consta de dos partes: el alma, que la describe y controla, y el cuerpo físico, que es un objeto.

La OOP es una disciplina, no una anarquía - quien hace lo que quiere.

 
Nikolai Semko:
Al fin y al cabo, el paradigma de la programación orientada a objetos sólo puede ser entendido por verdaderos programadores enamorados de su oficio.

No necesariamente.

Renat, en la página anterior, ha señalado con razón que "si se le pone a hacer un proyecto de verdad", fracasará. Y rápidamente se convencerá de todas las ventajas de la POO, que compensan con creces todas las desventajas. Apuesto a que ninguno de los que critican aquí la POO ha participado en la redacción de un solo proyecto, aunque sea pequeño y complejo. Lo que explica su opinión.

Como "el coche requiere muchos recursos generales, y no puedes alejarte de ellos, tienes que llevar ese montón de chatarra todo el tiempo, lo que significa que es mucho más correcto caminar". Y, efectivamente, es una tontería ir a la calle de al lado. Sin embargo, si tienes que ir a otra ciudad, muy poca gente habla en serio de "caminar".

Y así es aquí.

 
George Merts:

No necesariamente.

Renat, en la página anterior, ha señalado con razón que "si se le pone a hacer un proyecto de verdad", fracasará. Y rápidamente se convencerá de todas las ventajas de la POO, que compensan con creces todas las desventajas. Apuesto a que ninguno de los que critican aquí la POO ha participado en la redacción de un solo proyecto, aunque sea pequeño y complejo. Lo que explica su opinión.

Como "el coche requiere muchos recursos generales, y no puedes alejarte de ellos, tienes que llevar ese montón de chatarra todo el tiempo, lo que significa que es mucho más correcto caminar". Y, efectivamente, es una tontería ir a la calle de al lado. Sin embargo, si tienes que ir a otra ciudad, muy poca gente habla en serio de "caminar".

Y así es aquí.

A eso me refiero...
 
Renat Fatkhullin:

Ahora para microproyectos de hasta cien mil líneas. Esto permite crear cualquier cosa, ya que tiene la posibilidad de caber en la cabeza de una persona y mantener la ilusión de control. Cuando intentas aumentar la escala: dolor, frustración y muerte.

Me cuesta imaginar incluso un proyecto de 10.000 líneas sin OOP. Probablemente sean muy pocos.

 
Renat Fatkhullin:

El tío es un teórico y un bocazas, como la mayoría de los académicos. Y no importa que sea catedrático (el título hace tiempo que está inflexionado) y autor de libros.

Esta basura de frases lleva mucho tiempo dando vueltas e ignora por completo el crecimiento exponencial de la complejidad de los productos de software. Lo que era hace 30-20-10 años no es en absoluto comparable a la escala y complejidad de los proyectos actuales. Y siguen prefiriendo jugar en la caja de arena, reduciéndola a modelos.

Siéntese a fabricar un producto real, que tiene muchos requisitos, incluidos los de recursos, económicos y competitivos. Al instante flipará con su razonamiento, fallando en todo lo que pueda. Es más probable incluso que te echen por capitanía infantil en la fase de diseño de la solución.

El mundo ha probado muchas balas de plata, pero todas han resultado inútiles y hace tiempo que se han descartado. Eso deja un crecimiento constante de la complejidad, el crecimiento de las bibliotecas (y hay un oop) y frameshots (y hay un oop), que permiten al menos un cierto control sobre la complejidad.

Y no se puede evitar la creciente complejidad. Habrá aún más complejidad, habrá más desarrolladores analfabetos incapaces de seguir el ritmo de los requisitos de calidad del conocimiento.

Habrá más intentos de idear lenguajes aún más sencillos para satisfacer el nivel de masa de programadores, cada vez más reducido. Cada vez más empresas de software se encontrarán en desventaja por el simple hecho de creer en la tecnología equivocada y perder la carrera competitiva. Lo que ocurre es que sus competidores utilizarán una tecnología más pesada, pero eficaz en cuanto a los resultados del producto.

Invertir en empresas de software ha sido durante mucho tiempo algo mortal. Los índices de mortalidad y fracaso son asombrosos, y la situación va a empeorar.

¿Por qué? Sí, porque se trata de un negocio con grandes exigencias económicas, no tecnológicas. Alrededor del 80% de una empresa de software viva y en pie consiste en marketing y ventas. La tecnología equivocada (y aquí la mayoría de la gente prioriza la supuesta simplicidad) mata fácilmente las ventas futuras. Porque siempre hay competidores que tomaron un camino más difícil y obtuvieron mejores resultados al final.

Ahora sobre los microproyectos de hasta cien mil líneas. Esto permite crear cualquier cosa, ya que tiene la posibilidad de caber en la cabeza de una persona y mantener la ilusión de control. Si tratas de aumentar la escala: dolor, frustración y muerte.

Conclusiones:

  1. la complejidad de los proyectos crece y seguirá creciendo
  2. Muchas ideas y enfoques nuevos morirán sin producir resultados.
  3. la mayoría de los programas informáticos se escriben y seguirán escribiéndose en código abierto, duro y con esfuerzo
  4. Las inversiones en empresas de software de nueva creación mostrarán tasas de fracaso cada vez mayores.
  5. no hay salida, sólo dolor y sufrimiento.

Todo esto es bueno y hermoso sólo en palabras....

Para crear proyectos grandes e interesantes utilizando la POO es necesario saber cómo hacerlo.

1 - Los que saben no van aquí a µl, el lenguaje se limita a un par de plataformas, y son profesionales (ya con proyectos en otros idiomas) ya en el negocio...

2 - Y los que no sepan cómo, retorcerán OOP y otros como monos y no parirán nada...

Sí, por supuesto, hay algunos aficionados a los mercados financieros, pero demasiado pocos para hacer algo serio y ganarse la vida... El interés principal es...

Lo que quiero decir, Renat, es que el mt 5 pronto cumplirá 10 años, 10 años no es ninguna broma...

Y no hay una formación adecuada en programación OOP...

¿Cuál es el tema sobre el que escribí? ¿Sobre la OOP y a qué se redujo? En la basura...

Mi pregunta para ti Renat, ¿cómo o dónde debe aparecer la gente que programa grandes proyectos en mkl?

 
Vladimir Pastushak:

¿cómo o de dónde debe venir la gente que programa grandes proyectos en µl?

Nunca ha habido ni habrá grandes proyectos de algotrading dentro de un mismo parqué, independientemente del idioma y la plataforma.

Como mucho, hay proyectos semiautomatizados.

¿Incluso un gran proyecto como semiautomático en cualquier idioma? Las unidades de escalada son las más difíciles. Pero nunca han tenido un atractivo masivo. Y si no hay masa, ¿por qué molestarse con algo grande? Es más fácil construir algo para el Mercado sobre una rodilla.
Razón de la queja: