jueves, 27 de abril de 2017

El arte de nombrar (parte 2)

En la primera parte hice comentarios mayormente prácticos sobre problemas y sugerencias a la hora de dar nombres a variables, clases, funciones, etc. Ahora vengo a completar las ideas con otro punto de vista, pensando más en la elección de las palabras que en la forma de escribirlas o abreviarlas.

Estas reflexiones tienen dos orígenes: por un lado la introducción del clásico libro de patrones de diseño de "la Pandilla de 4", por el otro una mini-frustración personal que me agarra a veces dando clases.

jueves, 6 de abril de 2017

El arte de nombrar (parte 1)

En general, ponerle nombres a las cosas no suele ser tarea simple. En particular, hablando de programación, nombrar variables, clases, funciones, etc, no constituyen excepciones sino todo lo contrario. ¿Cuál es la verdadera importancia de un buen nombre en el código? ¿Qué haríamos sin "foo" y "bar"?

No cabe duda de que un nombre descriptivo es mejor que uno genérico. Obviamente "vel", "pos" y "acel" son mejores identificadores para una terna de variables que guardan el estado de un cuerpo rídigo que "a", "b" y "c". Pero... ¿alcanza? He aquí algunas consideraciones mayormente prácticas al respecto.

jueves, 16 de marzo de 2017

¿Existe el programador 10x?

Acabo de leer un post en otro blog sobre el "mítico programador 10x". El artículo discute la existencia de tal criatura (más abajo definición y resumen) y es muy interensante por sí mismo, pero más aún si se complementa con la discusión que aparece en sus comentarios. En la primera lectura me generó un cierto conjunto de pensamientos, y luego se fueron transformaron al empezar a leer esos comentarios.

Nota: no hace falta que lean aquel post para entender este, pero igual lo recomiendo.

martes, 7 de marzo de 2017

Reescribiendo PSeInt (parte 2.c): complicaciones

Si estuviera haciendo un intérprete para un lenguaje propio y para un uso real, seguramente tendría cuidado de ajustar el lenguaje para que sea simple de parsear. Esto es bueno por mil razones, pero la directa es facilitarle la vida al intérprete y a todas las demás herramientas que surjan junto al lenguaje. Es la clase de cosas que hacen que en un lenguaje como C++ algo tan simple como renombrar un método sea una pesadilla, mientras que en otros lenguajes más nuevos como Java en verdad es simple. En fin, volviendo al pseudocódigo, el pseudolenguaje que usamos no es de los súper simples para este punto de vista, y eso complica un poquito el nuevo diseño del intérprete.

miércoles, 22 de febrero de 2017

Reescribiendo PSeInt (parte 2.b): implementación

En la parte 2.a expliqué la estructura general del proceso de parseo e interpretación, indicando cuales serán las cuatro etapas y sus responsabilidades. En esta entrega, algunos detalles más sobre cómo implemento esto a nivel de clases y patrones de diseño.

viernes, 17 de febrero de 2017

Reescribiendo PSeInt (parte 2.a): arquitectura

Ya introduje en el primer post de esta serie los problemas que busco resolver en esta travesía de reescribir desde cero la parte más crítica de PSeInt. Ahora toca hablar un poco más en detalle de la nueva arquitectura interna de esta "parte".

viernes, 10 de febrero de 2017

Rehaciendo PSeInt (parte 1): motivación

Hace no mucho comenté que quería empezar a reescribir el código relacionado al parseo interno que hace el intérprete dentro de PSeInt. Todavía falta mucho para que el nuevo código llegue a "producción", pero ya hay varias cosas hechas y por ahora el cambio tiene buen color.