Lección 1: Primeros Pasos

Lo primero de todo es entender qué es la programación. Vemos los programas y sabemos que los realizan los programadores, pero cuál es realmente su función, es algo muy distinto. Propondré para explicar esto un ejemplo sencillo que luego servirá para explicar los elementos que forman la programación.

Imaginemos a un niño que va caminando por la playa y al que le pedimos que meta las piedras blancas que encuentre en una bolsa blanca y las piedras negras en una bolsa negra. Pues esto sería "programar", indicar a un sistema una serie de instrucciones para operar sobre una serie de elementos. El conjunto de instrucciones se llama código. Nuestro código en este caso sería algo como:

Si la piedra es blanca, métela en la bolsa blanca.
Si la piedra es negra, métela en la bolsa negra.
Para si no quedan más piedras en la playa.

El nivel de detalle con el que vamos a tener que dar nuestras instrucciones será el ajustado por lo que se conoce como el lenguaje de programación, así como la gramática que utilizaremos para expresarnos y ser entendidos. En el ejemplo el lenguaje de programación sería el español ya que es el que ambas partes entendemos. En el caso de las máquinas utilizaremos un lenguaje que ellas entienden y que nosotros podemos aprender.

La gran mayoría pensará que esto es obvio, pero es importante tener los conceptos claros y nunca está de más repasar hasta lo más básico.

Veamos ahora qué elementos están interviniendo:
-el niño
-nosotros
-las piedras
-las instrucciones que le hemos dado

El niño en este caso sería el sistema, que recibirá nuestras instrucciones. El niño es suficientemente inteligente como para realizar las instrucciones que le vamos a pedir, y eso es importante, pero las instrucciones deben ser, y esto lo veremos más adelante, suficientemente inequívocas como para que sólo pueda haber una interpretación de ellas. Los sistemas, por lo general, son extremadamente tontos y sólo saben cumplir con las instrucciones más básicas, y esto, es en parte así, porque es la única manera de que no se confundan. Si yo le doy al niño dos bolsas idénticas y le pido que según vea piedras las meta en cada una de las bolsas diferenciándolas por color, tal vez no obtenga el resultado que yo espero al final de la tarea. El niño puede haberse encontrado con piedras rojas y las podría haber metido con las negras, cuando yo quería que no las cogiese. En este caso mis instrucciones no son claras, y el sistema las ha malinterpretado. Esto no debe suceder jamás y por eso hay que tener en cuenta que los sistemas sólo saben obedecer instrucciones inequívocas y simples.

Nosotros en este caso somos los programadores, somos los que damos instrucciones al sistema, y para ello debemos conocer el lenguaje con el que comunicarle las instrucciones y saber bien qué queremos que haga el sistema.

Las piedras son los objetos o elementos que manipulamos, transformamos o almacenamos, que en programación se conocen como variables. Al final querremos hacer algo con estas piedras, tal vez meterlas en un tarro, tal vez pintarlas, tal vez simplemente saber cuántas había... En los sistemas informáticos las variables son simplemente información. Serán cifras bancarias, palabras, imágenes o cualquier tipo de información que se nos pueda ocurrir y una máquina pueda almacenar o procesar.
La definición de piedra, la imagen genérica que engloba a todas las piedras dentro de la misma categoría y que nos hace reconocer una allá donde la vemos, sería el tipo. Los tipos se utilizan para definir qué clase de información se almacena en una variable. Los tipos más clásicos y básicos para las variables en la programación son: números (enteros o reales), letras (llamadas caracteres), palabras (llamadas cadenas de caracteres) y afirmaciones de verdad (llamados booleanos y cuyos valores son true (si es cierto) o false (si es falso)).
Hay bastantes lenguajes que no utilizan los tipos pero como hay otros muchos que sí, veo fundamental explicarlos, y es bueno conocerlos y acostumbrarse a ellos porque asienta mucho mejor unas buenas prácticas para la programación.
Si en el lugar que tenemos reservado para una piedra (la mano del niño o la bolsa) tratamos de introducir algo que no es una piedra, el niño protestará. Le hemos mandado recoger piedras y si se encuentra con una pala, no está en su reconocimiento asociativo el pasar una pala por una piedra, y si intentamos forzarle a hacerlo nos dirá que eso no es una piedra y que le hemos mandado coger piedras. Para eso sirven los tipos, para avisarnos de usos indebidos de los datos.

