Derru, el problema de los sistemas no es tanto de saturación de capacidad de procesador como de necesidad de presentación de variables.
Antes del paradigma de la programación orientada a objetos, los sistemas se programaban "contra la foto". Es decir, yo tenía que definir todas las variables de una coyuntura para que el programa supiera qué responder.
Ejemplo burdo: yo hacía un programa para controlar el comportamiento de un sensor de presencia que usa un láser, como en las películas.
Bien, si la idea es que cualquier cosa que interrumpa el flujo del láser del punto A al B, es simple: Si la condición se cumple (A----B), todos felices; si no (A--/ B), se dispara la alarma.
Supongamos entonces que por algún requerimiento necesito que la alarma se dispare ante cualquier cosa menos el perro.
Le voy a tener que agregar hardware que haga reconocimiento, identifique al perro, y ante esa respuesta, evalúe la condición del láser. Si lo único que necesito es que me diferencie un perro de cualquier otra cosa, también es binario: si perro, ok. Si no perro, a sonar.
Un día la patrona me trae un gato. Entonces habrá que agregarlo a la ecuación. Y así con cada cosa que necesite identificar.
En programación tradicional, necesitaba escribir por cada una de las condiciones, una línea de código. Eso se vería (sin entrar en código posta, para que sea menos doloroso al ojo no entrenado) máso meno sasí:
1. Si A no llega a B y cámara no identifica perro ni identifica gato, sonar alarma
2. Si A no llega a B y cámara identifica perro no sonar alarma
3. Si A no llega a B y cámara identifica gato no sonar alarma
Ahora, si hay una identificación simultánea? Cómo reacciona el programa?
Si yo no le defino todas las variables, no obtengo respuesta. El ejemplo clásico sería Deep Blue, ganándole a Kasparov. La máquina sabía jugar al ajedrez? Nop. Lo único que hacía era consultar en una base de datos inmensa todas las fotos que tenía de posiciones de piezas idénticas a la actual. Y de acuerdo a eso elegía la que tenía categorizada como la mejor. Nunca tuvo un plan, sino que hizo una sucesión de mejores decisiones individuales. Cuando Kasparov jugó fuera de la teoría tradicional a propósito, eso la descolocó porque no había tanta información (tantas variables) sobre esas posiciones en el tablero. Y ahí es donde pifió.
Así se explica también un apagón de servicio telefónico en USA hace una parva de años, que no recuerdo específicamente cuál fue: todas las centrales tenian un sistema que ante un fallo inminente, avisaba a las demás que salía de servicio y redireccionaba proporcionalmente el tráfico que manejaba a las centrales aledañas. A su vez, las centrales que recibían este tráfico avisaban a sus aledañas que lo tomaban y que en caso de un segundo fallo lo enviaran a alguna con menos carga.
Fallaron dos centrales en el mismo momento, las centrales nunca se pudieron dar el aviso de transferencia y recepción y fueron cayendo como moscas una por una.
Lo que pasó entre Coventry- Broadsword es que en medio de las maniobras evasivas, una de las variables no calculadas (en combinación con otros factores) se dio; lo que hizo que el sistema rompa el lock-on que tenía sobre los A-4.
Se pudo haber preparado al sistema SeaWolf para encontrarse una nave amiga en el barrido radar; se pudo haber preparado para que en ese caso se anule el lock on por seguridad; se pudo haber calculado diferenciar la amenaza a una determinada altura aún con propia tropa en el mismo barrido. Lo que creo que no se evaluó es la línea de código que incluía todas las variables del momento.
Cuando el paradigma de programación cambió a la programación orientada a objetos, yo lo que defino es una serie de objetos, y sus atributos.
Entonces, para la misma situación, yo escribo:
Si <sensor A> está en estado "emite" y <sensor B> esta en estado "no recibe", y <perro> y/o <gato> no son razón de interrupción, <alarma> asume estado "on".
Si necesito definir otra cosa, pongamos conejo, creo el objeto <conejo> y lo agrego a la misma ecuación.
La sentencia es más corta, y se requiere de una evaluación lógica más intensa que se asume en la misma operación, lo que reduce el ciclo. Lo que también hace que en la misma extensión de código tenga más variables y hasta variables por la negativa: es decir, si no cumple ninguna de las variables anteriores, sonar alarma.
El hardware nuevo siempre es bienvenido, pero con las líneas de código correctas, la situación Coventry-Broadsword se hubiese resuelto. Lamentablemente, no podemos considerar el SdA SeaWolf como malo per se. Tenemos tristes resultados a la vista.
En fin, se hizo largo, pero la base es más o menos ésa.
Saludos,
Diazpez.-
