DAPI Diseño de Aplicaciones Curso: 2425–2M

Informáticas Fecha: 13/09/2024

UD 01 Teoría Tipo: enseñanza –aprendizaje

Título Conceptos básicos de programación

¿Qué es programar?

La programación
Qué es programar

Podemos definir la programación, de manera informal pero efectiva, como:

Programar es decirle a una máquina que haga lo que yo quiero

Esta definición es muy importante para el programador, ya que le acompañará

durante toda la vida, y es muy importante comprenderla en profundidad. Aunque
no se debe trivializar: parece una sentencia sencilla de comprender, pero a menudo
se cometen muchos errores inconscientes que contradicen a esta expresión.

Veremos, a lo largo del tema, unos ejemplos de situaciones en las que volveremos
a recordar esta definición, como si de un mantra se tratase.

Lenguaje máquina y algoritmos

Para programar, leyendo una vez más su definición, necesitamos solo dos cosas:

● 1. Saber lo que queremos hacer (muy importante, que se olvida a menudo).

● 2. Que la máquina lo haga por nosotros. Y para eso necesitamos una forma
de decírselo. Para decirle cosas a una máquina vamos a usar lo mismo que
necesitamos para hablar con otras personas, es decir, un lenguaje.

El único lenguaje que entiende una máquina concreta1 es el llamado lenguaje

máquina o código máquina. Su nombre no es muy original que digamos, pero se
llama así; claro y directo.

Este es un ejemplo (inventado) de una instrucción del lenguaje máquina:

011011101101011010101110101

Aquí podría poner, en el lenguaje de la máquina, suma 2 + 5, por ejemplo, o ¿el 7

es menor que el 18?, o quizás también si la respuesta anterior ha sido SÍ, entonces
sigue el programa en esta otra instrucción….

Antiguamente, y no hace demasiado, estas instrucciones se insertaban en el

ordenador usando tarjetas de cartón con agujeros, llamadas fichas perforadas. Hoy
en día, ya se guardan en discos SSD, en donde estos “agujeros” son de tamaño
microscópico y se almacenan billones de ellos en muy pocos centímetros cuadrados.

1
Se llama igual, pero es diferente de una máquina a otra, aunque todos se parecen mucho en filosofía y
prestaciones.
Pero, en esencia, todo sigue siendo igual: las instrucciones se transfieren a la
memoria ram, y se ponen en fila una detrás de otra junto con los datos que van a
manipular, y el procesador de la máquina las va ejecutando una por una.

El programador es el quien, partiendo de lo que quiere que la máquina haga, y

usando el lenguaje de la máquina, acaba transfiriendo esa lista de instrucciones
binarias a la memoria ram, y la máquina las ejecutará.

A la secuencia concreta de instrucciones que el programador piensa y escribe con

cuidado, en ese lenguaje que la máquina entiende y luego ejecuta, se le llama
algoritmo.

Lenguajes formales

¿Una máquina entiende inglés o castellano para comunicarse con ella? De momento
no2.

Entonces, ¿es necesario aprender lenguaje máquina para decirle cosas? Tampoco.

Existen lenguajes intermedios, inventados por el ser humano, con el fin de poder
expresarnos más fácilmente, más parecido a nuestra lengua materna y más
adaptados a como observamos el mundo y lo describimos. La pregunta importante
aquí es: ¿para qué inventar nuevos lenguajes artificiales parecidos a nuestro
lenguaje natural, cuando ya tenemos nuestro propio lenguaje natural?
Precisamente por eso, porque nuestro lenguaje es natural, es decir, tiene
ambigüedades, ironías, etc., que no se pueden traducir luego fácilmente al lenguaje
de la máquina.

En un par de meses, el futbolista Paco se cambiará de camiseta

(¿acaso no se ducha a diario?)

Dar instrucciones a una máquina mecánica3 sería desastroso si estas tuvieran más
de una interpretación posible. Por esto, a los lenguajes que van bien para dar
instrucciones a una máquina se les llama lenguajes formales: solo tienen una
posible interpretación. Por eso mismo, programar es fácil; basta con entender que:

Quiero decirle algo preciso y concreto a la máquina y se lo digo en un lenguaje que

solo se puede interpretar de una manera posible

Tip: cuando el ordenador no hace lo que en teoría hemos programado, solemos

instintivamente echarle la culpa a cualquier cosa: el ordenador está mal, la aplicación que
hemos usado para programar no va bien, la luna está en cuadratura con Saturno,
cualquier excusa… La realidad suele ser en general bien diferente: le hemos dicho mal a la
máquina lo que queríamos hacer. El ordenador no tiene la culpa de nada, y hay que revisar
nuestro proceso. El error es humano.

Hay muchos lenguajes formales de programación a día de hoy. Entre los más
populares están, por ejemplo Python, Java, Kotlin, Swift, Javascript, Typescript,
PHP, C, C++, C#, Go, Ruby, Rust, R y un largo etcétera.

2
Aunque se está trabajando mucho para que pueda ser así en el futuro.
3
Máquina = mecánica

Página 2
Un ordenador, en realidad, no entiende ninguno de estos lenguajes, pero para eso
existen unos programas intermedios que sirven para lo siguiente:

● Compiladores: programas que traducen desde un lenguaje formal cualquiera

al lenguaje máquina4. Y luego dichas traducciones son las que se ejecutan.
La acción de traducir se llama, por tanto, compilación.

● Intérpretes: programas que simulan la ejecución de las instrucciones de un

lenguaje formal (no las traducen en realidad, pero producen el mismo
efecto, y por eso también son más lentos en ejecución).

Paradigmas de programación
Qué es un paradigma de programación

Un paradigma de programación es la filosofía concreta sobre cómo se debe pensar

y codificar con ciertos lenguajes. Es decir, son todas aquellas teorías y prácticas que
definen la estructura gramatical que van a tener aquellos lenguajes que luego
usaremos para hablar con la máquina.

El lenguaje de una máquina, como ya sabemos, es el lenguaje máquina. Pero, ¿es

un lenguaje simple o complejo?

En realidad es el lenguaje más simple con el que podemos programar, porque tan
solo consta de un conjunto de instrucciones pequeño y sencillo, no más de 25 o 50
instrucciones diferentes, típicamente. Pero precisamente por esa razón, desde el
punto de vista de las personas, se convierte en un lenguaje muy incómodo para
expresar ideas complejas. ¿Se puede programar el Super Mario a base de sumas y
restas, escribiendo directamente los 0s y los 1s de la máquina? En teoría, sí. Pero
en la práctica, esta tarea se vuelve muy compleja, por no decir imposible. Es aquí
donde entran otros paradigmas; unos de bajo nivel, otros de nivel medio y otros de
alto nivel. Se dice que un paradigma tiene más alto nivel cuanto más se acerca a
nuestro lenguaje natural.

El ensamblador

El ensamblador es el paradigma (y lenguaje) de más bajo nivel que podemos

encontrar. En realidad, el ensamblador tiene el mismo nivel de abstracción que el
lenguaje máquina, pero tiene una ventaja fundamental. El ensamblador no se
escribe con 0s y 1s, y en su lugar utiliza mnemónicos en inglés. Ejemplo:

011011101101011010101110101

ADD #27, D0

(sumar 27 al registro D0 del procesador)

En resumen: el ensamblador es equivalente al lenguaje de la máquina, pero es

mucho más fácil de leer y de escribir.

4
En ocasiones, a lenguajes intermedios.

Página 3
El código espagueti

El ensamblador tiene la ventaja de que aprovecha toda la máxima potencia que

puede dar un procesador y la gestión de la memoria. Pero es un paradigma que
está muy alejado del lenguaje natural.

Es por esto que, en la década de los 70, surgieron lenguajes (interpretados o

compilados) que simplificaban la expresión de los programadores.

También aparecieron diagramas de flujo, que son esquemas visuales con los que
“programar” bajo un determinado paradigma, sin tener que pensar todavía en la
sintaxis concreta de un lenguaje.

Sin embargo, este paradigma no tenía muchas reglas de sintaxis restrictivas: el

programador podía hacer lo que quisiera en realidad, según su propia experiencia e
instinto. Un programa podía tener este aspecto:

Este paradigma ya permitió hacer programas un poco más complejos, pero seguía
teniendo un problema fundamental: el hecho de que las bifurcaciones podían ir en
cualquier dirección y sin ningún criterio, hacía extremadamente difícil estar seguros
de que el programa ejecutaba efectivamente lo que uno quería. A día de hoy, a este
paradigma liado y enmarañado se le conoce, con una mezcla de cariño y de estupor
simultáneos, como programación espagueti. Y es ahí donde entró un paradigma que
lo cambió todo: la Programación Estructurada.

La Programación Estructurada

La Programación Estructurada nació también en los años 70 pero cogió fuerza en

los 80 entre la comunidad de programadores.

Las ideas teóricas de este paradigma se enuncian en el llamado Teorema de

Dijsktra5. Dijkstra estaba convencido de que, con una gramática de tan solo 3
estructuras, se podía construir cualquier programa que se nos ocurra.

Aquí empezó la era dorada de la programación, y aparecieron lenguajes míticos

como C o Pascal, por ejemplo. Es la época del Tetris, el Street Fighter o el Arkanoid,
y también el de los primeros sistemas operativos comerciales. Ya se podían crear
programas de varios miles de líneas con relativa sencillez y garantías.

5
Aunque en realidad lo demostraron Böhm y Jacopini, en 1966.

Página 4
La Programación Orientada a Objetos

Ahora bien, la industria del software se ha complicado considerablemente en los

últimos años. Los programan los crean equipos de varios desarrolladores, que
pueden estar en diferentes países, integrando piezas de software de otras
compañías y con productos que pueden llegar a los millones de instrucciones.

La programación estructurada se queda un poco corta para atacar a problemas tan

grandes, y por eso, a partir de los años 90 se transformó en el paradigma de
programación más popular a día de hoy: la Programación Orientada a Objetos. Este
tipo de paradigma empieza a partir del Estructurado (no lo invalida, solo lo
extiende), pero es mucho más grande y complejo de aprender. A cambio, permite
crear software muy profesional con relativa sencillez y con gran calidad, una vez
que se entiende y se domina.

Programación Estructurada
La Programación Estructurada es un paradigma muy sencillo y bastante útil que se
basa en el teorema de Dijkstra. Dijkstra dijo básicamente que:

Todo algoritmo se puede crear usando solo secuencias, alternativas e iteraciones

Es decir, con solo 3 estructuras diferentes es suficiente, combinándolas entre sí. Y

no solo eso, también se demostró la manera de traducir estas estructuras. Eso
permitió crear compiladores con los que el programador podía escribir en C o
Pascal, y estos lo traducían usando esas reglas al código máquina ejecutable.

Primera estructura: la secuencia

La primera forma de combinar instrucciones es la secuencia:

La secuencia dice algo que no es obvio, pero parece natural: las instrucciones se
ejecutan en serie, ordenadas en el tiempo, nunca dos o más a la vez. Primero se
hace A, luego B y luego C.

Página 5
Segunda estructura: la alternativa

La segunda forma de combinar instrucciones es la alternativa. Si solo existiera la

secuencia, no habría forma de decirle a la máquina que se adapte a la realidad
cambiante y a resultados previos. La alternativa tiene siempre esta forma:

En palabras: primero se hace una pregunta cerrada cualquiera. Una pregunta

cerrada es aquella cuya respuesta es Sí o No. Dependiendo de la respuesta que
obtenga la máquina, si es que Sí, entonces hará el bloque A. Si es que No, entonces
hará el bloque B. Pero A y B son excluyentes.

La alternativa se conoce coloquialmente como “if”.

Lo más importante de una alternativa es que, tanto si se hace A como B, ambos

bloques siempre vuelven a confluir en el mismo punto (lo que no sucedía
anteriormente con la programación espagueti).

Tercera estructura: la iteración

La última estructura necesaria para completar el teorema es la iteración. La

iteración es fácil, se trata de repetir un bloque A el número de veces que sea
necesario:

A este tipo de iteración, o bucle, se le suele conocer como “while”.

Página 6
Hay que observar que esta es la variante “oficial” de la iteración, gobernada por un
guardian, cuya pregunta cerrada (sí o no) controla cada nueva posible iteración,
antes de que esta se produzca.

No obstante, por comodidad, suelen existir un par de variantes:

● Que el guardian se coloque al final, es decir, primero se hace el bloque A y

luego se pregunta si se va a repetir otra vez más. Esta variante tiene la
desventaja de que el bloque A se va a ejecutar mínimo una vez. Pero si esto
está garantizado en nuestro diseño, a veces es más cómodo. Se le suele
conocer como “repeat”.

● La segunda variante se da cuando sabemos a priori que el bloque A se va a

repetir un número determinado de veces. No todas las iteraciones son de
este subtipo, pero merece la pena descartar primero este caso, ya que si se
dan las condiciones, es el tipo de iteración más sencilla de codificar. A este
caso se le suele llamar “for”.

Funciones

Hay dos reglas básicas muy interesantes a añadir a este paradigma:

● La primera regla, imprescindible, es que cada bloque de una secuencia,

