Ver el código de «Apuntes de Papers NoSilverbullet y SmalltalkHistory (Ingeniería II Vieja)»

{{Back|Ingeniería de Software I}}

'''Nota del autor:''' Son literalmente los apuntes que tome de los Papers. Lo pego "as is". A mi me fue bien con ellos, pero no garantizo que esten bien ni que esten completos.


=No Silver Bullet=

Essential vs accidental

* Essential complexity: es sobre estructuras abstractas, estas no se pueden evitar con ningun avanze tecnologico.
* Accidental complexity: es como pasar una estructura abstracta a una aplicacion concreta, con cotas de espacio y velocidad. Estas son de ahora.


Idea: Reduccion de complejidad accidental no es tan valioso como antes cuando habia una enorme cantidad de complejidad accidental por temas como lenguajes de programacion raros o hardware insuficiente. Salvo que la complejidad sea agobiante (90% del trabajo), esforzarse para disminuirla o optimizarla no tiene demasiado sentido. En cabio, hay que concentrarse en mejorar el trabajo essensial, que es sobre el que se trabaja.

> Comprar
> Fail fast
> Crecimiento natural
> Trabajar sobre el diseño conceptual.

La bala de plata habla tanto de tecnologia o tecnicas de administracion, para mejorar la simplificdad, confiabilidad o productividad. Esta no existe. La unica forma de mejorar es aceptando cambios pequeños y progresivos que, acumulandose, lleven a una mejora significativa. El ejemplo que da es abandonar la idea de demonios y humores por los germenes y bacterias. No hay un “exorcismo” que cure a todas la enfermedades, pero sepa por sepa se va para adelante.



Por que software?

Desde la escencia, hay 4 problemas que hacen que el software sea diferente que la produccion fisica.

* Complejidad: Software es extremadamente complejo y lleva a un gran nivel de cohesion. No hay “partes” repetidas, todo trata de tener su propia abstraccion. (y se generaliza desde dicha abstraccion)

>> La cantidad de estados que puede tener un software hace dificil su creacion, documentacion y testeo.

>> Escalar un sistema tambien se vuelve dificil, ya que dificilmente se puedan repetir piezas existentes, y deba crearse un numero exponensial de elementos nuevos.

>> Esto lo compara con la fisica o la matematica, donde se pueden hacer procesos que simplifican propiedades de la realidad, y despues se testean contra la realidad. La propiedad puede entonces ser falseada (o no) ignorando las complejidades que decidieron ser ignoradas. Esto en software no se puede hacer.

>> De esta complejidad sale los problemas administrativos (se vuelve dificil documentar y comunicar cosas), los problemas de entender todos los estados del sistema (que genera unreliability), vuelve a los programas dificles de operar, dificiles de expandir sin efectos adversos y de proteger contra estados que den paso a backdoors (vectores de ataque).

* Conformity: Un software para ser util no puede estar aislado , por lo que tiene la necesidad de adecuarse al marco tecnologlico actual, a las interfaces del software/hardware existente, que vienen de afuera y no pueden ser controladas.

* Changeability: Al software se le demanda mas rapido que cambie. La facilidad de modificar el codigo mezclado con el hecho que en el software el “objetivo” es el “producto”, conlleva a que el mercado lo pida. Usuarios que lo usan y lo disfrutan descubren mas necesidades del dominio, o la aparicion de un nuevo software/hardware requieren que se modifique.

>> Relacionado con conformity, pero esto es para cosas nuevas, confirmity es lo que ya venia antes.

* Invisibility: el software es abstracto y no tiene una forma de mapeaerlo a la realidad fisica. Tratar de generar un mapa o diagrama termina en varios graficos distintos como flujos de dato, patrones de dependencia, sequencias temporales, name-spaces, etc. Todos ellos son aproximados, con decisiones arbitrarias (que pueden replantearse) y sin ningun orden especifico.

>> Nota: propone un paper donde la idea es simplificar datos y postular datos hasta que se genere una jararquia por defecto. 

>> Nuevamente, esto pone en conflicto la comunicacion entre programadores.


Mejoras de dificulatad accidental:

* Lenguajes de alto nivel: permiten concentrarse en elementos mas abstractos como tipos de datos /secuencias /operaciones /sequencias /comunicaciones /etc y dejar de pensar en cosas accidentales de bajo nivel (registros, bits, condiciones, branches, etc.).

