Pragmática

Objetivo de aprendizaje

Al concluir este tema, el estudiante será capaz de:

1. Definir la pragmática de un lenguaje y distinguirla de los niveles léxico, sintáctico y semántico.
2. Aplicar los criterios de legibilidad, facilidad de escritura, fiabilidad y costo para analizar un lenguaje.
3. Explicar una decisión de diseño como un compromiso: qué criterio favorece y qué costo tiene en otro.
4. Construir una matriz de decisión ponderada para elegir un lenguaje y evaluar la sensibilidad de su resultado.
5. Justificar por escrito la elección de un lenguaje para un problema, reconociendo los límites del método.

Ruta de trabajo del tema

1. Planteamiento inicial

Los lenguajes de programación de propósito general pueden, en principio, expresar los mismos cálculos: lo que puede resolverse en uno puede resolverse también en otro. Sin embargo, existen cientos de lenguajes en uso, y las organizaciones discuten con frecuencia cuál elegir para un proyecto. Hasta ahora se ha estudiado cómo se escribe un programa (léxico y sintaxis) y qué significa (semántica). Queda una pregunta distinta: por qué importa elegir un lenguaje y no otro.

Esta hipótesis se retomará al final de la sección 5.

2. La pragmática y los criterios de evaluación

Definición — Pragmática: la pragmática de un lenguaje de programación estudia su uso en la práctica: cómo lo emplean las personas, qué efectos tiene sobre el trabajo de programar y qué costos implica. Responde la pregunta: ¿para qué sirve y a qué costo?

Con este nivel se completan las cuatro preguntas que describen un lenguaje:

Caso de estudio: criterios clásicos. Para evaluar un lenguaje de manera sistemática, la literatura propone cuatro criterios principales, cada uno con factores que lo determinan:

Más allá de estos criterios, en la práctica intervienen otros factores del contexto: el ecosistema de bibliotecas y herramientas, la portabilidad, la disponibilidad de personal capacitado, el rendimiento requerido y las licencias.

Importante: estos criterios entran en tensión. Un ejemplo clásico es la verificación de los límites de un arreglo: aumenta la fiabilidad (un índice fuera de rango se detecta de inmediato), pero cuesta rendimiento (hay una comprobación adicional en cada acceso). Ningún lenguaje maximiza todos los criterios a la vez.

Práctica A: los cuatro niveles en un fragmento

Para cada afirmación sobre el fragmento, determine a qué nivel de descripción pertenece. Es un ejercicio de síntesis de todo lo estudiado en la unidad.

3. Legibilidad: lectura comparada

Definición — Legibilidad: facilidad con que una persona puede leer un programa y comprender lo que hace. Depende de las propiedades del lenguaje, pero también del lector (su experiencia previa), del contexto y del propósito de la lectura.

Caso de estudio. Se presenta un mismo algoritmo (sumar los números pares de una lista) escrito en cinco lenguajes. Los programas son equivalentes y producen el mismo resultado. La diferencia está en la forma en que cada lenguaje exige expresar la solución: algunos requieren declaraciones y símbolos adicionales; uno de ellos pertenece a un paradigma distinto, el funcional, que se estudia en la Unidad IV y en el que la solución se expresa sin ciclos ni variables que cambian.

Aplicación práctica. Lea los cinco programas y valore la legibilidad de cada uno según su propia experiencia. Después se comparan sus valoraciones con unas métricas elementales de «ruido sintáctico».

Nota: las métricas del laboratorio son indicios, no definiciones. Medir la cantidad de símbolos es sencillo; medir la legibilidad es difícil precisamente porque depende de quien lee. Cuando una métrica y la experiencia de las personas discrepan, la discrepancia es información valiosa, no un error.

4. Decisiones de diseño y compromisos

Definición — Decisión de diseño y compromiso: una decisión de diseño es una característica que se incorpora (o se omite) en un lenguaje. Casi toda decisión es un compromiso: favorece uno o varios criterios y tiene un costo en otros.

Caso de estudio. El lenguaje Mini, que se utiliza como hilo conductor de esta unidad, tomó varias decisiones con consecuencias prácticas. Exige terminar cada sentencia con «;», lo que simplifica el análisis sintáctico y obliga a escribir un símbolo más. Verifica los tipos antes de ejecutar, lo que adelanta la detección de errores y rechaza programas que quizá habrían funcionado. Define la división como siempre real, lo que evita sorpresas con la división entera y obliga a convertir el resultado cuando se desea un entero.

Aplicación práctica. Para cada decisión de diseño de lenguajes reales, indique qué criterio favorece principalmente. La retroalimentación señala el costo asociado.

5. Elegir un lenguaje: la matriz de decisión

