Es interesante plantearse este interrogante. Parece una pregunta sin sentido pero nos ayuda a comprendernos al momento de sentarnos a codear.
Codear = Escribir código
Actualmente al momento de abordar el aprendizaje de la programación como disciplina, en muchos casos, nos encontramos con un "método" que nos introduce a un lenguaje específico, con un variado número de ejemplos y se espera que por simple analogía se pueda alcanzar la resolución de nuevos problemas. Pese a que pueden ser totalmente distintos a los problemas ejemplificados en un inicio.
Y... ¡Está bien! Apoyo por completo la idea de hacer para aprender, pero esto nos convierte un poco en una especie de guerreros del código, que abordan las resoluciones al mejor estilo de Rambo y naturalizan una tediosa tarea que nos gusta llamar Debugging; Haciendo referencia a la cacería de "bichos" en nuestro programa, como si estos entraran de manera inesperada e infectaran nuestra sana y preciosa solución.
El debugging se define como la actividad mediante la cual detectamos y eliminamos errores de nuestro código, por lo tanto ¿La programación es la actividad mediante la cual los ingresamos?
No me malinterpretes, no estoy negando la necesidad del debugging, pero pese a nuestro esfuerzo asesinando bichos ¿Podemos asegurar por completo que los eliminamos a todos? o vamos más allá ¿Sabemos con seguridad que no creamos nuevos al matar a los anteriores?
Hoy en nuestra industria se toma como pan de cada día el pasar horas y horas detectando errores introducidos, y se le asigna un peso muy relevante a esta actividad dentro el proceso del desarrollo de soluciones. Lo que puede ser de alguna manera comprendido analizando un poco la evolución de nuestro concepto de "programa".
En un principio, el propósito de un programa era el de dar instrucciones específicas a una máquina para cumplir una determinada tarea. Pero, por el contrario, en la actualidad, resulta más fácil cranear la idea de "programa" como la construcción fundamental y asignar un rol secundario a la máquina que solo debe ejecutar lo que nuestro código dice.
Cranear = Pensar, construir una idea.
Este simple cambio de ángulo impactó en el diseño y semántica de nuestros lenguajes de programación. Dado que si hubieramos mantenido su escencia originalmente descriptiva respecto a las operaciones que se realizan en una máquina, nos sería prácticamente imposible razonar con ellos. Pero, al elevarlo y aproximarlo más al lenguaje humano, en el camino, perdimos gran parte de la naturaleza específica y efectiva de la notación original.
Entonces, ¿No existe otra manera?
Por suerte, existe una forma de aproximarnos a la programación a través de algo llamado especificaciones.
Las especificaciones nos permiten desarrollar un programa de manera metódica, de forma tal que la calidad del código/programa obtenido respecto a la especificación dada, se vea respaldada por la manera en la que dicho código fue construido.
Al contar una notación adecuada para plantear la situación a resolver, y disponer de simples y poderosas herramientas para aproximar nuestra solución a la especificación del problema, causa que los posibles errores sean mucho más sencillos de resolver y reduce la probabilidad de que los bugs provengan de una mala comprensión del problema propiamente dicho.
En este punto, nos tenemos que aliar con la lógica matemática y cranear la idea de obtener un programa a partir de una especificación formal de un problema. Siendo esta última un predicado sobre algún universo de valores.
WOW! Stop! ¿Un qué?
Okey, a medida que vayamos avanzando, los conceptos van a ser más claros. Pero de momento te pido que nos conformemos con que un Predicado es una maquinita lógica que siempre devuelve valores booleanos (True o False) pero podemos darle de comer cualquier tipo de valor, booleano o no.
Bueno, retomando...
Al construir nuestra idea de programar como la obtención de código a partir de una serie de pasos lógico/matemáticos que se derivan de una especificación formal de algún problema que nos den. No solo como resultado final adquirimos el programa que resuelve la situación, sino la demostración de que ese programa realmente solventa el problema.
¿Cómo aprender más sobre esta maravillosa magia?
Bueno, en caso de que te sirva, voy a estar posteando de manera periódica una serie de entradas que vayan tocando temas relacionados a esto. Podes seguirme en redes sociales (@fecocode), y de esta manera te estarías enterando cada vez que haya una nueva entrada o contenido relacionado.
Y en caso de que seas una bestia voraz y no quieras esperar a que suba nuevo contenido, te recomiendo el libro Cálculo de programas de los Doctores: Blanco, Smith y Barsotti. En el cual baso el contenido y estructura de estas entradas.
En la próxima entrada vamos a empezar a meter un poco las manos en el barro... Saludos! :)
Top comments (0)