>> Agrega la idea de que hay dimishing returns, y hasta problemas en hacerlo demasiado alto nivel. Un lenguaje con mucha parafernallia se puede volver dificil de manejar, creando una nueva complejidad accidental. (no inherente al problema)

* Tme-sharing: La capacidad de poder correr el codigo al mismo tiempo que lo programamos, y no tener un delay. Esto evita los problemas de tener que recordar un codigo que escribimos hace tiempo despues de su corrida, y nos permite tener fresco los pequenios detalles que se pierden con facilidad.

>> De nuevo, dimishing returns. Si tarda menos de un segundo te resbala si son 500 millisegundos, 150 millisegundos o 2 millisegundos.

* Ambientes de desarollo unificado: Cosas como UNIX permiten pegar diferentes programas juntos, salteando la complejidad de tener que buscar una forma de puentearlos.

Problemas:
* Lenguajes alto nivel : Su alcanze es limitado, una vez eliminado la complejidad del alto nivel, los problemas que quedan dan dimishing returns si se tratan de solucionar.

* Object oriented programming:

>> Abstract data types: un objeto tiene su tipo definido por un nombre, valores, y las operaciones, con sus datos ocultos. Es decir, tiene que haber encapsulamiento .

>> Hierarchical Types (classes): las clases son interfaces que tienen que poder hederarse. La clase padre siendo mas general, y las subclasses especificando y/o expandiendo.

En ambos casos ayudan a quitar al programador la necesidad de repetir codigo (o tener cuidado con como se relaciona el codigo entre si) y hacer su codigo mas abstracto. 

De todas maneras, esto solo sirve para expresar de forma mas facil los disenios que ya fueron hechos. La complejidad de generar esos disenios todavia existen, por lo cual no es una solucion universal.

* AI:

>> Definicion 1:  (PAGINA 8) Esto no lo entiendo bien. Automatizacion de tereas con programacion. La idea del autor es que esto no funciona por que podemos tratar de entender con ingenieria inversa como se soluciona el problema. Menciona como varios problemas de automatizacion terminan siendo unicos de su dominio y no agregan valor. Entonce sun programa que entiende dialogo no es lo mismo que un programa que entiende caligrafia, y ninguno de los dos se puede usar. Esta parte del paper es bastante confusa.

>> Definicion 2: Heuristicas o Expert Systems para resolver problemas, que cada vez se adecue mas al dominio sobre el cual se trabaja para dar .

Menciona 2 problemas. El primero es que se tiene que tener mucha informacion del dominio. El segundo es que se tiene que entender el dominio, tener un “experto”.

El autor lo piensa como estas AI puede ayudar a programar mejor . (por ejemplo, en la creacion de tests) El problema con este avance es que achica la diferencia entre excelentes programadores y gente que recien empieza, no elimina nada para alguien que la tenga super clara.

* Programacion automatica: Creacion de programas que crean programas. El autor se queja que para ponerle el input a estos programas, uno tiene que pensar detalladamente que quiere. Desde cierta perspectiva, no hay diferencia con pensar este “input” como un simple lenguaje de muy alto nivel.’

* Programacion visual: definido previamente por que no funciona, el software es dificl de imaginar con imagenes. Por lo general se tiene que resolver el problema ANTES de usar programacion visual.

* Ambientes y Herramientas: linters/IDES/etc. Dice que esta bueno para solucionar problemas como faltas de ortografia, pero que no dan una ganancia significativa.

* Mejroar las estaciones de trabajo: sirve pero no son magicos.


A futuro (este paper fue escrito en los 80)

* Comprar en vez de programar: el software ya esta hecho. Es mas seguro y barato. Esto absoultamente paso, aunque hay una tendencia muy fuerte a nivel monopolico con ciertas apps.

* Refinamiento de requerimientos y prototypado rapido:  Como el empleado no es experto de dominio, la creacion de los requerimientos tiene que ser iterativa.  El prototypado rapido se usa para encontrar errores o saber que algo anda bien de forma economica y veloz.

* Disenio de software de forma incremental (crecer el software, no crearlo): la idea es ir creando al software por etapas. Empezar con algo chico que no haga nada, e ir agregando partes. Recomienda hacerlo top-down.

* Programadores: El valor humano, solo gente que sabe y tiene pasion puede generar buenos resultados.



=SMALL TALK=

‘60 ARPA (defensa) Creen en la “human-symbiosis”, donde el trabajo humano es perfeccionado por las maquinas. Cosas como time-share (permitir que varios usuarios trabajan al mismo tiempo en la misma maquina, eliminando los tiempo de espera necesarios para el batch programming), interfaces graficas o lenguajes de alto nivel. Sobre esto es lo que se construye las evoluciones del libro. De todas maneras, el libro hace enfasis en que el cambio fue drastico, y no tan solo un refinamiento de lo que vino antes.

ARPA → (arpa se dedica a hacer cosas mas concretas, menos research) → xerox park.

Los lenguajes se dividen en dos categorias, “aglutanadores de ideas” o “cristalizacion de estilo”.  En otras palabras, aquellos que tratan de abarcar mucho o aquellos se basan en un concepto muy especifico.

Small talk es la cristalizacion de un estilo que construye de forma recursiva sobre un estructura que oculta sus estados internos y solo puede ser interpretada por su interfaz. (cambio de mensajes)

Objetos – Idea
Clases – Idea de idea (Clase)
La clase “Clase” - idea que es instancias de si misma

Esto permite abstraerse al mundo de las ideas, donde cada idea se parte en otras ideas de mayor o menor fuerza,  y no mapearlo a estructuras mas simples o debiles (como funcioneso estructuras de datos). La metafora que usa alan key es que smalltalk es como un millon de computadoras conectadas, cada una operando a su propio ritmo.

En parte la existencia de OO (al igual que la existencia de IDEs de desarollo y sistemas operativos) se relacionan fuertemente con el avance de la epoca y la “Explosion de silicio”.

OO ya existia en los 60, en parte para tratar con information hidding (o encapsulation) y en otra para buscar formas eficientes de asignacion. (lo que arriba se definia como abstract data types y herarchy classes)

Formas de aprender: apenas se lo percibe → se lo ve pero no parece de importancia cosmica → se lo usa en forma experimental en varias areas → se encuentra un patron y se lo usa como nueva base para enfrentarse a distintos problemas (“nueva forma de pensar”) → se vuelve rigido e inflexible.

Primer caso: sistema de archivo 200 donde cada archivo describia sus propios metodos. Parecido a un objeto.
Segundo caso: sistema B5000 que tenia una tabla de referencia de programas con una interfaz para cada modulo.
Tercer caso: Sketchpad, sistema jerarquico de dibujos y con referencias entre ellos. (parecido a lo visto antes)
Cuarto caso: lenguaje Simula, tenia objetos (actividades) que apuntaban a instancias independientes. (procesos) Esto seria la primer aproximacion a clase-instancia.

>> Disenio recursivo: las partes tienen que ser tan poderosas como el todo. La idea es separar una computadora en “mini computadoras”.

Trivia data: En ARPA lo mandaron a trabajar en una maquina “pequenia” para “usuarios no profesionales” usando algun lenguaje de alto nivel. Alan eligio FLOSS (un lenguaje simple pero bonito) y crearon FLEX. El tema es que querian, de manera dinamica, simular y extender, cosa que no era posible con JOSS. Y debido a limitaciones de memoria de FLEX, SIMULA era imposbile. Probaron con EULER, algo parecido a LISP pero con procesos que eran de primer tipo.
De todas maneras, querian que el nuevo lenguaje para la maquina FLEX estuviera mas influenciado por SIMULA que EULER o ALGOL.

Final de los 60, un tipo ya estaba pidiendo por las computadoras personales.

El objetivo abstracto de “mejora humana” los ayudo a mantenerse en rumbo.

NLS (tecnologia para mostarr informacion de forma grafica y potenicalmente online, como si fuera wikipedoa), tenia una interfaz parametrizable por un parser y un tipo de gramatica libre de contexto. El problema es que las gramaticas imponen limitaciones de que estado a que estado ir (para ser eficientes).

Para la parte visual usaron un sistema como sketch. Por su parte, los objetos son referencias a clases e instancias, como en B5000. En este momento Alan Keyn se dio cuenta que un objeto puede ver visto como un mappeo de los mensajes que responde. (una interfaz) y que cosas como “=” o “+” son mensajes.