alternativa o iteración, a su vez se puede descomponer como una nueva
secuencia, alternativa o iteración. Así, hasta llegar a instrucciones
indivisibles (o bien, bloques vacíos, también es legal). Veremos luego que
esto se traduce en una técnica de descomposición llamado diseño
descendente o top-down.

● A cada bloque de estas estructuras se le puede asignar un nombre, y definir

su estructura de manera independiente, siguiendo la filosofía de divide y
vencerás. A cada bloque de estos, con nombre propio, se le suele conocer
como función6. Las veremos en el siguiente apartado.

Waterfall
El teorema de la Programación Estructurada está muy bien, pero ¿cómo se manejan
dichas estructuras? ¿cómo las sacamos? ¿por instinto? ¿y si el programa es muy
grande y muy complejo? Aquí entra una metodología de desarrollo de software que
se llama waterfall7.

Las cuatro etapas más relevantes en el método waterfall son las siguientes, y en
este orden: análisis, diseño, codificación y testing.

Fase 1: Análisis

Si programar es decirle a una máquina que haga lo que yo quiero, lo primero de

todo, e imprescindible, es saber lo que queremos que haga la máquina. Pero no

6
También procedimento, subrutina, método, etc. Depende un poco del contexto y del lenguaje. Tiene
muchos nombres diferentes debido a la importancia vital que tiene en la programación estructurada.
7
Existen otras metodologías diferentes, algunas más modernas y experimentales, pero las cuatro fases
principales del waterfall son una base importante que se debe conocer y controlar.

Página 7
basta solo con eso: es necesario asegurarse de que efectivamente, y no de manera
vaga, sabemos hacer aquello que luego queremos expresar en el lenguaje.

En otras palabras, el análisis consiste en hacer un mismo, con sus propias manos y
sin el ordenador, el problema que queramos resolver. Es lo mismo que hacemos de
niños en el colegio al aprender a sumar o multiplicar: repetimos una y otra vez los
mismos procedimientos hasta que estamos seguros de que sabemos hacer cierto
algoritmo mecánico.

No confundir el análisis con el diseño. No se trata de explicar cómo se hace algo,

sino directamente hacer ese algo y, muy importante, anotar todo el proceso mental
invisible que haya por el camino, para verlo después y pasar a la siguiente fase: el
diseño.

Fase 2: Diseño

Ahora sí: en el diseño se trata de describir cómo se ha hecho aquello que hemos
hecho varias veces durante el análisis. Y para describir esto, tenemos que seguir las
tres estructuras de la programación estructurada.

No es necesario usar un lenguaje específico. Lo importante son las estructuras. Así

que lo recomendable es utilizar el propio lenguaje natural y describir cada uno de
los bloques que las componen.

Es importante observar mentalmente, partiendo del análisis, la secuencia temporal

del algoritmo, con calma y despacio, para no dejarse cosas y describir el proceso
con precisión.

Página 8
Fase 3: Codificación

En la tercera fase, toca traducir los diagramas del diseño al lenguaje con el que
queremos programar. Por ejemplo, el diseño anterior, en lenguaje Python quedaría
así:

Hay dos claves en este proceso:

Página 9
 ● Esta fase está separada del diseño porque en el diseño es muy importante
pensar en el problema y no contaminarse todavía con el lenguaje específico
con el que luego hablaremos con la máquina.

● En la codificación se trata más bien solo de copiar y de pensar lo menos

posible. Para pensar, ya tenemos la fase de diseño anterior. Pensamos en el
diseño; traducimos en la codificación.

Fase 4: Testing

Hay que recordar dos cosas que son muy importantes:

● Los programadores somos humanos, no somos máquinas8. Eso hace que, al

contrario que estas, cometamos numerosos errores. Por eso esta fase es
imprescindible: consiste en esencia en eliminar aquellos errores que
hayamos podido cometer por el camino.

● Es crucial tomarse en serio las tres fases anteriores. El testing va a apoyarse

en la fase de la codificación. La fase de codificación se apoya en un buen o
mal diseño. El diseño se apoya en un buen o mal análisis. Si se cometen
errores en las capas superiores, descubriremos que la máquina no hace lo
que supuestamente queríamos que hiciera. Y, sencillamente, si se ha
dedicado un esfuerzo insuficiente en las fases anteriores, estos problemas
pueden convertirse en una pesadilla y no lograr corregir el programa nunca.
Seguramente, habría que borrarlo entero y volver a empezar.

Las técnicas de testing dan para hablar largo y tendido, y exceden el alcance de
este tema introductorio.

8
Al menos por el momento…

Página 10