Por último tenemos las instrucciones, que deben estar en un lenguaje común al sistema y al programador y ordenadas adecuadamente a la secuencia de eventos que queremos que ocurra. Las instrucciones son las que harán que los datos de las variables cambien y se transformen y al final obtengamos el resultado deseado.
Es importante resaltar el hecho de que deben estar convenientemente ordenadas. Un orden erróneo de las instrucciones da lugar a resultados erróneos. Imaginemos que ahora al niño le mandamos otra tarea, que según le vayamos dando tarros llenos de piedras, las cuente, las multiplique por 5, que es la cantidad por la que le vamos a vender, y luego le sume 20 por el precio del tarro. Si nosotros le decimos:

Cuenta las piedras.
Multiplica por 5.
Suma 20.

Obtendremos los valores deseados, pero si alteramos las instrucciones en otro orden:

Cuenta las piedras.
Suma 20.
Multiplica por 5.

No obtendremos el valor deseado. Por ejemplo, si le damos un tarro con diez piedras, en el primero caso tendremos un resultado de 70, mientras que en el segundo de 150. El orden es realmente importante.

También es importante darse cuenta que lo que queremos hacer nosotros es un programa válido para que le podamos pasar infinitos tarros, y no uno solo. Si quisiéramos darle un único tarro de 15 piedras, lo podemos calcular de cabeza. Pero programamos para automatizar procesos que se van a repetir en el tiempo y cuyos datos de entrada no van a ser siempre los mismos. Si siempre llegasen tarros de 15 piedras, no tendría sentido hacer un programa.

En este ejemplo el número de piedras, el 20 y el 5 serían variables, aunque las dos últimas serían constantes, y no cambiarían nunca. Habría una variable implícita que es el conteo de las piedras, ya que las piedras son de tipo piedra, pero el conteo es de tipo entero (número entero), son variables distintas. El 20 y el 5 serían también de tipo entero.

Las instrucciones más comunes implican operaciones aritméticas sobre números (sumar, restar, multiplicar y dividir), operaciones de comparación (mayor que, menor que, igual que), asignación de valores (ahora esta variable vale esto), operaciones lógicas (que ya veremos más adelante) y bloques de control (del tipo "si se cumple esto haz esto" o "mientras pase esto realiza estas acciones").

Son realmente dos cosas distintas los operadores y los bloques de control, pero al fin y al cabo son el alma de las instrucciones y por eso las he explicado juntas, pero en la siguiente lección las explicaré más a fondo por separado.

Por último voy a explicar dos conceptos sobre las herramientas que tiene que utilizar un programador, el editor de textos y el compilador.

El editor de textos es sencillo, es simplemente una herramienta informática donde escribir textos, como puede ser el bloc de notas de Windows o el programa para documentos de OpenOffice. Es donde escribiremos las isntrucciones de nuestros programas.

El compilador es un programa que traduce nuestro código al lenguaje que entienden las máquinas, el de los unos y los ceros. El compilador entederá un lenguaje que se parece más al que utilizamos nosotros y lo traducirá al que entienden las máquinas. Programar en el lenguaje que utilizan las máquinas es engorroso, lento y poco abstracto y aunque a veces se tiene que hacer, se evita todo lo posible. Por ello el compilador cogerá nuestras instrucciones y las transformará de una manera transparente a la máquina. También nos dirá si hay algo de la gramática que está mal, ya que si no entiende bien las instrucciones nos dirá que hay un error.

Sé que puede parecer raro que en la lección no se haya visto código, pero creo que es una equivocación empezar la casa por el tejado, por mucha prisa que tengan los alumnos, y que los conceptos deben estar claros para que el alumno entienda lo que está haciendo para poder hacerlo bien.

Un saludo y para cualquier duda, escribid un comentario.