El Futuro de los Lenguajes de Programación (Capítulo 2): Programación Declarativa para Mentes Procedimentales

Siguiendo con la reflexión expuesta en el primer capítulo de esta serie, otro fenómeno en el cual estaremos renunciando a cierto nivel de control sobre nuestros desarrollos a cambio de un incremento en nuestra productividad es la adopción de un lenguaje de tipo declarativo (también conocido como descriptivo o funcional). Este fenómeno va incluso más allá de una simple renuncia a nuestro nivel de control, también en cierto modo estamos renunciando al código. Y con esto último no sólo quiero decir que terminaremos escribiendo aplicaciones con la misma funcionalidad y menor cantidad de líneas de código, sino que además estaremos cambiando de paradigma de programación.

El repaso y análisis sobre los diferentes paradigmas de programación existentes bien merece un capítulo aparte en esta serie (y por tanto, trataré de publicarlo lo antes posible aquí), pero adelantándonos un poco a dicho capítulo, diremos que el cambio de paradigma procedimental por un paradigma declarativo implica aprender a describir qué queremos que suceda en una aplicación y dejaremos el cómo llevarlo a cabo a las capas subyacentes del compilador y la plataforma que estemos empleando.

En la programación procedimental (también conocida como imperativa y, dicho sea de paso, el uso de la palabra “procedural” es apropiado en lengua inglesa para referirnos a este concepto, pero no es una palabra reconocida por la Real Academia Española de la Lengua) generalmente debemos pensar y elaborar el cómo nosotros mismos. No hay ninguna diferencia entre el hecho de que estemos programando en ensamblador o en otro lenguaje como C, C++, C#… El modo de construir nuestro programa será articular una por una las instrucciones que queremos que se ejecuten, ya que de ningún otro modo serán ejecutadas. En la programación procedimental sólo se ejecuta aquello que nosotros, imperativamente, exigimos que sea ejecutado.

Por el contrario, en la programación declarativa, el concepto imperativo de órdenes desaparece casi por completo. Mientras que en ciertas ocasiones aún deberemos (y por supuesto, podremos) especificar una serie de acciones a ejecutar, los detalles relativos a “procesos” y/o “procedimientos” desaparecen de nuestra realidad cotidiana, de igual modo que los exámenes parciales desaparecieron de mi realidad cotidiana cuando salí de la Universidad (ánimo amigos!). Definitivamente, dejaremos estas tareas en manos del compilador subyacente, que se encargará de procesar en el momento oportuno cada sentencia declarativa y generar al vuelo su equivalente conjunto de órdenes procedimentales de la forma más optimizada posible. Remarcando el concepto, habremos definido qué queremos obtener, y nuestro compilador se habrá encargado de los detalles relativos a cómo obtenerlo de una manera eficiente.

Ofreciendo una analogía no relacionada con la Informática, la programación declarativa es bastante similar al modo en que diseñaríamos una casa y dejaríamos los detalles técnicos en manos de quien la fuera a construir. Describiríamos la distribución de habitaciones, el color de las paredes, la ubicación de puertas y ventanas… Es decir, especificaríamos cuál es el aspecto de lo que queremos obtener finalmente. No obstante, dejaríamos en manos de los constructores aquellas cuestiones internas como el cableado eléctrico, el sistema de tuberías, etc.

Obviamente, en el proceso de construcción de nuestra casa no deseamos que se emplee el doble de metros de cableado eléctrico de lo que es realmente necesario, pero a menos que deseemos meternos directamente en un nivel de abstracción muy bajo, como el nivel en que se desenvuelve un programador procedimental, dejaremos estas decisiones en manos de arquitectos u obreros, de igual modo que haríamos con nuestro compilador en el contexto software y confiaremos en su buen hacer, en favor de la eficiencia.

Llegados a este punto de la serie hemos analizado la importancia de escoger un nivel de abstracción apropiado en nuestros desarrollos software, y también hemos establecido una serie de diferencias entre paradigmas de programación (qué queremos conseguir y cómo conseguirlo)… evaluando los pros y contras de una y otra alternativa. De este modo, hemos transitado por el puente desde los lenguajes imperativos de más bajo nivel de abstracción (lenguaje máquina) hasta los lenguajes descriptivos de alto nivel, que nos permitirán gozar de una potencia expresiva suficiente para crear nuestras propias abstracciones, nuestros propios modelos. Pero eso será en el próximo capítulo, por ahora realizaremos una parada y disfrutaremos de otro bello paisaje en Stanley Park…

lgsw16

11 comentarios en “El Futuro de los Lenguajes de Programación (Capítulo 2): Programación Declarativa para Mentes Procedimentales”

  1. El último párrafo es un poco vago. De lo que se trata es de que la potencia expresiva de los lenguajes declarativos nos permita resolver nuestros problemas de forma eficaz, sin más rodeos.

    Por otra parte esto parece un futuro bastante lejano. 🙁

  2. Aunque es cierto que la programación imperativa se confunde muchas veces con la programación procedimental, son dos cosas diferentes, igual que la programación funcional y la programación declarativa.

    Existen lenguajes imperativos no procedimentales como SQL y procedimentales no imperativos como LOGO.

    Por ejemplo SQL es declarativo, no funcional e imperativo, y también tiene una parte procedimental.

    En el Free On-line Dictionary of Computing tienes definiciones bastante buenas de todos estos conceptos.

  3. Todo esto es un rollo tio…ni DSL’s ni hostias. Que todo se puede hacer en SQL, o no te has enterado? SQL y un DBMS!!!! Ahí está …y si no que te lo diga Alfredo.

    Esto se ha ido a tomar por culo…cada vez que aparece Alfredo por algún lado, es momento de irse.

  4. Don Anónimo, yo ya le comenté a Alfredo en su momento que a mí tampoco (en absoluto, vaya) me parece que SQL sea un lenguaje de programación (ni SQL como tal -ANSI- ni los ‘dialectos’ que cada fabricante le añada). No es que no me lo parezca, es que no lo es. Por muchas estructuras de control y bifurcadores que tenga. Sin embargo y a pesar de que recuerdo que fue una discusión ‘apasionada’ -aunque sin llegar a ‘encendida’-, creo que lo hice con algo más de educación que usted.

  5. Pues si SQL no se usa para programar no se yo para que se usa, ni se a que me dedico la mayor parte del día.

    Además de la grosería es ridículo que alguien critique que nombre a SQL cuando se habla de lenguajes declarativos cuando es el único lenguaje declarativo que ha tenido un gran éxito.

  6. Estoy en un curso de programación declarativa, y la verdad que no entendi nada. Debe ser porque hace 7 años que programo de modo imperativo. No me resulto sencillo y no le veo futuro en mi vida profecional.

    Saludos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *