December 2008 - Posts
Hace 30 años, yo era un joven adolescente, que vivía en el Gran Buenos Aires, Argentina. Estaba tratando de decidir qué hacer con mi vida. Conocía algunos temas de computadores digitales (lo suficiente como para entender notación binaria, circuitos lógicos, codificación decimal en 4 bits, etc...) pero no conocía nada sobre programación de software. En aquellos tiempos, pocas personas tenían acceso a una computadora, que por aquí eran generalmente mainframes IBM. Por casualidad, comencé a leer sobre software, y tomé un curso de programación. Entonces, mis primeros programas fueron escritos en COBOL, al estilo IBM.
Aún recuerdo los formularios de paper que se usaban para escribir programas COBOL: filas y columnas, los comentarios tenían que comenzar en la columna 7, letras en mayúsculas. Data division, procedure division, y las inacabables variantes de la environment divion. Recuerdo las tarjetas perforadas, y lo inextricable del Job Control Language, un lenguaje extinguido (espero) que supongo tuvo su origen en el antiguo Egipto. . PERFORM ... THRU... OCCURS.... 01, 02, 88 levels, tantas cosas.. ¿dónde está eso ahora? Seguramente corriendo en muchos sistemas financieros y bancarios.
Pero no tenía ninguna computadora donde ejecutar los programas. Los escribía y los probaba en pruebas "de escritorio". No era fácil.. :-). Todo esto pasaba al final de 1978. Al próximo año, encontre un libro sobre programación de IBM 360 assembly language. Comencé a soñar con instrucciones BALR (Branch And Link Registes) y expansiones de macros. Sí, me había transformado en un informático.
Al terminar el colegio secundario, pasé a la Universidad de Buenos Aires, Facultad de Ingeniería, para aprender más sobre computadores y programación. Aprendí sobre computadoras digitales, Algol-W, BCPL, más IBM 3x0 assembly language, pero mucho más sobre matemáticas, álgebra, cálculo, y pensamiento formal. Fue un gran tiempo para mí, mi mente se abrió a temas que algo conocía, pero no había profundizado. Desde entonces, las matemáticas me acompañan, cada año de mi vida. Amo las matemáticas, aún más que al software. Pero en aquellos años, decidí estudiar computación: ese campo esta teniendo un auge en el mercado de trabajo de Argentina, y necesitaba dinero.... ejem... el mismo estado actual de mi vida... ;-)
BCPL era interesantísimo: era una lenguaje compilado, ejecutando en mainframes IBM y en otras máquinas. Su compilador estaba escrito en BCPL mismo: esa idea fue una iluminación para mi mente. Los lenguajes auto definidos son una gran idea. Conocí a un predecesor BCPL leyendo una reimpresión de un viejo artículo del Scientific Americal, que mencionaba al lenguaje CPL, un intento más ambicioso, que por eso mismo no parece haber prosperado.
Fortran IV fue otro lenguaje que se usaba para enseñar programación en esos días. Todavía recuerdo los campos Hollerith, y la falta de recursión (una falta clásica de todo el mundo IBM). Los libros de Mc Craken eran un clásico best sellers. No llegué a trabajar con Watfor , que contenía un preprocesador: sólo con Fortran IV.
Todos estos programas que escribí, se ejecutaban en un mainframe de la universidad, que si mal no recuerdo, apenas tenía algunos K de memoria. Escribía los programas en planillas de papel, alguien (o yo mismo) las pasaba a tarjetas perforadas. Dejaba las tarjetas al administrador del centro de cómputos, digamos, un miércoles, y recien al OTRO miércoles tenía el resultado de la corrida. Si había cometido un error trivial, olvidarme un punto o una coma, debía rehacer el trabajo, y esperar OTRA semana para ver si ahora sí andaba. Con el tiempo, llegué a poder leer las tarjetas perforadas, con sólo ver las perforaciones. EBCDIC era mi amigo (algo feo, las letras no estaban todas consecutivas).
Ah! Otro lenguaje: RPG II. ¡Y qué lenguaje! Cinco clases de planillas a escribir, muchas especializadas en cortes de control para producir reportes. Claro, RPG era la sigla de Report Programming Generator. Solamente con RPG III comenzó a tener características de lenguaje genera, pero me perdí esa versión. Curiosamente, en este siglo actual conocí a un programador RPG III que gracias a eso viajó por más de un continente, teniendo trabajo en eso.
Un día, compré una revista que llegaba a Argentina, la Dr. Dobb's. ¡Qué excelente revelación! Fue mi primer encuentro con el lenguaje C: ¡se podía escribir en letras minúsculas! (como en Algol y BCPL, que de alguna forma fue un precursor del lenguaje C), podía escribir en cualquier parte (no sólo a partir de tal columna). Soportaba recursión, punteros, alocación dinámica de memoria, una verdadera cosa nueva para alguien que había comenzado con COBOL. Las máquinas IBM no tenían ni noción de memoria dinámica, o de lo que era una pila. Las máquinas tipo DEC y otras fueron los "early adopters" de esas ideas. Había un nuevo (para mí) conjunto de caracteres, ASCII, con todas las letras consecutivas!
Pero mi primer amor verdadero fue Lisp: trabajé con una mínima implementación escrita por Gregory Chaitin (creo que había visitado mi universidad unos años antes), donde cada vervo se expresaba con un sólo caracter. Las variables tenía nombres de un solo caracter. Tenía alguna notación polaca. Chaitin lo había escrito en Fortran, sin recursión, imagino que habrá usado algun arreglo para ir simulando una pila. Un día me senté, y escribí mi propia implementación de esa notación, en lenguaje ensamblador de 8086, recuerdo horas de depuración.... Y sí, ya estaba tocado de la cabeza, en esos tiempos... ;-)
Había comenzado a tener acceso a computadoras personales. Pero antes de las PCs, trabajé con mini computadores, como las Microdata, que corrían con Pick operating system. Pick OS fue escrito como para una máquina virtual en microcódigo, así que podía portarse a cualquier hardware que admitiera la implementación de esa "máquina virtual". Es una lástima que Pick muriera joven, en los 90s. Su sistema operativo tenía ideas interesantes: memoria, registros, disco, archivos, eran todo lo mismo, sin diferencia. Podía tener un sector en memoria o en disco. Los registros de los procesos en ejecución estaban en sectores, que de nuevo, podían estar en memoria o disco. Un archivo podía comenzar en el sector 3000 o en cualquier otro sector. Los verbos de consola estaban codificados en sectores. Así, si un comando X estaba en el sector 4320, uno podía reescribir ese sector para implementar una nueva versión del comando. No recuerdo los detalles exactos, pero cualquier comando se mapeaba a un sector usando un archivo por comando, donde la primera línea era el sector. Entonces, se podia copiar ese archivo con otro nombre, y teníamos el mismo comando renombrado. Pick OS tenía un lenguaje de shell, y una interesante implementación de Basic, llamada Pick Basic. Fue el primer programa que tuve disponible para mí, en el que pude escribir programas recursivos. Entonces, reescribí mi intérprete Lisp en ese lenguaje, pero como no tenía soporte de punteros o algo parecido, las listas eran strings, y un CAR era una operación para tomar un substring. No había listas con ciclos. Bueno, era lo que había... :-)
Pick Systems tenía una variante de runoff, el primer programa que usé que generaba manuales desde texto, con soporte de tipos de letras. Imprimía esa documentación en impresoras Printronix, que tenían martillos para plotear puntos en papel.
Con esas impresoras, podía controlar la impresión a nivel de pixel, así que me divertí escribiendo un programa de dibujo: leía de un archivo una especie de lo que hoy llamaría DSL (Domain Specific Languages), dedicado a describir líneas y objetos compuestos, y los ploteaba en 2D/3D, en la Printronix. Me divertia fácil entonces... :-)
Había varias marcas de computadores: Ohio Scientific, Cromemco, Ontel... Recuerdo la Ontel: tenía discos removibles grandes, casi medio metro de ancho, creo. Un día, llevé el disco a un restaurant, y no me dejaron entrar, pensando que era una bomba.
El sistema de archivos de la Ontel era medio "weird": no había ni siquiera FAT (File Allocation Table). Cada sector tenía un puntero al próximo sector del archivo, así que para ir a tal posición de un archivo, el sistema operativo tenía que recorrer una vez los enlaces, recorrido que luego recordaba. Recuerdo un día, un fin de semana con una entrega el lunes, y mi jefe se equivocó editando sectores, y los enlaces se perdieron. Pasamos una mañana recuperando manualmente los enlaces de los archivos de textos que tenían el código, fue una especie de trabajo de rompecabezas.
Con Ontel se programaba en OPL: Ontel Programming Language, una especie de assembler, una instrucción por línea. Pero tenía un editor de pantalla decente: la primera vez que me senté en una Ontel, no me levanté en un días: imaginen, era la primera computadora que TENIA para mí solo, podía escribir el programa y probarlo ahí mismo!. Luego de la experiencia de las tarjetas perforadas, fue un avance hermoso.
Ohio Scientific tenía una cantidad inmensa de memoria para aquellos tiempos: 64K (creo que el mainframe de mi universidad tenía una capacidad similar). 32K estaban dedicados al intérprete basic. Los otros 32k eran para mi programa. Cada línea tenía un número. Uno escribía la línea 10, luego la 20. Si uno quería agregar más lógica entre las dos, debía usar un número intermedio. Pero contrario a las Ontels, que eran mono usuario, las Ohio soportaban múltiples terminales.
Compilando con esas máquinas era un ejercició de multitasking: mientras compilaba, uno se podía dedicar a otras "tasks", como hacer café, ir al baño, charlar con las jóvenes recepcionistas de la oficina... ;-) ... Compilar podía ser un proceso largo en esas máquinas.
Más máquinas: escribí programas COBOL en cinta, para máquinas NCR. Debía partir el programa en partes, porque el compilador no podía compilar programas grandes. Por aquel entonces, se agregó a COBOL la screen y report sections, pero no recuerdo haberlas usado.
Mi primera computadora personal real fue una IBM. Tenía una sola disketera. Uno tenía que bootear con un diskette, retirarlo, y luego poner un segundo diskette, donde estaba el editor, el edlin en aquellos días. El GWBasic era el intérprete que usaba. Pero antes de llegar a DOS, programé para CP/M, el bebé de Gary Kildall. No tenía directorios, sólo archivos. Los programas se cargaban en una posición fija de memoria. No había realocación, o direcciones relativas. Los primeros 128 bytes de un programa eran un header dedicado. La ejecución comenzaba en 100h, y el procesador tenía 4 registros. Luego, el Intel 8086 nos trajo AX, AL, AH.... SI, DI eran los source increment, destination increment, que se usaban para movimientos masivos de memoria... DS, CS apuntaban a los segmentos de datos y código, con lo que ahora tenía realocación y direcciones relativas, otro avance.
Recuerdo vagamente haber trabajado algo con CP/M multiusuario. Sí, había una versión con soporte de multiusario. Pero fue tarde para el bueno del CP/M: el DOS había comenzado a dominar el mundo.
No tenía soporte de base de datos en DOS. Entonces, escribí una rutina de manejo de árboles balanceados, invocada desde GWBasic, pero escrita.... en assembler!. Reconozcamos que en esos tiempos, ya merecía medicación... ;-).... Años después, apareció BTrieve.
Ah! La Int 21h, era la puerta al paraíso del DOS. Para tener compatibilidad hacia atrás con CP/M, la instrucción de la dirección 0 era un jump a la int 21h. El cargador de exes ponía ahí la dirección exacta de esa interrupción. En CP/M, una llamada al sistema operativo era un jump a la dirección 0 del programa en curso. Ahí había un jump al sistema operativo, creo que se usaba el registro C para pasar qué tipo de llamada queríamos.
¿Recuerdan Sidekick? Uno debía reescribir el config.sys, agregar una línea con files=40 y todo andaba.
¿Y el command.com? Residía en memoria. Si era sobreescrito, el sistema operativo lo recargaba. En los sistemas de una disketter que mencioné, eso implicaba a veces, sacar el diskette que uno tenía, y reponer el diskette que tenía el command.com.
¿Y recuerdan el BIOS? Yo trabajé también para IBM Argentina, y tenía acceso a uno de los diez (sí, sólo 10!) BIOS Reference Manual que había disponibles en mi pais. Incluía el listado del código fuente, en assembler. Recuerdo haber paseado por la interrupción del reloj, y haber explorado el código de la interrupción que atendía la presión y liberación de las teclas.
Acostumbraba a leer revistas como Byte, TechJournal, Computer Language, y como mencioné, mi favorita, Dr.Dobb's. Disfruté leyendo ahí del Small C y su implementación por Cain y luego por Hendrix. Estaba asombrado de otras implementaciones, como los compiladores de C Leo Zorman. Recuerdo avisos en Dr.Dobb's de la universidad de Vrije University, ofreciendo un cross compiler (supongo que era el trabajo de Tanenbaum) por unos módicos u$s 9999.
Gracias a las máquinas PC, tuve mi primer encuentro real con un sistema tipo Unix: el venerable Xenix de Microsoft, se podía ejecutar en PCs. IBM tenía otra oferta, un AIX, y un PSystem, sistema operativo basado en Pascal. Pero el DOS despegó fuerte y tomó control del mercado.
Un día, descubrí en las oficinas de IBM, a su Global Network, que comunicaba todas las subsidiarias. Uno podía preguntar algo a un grupo de producto, por ejemplo, uno de Australia, via un mensaje electrónico, y tenía una respuesta, posiblemente en el mismo día. Fue mi primer experiencia con ese tipo de comunicación.
Exploré y jugué con el Dialog system: uno de mis primeros trabajos relacionados con la búsqueda en documentos. El Dialog era un sistema en línea, para buscar papers, libros, usando palabras claves. Con un equipo, programamos un sistema similar par un agencia del gobierno de Argentina. Podría considerar un predecesor de Google.... ;-)
Aprendí Smalltalk, en mi tiempo libre. No había clases de Smalltak en mi universidad. Pero sólo podía aprender sin practicar, porque el costo del hardware para correr el entorno gráfico y el costo de los ambientes de Smalltalk, eran no alcanzables para mí. Lo mismo me pasó con Golden Common Lisp, y sistemas expertos: no pude probarlos por falta de recursos, así que seguí escribiendo mis propios intérpretes, que eran muy primitivos.
Bueno, podría seguir escribiendo por días sobre aquellos primeros años. Pero el punto es: la pasé bien, me divertí, fueron años interesantes. El desarrollo de software sigue siendo hoy así, algo fascinante. Lección aprendida: el cambio es la única constante, en esta profesión y arte.
Pero más importante que el software y la tecnología, es otra cosa. Tuve suerte: durante esos años, llenos de actividades, tuve la oportunidad de conocer a gente extraordinaria. La gente ha sido la verdadera ganancia de estos años de profesión. Quiero entonces, hoy, agreceder a todos, a amigos, compañeros desarrolladores, clientes, que me acompañaron en esta larga jornada. Este post es solo un fragmento de mis memorias, enfocado en algunas tecnologías. Pero lo importante estuvo en otra parte: la gente que conocí. ¡Gracias a todos!
Imágenes de
Confessions of an Antediluvian Geek - A personal history of computing
WikiPedia Commons File-Punched_card.jpg
Old Computers Museum
My personal experience with technology, from the early years of computers in the 1970's to today in 2008
Enlaces relacionados
Historic Documents in Computer Science
http://delicious.com/ajlopez/computerhistory
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Desde fines del 2006, estoy trabajando con programación distribuida, usando CCR/DSS, WCF y otras tecnologías, como Message Passing Interface. En estas últimas semanas, comencé a trabajar con High Performance Computing Windows HPC Server 2008.
Ahora, en Enero, daremos con Sebastián Renzi 
(@SebaRenzi) un seminario gratuito en el Microsoft User Group:
SEMINARIO GRATUITO "Programación Paralela, Programación Distribuida, High Performance Computing".
Thursday, January 15, 2009
Lugar: Auditorio del MUG, Rivadavia 1479 1º A, Ciudad de Buenos Aires.
Ahí está el abstract:
Hay aplicaciones que necesitan procesar gran cantidad de información, o que tienen requerimientos de velocidad exigente.
Exploraremos en la charla algunas tecnologías y estrategías que tenemos disponibles como:
- Programación Paralela: usando múltiples threads, TPL (Task Parallel Library).
- Programación Distribuida: enviando el trabajo a realizar a distintas máquinas, usando WCF o DSS/CCR
- High Performance Computing: ejecutando jobs, tasks, y programas
HPC Server 2008 es el producto de Microsoft que permite armar un cluster de máquinas, pudiendo llegar a tener cientos de nodos.
Es la tendencia actual en supercomputación.
Mostraremos ejemplos de código de cada uno.
Las vacantes son limitadas.
La idea es explorar algunas ideas de AjMessages, grid computing, Task Parallel Library, MPI, MPI.NET y programación HPC. También mostrar código andando, esperamos poder llevar un cluster virtualizado andando, para mostrarlo en la charla.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Actualicé mi ejemplo de fractal y ahora soporta MPI.NET (Message Passing Interface with .NET) y tasks paramétricas en Windows HPC Server 2008. El ejemplo puede ser bajado desde mi proyecto Google code ajcodekatas:
http://code.google.com/p/ajcodekatas/source/browse/#svn/trunk/FractalExample
Hay dos soluciones. Esta es la Fractal.sln:
El proyecto Fractal.Console es una aplicación de consola que toma parámetros de la línea de comando. Los usa para generar un sector del fractal, al que serializa binariamente en un archivo:
static void Main(string[] args)
{
if (args[4].Equals("*"))
args[4] = "0";
SectorInfo sectorinfo = new SectorInfo()
{
RealMinimum = Convert.ToDouble(args[0]),
ImgMinimum = Convert.ToDouble(args[1]),
Delta = Convert.ToDouble(args[2]),
FromX = Convert.ToInt32(args[3]),
FromY = Convert.ToInt32(args[4]),
Width = Convert.ToInt32(args[5]),
Height = Convert.ToInt32(args[6]),
MaxIterations = Convert.ToInt32(args[7]),
MaxValue = Convert.ToInt32(args[8])
};
Calculator calculator = new Calculator();
Sector sector = calculator.CalculateSector(sectorinfo);
SectorSerializer serializer = new SectorSerializer();
string filename = string.Format("{0}-{1}-{2}-{3}-{4}.bin", args[9], sectorinfo.FromX, sectorinfo.FromY, sectorinfo.Width, sectorinfo.Height);
serializer.Serialize(sector, filename);
}
Pueden ejecutar el proyecto en modo DebugYou can run the project in Debug mode, con parámetros:
Lancen el nuevo proyecto Fractal.GUIFiles. Es una aplicación WinForm, como la que presenté en mi anterior posts, pero con un nuevo botón Read a la derecha:
Con ese botón, pueden seleccionar uno más archivos de sector, como el que generó Fractal.Console en su directorio bin\debug:
Este es el resultado:
Creando sectores con HPC
La aplicación de consola puede ser usada en un cluster. Supongamos que la aplicación está instalada en el directorio c:\FractalConsole en cada nodo del cluster. Supongamos que el nombre de la máquina head del cluster es HEAD-NODE, y que ahí hay un directorio compartido llamado \shared, que puede ser accedido desde cada nodo. Entones, podemos lanzar un job paramétrico:
job submit /parametric:0-500:100 c:\FractalConsole\Fractal.Console.exe 0.3 0.3 0.01 0 * 1000 100 2000 4 \\HEAD-NODE\shared\sector
Este comando envía un trabajo al cluster, pero con un parámetro variable. El asterisco en la lista de parámetros será reemplazado por los valores 0,100,200,300,400 y 500 (en este caso, es la coordinada Y de la esquina superior izquierda de un sector). Cada ejecución producirá un archivo con un sector serializado en el directorio compardio, que podremos leer y mostrar usando la aplicación Fractal.GUIFiles.
Usando MPI.NET
Hay una segunda solución Fractal.MPI:
Este código usa MPI (Message Passing Interface). El rank 0 recibe los datos de un sector, y lo parte en subsectores, que son enviados a todos los ranks (instancias) de la aplicación. Cada instancia genera un archivo, con la serialización de un subsector del sector original.
Para compilar y ejecutar este ejemplo hay que instalar el HPC Pack que se baja de:
HPC Pack 2008 SDK download
e instalar el MPI.NET Software
(Yo instalé MPI.NET SDK.msi pero también bajé y expandí MPI.NET-1.0.0.zip: tiene mejores ejemplos, con soluciones completas para Visual Studio)
(Nota: si quieren ejecutar el ejemplo bajo XP Pro, deben bajarse NO el HPC Pack, sino la anterior versión:
Microsoft Compute Cluster Pack SDK
El nuevo SDK tiene un problema con XP. Más información en:
http://social.microsoft.com/Forums/en-US/windowshpcdevs/thread/19deb181-15c2-40be-bb5e-2d4604b984a4
http://www.pluralsight.com/community/blogs/drjoe/archive/2008/10/10/32-bit-sdk-for-hpc-server-2008-fails-quot-the-procedure-entry-point-getprocessidofthread-could-not-be-located-quot.aspx
)
Podemos ejecutar el programa usando el utilitario mpiexec, que lanza varias instancias de un mismo programa, conectados como ranks de MPI:
mpiexec -n 10 Fractal.Mpi.Exe 0 0 0.01 0 0 500 1000 2000 4 sector
El sector será producido entonces por 10 instancias, en este caso:
que podemos leer y mostrar usando Fractal.GUIFiles.
Podemos ejecutar el anterior comando en un HPC cluster, usando:
job submit /numnodes=10 mpiexec c:\FractalMpi\Fractal.Mpi.Exe 0 0 0.01 0 0 500 1000 2000 4 \\HEAD-NODE\shared\sector
(asumiendo que hemos copiado la aplicación en cada nodo, dentro del directorio c:\FractalMpi de cada nodo)
Para un más completo ejemplo, ver:
Learning Parallel Programming — from shared-memory multi-threading to distributed-memory multi-processing
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter/ajlopez
Esta es la última entrega de la charla de la charla de Alejandro Reimondo de Smalltalking, dictada hace unas semanas en la Universidad Tecnológica Nacional, sede Buenos Aires. Como antes, transcribo no textualmente las palabras de Alejandro en cursiva.
En Smalltalking, promovemos la idea de ambiente de objetos. Un ambiente no es su contenido, sino que es una trayectoria en el tiempo, de algo que vemos cambiar, y somos parte de ese cambio, pero ningún elemento que está dentro del sistema, tiene por qué subsistir en el tiempo. Lo que está fijo aca es la identidad del sistema, aunque cambien todas sus partes.
Es parte del sistemismo. Tenemos como ejemplo una persona, aunque cambien sus células, la seguimos considerando la misma persona. Como mencioné en otro post, es parte del problema de la identidad, planteado desde Leibniz, pero aclarado en gran parte con el sistemismo.
¿Que es Smalltalk en esa definición? Es algo en trayectoria en el tiempo, y cada persona tiene su Smalltalk, no hay un Smalltalk, hay un Smalltalk por cada persona. Y Smalltalk bajó esa idea de ambiente, es el de cada uno. El contenido no lo ves. Cada Smalltalk es un objeto.
En Smalltalking, no hablamos del lenguaje, o del contenido, o de la IDE, aunque hay smalltalkers que dicen que es eso. Cada uno tiene su trayectoria, y va cambiando lo que es ST para sí mismo.
No es algo que termina en una propuesta de arquitectura, esto es algo que está aceptado que todo cambie, y lo que se preserva es la identidad, mientras uno lo esté usando. Cuando falte uno mismo, para nosotros no es un ambiente.
El ambiente es la trayectoria de ese sistema abierto. Es abierto, por sus contenidos, porque puede tener nuevos contenidos, y abierto en el tiempo.
En la práctica, los contenidos de otras alternativas, son más fijos. Ruby, Python, son alternativas que están ancladas en esa caracteristica de Smalltalk, y promovidas para tener difusión.
Yo veo que hay algo más en esos lenguajes y otras tecnologías. Hay una comunidad. Eso es lo que hace que una tecnología o lenguaje tenga más sinergia. No es sólo uno el que programa o diseña. Igual hay que meditar sobre otras propuestas, y no tomar todo lo que es aceptado por una comunidad como verdad absoluta.
Es entender que Smalltak es un soporte para un cambio reiterado, pero es en sí, una trayectoria, no es una definición de un lenguaje o contenido, no son las clases o los frameworks lo que hacen al Smalltalk, sino que pueden cambiar, no es la maquina virtual, que tambien puede cambiar.
Yo veo que el soporte del cambio somos nosotros mismos y la comunidad. Tal vez por eso, no me impresiona esta visión del cambio que plante Alejandro. Lo importante es hacer, y también pensar y meditar sobre lo que hacemos, las herramientas que usamos y cómo las usamos.
Nosotros en Smalltalking, sólo se nos ha acercado smalltalkers.
Y yo diría que sólo algunos.
Se plantea: definímelo bien lo de ambiente. Y lo mejor, es no definirlo, sino uno entra dentro del método, lo estamos definiendo, y lo estamos cerrando.
No veo que una definición tenga que ser algo cerrado. Justamente, la definición lo que aclara es el camino para la comprensión, dentro de un diálogo. Ese miedo o rechazo a la definición, no lo veo justificado. Se confunde definición con definición cerrada. Ninguna definición en matemáticas congeló a las matemáticas. Un ejemplo en filosofía en
Sócrates y los nombres
Lo que es interesante, es lo que pasa. Cada vez que uno plantea esto, se pregunta, ¿qué estas planteando?
Hay otras formas de plantear lo mismo, como un soporte para un espíritu creativo, como una herramienta para inventar el futuro, como Alice, Squeak, en donde la propuesta es la mejor manera de predecir el futuro es inventándolo.
Muy emocionante plantearlo de esa manera, pero es una manera de garantizarnos un solo futuro. Y todos convergemos a esa idea.
Cada persona tiene distintos caminos, son divergentes, y las realidades son divergentes.
Hoy hay avances concretos en hacer desaparecer la maquina virtual; no ha ocurrido propuestas donde todo está descripto en objetos. En una maquina virtual, no podemos cambiar la maquina virtual mientras está corriendo. Pero en realidad, todo deberia cambiar. Es lo que se llama hoy sistemas sustentables, hoy tiene ese nombre, ST siempre fue asi, sustentabilidad de sistemas, S3.
Algo más sobre eso en mi post
Self-sustaining Systems, Cola, Pepsi, Coke y Mate - Angel Java Lopez
Les recomiendo el workshop de Postdam en alemania, es muy curioso las cosas que se plantean, tienen que ver con eso, que todo son objetos y todo puede cambiarse, la máquina virtual y su semántica no es el ambiente, esa idea no es necesaria, todo puede cambiar.
Alejandro menciona la reunión de
Self-sustaining Systems 2008 (HPI)
La idea es que los propios lenguajes puedan tener la suficiente expresión para cambiar su propia semática.
Es muy comun, preguntar, ¿cuál es el mejor Smalltalk? El mío. Se refieren al dialecto que usan. En realidad, es el mío, el que uso.
La comunidad es una formulación, como la de cardumen, y pone o seduce, de que es algo que es positivo, que cuando más instancias de uso de la herramienta hay, es mejor para la herramienta. Hay casos en que no es así, como el caso de Smalltalk que lo usan pocos, pero pervive.
No estoy negando el valor de idea de comunidad, lo que digo, es que para cosas de propagación vertical (padre a hijo) de Smalltalk, no sé si tiene valor.
Cualquiera puede aprender a programar en el "lenguaje" Smalltalk.
Leonardo, un asistente, pregunta: me gustaria que aclares cuando se considera programar en ST.
Donde esta definido una formula, una arquitectura, uno puede plantear un tiempo para aprenderla. Cuando todo puede cambiar, no. Hasta uno cambia y produce cambios en el camino.
Smalltalk como trayectoria, nos hace poner el foco en la actividad en lo que hacemos, mas que en el producto.
Aca tenemos oportunidades, por lo cerca de estamos con las catástrofes, en personas de otras latitudes no es tan común entender lo que hablamos.
Por acá tampoco. Acá se acabó el tiempo. Fue una lástima, porque quedaron temas para tratar. Pueden ver alguna información más en el sitio de Smalltalking. Pero sería interesante que Alejandro pasara en limpio las ideas finales a las que quería llegar. El piensa, por lo que entiendo, que el tema de lenguajes sustentables es importante, y que podemos hacer algo desde Argentina. Veremos cómo se desarrollan esas ideas, en los próximos años de Smalltalking.
Post relacionados
Superando los límites de la Orientación a Objetos (Parte 8)
Superando los límites de la Orientación a Objetos (Parte 7)
Superando los límites de la Orientación a Objetos (Parte 6)
Superando los límites de la Orientación a Objetos (Parte 5)
Superando los límites de la Orientación a Objetos (Parte 4)
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Sigo en esta entrega, transcribiendo y comentando la charla de Alejandro Reimondo de Smalltalking, dictada hace unas semanas en la Universidad Tecnológica Nacional, sede Buenos Aires. Pongo la transcripción, no textual, en cursiva.
Una cosa es decir "soy observador, y no me quiero comprometer, soy un orientado". Eso paso con la orientación a objetos.
Hay una POO, DOO, LOO, y hay con objetos. No hay libros donde se hable de eso. Todos tienen la O en el medio, de "Orientado", no se habla de "Programación con Objetos", sino de "Programación Orientada a Objeto".
Abundan la gente que habla de lo que funciona, pero no te dicen lo que no funciona.
En cambio reiterado, también se puede usar Smalltalk, y ahí se ve a Smalltalk como plataforma, como un buen IDE, ese cambio reiterado en un lugar donde todo se puede cambiar, el todo es un objeto me permite seguir proyectando y hacerlo crecer. Y genera en muchos smalltalkers una actitud de fanatismo. El fanático es el que ve distintas alternativas, elige una, y esa la defiende a muerte. Es una etapa común en los smalltalkers, una etapa de fanatismo. Y a veces, en los demás, es percibido como no entendible.
Y lo digo así, porque yo he pasado esa etapa, y ya no soy fanático, ¿por qué? Porque no veo alternativas ... ;-) ... no hay herramientas comerciales que permitan trabajar de esta manera.
Se refiere a programar con objetos.
¿Y por qué? ¿Me pongo a escribir otra cosa? Uno ve que tratan de salir otras cosas, que se parecen a Smalltalk, y luego no lo son, ¿por qué? No entiendo. Hay muchos orientados a objetos, hay pocos ambientes de objetos, y uno es Smalltalk, ¿por qué va a haber otro? Porque siempre lo podemos cambiar.
Lo que quiere decir, es que Smalltalk es cambiable, y de ahí, que no hace falta otra tecnología, en principio.
Ha habido otras cositas tan seductoras como Smalltalk pero no han logrado instalarse.
Algunos usan Smalltalk como sistema cerrado, y valoran Smalltalk con el concepto de imagen. Dicen entonces que Smalltalk es una caja que contiene objetos.
Acá Alejandro mostró un programa en 3 dimensiones, con un pez en una pecera, programado para nadar y reaccionar de forma simple.
No hablamos entre diferencia entre clase y especie. Este pez tiene una colección de pensamientos que puede tener basado en su especie. Este pez es muy estúpido, que sabe ir para hacia adelante, si ve a alguien de su misma especie, va a para ese lado. Cuando esta solo en la pecera, se choca contra todos los bordes. El sistema es pobre, es estúpido.
Si quiero cambiar el sistema, ¿qué puedo hacer? Ir a programar nuevo comportamiento, o puedo agarrar y poner más peces. Pongo diez peces más, y ¿qué pasa? Empiezan a juntarse y se hace un cardumen. El sistema es más eficiente, porque no hay tantas colisiones contra las paredes, los peces aprendieron a no chocarse contra las paredes, y trabajan en grupo. Esto se logra con mas peces. No hubo que cambiar el sistema.
Ese es el punto del ejemplo: no hizo falta cambiar el sistema, sólo agregar objetos. Y el comportamiento que se dió, es emergente: puede o no haber sido previsto por el que colocó la conducta en "pez". Y no hizo falta codificar, pensar, diseñar a "cardumen".
Cuando uno ve esto, piensa en codificar la clase cardumen. Pero vean que curioso, no hubo necesidad. Hay un candidato a objeto que no era necesario hacerlo. Era un objeto que no existía pero era un observable. Hay cosas que observamos que no son objetos. ¿Qué es, entonces, un objeto? Dije que un cardumen no es un objeto. Uds. debian saltar y decir ¿cómo? En las charlas informales de Smalltalking, es un observable, es cardumen. Pero muchos le ponen nombre y lo quieren hacer un objeto.
En cambio, cardumen es una abstraccion. ¿Vamos a poner en el sistema algo que nunca vamos a instaciar?. Estamos haciendo algo que no es del sistema, es algo orientado a objeto. Y en el equipo aparece la evidencia de ese observable, y alguno del equipo lo agarra y lo toma como objeto. Pero no lo es, ¿dónde aparecen los indicadores de que no es un objeto?
Cuando uno tiene un cardumen, y ponemos un vidrio, el cardumen original se divide en dos ¿cuál de los dos es el cardumen? ¿es ésto o es el otro?. O si tenemos dos cardumenes, y se juntan, ¿cuál desaparece?
Se invierte mucha energia en un equipo, para decidir lo que es evidente para todos y no es un objeto. Pero en un ambiente nos damos cuenta.
No queda bien definido a qué se refiere con ambiente, a esta altura de la charla. Venía más adelante una aclaración, pero no alcanzó el tiempo de la charla. Alejandro tiene que comenzar a manejar mejor los tiempos, para lograr transmitir lo que quiere decir. (En un cliente, me hacen practicar dando charlas de 10 minutos... ;-)
Uno de los indicadores es la instanciación, y la identidad. Si no podemos definir la identidad, dudemos de la conveniencia de definirlo como objeto.
Lo interesante es tener un soporte informático para ver un emergente del sistema, al ejecutarlo, antes de que el equipo se de cuenta.
El gran tema acá es la emergencia. Recomendaría para una lectura más amplia, el libro de Mario Bunge "Emergencia y convergencia", y otros, como su filosofía de la biología, para comprender mejor a sistema y emergencia.
En el sistema, van a emerger cosas, independientes de nuestra visión o voluntad de dirigir. Quedarnos con solo nuestra voluntad, nos olvidamos de estos emergentes que van a suceder. El paradigma de objetos se compromete con el tiempo, el sistema incorpora cambios.
En física tenemos sistemas ideales, reales, y naturales. La física trata los ideales, en la práctica, se tunea, para llevar ese modelo ideal a un modelo real, que funcione en máquinas. Y de la naturaleza nadie la trata. Hay un sistema natural, no tiene tratamiento, desde el momento en que uno lo representa.
Lo interesante es Smalltalk como soporte para que las cosas pasen, antes de darnos cuenta de por qué. Nos sirve para definir objetos, y para observar cosas que ocurrían, en cambio de decir de antemano "esto es un objeto, preserva identidad".
Esto de estar dentro y fuera del sistema, hace que las personas entiendan a Smalltalk como un sistema vivo, y en mi opinión, es una expresion usada sin cuidad, esto es lejos de ser un sistema vivo.
Post relacionados
Superando los límites de la Orientación a Objetos (Parte 7)
Superando los límites de la Orientación a Objetos (Parte 6)
Superando los límites de la Orientación a Objetos (Parte 5)
Superando los límites de la Orientación a Objetos (Parte 4)
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Este año, había escrito una demostración de generación de fractal, usando DSS/CCR, ver:
Distributed Agents and Fractals using DSS/VPL
Agentes Distribuidos usando DSS/VPL
Ahora, estoy explorando pasar el ejemplo a ejecución en paralelo, usando, entre otras tecnologías, Task Parallel Library, threads, o MPI (Message Passing Interface). Antes de pasar a programar esas nuevas versiones, añadí a mi proyecto Google code ajcodekatas, una aplicación base, un WinForm que dibuja un fractal, usando un solo thread, el mismo del proceso de la GUI:
http://code.google.com/p/ajcodekatas/source/browse/#svn/trunk/FractalExample
Tiene una librería de clases, con las clases principales, y un proyecto WinForm, que usa un objeto Calculator para calcular un Sector del fractal. Un fragmento de la invocación:
private void Calculate()
{
Bitmap bitmap = new Bitmap(pcbFractal.Width, pcbFractal.Height);
pcbFractal.Image = bitmap;
pcbFractal.Refresh();
realWidth = realDelta * pcbFractal.Width;
imgHeight = imgDelta * pcbFractal.Height;
realMin = realCenter - realWidth / 2;
imgMin = imgCenter - imgHeight / 2;
int width = pcbFractal.Width;
int height = pcbFractal.Height;
SectorInfo sectorinfo = new SectorInfo()
{
FromX = 0,
FromY = 0,
Width = width,
Height = height,
RealMinimum = realMin,
ImgMinimum = imgMin,
Delta = realDelta,
MaxIterations = colors.Length,
MaxValue = 4
};
Calculator calculator = new Calculator();
Sector sector = calculator.CalculateSector(sectorinfo);
this.DrawValues(sector.FromX, sector.FromY, sector.Width, sector.Height, sector.Values);
}
Ejecutando el proyecto Fractal.GUI, y haciendo click en el botón de Calculate, obtenemos:
Podemos arrastrar el mouse, seleccionando una zona. Al soltarlo, una nueva imagen es generada. Podemos cambiar los colores, que son generados al azar:
Próximos pasos
Quiero añadir en las nuevas versiones:
- Una versión multithread
- Una versión en paralelo usando Task Parallel Library
- Una versión distribuida (MPI.NET? AjMessages?)
Parte de la aplicación la vamos a mostrar en el webcast de hoy:
Webcast de desarrollo con Windows HPC Server 2008
Si son impacientes, puede ver este excelente tutorial, que implementa una aplicación fractal usando HPC 2008, y también con las tecnologías que mencioné arriba, está listo para descargar con código desde:
Learning Parallel Programming — from shared-memory multi-threading to distributed-memory multi-processing
Sugerencias, comentarios, bienvenidos!
Angel "Java" Lopez
http://www.ajlopez.com/en
http://twitter.com/ajlopez
Mañana viernes estaré dando con Sebastián Renzi (@SebaRenzi) un nuevo webcast de HPC, esta vez dedicado a la programación de aplicaciones para ese cluster. Pueden registrarse en:
Desarrollo de aplicaciones para Windows HPC Server 2008
(Estaré participando en lugar de Jorge "Chorch" García). Habrá ejemplos de MPI.NET, con código. Estoy adaptando mi ejemplo de Fractal:
Fractal application revisited
para que se pueda ejecutar por jobs parametrizados y por MPI.
Enlaces a anteriores webcasts en
Webcasts de Introducción a High Performance Computing (HPC)
Quedaron grabados, así que si se registran, pueden ver la grabación.
Post relacionados:
Primeros pasos con MPI.NET
Realidad aumentada con Windows HPC
Recursos de Windows High Performance Computing (HPC) y Programación
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
El fin de semanas, estuve escribiendo un ejercicio casi tipo codekata. Me gusta explorar la idea de programas evolutivos (como agentes con programas incorporados que van evolucionando en ambientes simulados), así que puse manos a la obra, y creé una solución dedicada a experimentar con una ejemplo de prueba de concepto. Está escrito en C#, usando VS 2008, usando el soporte de test de la herramienta. He publicado el código dentro de mi Google code project ajcodekatas en:
http://code.google.com/p/ajcodekatas/source/browse/#svn/trunk/EvolveExample
La solución es EvolveExample:
(Si no tienen el soporte de test de VS, pueden remover el proyecto Evolve.Test).
Las clases principales residen en el proyecto de librería de clases Evolve :
Animal representa un agente. Tiene una lista de Instructions, que son generadas al azar. El animal habita un campo con comida. Su programa tiene instrucciones como Eat, Move East, North, West, South, o Predate (tomar energía/comida de otro animal que esté en la misma celda de la grilla). Cada instrucción tiene un costo: un punto de energía. Eat es una instrucción que toma 10 puntos de energía o menos, tomando comida de la celda actual. Predate toma 100 puntos de energía o menos, restándoselo a otro animal que esté en la misma celda.
Para ver el programa en acción, lanzar el proyecto winform Evolve.GUI, seleccionar la opción Evolve -> Run. Veremos:
El campo es una grilla (en este ejemplo, de 20x20). Cada celda tiene un nivel de comida (verde está llena, negro es vacía). A la derecha, una lista muestra los mejores animales y sus programas. Los animales son rankeados de acuerdo a su nivel de energía al final de cada ronda de simulación. El programa continúa con más simulaciones, usando nuevos campos. En cada nueva simulación, la población es ordenada por energía descendente, y los mejores son incluidos en la nueva simulación, los lugares vacantes son ocupados por mutaciones de esos mejores, y algunos animales son inyectados con programas aleatorios.
Durante una simulación, aparece información sobre el nivel de comida y el animal que mejor se desempaña, al pie de la ventana.
Con las opciones de menú Food y Population podemos establecer el nivel de comida y el número de animales, a usar al comienzo de cada simulación. Estos valores se usan recién la próxima vez que elijamos Evolve -> Run. La opción Evolve -> Stop puede ser usado para terminar una serie de simulaciones.
Próximos pasos
Este es un primer ejemplo, una prueba de concepto que sirva de base. Tengo algunas ideas, para explorar en futuras versiones:
- Tener un conjunto de instrucciones más interesantes, con condicionales, y que sea sensible al ambiente. Me gustaría añadir instrucciones como "Si hay comida en tal dirección, ir hacia allí". En vez de un programa lineal, podría armar un árbol de instrucciones, algo como un programa Lisp.
- Los valores de ejecución (tamaño del campo, nivel de comida, energía inicial para cada animal), deberían poder establecerse por un formulario, y leer y grabarse de archivos XML.
- Serializar los resultados y poblaciones en archivos XML
- Evolución en un cluster. Podría usar AjMessages, AjAgents, o MPI sobre unc luster HPC, para simular evolución en una grilla o cluster de máquinas.
Como es habitual, ¡me divertí escribiendo este código!
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
http://delicious.com/ajlopez
Prosigo transcribiendo y comentando brevemente, la charla de Alejandro Reimondo de Smalltalking, dictada hace unas semanas en la Universidad Tecnológica Nacional, sede Buenos Aires.
Transcribo las palabras de Alejandro en cursiva:
Muchas veces se valora el cambio reiterado. Cuando trabajamos formalmente, hacemos un cambio en un sistema, y hacemos en otro sistema, no estan comprometidos uno con el otro. Hicimos un cambio, pero un sistema pudo ser correcto y el otro no. Cuando hay cambio, hay riesgo, entonces minimicemos los cambios.
En base a reconocer este problema, lo que se propone, es hacer iteraciones minúsculas, ciclos iterativos para produccion de software. Y quien tiene éxito trabajando de esta manera, son muchos los que tienen éxito, dicen, "yo trabajo de manera evolutiva", y es entendido entonces que evolución es cambio reiterado de características. Se trata de usar el cambio iterativo, para cambiar para mejorar. Pero estamos siendo inocentes, cambio implica intención, hay una dirección cuando planeamos la iteración.
No veo que la gente diga que trabaja de manera evolutiva, sino iterativa. Como en otros puntos de la charla, no hay una referencia a porqué se afirma algo. Si pongo el contexto de las metodologías ágiles, en un desarrollo iterativo la dirección de cambio puede ir cambiando, porque cada vez tenemos (los que desarrollan, y quienes necesitan el desarrollo) más idea y contexto de lo que necesitamos. Alejandro apunta a otro tipo de cambio, cuando dice evolución, pero (perdón que insista) de nuevo no da ningún ejemplo concreto. Ese es un problema en las presentaciones de Alejandro. Cada uno puede formarse una idea distinta, de un concepto, porque no está completamente definido, y lo "fuzzy" no se despeja, porque no hay ejemplo. Como siempre, el lenguaje humano es limitado, pero gran parte de esta charla, es una adivinanza, una especie de "veo veo", "¿qué ves?" "algo que llamo evolución", y nada más.
Evolución es lo que uno observa sobre algo que ya paso, como pasó, no lo sé! Pero tenemos un sistema que es distinto del que era. Luego, escribimos que hubo evolución, pero no fue planificado.
Asimilándolo a ciencia, esta distinción es parecida a lo que habría entre evolución biológica y diseño inteligente. También podría asimilarlo a historia humana vs ingeniería social, donde en la primera, los sucesos pasan (revoluciones, reordenamientos) sin una intervención humana dirigida.
Eso tambien tiene implicancia en ecología, se hacen cambios iterativos sobre objetos reales, para tratar de hacer evoluciones favorables, pero no tiene que ver con evolución, evolución describe lo que ya pasó, no es la intención dirigida.
Las teorías, cuando las cambiamos, cambian, no evolucionan. Todo cambio usando un lenguaje implica una voluntad definida a priori.
Yo diria que hay evolución, uno cambia algunas partes de forma dirigida, pero hay un nivel donde el ecosistema del software tiene evolución. Un caso que se me ocurren es la emergencia de Ajax, que no fué planeada, fué un emergente ocurrido ante la combinación no esperada de tecnologías que fueron apareciendo, no para llegar a Ajax, sino para solucionar otros problemas inmediatos.
Cambio implica entender antes de hacer. Evolución no. Es algo que pasó.
Ir diciendo como va el mundo, es útil en algunos contextos. En evolución, miramos lo que pasó hacia atrás, y reflexionamos. El cambio es imperativo.
Acá no entendí si esta frase indicaba: "El cambio (dirigido), al contrario de la evolución, es imperativo", o "El cambio (en evolución) es imperativo (siempre pasa)". Así me pasa con varias frases.
Uno no sabe todo, porque esta basado en un metodo reductivo.
Yo veo que no es un tema de método. Es un tema de no saber todo, por incapacidad humana, no por culpa del método reductivo.
En evolución, partimos de qué cambió, y ahora observamos. Todo cambio tiene un valor, es innegable. Ahora decir que por ese cambio genero tal cosa, nos perdemos otras cosas que tal vez genero.
Uno planifica cambios, no planificamos evolucion.
Hay un montón de cosas, que conviene decir lo que otro quiere escuchar. No hay que referirle reuso a alguien que dice reuso de componentes. Ahora, ante alguien que busca espacio en algo alternativo, es importante plantear estas diferencias.
Hoy es muy usado evolución, y no se detienen a pensar. Y dicen que cambios iterativos es evolución. Y deforman la palabra, pero evolución es otra cosa.
Evolución te hace dar cuenta, que por mas cambio que uno planea, hay cosas que pasan.
Insisto, hubiera sido interesante haber planteado un ejemplo de evolución en software. Creo que evolución es un término abusado en varios ámbitos. Se lo plantea como similar a la evolución biológica, y ésta tiene características muy definidas. Y si hablamos, en vez de evolución biológica, de evolución, hay que definir más precisamente a qué se refiere entonces esa palabra en solitario.
Post relacionados
Superando los límites de la Orientación a Objetos (Parte 6)
Superando los límites de la Orientación a Objetos (Parte 5)
Superando los límites de la Orientación a Objetos (Parte 4)
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Estoy leyendo el libro Agile Java Development with Spring, Hibernate and Eclipse, escrito por Anil Hemrajani. Acerca del autor:
Anil Hemrajani ha estado trabajando con Java desde finales de 1995, como desarrollador, emprendedor, autor e instructor. Es el fundador de Isavix Corporation, un exitosa compañía de servicios IT (ahora Inscope Solutions), u de isavix.net (ahora DeveloperHub.com), una comunidad de desarrollo, que ha crecido a más de 100.000 miembros registrados. Tiene 20 de años de experiencia en la comunidad de IT, habiendo trabajdo para varios de las compañías Fourtune 100 y también en organizaciones más pequeñas. Ha publicado numerosos artículos en revistas bien conocidads, presentado en conferencias y seminarios alrededor del mundo, y ha recibido el premio "Outstanding Contribution to the Growth of the Java Community" de Sun Microsystems, el premio "Best Java Client" en JavaOne por BackOnline, un producto de backup cliente/servidor basado en Java, y fue nominado para el premio Computerworld-Smithsonian por un sitio web que brinda un servicio online gratuito de almacenamiento de archivos. Su más reciente proyecto es el sitio visualpatterns.com.
Es un muy buen libro, que cubre los temas de logging, depuración remota, prácticas ágilas, JMX, JUnit, Ant, programación con POJOs (Plain Old Java Objects), librerías de tags de JSP, y más. Pero ahora, estoy interesado en comentar algunos párrafos del prefacio. Hemrajani escribe:
I began working with Java technology in late 1995, shortly before the Java Development Kit (JDK) 1.0 was formally released. Prior to that, I was programming in C and C++ for many years. I was truly excited about the features that Java offered, such as cross-platform portability, simpler syntax (simpler than C++, for example), objectoriented, secure, rich API, and more.
Traduzco libremente:
Comencé a trabajar con la tecnología Java a finales de 1995, poco antes de que el Java Development Kit (JDK) fuera formalmente liberado. Antes de eso, yo estuve programando en C y C++ por muchos años. Yo esta realmente excitado acerca de las nuevas características que ofrecía Java, como portabilidada cross-platform, sintaxis simple (más simple que C++, por ejemplo), orientado a objetos, seguridad, rica API, y más.
Yo tuve una carrera similar, pero por estos pagos. En algún momento de 1995, aprendía el lenguaje Java y parte de la librería, pasando a ser un fan del lenguaje. Era una liberación de programación con C++ (plagada de problemas de bien manejo de los new y los delete), y de Visual Basic (donde no había herencia, ni objetos completos). Pero debo admitir que la interfaz GUI estaba aún basada en una fea implementación AWT.
Over my 20-year career, I have learned a few things. Among these, my favorite is simplicity; anytime I see complexity, I begin doubting whether the solution is correct. This is how I had begun to feel about Java right around 2000, when the Java 2 Enterprise Edition (J2EE) started becoming mainstream. Note that from this point on, I will refer to J2EE as JEE because the "2" was recently dropped from the name by Sun Microsystems.
En mis 20 años de carrera, he aprendido unas pocas cosas. Entre ellas, mi favorita es la simplicidad: cada vez que veo complejidad, comienzo a dudar de si la solución que estoy viendo es correcta. Es así cómo me sentía alrededor de Java cerce de 2000, cuando el Java 2 Enterprise Edition (J2EEE) comnezaba a ser conocido. Noto que en desde ahora, me referiré a J2EE como JEE porque el "2" ha sido recientemente removido del nombre por Sun Microsystems.
Coincido. Cuando Sun lanzó J2EE, era todo un revoltijo. Por años, pensé que ellos, los de Sun, estaban en lo correcto, y que yo no entendía las razones para la complejidad subyacente en los Enterprise Java Beans. Hasta que leí los libros de Rod Johnson sobre desarrollo empresarial con Java: ahí confirmé lo extraño y complejo que es EJB.
My growing lack of interest in Java was a result of what I saw as unnecessary complexity in JEE introduced by layers of abstraction. I began to believe that Sun Microsystems (inventor of Java) was focusing Java and JEE on solving the most complex enterprise applications, but somewhat ignoring the relatively less complex, small- to medium-sized applications. Furthermore, I saw the hype take over people's common sense because I ran across projects in which Enterprise JavaBeans (EJB) were used for nondistributed processing, such as local logging. I felt strongly enough about this subject to write a short article for JavaWorld.com in 2000 (http://www.javaworld.com/javaworld/jw-10-2000/jw-1006-soapbox.html) titled, "Do You Really Need Enterprise JavaBeans?" (About five years later, we saw EJB 3.0 specifications being rewritten to become more simplified, to ease the development.) This brings us to this book and the reason I wrote it.
Mi crecience falta de interés en Java era un resultado de lo que yo veía como complejidad innecesaria en JEE, complejidad introducida por capas de abstracción. Comenzaba a creer que Sun Microsystems (los inventores de Java) estaba enfocando a Java y JEE para resolver aplicaciones complejas empresariales, pero ignorando las relativamente menos complejas aplicaciones pequeñas y medianas. Es más, yo veía que todo esa excesiva publicidad sobre el tema, estaba haciendo olvidar el sentido común, porque veia proyectos donde Enterprise JavaBeans (EJBs) estaban siendo usados para procesamiento no distribuido, como el logging local. Me sentía seguro en el tema, como para escribir un corto artículo en JavaWorld.com en el 2000 (http://www.javaworld.com/javaworld/jw-10-2000/jw-1006-soapbox.html) titulado, "¿Realmente necesita Enterprise JavaBeans?" (cinco años más tarde, vemos que la especificación EJB 3.0 ha sido reescrita para ser más simple, para facilitar el desarrollo). Todo esto nos trae a este libro y las razones para haberlo escrito.
Los EJBs son el trabajo del diablo. La programación con POJO, ORMs (Object Relational Mappers) como Hubernate, y el uso del framework Spring, son ejemplos de buen diseño creados por la comunidad de Java. Finalmente, la gente de Sun vió la luz, y adoptaron muchas ideas de la comunidad en su nueva especificación EJB 3.0, pero para mí, eso fue un ejemplo de "demasiado poco, demasiado tarde". La programación con EJB fue siempre una pesadilla, que merece ser borrada de la memoria de la humanidad entera.
Al comienzo de cada capítulo en este libro, hay una ilustración, describiendo una historia ficticia, que recorre el libro, describiendo cómo se lleva a cabo el desarrollo de una aplicación. No puedo resistir incluir una, del capítulo 2 (hay más en visualpatterns.com):
Más información sobre este libro, en
http://www.visualpatterns.com/agilejava.php
Esa página tiene la tabla de contenido, y comentarios de Scott W. Ambler, y Rod Johnson.
Otro libro que recomiendo, alineado con estas ideas:
Better, Faster, Lighter Java O'Reilly Media
también orientado a usar Hibernate, y Spring, pero explicando en cada capítulo las razones para adoptar tal o cual diseño.
Este post apareció originalmente en "Anglish" en
Agile Java Development with Spring, Hibernate and Eclipse
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Hace un tiempo, postée sobre la reunión que tuvimos en Buenos Aires, sobre Inteligencia Artificial. Se comentó también en los foros de ADVA (Asociación de Desarrolladores de Videojuegos de Argentina), pueden ver el thread completo en:
http://adva.com.ar/foro/index.php?topic=5254.0
(más sobre la reunión en
Inteligencia Artifical en Buenos Aires
Artificial Intelligence meeting in Buenos Aires
)
Hay muchos puntos interesante, pero me gustaría publicar acá el fragmento de un mensaje de Hernán Moraldo:
Creo que la IA está en este momento en un punto crítico, en diferentes sentidos en el mundo y en Argentina. En el mundo, porque lo que hasta ahora era casi un juguete académico, al menos para el que miraba de afuera y excepto por algunos usos específicos, se convirtió en muy poco tiempo en una disciplina que invade todas las áreas de la tecnología, con usos muy cotidianos (a veces hasta invisibles), como en las cámaras con detección de sonrisas, los buscadores que son lisa y llánamente grandes estructuras de IA, la detección de voz en servicios telefónicos, los captchas, los filtros de spam, las interfaces basadas en gestos o en visión, y un larguísimo etcétera. Y no sólo estos usos cotidianos, por supuesto, ya que en general las más grandes formas de IA están pagas por grandes empresas u organismos de tipo militar por ejemplo.
En Argentina, porque está empezando a hacerse visible alguna actividad, y porque si se la sabe buscar hay demanda para las aplicaciones útiles de IA, entonces quienes se meten en esto en general llegan a sacarle el jugo. Creo que lo que hace falta es de alguna manera que la gente que viene trabajando en IA, de todos los sectores (privado, académico, amateur, etc) entre en comunicación para que no tenga que estar cada uno en la suya sino que se pueda compartir información, materiales, posibilidades de trabajo, etc. Pienso que aún una muy pequeña comunidad de IA local podría ser muy útil para todos los interesados en el tema acá.
Coincido con el comentario. Otro participante dió un panorama de la actividad de IA en el ámbito académico:
La comunidad local de IA no es pequeña y existe hace rato. Nosotros en la Universidad N. del Sur hacemos Inteligencia Artificial hace mas de 15 años. La Universidad del Comahue y la Universidad de San Luis también tienen grupos de IA, con diversos desarrollos, y nos conocemos todos entre si, tenemos muchos amigos y hemos hecho muchas cosas juntos. En la UN de la Patagonia también se desarrolla en IA. En la Universidad Nacional de San Juan y en la UN de La Pampa también. Ya mencionaron en la reunión a la UNCPBA. Todos con mayor o menor medida hacen algún desarrollo en IA. Todos tenemos contacto entre nosotros y con muchas universidades extranjeras con algunos convenios de cooperación internacional. El CACIC (Congreso Argentino de Ciencias de la Computación), que se hace todos los años en diferentes lugares del país (2009 en Jujuy), tiene hace mas de diez años un Workshop de Agentes y Sistemas Inteligentes (WASI), donde nos encontramos anualmente varios investigadores de éstas y otras universidades. Ocurre lo mismo con las JAIIO, que es menos itinerante que el CACIC, pero en el 2009 se hace en Mar Del Plata. Realizó varias veces un simposio Argentino de IA (ASAI) donde también reunían investigadores locales en IA.
La comunidad es grande, pero a veces no trasciende en el mundo empresarial.
Coincido con ambos comentarios. Uno de los asistentes a la reunión presencial, ya había comentado la separación que hay entre el mundo académico y la industria local. Nos faltaría un panorama de la industria, de las empresas que necesitan IA, que ya la están usando, o que están creando software con IA incorporada.
Pueden ver más información sobre el CACIC en Congreso Argentino de Ciencias de la Computación de este año.
Agregaría también el WICC 2008 (X Workshop de Investigadores en Ciencias de la Computación 2008)
Recuerden que el año que viene (2009) tenemos el
Congreso de Inteligencia Computacional Aplicada
acá en Buenos Aires.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
En estos días, estoy explorando la programación con MPI, usando la librería MPI.NET implementada sobre el MPI de Microsoft, que puede ser usada en Windows HPC Server 2008.
MPI es el acrónimo de Message Passing Interface, una API que soporta la programación de programas con paralelismo. Una apllicación MPI puede ejecutarse en varias instancias, llamadas "ranks", y cada instancia puede recibir y enviar mensajes de y a las otras instancias. La API puede ser consumida desde lenguajes como C o Fortran. MPI.NET es un "wrapper" que facilita la escritura de programas MPI usando .NET.
No necesitamos un cluster para ejecutar un programa MPI. Cada programa puede ser probado localmente, lanzando varios ranks como procesos en nuestra máquina local.
Hace unos días, escribí algún código de ejemplo, para probar MPI.NET. Pueden bajarse el código desde mi Skydrive desde MpiNetFirstExamples.zip.
Si quieren probar otro camino, hace un tiempo escribí sobre otra implementación de MPI sobre .NET:
MPI Message Passing Interface in .NET
MPI
MPI (Message Passing Interface) está soportada por Windows HPC. Hay una implementación de Microsoft:
Microsoft MPI (Windows)
que puede ser invocada desde C++.
Hay una implementación .NET sobre Microsoft MPI en:
MPI.NET: High-Performance C# Library for Message Passing
Contiene el código fuente y ejemplos.
Para escribir y ejecutar los ejemplos de este post, instalé el HPC Pack que encontré en:
HPC Pack 2008 SDK download
y luego instalé el MPI.NET Software
(Instalé el MPI.NET SDK.msi pero también expandí el MPI.NET-1.0.0.zip: tiene mejores ejemplos, con soluciones VS)
Cuando se instala el HPC Pack 2008 SDK, nos quedan nuevos programas:
Y con MPI.NET:
Si expandimos el archivo adicional MPI.NET-1.0.0.zip obtenemos un directorio con más ejemplos y documentación:
Más sobre MPI en general:
MPI 2.0 Report
MPI Tutorials
Microsoft Messaging Passing Interface - Wikipedia, the free encyclopedia
Pure Mpi.NET
Hello World
Como siempre, un "Hello, World" es la primera aplicación a intentar. La solución es:
El código de program.cs es simple:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace MpiNetHelloWorld
{
class Program
{
static void Main(string[] args)
{
using (new MPI.Environment(ref args))
{
Console.WriteLine("I'm {0} of {1}",
MPI.Communicator.world.Rank,
MPI.Communicator.world.Size);
}
}
}
}
Notemos el uso de ref args en la inicialización del MPI.Environment. Un programa MPI recibe argumentos especiales que deben ser procesados y removidos del resto de los argumentos.
Si lo ejutamos en solitario, obtenemos:
No muy impresionante.... ;-)
Podemos invocar un comando mpiexec:
mpiexec -n 8 MpiNetHelloWorld.exe
y la salida es:
Hay 8 ranks (instancias) ejecutando en la misma máquina. Si tienen un cluster con soporte de MPI (como el Windows HPC Server 2008) podría ejecutar el program en todos los nodos del cluster.
Ringing con los nodos
En el anterior ejemplo, no hay comunicaciones entre los nodos. Un clásico ejemplo es enviar mensajes en un anillo, desde el rank 0 al 1 al 2, y al final, volver al 0. Esta es la solución:
El código de program.cs es:
class Program
{
static void Main(string[] args)
{
using (MPI.Environment environment = new MPI.Environment(ref args))
{
Intracommunicator comm = MPI.Communicator.world;
if (comm.Size < 2)
{
Console.WriteLine("At least two processes are needed");
return;
}
Console.WriteLine("I'm {0} of {1}",
MPI.Communicator.world.Rank,
MPI.Communicator.world.Size);
if (comm.Rank == 0) // It's the root
{
string sendmessage = string.Format("Hello from {0} to {1}", comm.Rank, comm.Rank + 1);
comm.Send(sendmessage, comm.Rank + 1, 0);
string recmessage;
comm.Receive<string>(comm.Size - 1, 0, out recmessage);
Console.WriteLine("Received: {0}", recmessage);
}
else
{
string recmessage;
comm.Receive<string>(comm.Rank - 1, 0, out recmessage);
Console.WriteLine("Received: {0}", recmessage);
string sendmessage = string.Format("Hello from {0} to {1}", comm.Rank, (comm.Rank + 1) % comm.Size);
comm.Send(sendmessage, (comm.Rank + 1) % comm.Size, 0);
}
}
}
}
Dispersando mensajes
Este es otro ejemplo (la solución MpiNetScatter), donde un arreglo de enteros es enviado a todos los ranks, un entero a cada uno, desde el rank 0:
class Program
{
static void Main(string[] args)
{
using (MPI.Environment environment = new MPI.Environment(ref args))
{
Intracommunicator comm = Communicator.world;
if (comm.Rank == 0)
{
int [] numbers = new int[comm.Size];
for (int k = 0; k < numbers.Length; k++)
numbers[k] = k * k;
int r = comm.Scatter(numbers);
Console.WriteLine("Received {0} at {1}", r, comm.Rank);
}
else
{
int r = comm.Scatter<int>(0);
Console.WriteLine("Received {0} at {1}", r, comm.Rank);
}
}
}
}
Threads y MPI
Podemos mejorar el ejemplo de anillo, usando una nueva característica de MPI2, soportada por la implementación de Microsoft: enviar y recibir mensajes usando múltiples threads. La solución es MpiNetMultiThreadRing. El código:
class Program
{
static void Main(string[] args)
{
using (MPI.Environment environment = new MPI.Environment(ref args))
{
Intracommunicator comm = MPI.Communicator.world;
if (comm.Size < 2)
{
Console.WriteLine("At least two processes are needed");
return;
}
MultiComm multicomm = new MultiComm(MPI.Communicator.world);
Thread thread = new Thread(new ThreadStart(multicomm.Run));
thread.Start();
MultiComm multicomm2 = new MultiComm(MPI.Communicator.world);
Thread thread2 = new Thread(new ThreadStart(multicomm2.Run));
thread2.Start();
thread.Join();
thread2.Join();
}
}
}
Escribí una clase ayudante, MultiComm, que tiene métodos para enviar y recibir mensajes. Usa un lock: la implementación MPI no soporta el uso de comandos MPI, desde más de un thread en simultáneo. Entonces, tuve que sincronizar los métodos de acceso a MPI desde diferentes threads. Es un incordio, pero es lo que está soportado (no sé si hay una implementación de MPI2CH que soporte un nivel de multithreads libres).
Conclusiones
MPI implica una nueva manera de pensar aplicaciones. No hay un camino fácil para convertir a MPI un algoritmos o aplicación. Podría jugar un poco más con el pasaje de mensajes de forma asincrónica. En los ejemplos de este post, cuando una instancia envia un mensaje, las otras partes deben estar escuchando para recibir el mensaje. Dejando sus idiosincracias, MPI es un interesante campo para explorar, con una amplia comunidad que hay producido interesantes aplicaciones.
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Sigo transcribiendo (notas no textuales) la charla de Alejandro Reimondo de Smalltalking.
Como antes, transcribo lo de Alejandro en cursiva:
Cuando empieza a popularizarse? Tiene que ver con toda esa historia y el vínculo con la ciencia. Y otra cosa interesante, plantea un camino iterativo de superación. Uno+uno, 2+1, nos alienta a ese inductivismo de hacer objetos hasta que te mueras.
Ahora, Alejandro embate contra la especialización, yo lo veo como recordatorio de no olvidarse del sistemismo.
Hay grandes obras que se han construido de esta manera, en ingeniería, utilización de recursos, las represas, ingeniería nuclear, son obras dignas de todo nuestro respeto, pero no podemos dejar de ver los efectos que todo tiene (peces muertos, una gaviota picoteando), y cuando veo eso, en Atucha 2, los que lo construyeron, ya no están. Cuando los peces empezaron a flotar, ellos ya no estaban. Trataron de llamar a los ingenieros. Pero no, ese no es mi área, no es mi pedazo de la torta. No forma parte de mi óptica, se llama a biólogos, hay un problema que la usina produce tres grados más que van al lago, más temperatura, menos oxígeno, menos peces. ¿Que podemos hacer? Pongamos peces que necesiten menos oxigeno. ;-). Tratamos de emparchar, en vez de ver lo que ya hicimos. No digo que está mal construida la usina, sino que cada vez que se enciende una luz, se proyecta una sombra.
Hay gente que protesta, en el Congreso, cuando ya está hecho, y son los que se dedican al arte, y ninguno entiende mas allá de su torta. Cuando más es su estudio profundo, más huecos tiene, y más temas no son de él.
Aparece un mensaje sobre el "slide" "Smalltalk como plataforma iterativa".
Lo interesante de Smalltalk es hacer cambios y ensayos, es un proceso iterativo. Quien trabaja de esa manera, va a ver a herramientas de Smalltalk, más que un lenguaje. Valora un browser, un inspector. Son muy valorables las herramientas que hay en ST.
La más notable, ver para creer. Quien ve algo, cree en ese algo, nadie cree en algo que no vió. El identificar un objeto, verlo, implica no dudar sobre su existencia, es algo valiosísimos, es algo muy utilizado cuando trabajamos con objetos, ¿por qué? ¿por que es así la realidad? No, porque queremos que otro no dude.
No lo vean que estoy diciendo que esta mal, hay puntos de valor que encontramos con objetos.
Acá hubo una discusión sobre modelo, no la seguí completamente.
Yo no quiero decir dónde tienen que ir los demás, sino que gente de esta región, busque algún ancla en estas críticas, para propugnar un avance. Lo mío no es ataque de la ciencia, sino crítica.
Yo reveria esta postura, estudiaría Bunge y el sistemismo, la ciencia no es como EL metodo que describe Alejandro.
Entonces, se ve a Smalltalk como un completo y robusto de conjunto de componentes "re" usables.
Cuando uno habla de POO, DOO, LOO, esta la palabra, y hacemos orientado a objetos. Esas palabras empiezan con distintas letras (P, D, L) y termina con O de Objetos. Pero nadie se detiene en la O del medio.
Vamos a POO, dice que hay algo que es programación con objetos, pero POO no lo es, sino sólo orientado a objetos. Todos toman que la "orientada" siempre va. Pero se está diciendo que hay algo que es programación con objetos, al que no van a llegar.
En las revistas de Smalltalk, se dibujó un puente entre lo tradicional y objetos. Planteamos una transición, para llegar a objetos. Eso fué hace veinte anios, pero todavía estamos encima del puente, sin ver la O del medio, no hemos abandonado lo de "orientado".
Tenemos una tecnología para trabajar sobre la realidad y no la estamos abordando. No haciendo dibujos sobre la realidad, sino que es el instrumento para llegar a la realidad misma. Si nos quedamos en el ver, pero no vamos al tocar, y realimentar con nuestros sentidos, vamos a estar del lado de lo orientado, y en nuestros problemas de como pensamos al mundo.
Acá de nuevo, hubiera sido interesante mostrar un ejemplo de "tocar" objetos en Smalltalk, contra "ver" diagramas, código y otros artefactos.
El tema de todo esto de "ver", de decir, "esto es", y nos produce una pelota, una caja, y decir que lo que no esta dibujado acá no existe, y esto es una caja negra, nos pone afuera. Eso es el encapsulamiento, tiene un monton de virtudes. Pero, ¿cuales son las limitaciones? ¡Qué mejor que usar cajas negras! ¡Qué mejor que no reinventar la rueda! Nos estamos cortando un camino: los que producir software, queremos producir software, que mejor que hacerlo nosotros, que es nuestro trabajo.
Acá yo tengo una posición: hay distintos tipos de programadores. Hay quienes les gusta hacer la rueda, y otros que quieren una rueda ya hecha, para construir nuevas cosas encima de ella. Alejandro, veo, está muy centrado en pensar que el camino del desarrollo del software es armar algo sustentable por uno mismo o por su grupo de trabajo. Hay evidencia de excelentes programadores, equipos, y proyectos, donde lo que se hace es montarse sobre lo ya hecho por otro, para seguir avanzando y creando cosas nuevas sobre eso.
Entonces, en algun ámbito, se dice que Smalltalk es completo y robusto, que es un conjunto de componentes re-usables.
¿Que es re-uso? Pregunta tonta si la hay.
Alejandro propone una interpretación de reuso, que sólo la encontré en su discurso.
- Poner un componente, y lo usas en un sistema, y en otros sistema. Es no es reuso, es uso.
Acá alguien acotó que un "un objeto es él, y las relaciones con otros". De acuerdo, es una descripción cercana al sistemismo.
No es reuso, es uso. Usabilidad en el software se busca desde los 50, salio ADA, Pascal. La diferencia es que todos hemos cambiado, y las personas, ahora lo toman con naturalidad, entonces no. El planteo de Modula fueron componentes. Hoy los vemos usados. Pero eso da usabilidad. Nos permite usarlos varias veces. Pero no es reuso.
Una instancia de una abstracción, es válida en un contexto. Cuando queremos usarla en otro contexto, es kamikazee. Entonces, esto no nos anda en otro lugar. La abstracción, si es rica, es interesante. Las altas abstracciones son poco valiosas, están desprovistas de información, las que están más abajo, tienen demasiado vínculo con el contexto.
Sería interesante ver un ejemplo concreto de abstración alta, baja, instancia de abstracción y contexto.
Lo valioso a nuestro nivel de desarrolladores, es lo intermedio. Si la abstracción es intermedia, cuando vamos a otro contexto, lo que hacemos es refinarla, porque nuestra intención es instanciarla en con éxito, estamos partiendo de una instancia refinada, que no es lo mismo que usamos en otro sistema. Eso es lo que tiene de valor en nuestras abstracciones, el poder refinarlas para usarla en otro sistema. Ese refinamiento no se puede lograr a nivel de instancia.
Los componentes no son reusables, no es posible su reuso, es posible el uso. Y es inocente, es lo que ocurre en la industria. Los componentes no son importantes. El reuso es aplicable a las abstracciones pero no a los componentes. El reuso implica refinarla. ¿Que conecta una abstracción y una refinación de esa abstraccion? El tiempo, y decimos, "mi sistema evolucionó".
Quien ve reuso en componentes, tiene una vision ingenua.
Las librerías de Modula, no permitían hacer práctico el refinamiento, y ahí sí tuvo un lugar Smalltalk, que sí pudo hacer eso. Y HOY tenemos un conjunto de componentes robusto, pero que es resultado del tiempo.
Quien lo ve desde ese punto, valora su contenido, se fija lo que hay acá, y le sirve para desarrollar sistemas. Qué frameworks de clases hay, y como podemos usarlos.
Acá hay mucho para hablar, y que hacemos frecuentemente en Smalltalking, cada charla todos los meses. Un componente es un instancia, planteado como una caja, y la usamos en distintos contexto, lo valioso es que lo llevo a otro contexto y anda.
Pero puesto en distintos contexto, puede no servir. ¿Que cambiar? ¿La forma? Eso es usarlo. Si cambiamos la idea, es reusarlo. Hay un proceso destructivo de las viejas ideas, y está sostenido en el tiempo. No es un proceso donde esto viejo no me importe, y lo escribo de nuevo para otro mercado.
Smalltalk me da el soporte para cambiar la idea.
¿Qué es lo constante cuando aca decimos tiempo? Lo constante es uno, es la trayectoria de uno como ser humano. Dependiendo de las oportunidades que tengas de usar tus componentes o abstracciones, pero el soporte son las personas. Uno no es el mismo a medida que pasa el pasa el tiempo. Entonces, Smalltalk es un soporte para el cambio de personas.
No tienen valor las cosas, no compres componentes. Sabemos hacer ruedas.
Lamentablemente, todos los libros dicen lo que se conoce hoy, no dudan de eso por la informacion que hay. Cuanto lugar hay para la duda, no existe. No podes pensar de otra manera. Tenemos una punta para desenroscar algo mas, y hacer un aporte. Hay algo que no se ve, que está oculto, y se lo niega.
Vemos analogías en otros lados, fuera de informática, siempre hemos usado la misma forma de disectar el mundo, y lo que no vemos no existe. No digo que no tengamos que hacerlo asi, sino que hay puntos sobre los que podemos trabajar.
Post relacionados
Superando los límites de la Orientación a Objetos (Parte 5)
Superando los límites de la Orientación a Objetos (Parte 4)
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Hace unas semanas, tuvo lugar una reunión en Buenos Aires, de gente interesada en el tema de Inteligencia Artificial. La idea de la reunión nació de un "twit" de @hhm 
(Hernán Moraldo) . Pueden leer:
Inteligencia Artifical en Buenos Aires
Artificial Intelligence meeting in Buenos Aires
Hasta aparecimos en
Game AI Roundup Week #48 2008- AiGameDev.com
Como "outcome" de la reunión, se armó una lista de correo, en Google Groups:
IA Grupo
Pueden ver que hay interesantes discusiones, y participantes de diversos ámbitos: programación de juegos, IA académica, robótica, estudiantes, e interesados como yo. Uno de los "threads" es de presentación de cada participante. Como blogger compulsivo, quisiera escribir sobre mi relación, mis motivaciones para interesarme en la Inteligencia Artificial.
Inicios
Como muchos de mi generación, mi primer contacto con algo relacionado con el tema de IA fue a través de la ciencia ficción. El bueno de Asimov, sus robots, sus tres leyes de la robótica, fueron lecturas de mi adolescencia. Cuando comencé a aprender qué eso del software y la computación, vi que realmente existía una amplia rama (con varias variantes) de la ciencia de la computación, bautizada en sus comienzos (confesémoslo, con algo de pomposo optimismo) Inteligencia Artificial.
Al ingresar a la Universidad de Buenos Aires, en 1980, comienzo a estudiar más seriamente sobre el tema. Comienzo a conocer los perceptrones del malogrado Rosenblatt, la crítica de Minsky y Papert, el auge de los sistemas expertos (recuerdo Mycin, y el trabajo de Feingenbaum), los lenguajes que se pueden automodificar, como Lisp y Prolog (recuerdo algún artículo seminal del Scientific American, y cómo me impresionó que ambos lenguajes tuvieran dialectos diferentes). Me impactó profundamente el trabajo de Douglas Lenat, con su AM y luego Eurisko: me parece, aún hoy, el programa más logrado. Lástima que Lenat abandonara ese trabajo y se dedicara a su proyecto Cyc. Ya varios de esos trabajos parecen lejanos o anticuados. Igual, pienso que es interesante estudiar la historia de la IA, porque enseña los problemas que se encontraron, los triunfos y fracasos, especialmente estos últimos, que dieron lugar al invierno de la IA.
Para los que no conocieron Eurisko, recomendaría:
Eurisko, The Computer With A Mind Of Its Own
Invention and Exploration in Discovery una reimplementación llamada Cyrano de las ideas de Eurisko
Quisiera recordar acá las excelentes lecciones del Ing. Guido Vasallo, que me guiaron en nuevos lenguajes y formas de programar, y al recientemente desaparecido Ing. Carranza, que siempre vestido de negro, y fumando en los descansos, nos enseñaba algunos temas de Inteligencia Artificial.
En aquellos años, armaba sistemas expertos de juguete, y algún intérprete Lisp. Sería largo de enumerar lo que luego vino, pero en resumen: siempre traté de agregar algo relacionado con Inteligencia Artificial, a mi trabajo de todos los días.
También en la UBA, conocí al juego milenario del go. Desde entonces, me interesó como ejemplo a estudiar, para programar IA que juegue aceptablemente.
Pasemos directamente a estos últimos años.
Enlaces, recursos y charlas
A principios de siglo, comencé a investigar de nuevo sobre Computer Go, e Inteligencia Artificial. En mi sitio, he ido coleccionando los enlaces que me interesaron, pueden visitar:
http://www.ajlopez.com/ia/
Luego, me convertí a Delicious, mis nuevos enlaces en:
http://delicious.com/ajlopez/artificialintelligence
http://delicious.com/ajlopez/artificiallife
En estos años, he estado dictando algunas charlas sobre IA, en el Microsoft User Group, el Club de Programadores y en algún TechNight de Microsoft, recuerdo:
Material de la Jornada de Introducción a la Inteligencia Artificial (MUG 2004)
Material del Seminario Introducción a la Inteligencia Artificial y .NET (Microsoft Argentina 2005)
Material del Seminario Introducción a la Inteligencia Artificial (Club de Programadores 2005)
Este año (2008) escribí sobre los temas que veo interesantes en IA:
Temas Interesantes de Desarrollo de Software, Parte 1- Inteligencia Artificial
donde encontraran enlaces sobre algoritmos genéticos, aprendizaje automático, planeación, vida artificial, juegos, lenguajes, visión por computadora, y robótica.
Computer Go
Dí una charla sobre Computer Go en el Congreso Argentino de Go de 2007 y de nuevo en el Congreso de este año 2008. Escribí:
Computer Go- El gran problema de AI
Computer Go en el Segundo Congreso Argentino de Go
AjGo- hacia un programa que juegue al go
Computer Go y el programa AjGo
En ese tiempo, fuí desarrollando mi programa de código abierto AjGo, donde estoy explorando algunas ideas sobre Computer Go.
Más enlaces sobre el tema en:
http://delicious.com/ajlopez/computergo
Computer Go en ajlopez.com
Desde hace años participo (modo lectura) en la gran lista de computer go:
http://computer-go.org/mailman/listinfo/computer-go
El grupo líder en el tema de IA en juegos de tablero y otros:
University of Alberta GAMES Group Home Page
Grid Computing y HPC
El año pasado, 2007, comencé a programar algunos ejemplos relacionados con Grid Computing, y ahora en el 2008, comencé a trabajar con High Performance Computing. Notablemente, el programa campeón mundial de Computer Go (y otros) están corriendo sobre un cluster de computadoras. Espero poder probar el ManyFacesOfGo de David Fotland, en un Windows HPC Server 2008 en cualquier momento. Otra idea a explorar es algorimos genéticos distribuidos en grilla o en cluster.
Para usar varias máquinas y tener más poder de cálculo, estoy explorando el camino de usar mi proyecto de código abierto AjMessages o el AjAgent. Por ahora, sirva como introducción:
AjMessages- hacia un procesador de mensajes
Microsoft Robotics
Desde el 2007, estoy trabajando con Microsoft Robotics, pero apenas he podido relacionarlo con IA. Algún intento en:
Genetic Algorithms with AjAgents and Concurrency and Coordination Runtime (CCR)
Algoritmos Genéticos con AjAgents y Concurrency and Coordination Runtime (CCR)
Lisp-like interpreter using DSS and VPL
Intérprete tipo Lisp usando DSS y VPL
Distributed agents using DSS-VPL
Agentes distribuidos usando DSS-VPL
Intérpretes
Estoy desarrollando dos intérpretes que me interesan: AjLisp, y AjProlog (versión anterior en AjProlog-0.2). Siempre me gustaron esos dos lenguajes, veremos si puedo aplicarlos para algún programa auto-modificable.
AjLisp- a Lisp interpreter in .NET
Generación de Código con IA
Espero poder incorporar a mi proyecto principal, AjGenesis, algo de IA. Pienso que un generador de código bien se puede asimilar a un sistema experto especial: debería, partiendo de un modelo incompleto, completarlo, tomar decisiones de diseño, inferir algunas partes del sistema, y generarlo.
IA, ciencia y filosofía
Desde los 90, me vengo topando con el problema mente-cerebro, y lo veo relacionado con IA. Críticas como las de Penrose, Hilary Putnam, y hasta Mario Bunge, me parecen interesantes, pero no las veo contundentes. Tengo pendiente postear sobre el tema, en mi blog personal no técnico, más filosófico. Apenas un preludio:
Inteligencia artificial, en la caída del conductismo
Bueno, espero que esto sirva como un pantallazo de mis intereses relacionados con IA, que está sobrevolando algunos proyectos míos, aunque no sea evidente aún.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Sigo transcribiendo (notas no textuales) la charla de Alejandro Reimondo de Smalltalking. En el anterior post habíamos llegado a un slide:
Transcribo lo de Alejandro en cursiva:
Los abordajes que hacemos acá, son abordajes de informáticas, que se ve poco, se habla más de computación que de informática, mientras en otras ciencias se ven temas de informática. Y aplican el método. No está mal, es el método. El problema es no reconocer las limitantes.
Hay algo inobjetable que aportó la masificación del concepto de objetos, que es la diferencia fundamental de trabajar con objetos. De la manera que se utilizaba antes, uno se focalizaba en qué tiene que hacer el sistema, uno trabajaba en el hacer. Los objetos aportaron un cambio en la óptica, en con qué se hacen las cosas. Uno con lápiz y papel, podemos hacer factura, pero también puede hacer cartas de amor. Ahí vienen las ventajas, en no focalizarse en que hacer, sino con qué lo hace, para usar las cosas en distintos ambientes. Cuando la gente empezo a entender, compró el tema de objetos, cuando vió que podia usarlo en distintos lugares.
Otra cosa, es que pudo hacer práctico el trabajo y utilizar encapsulamiento. Y con el tiempo empezaron a aparecer usos y construcciones, que empezaron a ser valoradas por la belleza, por otras cosas que no eran sólo la utilidad.
Aparece sobre el "slide" un mensaje "Haciendo software como se hace ciencia".
En el primer abordaje, se hace software como se hace ciencia. La propuesta es hacer software, utilizando EL método, y eso se promovió muchísimo en los ámbitos donde se hacía ciencia, y hay algo que sospechar, que eso nos pasó a todos los que empezamos y veíamos que hacer software no podia ser entendido en algo tan metódico, vamos dijimos en su momento, dijimos que había algo de arte. Eso estaba siendo ocultado, con estos métodos. Esto es lo que hay que hacer, y hay que hacer ciencia.
Como en otras partes de la charla, hubiera sido interesante tener un ejemplo de este caso.
Se puso los lugares donde se enseña informática, cerca de donde se enseña ciencia. Pero en ciencia hubo miles de años de estabilización, pero en software no.
Todos son objetos, todos podemos usar EL método, y hacemos una formalización, pero hay algo que está oculto, y no podemos no verlo.
Aparece en el "slide" un mensaje "Industria del software, Elementos para nuevos negocios".
El abordaje de modular, con Pascal, Modula, Ada, nos proponía una industria de software, que el software tiene que ver con los negocios, y que eso tiene algun vinculo con la informática.
Aparece en el "slide" un mensaje "Software como expresión de arte".
Y el software como expresion de arte, es la formula del pibe que es "cool", que es una óptica distinta, pero no formalizado. Ninguna de las otras dos nos da soporte a ésta.
Aparece en el "slide" un mensaje "Smalltalk como ciencia" cerca del mensaje "Haciendo software como haciendo ciencia".
Vean Smalltalk como lenguaje, para hacer software como ciencia. Se ha utilizado con mucho éxito de esa manera.
Cuando se hace uso de Smalltalk para esta parte, se ve a Smalltalk como un lenguaje, minimalista, elemental, muy práctico, para descomponer y escribir piezas pequeñas. Y eso interesa a quien tiene que trabajar de manera eficiente de esta manera. No digo que no podamos trabajar o que no debamos trabajar. He visto y trabajdo con Smalltalk en esos ámbitos. Si busca trabajan con objetos, Smalltalk es el único ambiente de uso comercial, van a poder trbaajar en esas areas.
Luego, Alejandro pasó a comentar temas, como el origen de la OO, que veremos en un próximo post.
Post relacionados
Superando los límites de la Orientación a Objetos (Parte 4)
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Sigo transcribiendo (notas no textuales) la charla de Alejandro Reimondo de Smalltalking. Mostró un slide con un dibujo de bebé:
Pongo lo que dijo Alejandro (aproximadamente) en cursiva:
Hay un dibujito que se ha usado bastante, mira, mamá, todos son objetos, quedémonos tranquilos. Es algo muy utilizado para vender, si pensamos así, que la inocencia nos valga.
No sé cuántos de los asistentes a la charla vieron algún dibujo así. Hace tiempo que no aparece. El auditorio de esta charla, principalmente estudiantes universitarios, pertenece a una generación que no vió ese tipo de dibujo.
Está bueno decir todos son objetos, pero es muy inocente. ¿No sospecharon cuando les dijeron, "pone objetos"? Es demasiado simple. Muy simple, Y cuando uno lo piensa, todos son objetos, pero cuando uno ve la realidad, a todos nos va yendo mal.
Bueno, yo no diría a todos.
Hay cosas fuera de control, y hay problemas en el software, por ejemplo, en escalabilidad. Si 1+1 funciona, seguimos hasta el infinito, esa proyección inductiva que todos son objetos, nos pone en un camino infinito, y tenemos un mundo para darnos cuenta que cada vez que agregamos más de lo mismo, cada vez complicamos más. Esa complejidad que no vemos cuando empezamos por un sistema simple.
He visto mucha gente capacitada, que dice que todos son objetos.
Pero es interesante, ese dibujo de bebé, nos estan seduciendo a sentirnos que tenemos intercambiar, y tener ese rol.
No entendí esa frase. Pasamos a otro slide, con título Punto de Partida.
No vamos a tratar acá, hay todo un método que sustenta esto, el tratar de abordar a las cosas descomponiéndolas, en el fondo, entendiéndolas. Normalmente, cuando se nos presenta una problemática, lo que se nos sugiere hacer, es decomponerla en partes, seccionarla, y si todo esto era un problema, ahora tenemos tres poblemas mas simples.
Yo recordaría aquí a Descartes. En su método, algo de esto recomienda, pero también recomienda, como cuarto paso, revisar que no nos hayamos olvidado algo.
Cuando atacamos cada problema, vamos seccionándolo. Hay que ser cuidadoso, hay que ver donde seccionar. Hay que saber donde cortar el sistema,para que el problema sea más entendible. Es algo bien enseñado, no tengo que hablar de esto, es diseccionar sistemas, es cuestión de tener un hacha. A medida que tiene más partes, más comienza a ser todo ser inmanejable. No se sabe cual es el vínculo entre las partes. En esa partición estratégica que hicimos, dos partes no tendrían que estar asociadas, pero están.
Lo más curioso, no nos damos cuenta nunca, cuando más partimos, más queda entre medio, más queda entre los intercisios, y lo que entendemos, cada vez es menor, este método genera no solo incertidumbre, cada vez entendemos menos, lo que importa son las partículas, y en el medio lo negamos, es vacío, todos son objetos, son pelotas, es la primera parte del paradigma, entonces, encontramos esas pelotas, marcamos las relaciones, pero en medio hay algo incontrolable, que si lo tocamos, hay cambios en otras partes.
Acá creo que hubiera sido bueno mostrar un ejemplo, para mostrar esa pérdida con un caso concreto.
Es una forma de abordar la realidad, es la única que tenemos. No tratamos de sugerirles que hay otra forma, solamente estamos siendo criticos, de lo que hacemos todos los dias.
Cada vez que arrancamos con algo, empezamos a disectar.
Ese metodo que es lo que produce? ese metodo produce, un sistema, que se entiende como un conjunto de reglas, en donde uno puede chequear, la validez de ese sistema, mientras nada cambia, es un sistema cerrado. Y si una encapsula un conjunto de reglas, lo podrá llamar clases. Y eso está muy bueno para lo que es el estudio y la descripción de lo que es el sistema.
¿Pero qué compromiso tiene con la realidad?
El sistema real no tiene compromiso con cómo lo dibujemos. Cada persona que venga con un hacha nueva, lo parte distinto. Hay un componente importante que está dada por la óptica, y no con la realidad. Queda como uno ve la realidad, más que la realidad.
Cuando un sistema es cerrado, si uno cambia una de las reglas, algo cambia, el sistema resultante es otro sistema, el anterior puede ser correcto, y el siguiente no serlo. Es decir, de ese sistema al sistema modificado, un cambio produce otro sistema, y el primero no tiene relación con el segundo, porque no tiene compromiso con la realidad, es una descripción.
Alejandro hace años que viene afirmando esta postura. Pero creo que le falta algún ejemplo, él ya está tan acostumbrado a transitar este argumento, que le parece claro. Pero el que enfrenta este tema por primera vez, sin saber hacia dónde se quiere llegar, o sin tener una referencia concreta de lo que se está hablando, se puede perder, o entenderlo de otra forma.
Ese método que estamos usando, siempre se compromete, como mucho, a definir la óptica que tenemos con la realidad, pero no está comprometida con la realidad.
Recordemos la experiencia de Alejandro con el sistema de simulación de locomotora. Ahí él armó un sistema, que era el reflejo de la realidad. Hacia ahí apunta el argumento, en parte. Para el que haya usado Smalltalk, también le parecerá algo conocido el camino al que quiere llegar Alejandro: armar el sistema usando el propio ambiente.
No ve a la implementación como una herramienta de percepción. Utiliza la cabeza para hacer los cortes, obtiene un sistema, y como un cambio en ese sistema, resulta en una vuelta atrás, no es utilizado para entender la realidad del sistema.
Cuando obtenemos un modelo, la codificación no es utilizada para entender la realidad que modelo.
Yo veo que gran parte de esta discusión, ya ha sido encarada por los propulsores del diseño dirigido por el modelo, Eric Evans a la cabeza. Aunque ellos no usarían siempre la computadora, sino el lenguaje ubicuo, y otras herramientas de comunicación con el usuario. Pero Alejandro apunta a armar el sistema en el ambiente.
Usamos representaciones, dibujos, pero no usamos la computadora. El sistema virtual que estamos generando, no tenga la posibilidad de utilizar de realimentarnos. es imposible tener experiencia.
Estoy hablando antes de ambiente. Le decimos a la gente, usa la computadora, pero nosotros no las usamos.
Podemos termina ahi, o podemos tratar de ver alternativas, y ver que es una consecuencia del método que estamos tomando. Tratemos de hacer explícita esa limitación.
Se invierte mucha energía en enseñar este método, este método de disectar, pero no queda tiempo para enseñar cuales son los límites del mismo. Mucha gente no tuvo la posibilidad de darse cuenta cuándo ese método no funciona.
No estoy diciendo de desecharlo, de tirar algo que da valor. No. Si yo dijera "tiremos eso, y les doy otra cosa X", estoy cometiendo el mismo error, de darles que en cambio de "todo son objetos", ahora es "todo son X". Quiero motivarlos, para mostrar los límites. Porque sino la gente aplica las cosas rutinariamente, y luego trata de emparcharlas, con la inducción de sigamos siendo lo mismo.
Si hay un problema en lo que hiciste, escribiste mal esto, esto, arréglalo. Yo no me quedo tranquilo en hacer siempre lo mismo. Sin reflexionar sobre la realidad.
Nada mas difícil que un diseño para ver cuando hay una falla. Los intercisios no están escritos en ninguna parte. Son negados con pongamos mas objetos.
Post relacionados
Superando los límites de la Orientación a Objetos (Parte 3)
Superando los límites de la Orientación a Objetos (Parte 2)
Superando los límites de la Orientación a Objetos (Parte 1)
Mas allá de objetos
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Me confirmaron el webcast que junto con Sebastián Renzi (@SebaRenzi) vamos a dar hoy sobre el tema de HPC y Windows HPC Server 2008
HPC 2008: Introducción
Resumen del tema:
El termino HPC (High Performance Computing) se refiere a la necesidad de contar con gran potencia de computo para la resolución de problemas. Con el avance de la tecnología y el abaratamiento de los costos en hardware, hoy en día no es necesario contar con una supercomputadora e invertir grandes cantidades de dinero para obtener gran poder de computo. A partir de la aparición de "clusters", conformados por máquinas convencionales, podemos explotar al máximo la capacidad de cálculo de cada una de ellas mediante la utilización de Windows HPC Server 2008. En esta oportunidad veremos una introducción al tema de HPC, conjuntamente con las principales características de Windows HPC Server 2008.
Otros webcast que se vienen sobre el tema, preparados por el equipo en el que estoy trabajando sobre el tema:
Con Windows HPC Server 2008, tenemos a nuestra disposición el poder de una supercomputadora: podemos armar un "cluster" de máquinas para ejecutar trabajos en paralelo, de forma de poder aumentar el poder de cálculo con solo agregar más máquinas en e l sistema. ...03/12/2008 10:00 a.m. Bogotá- 03/12/2008 11:00 a.m. | Duración:60 Minutos
Idioma principal: Español
Audiencia objetivo: Profesional de IT
Nombre del moderador: Ezequiel Bella, Maximiliano Déboli
|
Con Windows HPC Server 2008, tenemos a nuestra disposición el poder de una supercomputadora: podemos armar un "cluster" de máquinas para ejecutar trabajos en paralelo, de forma de poder aumentar el poder de cálculo con solo agregar más máquinas
en el sistema. ...04/12/2008 03:30 p.m. Bogotá- 04/12/2008 04:30 p.m. | Duración:60 Minutos
Idioma principal: Español
Audiencia objetivo: Profesional de IT
Nombre del moderador: Jorge Andrés Garcia, Maximiliano Déboli
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez