January 2013 - Posts
Ya saben que TDD (Test-Driven Development) es uno de mis temas favoritos. Y no sólo porque me gusta, sino porque creo que es uno de los temas a difundir para mejorar la calidad de nuestro trabajo, tanto en el código entregado como en la calidad de vida de nuestro día laboral. Soy un convencido de que el código de producción escrito SIN TDD debería estar prohibido, directamente. Y si insisto con el tema, es porque no veo que se aplique y entienda TDD, por lo menos en estos lares, Buenos Aires y Argentina. Por ejemplo, escucho por ahí:
- “TDD es más lento”, no lo veo así, es un caso de “vísteme despacio que estoy apurado”.
- “TDD no es para los programadores junior”, no, cuanto más inexperto es el programador, más va a aprender y mejorar haciendo TDD y usando el cerebro, claro ;-) TDD no produce mejores programadores, pero los hace pensar en lo que están haciendo.
- “TDD es hacer test y code coverage”, por favor, no me presenten a una persona que piense así. O que piense que TDD es aprender a hacer test unitarios, sea lo que sea que “unitario” signifique.
- “TDD es aburrido”, para mí es como un juego, cada test en verde es como superar un nivel de juego.
Una de las actividades que me nacen naturalmente cuando hago TDD, es que lo que escribo va creciendo de a poco, de a “baby steps”, de a pasos de bebé. En vez de hacer un gran salto en la implementación, si uno realmente programa con TDD va agregando poco código en cada test que se agrega. Y no se agrega código que no nazca, que no tenga una traza que lo remita a la necesidad de un test. Esto consiga que el software que vamos creando, crezca como si fuera un organismo vivo, desarrollándose de a poco. Esto trae varias consecuencias:
- Cada código agregado tiene su función específica: hacer que un test pase a verde
- No aparece código “por las dudas” o por casos de uso todavía no implementados.
- No pensamos “por adelantado”, poniendo código que todavía no necesitamos (evitamos romper YAGNI).
- No se adopta tecnología o soluciones (librerías, frameworks, base de datos, etc… ) hasta el momento en el que REALMENTE se necesitan.
Y algo menos evidente:
- El código que vamos armando es pasible de refactorización en cualquier momento
- Y aún puede haber más que refactorización, sino también cambiar algo de nuestro diseño, sin grandes “dolores”
Ahora les advierto: no se puede aplicar todo esto con TDD, si parte del código QUE ESCRIBIMOS NOSOTROS no lo hacemos con TDD. Porque entonces vamos a "sufrir" cuando lleguemos un día a necesitar refactorizar, o rediseñar, y entonces la parte del código que habíamos escrito SIN TDD nos va a pesar y nos va a complicar ese paso de refactor o de rediseño.
Me gustaría mostrarles un ejemplo, pueden ver los posts y series:
TDD Paso a Paso
Escribiendo una aplicación con TDD
Escribiendo un Intérprete en .NET
VAN en Alt.NET Hispano: Desarrollando una Aplicación con TDD
con video en Desarrollando una aplicación con TDD desde cero con código en https://github.com/ajlopez/TddOnTheRocks/tree/master/TddApp
y mis posts de TDD.
Pero cada día, en mi cuenta de GitHub, voy haciendo commits por test, así que pueden entrar a algún proyecto y ver cómo va evolucionando. Por ejemplo, hoy voy a empezar a codificar SimpleKeeper (una especie de ZooKeeper pero en Node.js). Pueden en cualquier momento entrar a ver la lista de commits e ir revisando si cumplo o no cumplo con TDD y “baby steps”.
Algo muy interesante, y relacionado con este post, es:
Kent Beck’s Four Hats
Controlling the size of your checkout is a valuable coding skill. You should be able to take small, baby steps, and check-in at any time. There are a number of benefits. If you check-in frequently the merge to source control becomes trivial. Your colleagues won’t get annoyed, because that change which they need is never far away. Most importantly you are in control of your work.
Vean ahí los cuatro sombreros de Kent Beck.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Hace más de una década, escribí un sitio que sirvió luego de base para mi sitio personal. Estaba basado en tener items heterogéneos (enlaces, páginas tipo wiki, etc…) clasificados en categorías. Las categorías se disponían en árbol, y se soportaba el concepto de enlace simbólico: una rama de una categoría podía ser un puntero a otro rama del árbol (como cuando tienen enlaces simbólicos en la jerarquía de directorios de un sistema de archivos). Un item se podía colocar en más de una categoría. Pero después de conocer a Delicious y al tiempo a Gmail, ahora prefiero organizar los items usando tags (en Gmail son las “labels”). Y en vez de tener categorías y un árbol de categorías, pienso que es más flexible tener conjuntos basados en predicados de tags. Por ejemplo, lo que sería en mi viejo sitio la categoría Programming –> C#, sería ahora todos los items con tags “programming”, “c#”. Algunas veces, necesitaría en vez de simples tags, un par key-value, como “author:unclebob”, o “project:storm”.
Así que hace unos días, puse manos a la obra, y comencé un nuevo proyecto, escrito en JavaScript/Node.js, llamado SimpleTags:
https://github.com/ajlopez/SimpleTags
Leo en el README.md:
var itemId = engine.createItem('http://nodejs.org', [ 'nodejs', 'javascript', 'engine', 'programming' ]);
…
An item has
data: Arbitrary value you supplied tags: An array of tags. A tag could be a non-empty string or an object with only one property with non-empty value.
Once created, the item has an associated id, supplied by the engine.
…
El proyecto tiene un modelo en memoria. Un conjunto de tags puede ser asociado a un item de datos arbitrario. Ese item podría ser los datos de un proveedor o factura, pero seguramente sería más usual tener como dato asociado el id del proveedor o la factura, y que otro sistema se ocupe de recuperar la entidad. Entonces, el dato arbitrario puede ser un id para una tabla en nuestra base de datos, o una URL, o lo que querramos y necesitemos. Lo importante es: asociar un dato arbitrario con un conjunto de tags, y recuperar items con predicados sencillos de esos tags.
Piensen como ejemplo: podemos tener una gran colección de enlaces, y usar SimpleTags para organizarlos. O documentos, fotos, multimedia. Podemos usar los tags en diferentes entornos. Es una idea poderosa y simple que se puede aplciar en varios dominios y escenarios.
Pienso agrega un sitio web como ejemplo concreto, donde se pueda agregar URLs y asociarles tags, y luego definir categorías o conjuntos, usando predicados. Luego de ese ejemplo general, podría implementar algo más concreto, como una lista de cosas para hacer, con tags, o una lista de tareas pendientes/completas por proyecto, iteración, estado, persona asignada, etc… Usé hace un tiempo un sitio así en un cliente para llevar el estado de los proyectos, y me resultó muy útil y flexible.
Podría ser una excusa para aprender más de Express, o para hacer “dog fooding” y consumir mi proyecto web SimpleWeb. En todo caso, me divierto como loco :-)
Como es usual, escribí SimpleTags usando TDD, pueden consultar el log de commits.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Hace unos años tuve la suerte y el agrado de conocer personalmente a Fernando Aguilar, uno de los mejores jugadores de Go, de Argentina y de Occidente. Pueden leer:
Fernando Aguilar y el Go
Sobre el juego del Go, ver mis posts y links:
http://ajlopez.zoomblog.com/cat/15644
http://delicious.com/ajlopez/go+baduk
Si leen mis posts, ya saben que me interesa la aplicación de la Inteligencia Artificial al juego del Go, ver:
Computer Go y el programa AjGo
AjGo: Hacia un programa que juege al Go
(Nota curiosa: AjGo fue reescrito en 2008 aplicando TDD en cada paso, pueden ver el repo. También pueden vigilar SimpleGo para ir viendo como voy a ir aplicando TDD completo, esta vez en JavaScript).
Pero volvamos al tema. Cuando estuve en la charla de Fernando, le pregunté: cómo piensa la próxima jugada. Quería aprender para poder aplicarlo a mis programas. El go tiene muchas más variantes en cada ply que el ajedrez, y tiene características sutiles, como que una jugada hecha un lugar puede tener grandes efectos en otro lado del tablero. Esto ha impedido que haya programas de go que sean tan avanzados como los que encontramos en ajedrez. Lo que recuerdo de la respuesta:
En determinado momento [cerca de la apertura] no pensé hacia adelante, no me interesó calcular jugadas. Miré el tablero y me dije: Estoy bien. Cualquier cosa que haga el adversario, yo voy a poder contestarle. No tengo debilidades. El futuro no me asusta.
Siempre me quedó esa respuesta (atención, puesta con mis palabras, no tengo las notas que tomé en su momento). También se puede aplicar al ajedrez. No es que no hay situaciones tácticas en go, donde el cálculo de un árbol de jugadas es importante. Pero no se da tanto en la mayoría de los juegos y situaciones, solo por momentos. De ahí que el “approach” Big Blue (atacar con fuerza bruta un gran árbol de búsqueda, con alguna heurística de dónde para en la exploración y evaluaciones parciales) no sea tan aplicable en el caso del go. Hay que trabajar más en buenos algoritmos evaluadores de posiciones estáticas, que me digan “estoy bien”.
Lo mismo nos da TDD, armado con casos de usos, y evitando romper YAGNI. Cualquier cambio que venga (recuerden que en lo ágil abrazamos el cambio, no “luchamos” contra él), cualquier cambio en los requerimientos, cualquier caso de uso nuevo, cuando hago TDD veo que puedo enfrentarlo cuando llegue el caso. No hace falta “pensar jugadas hacia adelante”. Cuando tengo un proyecto armado usando TDD, lo que se va creando crece orgánicamente, sin debilidades grandes. Si alguna vez tenemos que refactorizar en grande, TDD nos da la red de seguridad para enfrentar el cambio con coraje. El aplicar “baby steps” permite que nuestro sistema crezca como un organismo: de a poco. No será un “monstruo” que tenga dos cabezas, o un brazo más grande que otro. Y hasta agregaría que no tendrá cosas insertadas “porque las vamos a necesitar”. No, sólo tendrá lo que habremos necesitado hasta ese punto. Y nuestro código estará preparado para soportar cambios que vengan (que siempre vienen).
Eso nos va a ir dando un sistema que, a cada paso, no tiene mochilas al hombro. Vamos a “estar bien”, y ningún artefacto nos “va a pesar” o nos va a generar fricción. Estaremos en una posición tal como la de Fernando. El sistema y nuestro equipo podrá decir “Estoy bien. No tengo debilidades. El futuro no me asusta” :-)
Bueno, apenas relacionado, pero los otros días veía Enter the Dragon, (1973), la última película de Bruce Lee. Antes de olvidarlo, lo comparto con Uds:
A good fight should be like a small play, but played seriously. A good martial artist does not become tense, but ready. Not thinking, yet not dreaming. Ready for whatever may come. When the opponent expands, I contract. When he contracts, I expand. And when there is an opportunity, I do not hit. It hits all by itself.
Ready for whatever may come.
Dicho esto, que el creador del universo se apiade de los equipos que desarrollan software de producción sin TDD :-)
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Anterior Post
En el anterior post mostré a CobolScript generando salida basada en plantillas. Hoy quiero mostrar que eso se puede usar para generar páginas web. El ejemplo está en:
https://github.com/ajlopez/CobolScript/tree/master/samples/templateweb
El programa a ejecutar es simple:
var cobs = require('../..'),
http = require('http'),
fs = require('fs');
var program = cobs.compileTemplateFile('./factorial.cobp');
http.createServer(function(req, res) {
program.run(cobs.getRuntime({ request: req, response: res }));
}).listen(8000);
console.log('Server started, listening at port 8000');
La parte clave es la llamada a compilar el archivo de plantilla. Esto produce una función JavaScript ya compilada, que puede invocarse varias veces. El llamado program.run ejecuta la plantilla ya compilada, dado un contexto de ejecución (“runtime context”). Ese contexto es armado en cada pedido web, dándole los objectos request y response de ese pedido. El contexto se arma internamente, de manera tal que toda la salida producida por el programa CobolScript se deriva a la salida del response. De esta manera, el programa no sabe nada de web, sólo genera texto. Podemos ver a este contexto de ejecución como un proveedor de servicios para el programa CobolScript. Sus propiedades pueden ser accedidas si definimos una LINKAGE SECTION como en COBOL clásico. Pero eso sería tema para otro post. Ese acceso no fue necesario en este simple ejemplo.
El archivo de plantilla contiene:
<h1>Factorial</h1>
<p>Page generated by CobolScript, using templates</p>
<table>
<tr><th align='right'>n</th><th align='right'>n!
</th>
</tr>
<#
local n.
perform show-factorial using n varying n from 1 to 10.
#>
</table>
<#
.
stop run.
show-factorial section using n.
local result.
perform factorial using n giving result.
#>
<tr>
<td align='right'>${n}</td><td align='right'>${result}
</td>
</tr>
<#
.
factorial section using n.
local m.
if n = 1 then return n.
subtract 1 from n giving m.
perform factorial using m giving m.
multiply n by m.
return m.
#>
Lanzamos el servidor con la línea de comando:
node server
Luego, navegar a localhost:8000, para obtener el resultado:
Próximo post: un sitio web dinámico, escrito en CobolScript, ejecutando sobre Node.js, accediendo a una base de datos MySQL.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Ya saben que soy un “fan” de los modelos (de dominio) en memoria, claro, cuando el contexto lo justifica. Veo que hay muchos problemas que tendrían una mejor solución si nos olvidamos por un tiempo del “cliché” “usa la base de datos, Luke!”. La base de datos debe aparecer evolutivamente. Y en muchos casos, no se necesita, más que como persistencia, no como lugar al que ir a operar en cada comando de negocio. Por ejemplo, hay muchos proyectos y aplicaciones reales que usan Redis, que usando un solo “thread” termina implementando un completo y poderoso “key-value store” en memoria, con opciones de persistencia (Redis Cluster todavía está en desarrollo).
Estoy divirtiéndome implementando ideas en mis proyectos personales, usando un modelo en memoria. Ver:
SimpleMemolap: Una especie de modelo OLAP multidimensional, con los datos a explorar residiendo en memoria. Escrito en JavaScript/Node.js, tiene un ejemplo web simple.
Memolap: Otro tipo OLAP multidimensional, pero esta vez en C#. Vean que el ejemplo web sigue en progreso (me salió más rápido el de Node.js).
SimplePermissions: Subjects, Roles, Permissions, Contexts, todo en memoria. Ideal para mantener las autorizaciones por usuario, aplicación, país, etc.
AjKeyvs: Una especie de Redis, en C#, en memoria. Tengo que implementar un protocolo cliente, y un servidor correspondiente. Por ahora, es una librería, que se puede usar local in-process. Me gustó implementar los algoritmos internos, con TDD, puedo mejorarlos, tengo todo listo para hacer refactor en cualquier momento.
SimpleStore: Algo parecido, un Redis en memoria, un “key-value store”, pero en JavaScript/Node.js. Trabaja local in-process, pero puedo exponerlo hacia afuera (remoto) usando otros módulos: quiero hacer “dog fooding” de otros proyectos míos.
SimpleQueue: Implementación en memoria, de una cola, en JavaScript/Node.js. Puedo usarla en el mismo proceso o exponerla hacia afuera, igual que comenté arriba.
SimpleTags: En mi sitio personal, coleccionaba items (páginas, enlaces, …) agrupados por categoría. Luego de ver otros sistemas (notablemente Gmail) veo que es muy útil, en lugar de poner los items en carpetas, simplemente asociarles “tags”. Este proyecto maneja items, con datos arbitrarios, asociados a uno o más tags (simples strings o key-value, ver la página de ejemplos). Escrito en JavaScript/Node.js)
Podría incluir también a SimpleRules: un motor de reglas donde los hechos residen en memoria (muchos motores de reglas usan directamente la memoria para representar el estado del mundo).
Y hasta podría mencionar: SimpleBoggle, donde la lista de palabras para resolver un juego/tablero de Boggle se carga en memoria.
Todavía por comenzar:
SimpleDatabase: base de datos en memoria, con un lenguaje de consultas tipo SQL, escrito en JavaScript/Node.js.
Muchos de estos proyectos podrían extenderse para tener persistencia “enchufable”. Pero por ahora estoy interesado en tener algo andando, para mostrar cómo puede usarse en distintas situaciones. Me gusta bastante implementar los algoritmos internos, árboles, búsqueda, índices invertidos, etc. Y todo eso, haciendo TDD a cada paso.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
En estas semanas pasadas, he estado trabajando en ejemplos y módulos JavaScript/Node.js, usando TDD en cada paso. Practicar, practicar, practicar, el camino a la maestría.
Pueden ver mi progreso y revisar los commits que hago ante cada test. Lo que sigue es un resumen de este trabajo:
CobolScript: Ver mis posts un implementación de compilador de COBOL a JavaScript, con ejemplos de consola ejemplo web, usando MySQL y SimpleWeb.
SimplePipes: Una manera de definir pasaje de mensajes usando ‘pipes’ para conectar diferentes nodes/funciones en un grafo. Quiero extenderlo para que tenga proceso distribuido.
SimpleBoggle: Un programa que resuelve un tablero de Boggle, juega mejor que yo! Ver ejemplo de consola.
SimpleMemolap: procesamiento tipo OLAP multidimensional, pero usando un modelo en memoria. Hay ejemplo web que usa mi SimpleWeb (“dog fooding”):
SimpleChess: En progreso, define un tablero usando SimpleBoard, y ya calcula movidas. Estoy también trabajando en SimpleGo, para tener un tablero, un juego y evaluadores.
SimpleRules: Motor de reglas “forward-chaining”, hacia adelante (ahora que está de nuevo “de moda” la programación reactiva. Trabaja inspirada en algoritmo RETE-2, detectando los cambios de estado para disparar las acciones apropiadas.
SimpleScript: Ver mi post con las primeras ideas sobre este lenguaje, que compila a JavaScript, trabajo en progreso.
Py2Script: Compilador de Python a JavaScript, primeros pasos.
SimpleWeb: Una capa de “middleware”, a la Connect, con un ejemplo web:
BasicScript: Mis primeros pasos para compilar Basic a JavaScript. Quiero usarlo como lenguaje de programación para juegos en el browser.
SimplePermissions: El code kata de este sábado a la mañana ;-). Implementa Sujetos (Subjects), roles, permisos, otorgados en contexto.
SimpleFunc: Serialización/Deserialización de funciones y objectos con funciones.
SimpleMapReduce: Explorando la implementación del algoritmo Map-Reduce (y una variante, que llamo Map-Process) tanto sincrónico como asincrónico.
SimpleTuring: Implementación de una máquina de Turing.
Cellular: Implementación de autómatas de estado, lineales o de otras dimensiaones. Incluye un ejemplo de juego de la vida en consola.
Y en estos dos días pasados, agregué:
NodeDelicious: Para recuperar mis enlaces desde la cuenta de Delicious (sin tener que lidiar con el XML que devuelve directamente la API), ahora que el sitio ha sido rediseñado y no tiene paginación. La gente de Delicious sigue pensando que uno usa los enlaces como un feed (que lo viejo se pierde), pero no, muchos usamos a Delicious como un “Mis favoritos” en la nube y queremos acceder por rango de tiempo.
SimpleSudoku: Una reescritura desde 0, con TDD, de mi anterior AjSudoku, resuelve tableros de Sudoku.
Tengo que trabajar en:
SimpleDatabase: Base de datos en memoria, puede que en algún momento le agregue persistencia en archivos.
Y como siempre, todo esto es muy divertido ;-)
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Ya comenzó el año, estamos en el primer mes de 2013. Estuve bastante ocupado, programando mis proyectos. Primero, una revisión de las resoluciones del mes pasado:
- Trabajr en PythonSharp [pendiente]
- Trabajar en AjTalk en C# [completo] ver repo y ver mis posts
- Dar un seminario sobre Node.js [completo] ver mi post
- Comenzar mi tutorial de Java en páginas .md [pendiente]
Además, estuve trabajando en:
- Comenzar Py2Script compilador de Python a JavaScript [completo] ver repo
- Actualizar mis ejemplos Node.js [completo] ver repo
- Comenzar y publicar versión 0.0.1 de SimpleWeb, mi capa de middleware a la Connectr [completo] ver repo
- Comenzar BasicScript [completo] ver repo
- Comenzar y publicar la versión 0.0.1 de CobolScript [completo] ver repo y ver mis posts.
- Actualizar AjConsorSite [completo] ver repo
- Comenzar proyecto Inmob [completo] ver repo
Para este nuevo mes, las nuevas resoluciones (algunas ya comenzaron, ver mi cuenta en GitHub) son:
- Empezar SimpleScript
- Empezar SimpleBoard
- Empezar SimpleChess
- Empezar SimpleGo
- Comenzar y publicar una versión de SimpleMapReduce, con ejemplo local y distribuido
- Comenzar y publicar una versión de SimpleFunc, serialización de objeto con funciones de instancia
- Comenzar Memolap, una implementación C#, en memoria, de una librería OLAP multidimensional y sitio web de ejemplo
- Comenzar SimpleMemolap, lo mismo pero en JavaScript/Node.js
- Comenzar SimpleRules, un motor de reglas con encadenamiento hacia adelante, que compila a JavaScript
- Codificar SimpleBoggle, buscador de palabras en tablero de Boggle.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Filed under: C Sharp, Lenguajes de Programación, Javascript, Proyectos de Código Abierto, NodeJs, Programación Distribuida, SimpleGo, SimpleMapReduce, SimpleChess, SimpleMemolap, SimpleRules, Memolap, SimpleBoard
Sigo dando seminarios sobre Node.js (arancelados=, de un día, gracias a la gente del MUG de argentina. El próximo será en la ciudad de Rosario, en Febrero:
http://www.mug.org.ar/Eventos/3858.aspx
Leo ahí:
Fechas y horario:Viernes 22 de Febrero de 2013, en el horario de 09:00 a 18:00 hs.
Se recomienda tener conocimientos previos HTML y nociones de JavaScript.
Requisitos: Traer notebook con Node y Git instalados.
El instalador de Node (para Windows y otros) está en http://nodejs.org/download/
Git se puede bajar de http://git-scm.com/
Contenidos:
1. Introducción a Node.js
1.1. Programación Javascript desde Node sobre el motor V8
1.2. Entrada/Salida asincrónica
1.3. Módulos
1.4. Manejador de paquetes npm
1.5. Elementos de Test-Driven Development
2. Programación Web con Node.js
2.1. Módulo HTTP
2.2. Manejo asincrónico
2.3. Frameworks web con middleware
2.4. Framework MVC: Express
2.5. Acceso a Base de datos
3. Socket.IO
3.1. Comunicación con el browser
3.2. WebSockets y alternativas
3.3. Ejemplo multiusuario en tiempo real
3.4. Usando HTML5 y canvas
3.5. Chat simple
3.6. Juego simple
3.7. Ejemplo distribuido: varios servidores, varios clientes
La idea es que si alguien no vió Node.js, pero sabe programar, y tienen nociones de JavaScript, venga y vea cómo son los primeros pasos en Node.js, y luego levantar y ejecutar ejemplos más complejos. Luego quedará en cada uno ir profundizando cada tema. Pero de esta manera tendrán los elementos para poder explotar el ecosistema de Node.js, que es tal vez el punto más fuerte que tiene. Por un lado, JavaScript es “una manteca”, de tan flexible. Lo que nos puede llevar líneas y íneas de código en .NET o en Java, en JavaScript es tan simple que nos lleva a pensar: ¿Cómo podíamos programar antes con otros lenguajes? Pero esa flexibilidad nos recuerda a Peter Parker: un gran poder conlleva una gran responsabilidad. De ahí mi recomendación de usar TDD para el desarrollo con una tecnología tan flexible.
Espero que pueda transmitir todo eso en un solo día. Me va a servir de excusa para visitar Rosario, en la provincia de Santa Fe, a la que no voy desde Abril de 2009 (a dar un curso de Scrum, de nuevo gracias al MUG).
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Las pasadas dos semanas, estuve entretenido escribiendo CobolScript, mi compilador COBOL a JavaScript (ver posts). Tengo programas de consola de ejemplo, y otros que son sitios con páginas dinámicas escritas en CobolScript, ejecutadas sobre Node.js (ver samples). Los ejemplos web usan el simple módulo Node.js nativo http, y hay uno que usa mi nuevo módulo SimpleWeb, un simple middleware sobre HTTP, a la Connect. Comencé también a escribir un compilador Python 3 a JavaScript, ver Py2Script. Y ahora, luego de entrenarme en esos proyectos (los primeros donde compilo a JavaScript usando JavaScript), quiero ir un paso más allá y escribir un lenguaje simple compilado, lo llamé SimpleScript (ver repo).
Los puntos principales:
- Compila a JavaScript, así que está orientado a ese lenguaje. NO es lenguaje de scripting a ser implementado sobre distintas tecnologías (por ejemplo, .NET, Java y JavaScript). Está totalmente orientado a la semántica de JavaScript.
- Me gusta la tradición del lenguaje C, pero esta vez no quiero tener punto y coma y llaves. Quiero una sintaxis más orientada a Python y Ruby.
- No quiero depender de los espacios para agrupar comandos. Me gusta Python, pero el tema de la indentación no la quiero en este lenguaje.
- No hay separador de comandos (como el punto y coma) solamente la nueva línea. Es decir, puedo escribir
if a < 1 a = 1
o
if a < 1
a = 1
end
Vean el uso de end.
Pero no puedo (ni quiero) escribir DOS comandos en la misma línea:
if a < 1 a=1; b=2
En este caso, DEBERIA escribir:
if a < 1
a = 1
b = 2
end
- No más paréntesis alredor de las condiciones (ver el ejemplo de arriba).
- Una sola variante de for, el for … in , todavía lo estoy discutiendo conmigo mismo. Quiero tener un for..in… como en JavaScript, pero con alguna variante para poder acceder directamente a los valores en vez de a las claves/índices de un objeto/arreglo. Algo como
for k in myarray
itera sobre los índices de myarray. En cambio
for k in myarray values
iteraría sobre los valores de myarray, directamente. Una expresión de rangos:
for k in 0..n
compilaría a un simple for clásico.
- Los ciclos soportan continue, break. El principal comando de ciclo es while.
- Funciones como ciudadanos de primera clase.
- La palabra clave function keyword será usada para definir funciones anónimas. Estoy decidiendo si uso uso la palabra clave define para definir funciones con nombre.
- Invocación de funciones con parétesis explícitos (olvidarse de la convención de Ruby, o Python 2, ir hacia algo tipo Python 3.x).
- Acceso a arreglos con [] (olvidarse de la programación en Basic, donde se usan los paréntesis).
- Variables externas. Aprendí mucho de su utilidad con mi trabajo en los ejemplos CobolScript, donde uso linkage section para pasar y recibir valores al invocar un programa. Una variable externa es algo que se da en ejecución, al llamar al programa,no es una variable global (caso típico, el require de Node.js que depende del archivo donde se está trabajando). Por ejemplo, la función print puede ser una variable externa, de tal manera que el programa llamador puede definirla, para escribir a consola, a un buffer o al response de web.
- Las variables globales deben ser declaradas explícitamente. Todas las variables no declaradas se consideran locales (a la función donde están siendo usadas).
- Funciones tienen clausuras a la JavaScript. En contraste, por lo que entendí, en Python se debe declarar explícitamente su acceso. Prefiero la manera automática que usa JavaScript, así que por ahora la voy a incluir en el lenguaje.
- Llamadas asincrónicas. Lo agregué a CobolScript, y me parece que quedó simple y útil. Sería algo similar al await/async de C# 5.0
- Va a ejectuar en el navegador, y en Node.js.
- Soporte de clases: no me decido todavía, tengo un solo caso de uso, para usarla en la programación de juegos, en mi proyecto de juegos.
Sí, ya sé, hay otras implementaciones, como like CofeeScript. Pero quiero seguir enternándome en JavaScript, Node.js y TDD.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez