Hablando de la OLP en el salón - página 20
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
¡El artículo miente!
No he leído el resto del artículo. Lo más probable es que el despropósito del autor fuera inmediatamente señalado en los comentarios.Siga leyendo, todo está en su punto.
En la codificación procedimental, casi siempre es posible personalizar la arquitectura de un programa a medida que se escribe. Porque la flexibilidad y la libertad son totales
+
Es posible que te olvides de la POO sólo por el hecho de hacerlo, especialmente para los algoritmos computacionales, como en el comercio...
Sobre los mitos de la OLP - no para los pusilánimes adheridos a la OLP.
"Desde mediados de la década de 1980 existen varios mitos sobre la OOP. Uno de ellos, el Mito de la Reutilización, dice que la POO hace que el desarrollo sea más productivo porque permite heredar y extender el código actual en lugar de tener que escribirlo todo de nuevo. El otro es el Mito del Diseño, que implica que el análisis, el diseño y la aplicación se suceden sin problemas, porque todos son objetos. Por supuesto, ninguno de estos mitos puede ser el paradigma OOP".
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 menor. 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. Las tasas de mortalidad y fracaso son asombrosas, y a partir de ahora van 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:
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias
Hablando de la OLP
Renat Fatkhullin, 2018.01.17 09:17
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 está inflado desde hace tiempo) y autor de libros.
Esta basura de frases lleva mucho tiempo circulando e ignora por completo el crecimiento exponencial de la complejidad del 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. Esto 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 crear lenguajes aún más sencillos para satisfacer el nivel de masa de programadores, cada vez menor. 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:
El mejor post del mes, ¡o quizás del año! Renat, ¿por qué no escribes tú o tu empresa artículos en hubra(¡la empresa ni siquiera está registrada allí!)? Tienes mucho que decir, pero tu experiencia sólo se aprende en retazos de tus posts. En serio, muy actual y preciso. Para ilustrar su puesto:https://habrahabr.ru/post/344356/
El mejor post del mes, quizá del año.
¿Qué es lo que más te ha gustado de este post en el contexto del tema OOP? Probablemente no sea del todo correcto generalizar también sobre las cosas comerciales, los inversores no son tontos e implican a sus expertos para evaluar el riesgo de los proyectos...
Este artículo de algunos, pero todavía un profesor tiene argumentos lógicos específicos a los que no se han presentado contraargumentos adecuados para la discusión...
También está claro que el simple pograma no siempre es un mal para los proyectos...
El mejor post del mes, quizá del año. Renat, ¿por qué no escribes tú o tu empresa artículos en hubra(¡la empresa ni siquiera está registrada allí!)? Tienes mucho que decir, pero tu experiencia se aprende sólo en retazos de tus posts. En serio, muy actual y preciso. A modo de ilustración del post:https://habrahabr.ru/post/344356/
Trabajamos para millones, no para los 1.000 - 5.000 lectores/vistas que suelen tener los artículos de Habra.
Hemos hecho un estándar de la industria y estamos lanzando soluciones que tienen un impacto en el mundo. Por qué necesitamos una especie de Habr, y más aún, exprimido en un estrecho nicho del segmento ruso.
¿Qué es lo que más te ha gustado de este post en el contexto del tema OOP? Probablemente no sea del todo correcto generalizar también sobre las cosas comerciales, los inversores no son tontos e implican a sus expertos para evaluar el riesgo de los proyectos...
Hay argumentos lógicos específicos en este artículo de algunos, pero todavía un profesor, a los que no se han presentado contra-argumentos adecuados para la discusión...
También es obvio que el simple pograma no siempre es un mal para los proyectos...
Déjate de burlas diletantes, por favor.
Simplemente se le expulsará por ser un analfabeto técnico. No necesitamos ignorantes beligerantes en nuestro foro.
...
También es obvio que la simplicidad de la programación no siempre es un mal para los proyectos...
Hay un axioma: la complejidad nunca desaparece. En consecuencia, la "sencillez de programación" para el usuario es una transferencia de complejidad al compilador. La complejidad es como si fuera procesada por el compilador entre bastidores y éste, el compilador, trata de ocultar cualquier perversión del programador según el principio "más vale que funcione de alguna manera que nada". El compilador, y no el programador, se convierte en el propietario del proyecto. El desarrollo y el mantenimiento del código se hace imposible, porque no entiendes lo que está pasando (el compilador lo construye de alguna manera, pero da igual).
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias
Hablar de OOP
Renat Fatkhullin, 2018.01.17 09:17
...
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 bajo. Cada vez más empresas de software estarán en desventaja, simplemente por creer en la tecnología equivocada y perder la carrera competitiva. Es que sus competidores utilizarán una tecnología más pesada, pero más efectiva en términos de resultados del producto
...
Déjate de burlas diletantes, por favor.
Simplemente se le expulsará por ser un analfabeto técnico. No necesitamos ignorantes beligerantes en nuestro foro.