Elegir un lenguaje es un problema de decisión con varios criterios. Se aplica el mismo método de cinco pasos que en los temas anteriores:

Definición — Matriz de decisión ponderada: método para comparar alternativas. A cada criterio i se le asigna un peso wᵢ (su importancia) y a cada alternativa A una calificación cᵢ(A) en ese criterio. El puntaje de la alternativa es la suma de los productos: P(A) = Σ wᵢ · cᵢ(A). La alternativa con mayor puntaje es la favorecida por esos pesos.

Definición — Análisis de sensibilidad: examen de qué tanto cambia el resultado cuando se modifican ligeramente los datos de entrada. Si una variación pequeña de un peso cambia a la alternativa ganadora, la decisión es frágil respecto de ese peso, y conviene discutirlo explícitamente.

Caso de estudio. Considere elegir entre cinco lenguajes (C, Python, Java, JavaScript y Haskell) para un firmware de termostato y para un primer curso de programación. Con los mismos lenguajes y las mismas calificaciones, la ponderación distinta de los criterios produce un ganador diferente. El resultado depende de lo que se considera importante, y esa dependencia es precisamente lo que la matriz hace visible.

Aplicación práctica. En el taller siguiente, elija un escenario, asigne la importancia de cada criterio y examine el resultado y su sensibilidad. Puede ver una ponderación de referencia, pero se recomienda formular primero la suya. Al final, escriba la justificación y regístrela en su libreta.

Importante — límites del método: las calificaciones del taller son generalizaciones didácticas, no mediciones: son editables precisamente para que usted las cuestione. La matriz no reemplaza el juicio; lo organiza y lo vuelve explícito y discutible. Dos riesgos habituales son la falsa precisión (un puntaje de 67 no es más «verdadero» que uno de 63) y la dependencia entre criterios (por ejemplo, un buen ecosistema suele mejorar también la facilidad de escritura).

Contraste con el planteamiento inicial

6. Relación entre los niveles

Con este tema se completan los cuatro niveles de descripción y, junto con el tema 1.2.4, el recorrido de un programa desde su texto hasta su ejecución:

Los tres primeros niveles son formales: tienen herramientas precisas que permiten comprobar de manera mecánica si un programa es correcto. El nivel pragmático es distinto: sus respuestas dependen de las personas, el contexto y los objetivos, y por eso requiere argumentar y no solo calcular. Aprender a argumentar una decisión técnica con criterios explícitos es una de las competencias centrales de un ingeniero.

7. Errores conceptuales frecuentes

Error común: buscar «el mejor lenguaje» en abstracto. La pregunta solo tiene sentido si se precisa para qué problema, para quién y bajo qué restricciones.

Error común: confundir popularidad con idoneidad. Que un lenguaje sea muy utilizado indica que tiene ecosistema y personal disponible, pero no que sea adecuado para un problema concreto.

Error común: equiparar «menos símbolos» con «más legible». Un programa muy breve puede ser ilegible para quien no conoce su notación.

Error común: decidir con un solo criterio, por ejemplo únicamente el rendimiento. Los criterios entran en tensión y deben ponderarse conjuntamente.

Error común: tratar el puntaje de una matriz como una verdad objetiva. Es una forma de organizar un juicio; sus calificaciones y pesos son discutibles.

8. Verificación del tema

9. Libreta de trabajo

Reúna sus respuestas, su valoración de legibilidad y su decisión registrada; revíselas y expórtelas como evidencia para el portafolio.

10. Preguntas de reflexión

1. Elija un problema real que conozca (de la facultad, del trabajo o personal) y argumente qué lenguaje elegiría, indicando criterios, pesos y contexto.
2. ¿Qué decisión de diseño de Mini cambiaría? ¿Qué criterio mejoraría y qué costo tendría?
3. Si la legibilidad depende del lector, ¿cómo debería un equipo decidir las convenciones de escritura de sus programas?
4. ¿Qué ventajas y qué riesgos tiene adoptar un lenguaje únicamente porque es el más popular?
5. ¿Qué otros criterios, que no estén en la matriz, incorporaría para elegir un lenguaje en su contexto? ¿Cómo cambiaría el resultado?

11. Lecturas recomendadas

• Sebesta, R. (2015). Concepts of programming languages (11th ed.), capítulo introductorio, sección sobre los criterios de evaluación de lenguajes (legibilidad, facilidad de escritura, fiabilidad y costo). Pearson.
• Scott, M. (2015). Programming language pragmatics (4th ed.), capítulo introductorio sobre por qué estudiar lenguajes y qué determina su éxito. Morgan Kaufmann.
• Gabrielli, M., & Martini, S. (2010). Programming languages: Principles and paradigms. Springer. (Para el análisis de los paradigmas como decisiones de diseño.)