Ayer tuve que escribir un correo al personal técnico un prospecto de cliente. Básicamente me pidieron una cotización para pasar un proyecto de RUST a un sistema OOP .. en RUST. De entrada RUST puede ser , a veces , considerado un lenguaje OOP o no OOP. Hay características de ambas cosas, pero en realidad, no lo es. Usando un ejemplo sencillo, es como si alguien me pidiera cotizar un helado de pollo rostizado o un helado termino medio.

Voy a poner un extracto de lo que le voy a contestar al cliente.:

En una empresa hay empleados y coches, que son parte de un proceso, y por cansancio, desgaste o corrupción, en ocasiones se revisan a si mismos. Un obrero que inicia un proceso no puede juzgar BIEN si cumple la calidad el producto, solo si el tiene que hacer el producto terminado. Un coche que habla puede decir que necesita gasolina, pero no puede resolver su problema ni dar una alerta a menos que lo hayan programado, alguien lo revise, y esa persona este cerca. El problema mas común de los lenguajes orientados a objetos, y el que tienen ustedes actualmente, es que un objeto se verifica a si mismo. Así que aunque ayude a la autoestima del objeto, los lleva a problemas actuales de rendimiento y de abusos de confianza, porque hay una o mas personas que se revisan a sí mismos. Es la misma razón por la que nos están buscando a nosotros.

Su problema de velocidad es, usando una metáfora que tienen una bolsa con paraguas, manzanas, tuercas y celulares. Pero no solamente tienen que meter la mano en la bolsa, lo que es lento, sino que las tuercas dañan al celular y ensucian la manzana.

Los sistemas orientados a objetos pueden crecer, pero no es su complejidad lo que los hace lentos, sino la burocracia. hay un momento, que es en el que se encuentran ustedes, donde hay tantas dependencias, polimorfismo y burocracia que es necesario dejar lo que se tiene, corregir errores y a veces empezar de cero, principalmente por los estados y la contaminación de objetos (celulares con tuercas) además de lentitud Ejemplo, una lavadora no es solo encendido y apagado sino otros estados. Una puerta esta abierta, cerrada, cerrandose, abriendose, detenida en medio (cinco estados). Y lo que ustedes quieren evaluar no tiene estados iniciales y por lo mismo no puede evaluarse su calidad (no pueden medir calidad por la inexistencia de algo y al mismo tiempo hacerlo en objetos). Ejemplo, un coche normalmente tiene un estado inicial o default, pero una violación, robo, delitos de malversación, abusos de confianza, o algo tan sencillo como un costo o un precio de venta (que no sabemos cual hasta que se vende y si y solamente si se vende, porque ese precio no es cero ) .

Normalmente los sistemas orientados a objetos no son la solución a un problema como el de ustedes. Los programadores pueden pensar que creando polimorfismo u otras dependencias del objeto DEMORAN el problema pero cuando pasa como en este momento, que sus computadoras ya no dan el ancho, no es problema del lenguaje orientado a objetos o no sino que tienen demasiadas capas de comparaciones de peras con manzanas, y su forma de validar es preguntarle a la pera, eres una manzana ?

Es esta la razón por la que proponemos en ese orden estas alternativas:

a ) reescribir de cero en RUST en base a especificaciones

b ) Pasar a J2EE con el que están familiarizados

c ) Cambiar a PHP procedural por el equipo que tienen y la latencia de sus conexiones.

 

Todavía no se si les mando este link conocido en el medio, de OOP, el desastre del trillón de dolares, por Ilya Suzdalnitski .Habla sobre instancias compartidas y objetos mixtos, como pintores (accion usar brocha) y zombies (accion : comer cerebros), y que no es lo mismo el cambio de estado de un papel en estado original si el papel es la mona lisa.. o la vida humana.

https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7