El balace de las herramientas que me he estado preparando o estudiando
en estas últimas semanas para programar, es buenísimo y creo que con
el tiempo se percibirá aún mejor.
He estado programando al mismo tiempo en c++, python, generando
gramáticas para mis dos lenguajes y defininiendo con los mismos.
Las herramientas están maduras. Aunque el generador de mensajes y el
warper del sistema de comunicaciones no están acabados, todo está lo
suficientemente avanzado como para demostrar que son piezas muy
útiles.
Y eso me lo he demostrado haciendo programas de verdad.
La situación es clara y sencilla, pero hacerlo y conseguir un punto de
maduración de las herramientas adecuado, es duro.
1.- La productividad al escribir código es importante
2.- Es aún más importante el poder mantener y ampliar el código
¿Cómo conseguir estos dos puntos? también es fácil saberlo.
1. Reutilización de código.
2. Hay que separar el qué se quiere hacer del cómo.
3. Sistemas separados en piezas definiendo qué hace cada pieza, su
entrada, su salida y su diagrama de estados.
4. Las piezas se conectan con un middleware.
5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos
(lo que aporta también un paralelismo potencial y por tanto una
escalalibidad enorme).
6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.
7. Tratar de separar lo mínimo la documentación y el código.
Las herramientas y lenguajes de programación no ayudan mucho en ningún punto.
1. Reutilización de código.
Es lo que todos los lenguajes pretenden y dicen conseguir.
Pero sólo se consigue en lenguajes de tipado dinámico.
En los lenguajes de tipado estático, se consigue poco o son técnicas
complejas que no se suelen dominar ni utilizar.
Exceptuando contadísimos casos, tratar de hacer código realmente
reutilizable es muy costoso en rendimiento y complejo de escribir.
2. Hay que separar el qué se quiere hacer del cómo.
Si eres MUY metódico y MUY organizado, puedes intentarlo con los
lenguajes habituales (C++, C, Java, C#, VisualBasic, etc...)
Los lenguajes imperativos se centran en el cómo y el fracaso en la
separación dle qué y el cómo es casi seguro.
Para esto es mucho mejor utilizar lenguajes declarativos.
Si es así, ¿porqué los lenguajes declarativos están infinitamente
menos extendidos?
No es del todo cierto. Entre programadores de categoría, los lenguajes
declarativos son muy utilizados en tareas complejas.
Pero los programadores de bajo nivel, que somos una enorme mayoría
(más de 95%) sólo sabemos trabajar con lenguajes imperativos.
3. Sistemas separados en piezas definiendo qué hace cada pieza, su
entrada, su salida y su diagrama de estados.
Aquí no hay ninguna ayuda.
4. Las piezas se conectan con un middleware.
Hay unos cuantos middlewares, hay que aprender y utilizarlos.
Los lenguajes de propósito general, se pueden conectar a un middleware
o a crear ventanas, o a conectar con una base de datos...
Lo malo es que no son buenos haciendo ninguna de esas cosas
5. Diseñar sistemas distribuidos, lo que implica que sean asíncronos
(lo que aporta también un paralelismo potencial y por tanto una
escalalibidad enorme).
Las hebras y el paralelismo dentro de un proceso son una trampa
mortal. No utilizar salvo situaciones muy específicas y justificadas.
Sólo algunos lenguajes declarativos tienen una buena solución para este punto.
El lenguaje de referencia en este punto es Erlang
6. El código corto, es más fácil de leer y por tanto, de mantener y ampliar.
Los lenguajes de propósito general, también son un enemigo de este punto.
Los programadores de bajo nivel, símplemente nos acostumbramos a que
las cosas son así y nos cuesta imaginar que hay otras soluciones
infinitamente mejores.
7. Tratar de separar lo mínimo la documentación y el código.
Si separamos el qué del cómo y tenemos una buena sintáxis (sencilla y
clara), conseguido.
Inconvenientes, la separación en lenguajes imperativos es casi imposible.
La sintáxis clara para un problema específico utilizando un lenguaje
de propósito general... complicado
Lo que he preparado (en un estado muy avanzado y probado con un caso
real no trivial) ayuda muchísimo (si no da una solución decente) en
todos estos puntos.
¿Cómo?
Para empezar con un par de lenguajes específicos del problema a resolver.
Uno es la gestión del estado de la aplicación. BASTA YA DE HACERLO
MANUALMENTE y lo que es peor, improvisar una solución fácil de
escribir pero imposible de leer cada día.
Otro lenguaje para conectar nuestro lenguaje de propósito general, en
este caso C++ con la entrada y salida y por tanto, con el middleware.
En estos lenguajes, sólo se dice el qué y de forma muy concisa. No son
sólo código que se "compilará" para generar un programa, son
documentación.
Estoy contento porque el objetivo era ambicioso y complejo (montar y
probar un sistema así no era nada fácil para mi) pero he pasado el
punto de inflexión crítico.
De haberme quedado un poco más atrás, todo el trabajo podría haber
quedado en un gran esfuerzo pero una idea no utilizable
No hay comentarios:
Publicar un comentario