Tambien aclaran que tenian expresiones “when” que se activaban cuando sus guardas se cumplian, como un software interrupt. (para esto se pre parseaban en un arbol)

Grails (primera interfaz de tableta para dibujar)

Logo (lenguaje educativo par achicos, primeros pasos para ver eso)

En una conferencia le dieron la idea de un interprete en vez de una compilacion dirigida por sintaxis. La idea que lo movio a eso fue que los sistemas tienen que poder extenderse de forma natural. 

Al hacer esto le llego la idea de que los objetos pueden ser definidos como un interprete de los mensajes que le llegan (sobre su interfaz).

El CAL-TSS tenia punteros inmodificables y mascaras para dar “privacidad” a un objeto, con el fin de generar encapsulaminento. Segin Kain el problema es que solo se hacia para onjetos grandes (no era universal)

LISP falla en que sus mayores partes (lambda, quotes y conds) no lo eran. La duda era por que no volver LISP en un lenguaje de expresiones sin evaluar.


LISP le dio una herramienta para resolver mejor un problema. Entonces su herrmaienta tenian que ser “mejores” e incluir “respuestas dentro suyo”.

La primer version del smalltalk (smalltalk-71) tenia una sintaxis basada en META usando pattern matching. El problema esta en como simular los mensajes a objetos sin caer en “formas especiales”. Ademas,consideraba aplicar lazy evaluation para solucionar el tema del scope/ambiente en donde estan corriendo las cosas

Aca se habla de avances visuales. Con pantallas se hicieron sistemas visuales y programas para pintar.

Y despues sigue hablando de los nenes, como los sistemas no funcionan. La idea fue generar un sistema con soporte visual, programas para pintar y programacion visual.

Quizo escribir el codigo de smalltalk en una hoja (como LISP), pero no pudo por 3 razones No las entiendo del todo, menciona que queria hacerlo mas parecido a otro interprete, el manejo de mensajes y la forma no clara de relacionar enviar con recibir.

Los tipos compartieron informacio sobre el dynabook y XEROX les cerro el chorro, qutandole la capacidad de hacer cosas como presentar sus descubrimientos a universidades.

Bilbo, el primer dynabook, con una la arquitectura de coorutinas (para poder aprovechar el hardware y no caer en interrupciones). Sobre bilbo corria smalltalk. 


1. Everything is an object
2. Objects communicate by sending/receiving messages
3. Objects have their own memory
***
4. Every object is an instance of a Class (Classes are objects)\
5. The class holds the shared behavoiur for its instances (in a program list)
6. To eval a program list, control is passed to the first object and the ramainder is treated as its message.

Smalltalk permitio hacer polymorfismo. 

Junto con smalltalk-72 se llevaron adelante varios projectos Overlapping Windows. Findit (para encontrar classes con los objetos), TWANG (programa de musica), PYGMALION (programacion grafica!)

El primer programa de ventana (hecho en smalltalk-72) era una version simulada de LOGOs.

Despues habla bastante de enseniar a los chicos, y usa la metafora del sindrome del hacker, donde el 5% la tiene muy clara desde el comienzo (se le hace natural), pero hay un 80% que se le hace anti-natural. Su objetivo es ver si puede enseniar a ese 80%.


Smalltalk-74 los mensajes se vuelven objetos. diccionarios de clases, mejora a clases visuales, ademas de memoria virtual con OOZE.

La decision que se tomo es la de dedicar tiempo al recolector de basura, para asegurar tener memoria en caso de necesitarla y evitar crashes.

Necesitaban manejar logs en memoria para volver ante crashes con la integridad de objetos-putneros intacta. Para esto se usa una tabla (Resident Object Table) que aputna a los objetos y a  los objetos de una misma instancia se los aglutina juntos. Mas abajo explica como esa tabla permite eficientar memoria, pero no lo entiendo.

Abstract Data type (que como describimos antes, son cosas con campos internos). Segun Kay en estos se puede reemplazar binding and assignings con goals. El estado interno de los objetos deberia ser algo que no se modifica.

OOP tiene  4 tecnicas valiosas:
* estado persistente
* polimorfismo
* instansacion
* metodo-como-objetivo vs  “asigment-style”

ENCAPSULACION OBLIGATORIA Y TODO PRIVADO!!

Los objetos tienen que definir a si mismo y el programador no tendria que jugar con los estados.

Late binding permite mucha abstraccion, ya que las ideas no quedan atadas hasta no ser necesarias, evitando la explosion combinatoria.

 Nuevamente, se menciona la idea de que el conocmiento es lo que te permite construir con mas facildidad. Como muchas ideas utiles pueden no ser obvias, y se necesita enseniar DISENIO para poder llevarlas a cabo, se prepararon templates. De todas maneras, se dieron por vencido con el. (Alan Kain se arrepinete de eso)

Habla del hacer para saber, que el conocimiento se consigue de forma empirica, y que la computacion es la forma de entrenar esa capacidad. Que uno hace “estructuras” para entenderalas.

El problema es que las metaforas que usamos para expresarlas pueden sobreponerse sobre los objetivos que tenemos con el codigo, y posteriormente volverse dificiles de entender.

Alan habla de ser fluido en el area que se trabaja (y que salga en segunda naturaleza) y de usar el conocmiento para entender otras areas. Nuestro avance tiene que ser con conocimiento fluido y profundo a otras areas que podamos aprender de forma fluida y profunda.


Alan kay menciona como las herramientas tienen un effecto de feedback en sus creadores, y los remoldan. (cosa que es mala si la herramienta esta saliendo mal)

Smalltalk fue rediseniado en smalltalk-76 , cambiando la idea de funcion/clase y transformando todo en metodos intrinsecos. Adicionalmente se le agrego herencia. Por ultimo, se hizo una sintaxis mas rigurosa (y forzada a objetos) para mejorar la ejecucion de la VM que corria smalltalk (ahora llamada OOZE VM)

Delegation style inherance, que parece ser parecido a la idea de interfaces en Java, donde un objeto puede tener varias clases segun como se lo este manejando. (smalltalk no tiene sesto)

Segun kay, la herencia y la instansacion son cosas parecidas, y no hay una buena teoria que explique ninguna de las dos en detalles. (lo que lleva a uso ineficiente de codigo, y a un uso muy liberal del mismo)

* se pide generar una computadora portatil en 1976 y en la creacion de software, el pedido fracasa*


La interfaz visual paso por varias evocluiones, entre ellas una de “esta para que el usuario acceda a los componentes de forma visual” a “esta para que el usuario pueda aprender haciendo”. De la misma forma, el ambiente tiene que ser interesante por que este motiva al usuario. 

Smalltalk-76 fue rescrito de 0 en 6 meses. En 50 clases podia correr todo, incluyendo sistema de archivo, ethernet, etc.

Como habia problemas con los fonts, los fonts se hicieron modificables. 

Nuevamente, no les dejaron sacar laptop.

Steve Jobs lo vio, no lo pudo comprar pero se compro. Smalltalk les mostro el poder de programacion incremental al mostrarles como un pequenio cambio en un minuto tenia un gran cambio en el deslizamiento de la pantalla.


Smalltalk-80 se paso ascii (por compatibilidad), se aseguro que los blockes de codigo se instanciaran como expressiones lambdas (en vez de tener varias fromas de instansacion) y la creacoin de metaclasses.

Alan Kay propone el uso de views en vez de metaclasses, que ademas permitiria simplificar cosas como la clase objeto. Su conclusion es que esto no se adopto por que smalltalk se habia rigidizado.


Segun Kai HW tiene SW pre diseniado. Gtan parte de las mejoras de HW son para hacer late-banding entre cosas y sus recursos (por ejemplo, direcciones de memoria) OOP es 100% late-binding de todos datos que se sabran despues. (donde se ubica, como corre, el hardware, etc.)

El wrapping tiene que ser rapido (por ejemplo, 3+4 tiene que ser pasado al ALU de manera veloz) o decidirse como resolverlo en caso que no se pueda. Alan recomiendo usar llamados a trampas con el MMU usando direcciones virtuales.

Habla de protocolo de metaobjetos donde se cambie el comportamiento de ciertos objetos. 

Ademas, se comenta la necesidad de entender “nuevos” objetos que vienen desde afuera, que es en lo que python entenderiamos como un pickle. El autor habla de como estos objetos viajaran en la red y se propagaran.