|
|
La serie “El computador mágico” está disponible también en forma de libro. |
Terminamos el último artículo definiendo las puertas lógicas habituales (recuerda que también publicamos un apéndice entre medias), y en este veremos cómo combinarlas para lograr cosas más complejas.
Lo que vamos a hacer es definir una función lógica o función booleana. En una función de este tipo, tomamos una serie de entradas y, en función de los valores de esas entradas, definimos si la salida vale 0 ó 1. Podemos definir esa función en roman paladino, pero lo habitual es que prefiramos hacerlo de un modo más formal, que nos permita operar con ella, simplificarla, fabricarla o enviársela sin ambigüedad a un fabricante de circuitos; y para esto se inventaron las representaciones en forma de tabla, en forma algebraica o el esquema de circuitos digitales.
La mejor forma es verlo con un ejemplo. El ejemplo que vamos a ver es poco reutilizable para seguir avanzando con la construcción de nuestro ordenador, pero es muy sencillo, así que vamos a empezar con él. Ya veremos más adelante ejemplos más aplicables a nuestro viaje hacia el ordenador.
Vamos a empezar definiéndolo en español plano: queremos un pequeño sistema de alarma. Tiene una llavecita que activa o desactiva el sistema. Si la llave está en Activo, genera un 1; si está en Desactivado, genera un 0.[1] También tenemos dos sensores colocados en las ventanas. Dichos sensores son simples pulsadores, de forma que mecánicamente, si la ventana está abierta el pulsador está suelto y se genera un 0; y si la ventana está cerrada, el pulsador está apretado y se genera un 1.[2] Lo que queremos es que si la llave está en Desactivado (es decir, es un 0), la salida siempre sea un 0; pero si la llave está en Activado (es decir, genera un 1), la salida debe ser un 1 si cualquiera de las ventanas están abiertas (es decir, cualquiera de ellas es un 0), y un 0 en caso contrario. Finalmente, conectaremos esa salida a una sirena, de modo que sonará la sirena si se abre una ventana mientras el sistema está en Activado.
Entender esto puede ser complicado. Bueno… está bien… es un párrafo nada más… pero imagínate que fuera algo mucho más complicado. Imagina que fuera el control de una cadena de montaje con doscientos posibles sensores y cincuenta salidas distintas. O alguna de las cosas que veremos más adelante en la serie. Sería complicado definirlo simplemente en español. Así que podemos representarlo en forma de tabla. Vamos a llamar L a la llave, A y B a cada una de las ventanas y S a la salida.
|
L |
A |
B |
S |
|
0 |
0 |
0 |
0 |
|
0 |
0 |
1 |
0 |
|
0 |
1 |
0 |
0 |
|
0 |
1 |
1 |
0 |
|
1 |
0 |
0 |
1 |
|
1 |
0 |
1 |
1 |
|
1 |
1 |
0 |
1 |
|
1 |
1 |
1 |
0 |
La tabla es mucho más explícita. No tenemos que estar definiendo esto y lo otro en español, con lo ambiguo que es el lenguaje, sino que queda todo mucho más explícito: tenemos 3 entradas (L, A y B) y una salida S, y nos dejamos de ambigüedades: si L=0, A=0 y B=0, entonces S=0; si L=0, A=0 y B=1, entonces S=0; y así sucesivamente.
Esta tabla se llama tabla de verdad o tabla de estado del circuito.
Pero claro, la tabla es un poco pesada. Si tenemos tres entradas, la tabla tiene 8 filas.[3] Pero si tenemos 4 entradas, la tabla tiene 16 filas. Y cuando hay más entradas… para 6 entradas, tiene 64 filas… empieza a ser inmanejable.
Así que lo que se puede hacer es representar esa tabla en modo algebraico. Para ello utilizamos las formas algebraicas de las puertas lógicas que veíamos en el artículo anterior.
Vamos a poner directamente la función que representa esa misma tabla, aprender a interpretarla, y ya contaremos más adelante cómo se consigue.
La función que consigue el mismo comportamiento definido en la tabla de más arriba es:
S=LA’B'+LA’B+LAB’
¿Cómo interpretamos esa función?
Si recuerdas la notación algebraica de las puertas lógicas que vimos antes, recordarás que el apóstrofe que acompaña a veces a la A o la B significaba un NOT; la “multiplicación” de dos variables (es decir, ponerlas juntas sin símbolo de por medio) significaba un AND y la “suma” (es decir, unirlas con el símbolo +) significaba un OR. Cuidado, porque usar las palabras “multiplicación” y “suma” es muy peligroso. Las utilizo aquí para hacer la analogía con lo que estamos acostumbrados en nuestra álgebra “de toda la vida”, pero no debemos interpretarlo como multiplicación de verdad o suma de verdad, sino como AND y OR.
Por lo tanto, podemos poner esa misma función de la siguiente forma, un poco menos legible, pero que significa lo mismo:
S=(L AND (NOT A) AND (NOT B)) OR (L AND (NOT A) AND B) OR (L AND A AND (NOT B))
¿Vemos que es lo mismo? Bien, pues a partir de ahora seguiré usando la notación algebraica corta, porque es más sencilla de escribir.
Antes de seguir, prometí que iba a decir cómo convertir la tabla en esa función. Es muy sencillo. Las filas en que haya un 0 en la salida, las ignoramos. Las que tengan un 1 son las que nos interesan. Para cada una de ellas habrá un término unido con OR a los demás.
|
L |
A |
B |
S |
|
1 |
0 |
0 |
1 |
|
1 |
0 |
1 |
1 |
|
1 |
1 |
0 |
1 |
Así que tendremos:
algo + algo + algo
¿Qué son cada uno de esos “algos”? Cada uno de ellos lo rellenamos con las entradas de esa fila operadas con un AND. Si la entrada era un 1, ponemos directamente la entrada. Si la entrada era un 0, ponemos la entrada negada. Así, el primer “algo” es:
L · A’ · B’
Recuerda que los · del AND simplemente los quitamos, así que queda:
LA’B’
Por lo tanto, el segundo “algo” es:
LA’B
Y el tercero:
LAB’
Y ahora ya simplemente los unimos con OR:
S=LA’B'+LA’B+LAB’
Esto es lo que se llama Forma Normal Disyuntiva de la función (o simplemente FND).[4] Podemos dibujar entonces el circuito lógico de esta función:
Este circuito funciona. Hace lo que dice la tabla. Si no te lo crees, compruébalo caso por caso, para todos los posibles valores de L, A y B. Pero… es un poco feo… ¿no crees? ¿Podríamos simplificarlo?
El caso es que podemos operar con esa función, de forma muy similar a como operamos con nuestra funciones “normales”. Por ejemplo, podemos sacar factor común, podemos simplificar términos que se anulan unos con otros y cosas así. Aunque vamos a ver algún ejemplo, no vamos a ver cómo son esas operaciones. La mayoría se pueden ver simplemente “por sentido común”. Si quieres profundizar en ello, es mejor referirse a la serie sobre Lógica de Macluskey, en particular al primer capítulo.
Así que vamos a simplificar nuestra función, viendo de paso algunas de las operaciones que podemos hacer.
Para empezar, podemos sacar factor común de la L, ya que está en todos los términos:
S = LA’B'+LA’B+LAB’ = L(A’B'+A’B+AB’)
Ahora fíjate bien en la parte entre paréntesis. Luego revisa la descripción de la puerta NAND del artículo anterior. ¿Te das cuenta de que es lo mismo? Lo que tenemos entre paréntesis es el NAND de A y B, así que llegamos a:
S = L(A’B'+A’B+AB’) = L(AB)’
Por supuesto, existe una manera mucho más formal de hacer esto, pero para nuestro ejemplo nos vale con estas operaciones de “cuenta de la vieja”.
Así que ahora ya podemos dibujar el circuito digital de esa función:
Ahora sí, es mucho más sencillo que el de la FND.[5]
En un circuito tan sencillo como este probablemente, si hubieras dedicado unos minutos a pensar sobre él, hubieras llegado a este diseño de circuito lógico sin tener que pasar por la tabla, la FND y las operaciones. En un circuito más complicado… pues depende. A veces seguir todo este proceso ayuda, y a veces estorba. Más adelante en la serie veremos circuitos digitales donde, simplemente pensando y aplicando lo que sabemos que hacen las puertas lógicas, podremos llegar a circuitos digitales eficientes sin tener que pasar por todo este proceso de tabla-FND-simplificación.
Pero es que la gracia de este proceso de tabla-FND-simplificación no es que sea sencillo o no, sino el mero hecho de que es posible: si tienes una salida digital que depende únicamente de los valores digitales de una serie de entradas, existe un circuito digital de puertas lógicas que logra esa función. Que ese circuito sea sencillo o complejo, que sea fácil o difícil llegar a él, que tenga muchas puertas o pocas… a lo mejor depende de nuestra habilidad. Pero existir, existe. A esto lo llamamos “lógica combinacional” porque se logra simplemente combinando puertas lógicas de forma más o menos astuta.
¿Entendido hasta aquí? Este punto es importante, porque más adelante veremos situaciones en las que tenemos un montón de entradas digitales (empezaremos con cantidades pequeñas, pero probablemente llegaremos a circuitos en los que tengamos decenas) y una o varias salidas que dependen de ellas. Cuando lleguemos a ellas, no mostraremos el circuito: en nuestra explicación nos bastará con saber que el circuito existe y que seríamos capaces de diseñarlo si hiciera falta. Interioriza esa idea antes de seguir.
En el próximo capítulo haremos un inciso para mostrar algo acerca de la representación binaria y su aritmética, porque nos hará falta.
- Fíjate en que eso es sencillo de hacer: es simplemente un conmutador que se conecta a 5V ó a 0V dependiendo de si la llave está girada o no. [↩]
- Como antes, es sencillo de hacer: el pulsador conecta con 0V ó con 5V respectivamente. [↩]
- 2 (valores distintos posibles de cada variable) elevado a 3 (número de variables). [↩]
- Existe otra forma normalizada de presentar la función, la Forma Normal Conjuntiva, en la que en vez de mirar los 1s y hacer ORs de ANDs, se miran los 0s y se hacen ANDs de ORs. Pero ambas formas son equivalentes, representan la misma función matemática. [↩]
- Ojo, que parece ser que, debido al procedimiento de fabricación de los microchips, en algunos casos la FND no es ineficiente, aunque parezca fea porque tiene un montón de componentes. [↩]
The Computador mágico VII – Lógica combinacional by , unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.
{ 12 } Comentarios
Sé que lo que voy a comentar no tiene nada que ver con el artículo, pero es lo primero que he pensado nada más ver el planteamiento del problema de ejemplo.
Es curioso ver que el ejemplo de una alarma se usa casi siempre que se habla de construir circuitos con puertas lógicas, me harté de hacer ejercicios de estos en clase. Al principio los planteábamos como tú, pero después del segundo o el tercero, recuerdo que el profesor nos contó una cosa bastante curiosa acerca de eso. Cuando se hace un diseño de una alarma, las señales de entrada se diseñan justo al revés de como se ha planteado aquí. Es decir, que un 1 es la señal de “no ocurre nada” y un 0 la de “aquí pasa algo”. Para nuestro ejemplo, los sensores de la ventana emitirían un 1 cuando está cerrada y 0 cuando está abierta.
Esto es así porque si, por un casual, se jodiera el circuito sensor, y “pasa algo”, este seguiría emitiendo un 0, por lo que la alarma no se enteraría de nada. El principio imperante en estos diseños es el de precaución, más vale un falso positivo que no un falso negativo. Suele ser un principio a la hora de diseñar sistemas de control.
Como ya he dicho, no tiene mucho que ver con el artículo, pero es que si no lo suelto, reviento.
@Battosay: aunque efectivamente lo que comentas en tu comentario no es relevante para lo que se cuenta en el artículo de J, es efectivamente muy importante en todo diseño de sistema tener en cuenta eso de ¿qué pasaría si…?
Seguro que en diseño de circuitería electrónica esto se tiene más en cuenta (aunque sólo sea para asegurarse de que los aparatos no duran demasiado tiempo, por eso de la “obsolescencia tecnologica”), pero lo que sí te aseguro es que en informática cada vez se tiene menos en cuenta.
La mayoría de neoprofesionales de la informática sólo se preocupan de que su programa/diseño/sistema vaya bien (o sea: más o menos bien, que tampoco hay que exagerar) pero nunca jamás se preocupan de pensar en qué pasaría si…
¿Qué pasaría si el programa casca? ¿Qué pasaría si un fichero no existe? ¿Qué pasaría si el dispositicvo no está ready? ¿qué pasaría si el usuario no hace exactamente lo que el programador/diseñador supone que va a hacer?…
Miriadas de discusiones he tenido sobre el tema. Inútiles. Es como discutir con la pared: simplemente no entienden el problema. Y claro, ahora las aplicaciones y sistemas son cada vez más débiles, inseguras, ineficientes…
En fin, reflexiones de un dinosaurio de la informática…
@ Macluskey, mi comentario no iba tanto por ahí, como por la anécdota en sí. Pero vamos, que lo de, “¿qué pasaría si…?” da para escribir libros. Yo me he dedicado durante algún tiempo a configurar aplicaciones del tipo SAP, que, si bien ya te dan casi todo hecho, siempre te toca a ti picar algo. Y cosas de esas he visto, tanto por nuestro lado, como la del cliente.
Por nuestro lado, porque, aún siendo consciente del problema, simplemente tienes unos plazos que cumplir. Y es curioso como un trozo de código que puede tener tres líneas si todo va bien, se convierte en un cojo-programa enorme si tienes en cuenta todo lo que puede ir mal. Y por el lado del cliente, porque se le pregunta qué quiere que pase en esos casos y no te dice nada o se va por las ramas y te lo deja a tu criterio.
Al final, como vas a ser tú el que se coma el marrón si casca, pues simplemente haces que quede constancia del error y que si pasa te enteres de lo que ha pasado exactamente y ya te pelearás con él cuendo casque. Triste, pero es la realidad de muchas cosas hoy día. Es lo que tiene contratar los trabajos al peso.
Ya. Efectivamente, Es lo que tiene contratar los trabajos al peso… je, je
Pero es que ni siquiera cuando sí hay tiempo; ni siquiera cuando es “el cliente” el que escribe el programa para él mismo se tiene en cuenta el “qué pasaría si…”. Luego, cuando cascan las cosas (porque siempre, siempre acaban cascando, tarde o temprano, más bien temprano, pero siempre) pues ya se verá… y con suerte, ya lo vera O T R O y el que venga detrás, que arrée…
Como tú dices, comprobar programáticamente todos los casos posibles es costoso, pesado y poco vistoso. Aparentemente es dinero y esfuerzo tirado, porque, total, como Todo, todo va a ir bien siempre y en todo momento…, de poco sirve controlarlo todo para que luego no se vea en la demo final al usuario…
Un ejemplo: hay una técnica de ataque a páginas web llamada “SQL injection”, que brevemente consiste en añadir texto SQL a una página normal… Me explico: Supongamos que estas en una tienda online cualquiera, y deseas ver cierto artículo, de código 1588. Es muy muy normal que cuando pinchas en la foto o el link del artículo 1588 se genere una llamada a una página de la forma: tutiendaonline.loquesea/paginadepresentacion…/articulo=1588
El programa (java, php, VisualBasic o lo que sea) que atiende a la paginadepresentacion lee lo que viene tras el signo = y lo usa para construir un hermoso SQL para acceder al artículo 1588, por ejemplo “Select a,b,c… from mitabla where codarticulo=1588″, siendo el 1588 lo que viene tras el = de la invocación.
Pues los hackers que desean atacar la web se limitan a poner en su navegador:
tutiendaonline.loquesea/paginadepresentacion…/articulo=1588 OR 1=1.
Como nadie se molesta en validar qué es lo que viene tras el = (o al menos cortar los 4 primeros caracteres, si esa fuera la longitud de los códigos de artículo), entonces la sentencia SQL que se lanza es ” “Select a,b,c… from mitabla where codarticulo=1588 OR 1 = 1″. Ahora la obediente base de datos en lugar de devolver sólo el artículo 1588, devuelve todos los artículos de la base de datos…
El programa casca, la web se cae, el rendimiento de todo el sistema se desploma… y todo por no poner una misera validación de formato en la entrada. Hay millones de páginas web en el mundo con este problema. Arreglar ahora todo el follón cuesta un montón, cuando haberlo tenido en cuenta en la construcción no hubiera costado virtualmente nada…
En fin, la informática ya no es lo que era.
Hombre no voy a ser yo el que diga que esto es la leche, pero vamos, que no comparto tu punto de vista tan pesimista. Igual es porque llevo currando sólo cinco años y se me acaba pasando.
Pero por cuestiones laborales sí he visto algunas cosas de esos programas mastodónticos en Cobol del sector bancario. Y, bueno, si por mi fuera le plantaba fuego a todo. Porque ahí sí se sigue la máxima del “si funciona no lo toques”. Estos ojitos no se han puesto a llorar como una nena porque uno es un mocetón aguerrido, pero ves procesos con unas limitaciones bestiales, inconcebibles a día de hoy, que no se cambian ni de coña simplemente “porque funcionan”. Nos ha jodido mayo con las flores (con perdón), son programas con más años que yo y si eso no está limado ya hasta el límite, no va a estar nada, efectivamente, tienes un 600 que nunca falla, pero, leches, creo que deberías ir pensando en poner, aunque sea, un Fiesta.
Sobre el ejemplo que pones, pues creo que no es el más adecuado. Es una vulnerabilidad como una casa lo del SQL injection, pero creo que, para darse cuenta la primera vez hay que ser bastante avispado, no es algo obvio. Eso sí, el que, a día de hoy no se proteja contra eso, es para darle de hostias de dos en dos hasta que sean impares. Aunque es curioso, una simple comprobación de tipos, cosa que sí se debería hacer, prevendría todo el desbarajuste. Bueno, igual no es tan mal ejemplo
Comparto contigo en que la informática ya no es lo que era, pero más en el sentido de que ha cambiado mucho, que en el de que antes era mejor (que puede que sí, pero tampoco es para tanto).
Me da pena emprender esta agradabilísima discusión en un artículo de J sobre lógica combinacional… pero bueno, bien está lo que bien acaba, así que… sigamos.
Perdona, J. O mejor, únete!
Vamos a ver. Hace treinta años los medios eran limitadisimos. No había casi CPU, ni memoria, ni capacidad de almacenamiento… Supongo que habrás leído alguno de los artículos de mi serie de la Historia de un Viejo Informático dedicados a los años en que vivimos peligrosamente…
Aquello había que hacerlo andar, y para ello los que trabajábamos en informática sabíamos muchísimo sobre nuestras máquinas, nuestros sistemas, nuestros métodos… No había otra. Y conocíamos perfectamente las necesidades de nuestros usuarios, mejor que ellos en muchos casos.
Pero ¿sabes lo mejor? Lo mejor de aquellos años era que todos, todos, estábamos empeñados en sacar los proyectos adelante. Sistemas, Desarrollo, Producción… todos arrimábamos el hombro y ayudábamos en lo que se nos ocurría para que el proyecto (cualquier proyecto, no el nuestro, acabara y funcionara. Recuerdo con nostalgia esas reuniones de todos los grupos de Desarrollo de los viernes por la tarde en que cada grupo explicaba cómo iba y qué problemas tenía, y todo el mundo se ponía a dar soluciones, echar una mano, dedicar recursos de tu grupo para que el de al lado sacara su embolado particular… Eso se ha acabado. Definitivamente.
Ahora cada cual se preocupa exclusivamente de sus cositas, y le importa un ardite si el de al lado se estrella… es más, ¡prefiere que se estrelle! Si es malo para la compañía, no importa siempre que sea bueno para mí…
¿O no?
La única preocupación de todo el mundo no es “Si funciona no lo toques”, no. Ahora es: “¡Que no me pillen!” Y claro, el que no toma decisiones no se equivoca nunca.
Tú dices que eres consultor SAP, o sea que lo más probable es que estés un tiempo en un ciente, otro más en otro, y así. Por eso quizá tengas una idea sesgada de la situación real de los departamentos de las empresas… porque una vez implantado el SAP o lo que sea, el consultor desaparece y el marrón se queda.
Hablas de esos programas inmensos en Cobol que nadie quiere tocar… no es eso lo que pasa: lo que pasa es que nadie los sabe tocar, porque, claro, los virgueros que los escribieron hace tiempo que se jubilaron y los que ahora mantienen los sistemas apenas entienden nada de lo allí escrito. Y desde luego no tienen ni la más remota idea ni de las posibilidades que dan los mainframes ni mucho menos de los métodos y técnicas que hay que usar en dichas máquinas.
El Cobol es potentísimo; los mainframes con MVS (o como se llame ahora) son las máquinas más potentes jamás construidas; sus capacidades son simplemente estratosféricas… pero, claro, tiene un problema: ¡el iSPF!, con su pantalla negra de 80×24 líneas, sin ratoncitos ni colorines… ¡tan feas! ¿Quién querría trabajar en un sistema tan poco cool…?
Por otra parte, construir ahora de nuevo el sistema completo de un banco, ése tan feo y tan antediluviano, en alguna cosa moderna, exigiría centenares de años hombre de trabajo, máquinas con centenares de procesadores y teras de disco, decenas de técnicos de sistemas dedicados… Irrealizable, vaya. Y todo para hacer apuntes en la cuenta: ¿Tiene Vd. saldo? Pues le pago, ¿No lo tiene? Pues no le pago. Y así. No sé muy bien qué aportaría esa reescritura del sistema en buen java, por ejemplo, para el negocio (para el negocio del banco, quiero decir, que para el de las consultoras, está clarísimo).
En fin, podría escribir seis o siete artículos sobre el tema, pero creo que es mejor dejarlo aquí.
Saludos de nuevo
Bueno, vamos por partes.
La verdad es que me da un poco de envidia ver cómo se trabajaba en tu época. No te voy a negar que ahora la cosa es cada uno por su lado y lo demás que les jodan. Ni pienso defenderlo, pero vamos, que no es sólo en la parte informática, eso es en todo. Creo que una posible explicación es que antes érais cuatro gatos y eso facilitaba la comunicación. Ahora todo es enorme, y el lanzamiento de mierda, que antes sólo se producía en las áreas de negocio, llegó al área de informática.
Soy consultor, pero no de SAP, lo he puesto como ejemplo porque es más conocido y vale lo mismo. Lo que hago yo es bastante específico y sería fácil saber quién soy si lo leyese alguien que me conociera. Prefiero evitar problemas.
Mi caso es pelín particular, porque aunque he cambiado de proyectos, he estado muy relacionado con las empresas en las que estuve, haciendo varios proyectos para ellas y he visto como se funciona demasiado bien. Me conozco bastante cómo está el percal. En nuestro caso no es implantación y a correr. Son proyectos largos, de años, empezamos por un alcance básico y vamos metiendo mierda poco a poco, por lo que llegamos a conocer la casa mejor que el dueño. En mi caso al menos.
En el sentido de conocer lo que hace falta, te puedo asegurar que sigue siendo parecido, seguimos viendo perfectamente lo que hace falta y lo que no, errores que se comenten y que te das de cabezazos para que cambien, pero el “siempre se ha hecho así”, manda mucho. Eso era una ventaja que tú tenías, lo que hacías era nuevo y aportaba una ventaja clara y visible. Ahora es mucho más complicado, ¿por qué vamos a cambiar algo que ya funciona? Pues porque se hace mal, cuesta un huevo y necesitamos hacer más cosas de las que hacemos, pero convence tú de eso al señor que pone la pasta (o al que lo usa, verás qué risa).
Sobre el Cobol un par de cosas.
Primera, no he dicho que haya que quitarlo y cambiarlo todo por algo nuevo. Soy consciente de que no es realista. Lo que digo es que hay procesos que se han estancado y no se cambian ni a hostias. Ejemplo práctico: Soy el Banco Jeando que hace 30 años operaba en Villa Abajo de los Palotes y Comarca. Tengo que automatizar las transferencias y me hago una aplicación que guarda todas las del día, a las doce de la noche se cierra el acceso a las mismas y hasta las seis de la mañana las hace efectivas. A día de hoy soy un banco internacional y compro el Banco Molocos en Ulan Bator. Por política corporativa, Ulan Bator tiene que usar las aplicaciones de España, que cierran por la noche, hora española. Funcional 100%, véndele tú eso al responsable de sistemas de Ulan Bator, verás qué risa. Es un caso ficticio, pero cosas parecidas están ocurriendo.
No digo que haya que darle un patada al Cobol y usar Java (de hecho, dudo que Java fuese una elección idónea para según qué sistemas), pero sí adaptar lo que está hecho a las nuevas necesidades. Y no se hace porque nadie se atreve a tocar lo que está hecho.
Y lo segundo, relacionado con esto. En efecto, los que están a día de hoy, seguramente no tengan ni puñetera idea de lo que hay hecho ni cómo sacar el provecho que le sacábais vosotros. Pero, ¿de verdad alguien duda de que eso no se puede aprender? Te puedo asegurar que si me pagas un sueldo decente, me pongo yo a aprender Cobol y verás qué risa. ¿Lo haré mejor que tú? Lo dudo, porque los años de experiencia no te los quita nadie, pero te puedo asegurar que haré un trabajo más que digno. Ahora bien, no me pidas que te haga un portaaviones pagándome las guarradas que se pagan a los que se dedican a picar código. Te hago una barquita y vas que te das. Creo recordar que tu hija estaba estudiando informática, así que seguro que estás al tanto de lo bien que se paga picar código a día de hoy.
Eso es lo que echa para atrás del Cobol, no las pantallas feas sin colorines. Además, me juego lo que sea, a que hay entornos de programación en Cobol perfectamente bonitos. No me extrañaría nada que Eclipse tuviese un plugin de Cobol.
Me da la sensación que, aunque tenemos visiones distintas, más o menos estamos de acuerdo en lo fundamental. Lo que pasa es que tú eres un viejo informático algo desencantado del mundo y yo llevo cinco años metido en esto y aún me queda la ilusión del nuevo.
Saludos.
Pues sí, amigo Battosay… En realidad estamos muy de acuerdo en todo.
El problema, como quizá se infería en mi comentario anterior, no es tanto en la informática en sí como en el actual “Sistema del Mundo”, como diría Neal Stephenson. Lo que pasa en nuestra profesión es má-o-meno lo mismo que pasa en tantas otras áreas: ya no se paga la perfección. No interesa ser perfecto. A prácticamente nadie le importa que lo que se genere sea perfecto; es más: yo creo que se prefiere que sea imperfecto.
Ejemplos los hay a miles, pero pondré un par:
Han pasado los años, y ¿qué pasa? Que la mayoría de la gente escucha su música en un MP3 patatero (o en el teléfono) con unos cascos baratitos y la propia música, además, está en MP3 como mucho a 128Kb, lo normal a 64, porque es mejor tener 5.000 canciones que se escuchan fatal a tener sólo 1.000 que se escuchan bien. Ya no interesa la perfección para oír música enlatada, cualquier cosa sirve.
Entonces empezaron a salir artilugios: videos Beta, luego 2000 y VHS, Laser Disc, DVD, Blue Ray… la historia es muy similar a la anterior, y el resultado, muy parecido: ahora casi todo el mundo se ve las pelis en el ordenador, con una resolución penosa, un audio horrible, y eso si no lo ven en youtube… La perfección ya no interesa (bueno, salvo para ver partidos de fúmbo, entonces sí que queremos 70 pulgadas en Super-HDTV-Plus…).
¿En informática iba a ser distinto? No, claro que no. Es igual. Preferimos una aplicacióncita guarra que haga tres cositas en vez de una aplicación como dios manda que resuelva el problema de una santa vez. Y, claro, para una aplicaconcita guarra no vas a pagar como si fuera buena.
El Sistema está enfermo. Todo el Sistema, no sólo nuestra profesión. A mí me queda poco para jubilarme (o que me despidan, o ambas cosas, yo qué sé), pero a los que acabáis de empezar… ¡Os queda mucha mili!!
Ánimo, chaval, y que no se pierda la ilusión. Ya ves, aunque no lo parezca, yo sigo yendo a trabajar con la ilusión del primer día por hacer bien las cosas, aunque resulta dificilísimo hacerlo así. Me desespero porque sé positivamente que con un 2% más de esfuerzo se conseguirían sistemas muchísimo mejores… y a veces, incluso con menos esfuerzo, pero dedicado en cosas ligeramente distintas, eso es lo que me quema. Pero ilusión… ¡Toda!
Saludos de nuevo
Mac
Con lo de la perfección podríamos entrar en otro debate harto largo, supongo que habrás oído alguna vez eso de “lo perfecto es lo enemigo de lo bueno”.
Como siempre hay de todo. Yo soy de los que escucha la música en el móvil, más que nada porque me parece feo poner una mini-cadena en el curro. Pero cuando voy de visita a casa de mis padre y pongo el equipo de música que tengo allí (en mi casa tendría que salir yo), da gloria cómo se escucha. Lo malo es que enseguida se oye eso de: “Baja esa música”. No se puede tener todo XDDDD
En lo de las pelis estoy de acuerdo contigo. Aunque he de decir que hace años veía screeners, ahora me dan cáncer de ojos y no se me ocurre acercarme a uno. Recuerdo cuando me compré la tele, 32 pulgadas, acostumbrado a una de tubo de 29 que tenían mis padres. El vendedor me dijo “te parecerá pequeña”, a mí me entró la risa. Cuando puse el primer juego de la Play3 que tuve a 1080, pensé que qué razón tenía.
Y ya paro, que parezco un abuelo cebolleta yo también XDDDD
Macluskey
Tu comentario sobre la inyección de código me ha recordado esta viñeta de xkcd
http://xkcd.com/327/
Un saludo
Genial, Toni.
Llevo media hora riéndome y no sé cuándo pararé…
Enhorabuena por esta serie, J. Está muy bien explicado todo. Gracias por tu esfuerzo
Escribe un comentario