Recientemente, me he inclinado por la idea de aprender cosas nuevas. Una de ellas y de las que m谩s aprensiones me causaban, era la programaci贸n. B谩sicamente, porque no ten铆a idea de qu茅 es programar. Hasta cierto punto lo que se me ven铆a a la cabeza cuando se nombraba el tema eran:
S铆, puede que s铆 tenga algo que ver con alguna de estas cosas, pero aun as铆 nos quedamos MUY cortos.
Pero he ido aprendiendo una y otra cosa, mis ideas se han aclarado y mis ojos se han abierto ante una realidad abrumadoramente enorme y, porque no, divertida. He descubierto en el mundo de la programaci贸n un impulso de aprender, hacer, crear, descubrir, rearmar y jugar como cuando era un ni帽o. De hecho, ando tan emocionado con el tema que, no solo me anim茅 a escribir sobre ello, sino que hasta los c贸digos de Markdown los escribo de "memoria" y no con el usual copia y pega que acostumbraba. (No se r铆an, es en serio).
Sin embargo, todo se me hace un poco complicado todav铆a y como ense帽ar es aprender dos veces, quisiera compartir con ustedes mis apuntes de lo que voy estudiando. De ese modo, asimilar茅 mejor los contenidos y posiblemente pueda ser de utilidad para alguno.
Entonces...
Ya se me complic贸 todo. Mientras m谩s leo, la programaci贸n resulta ser cada vez m谩s cosas. Pero si lo llevamos a lo esencial:
Programar es resolver problemas
Me explico.
Imaginemos que queremos construir una casa. Ese es el objetivo. Suponiendo que tengamos todas las herramientas y materiales, lo que necesitamos es ponernos manos a la obra siguiendo los planos de esa casa.
Entre el problema, que es necesitar la casa, y la soluci贸n, que es tener la casa, existe, precisamente, el proceso de construcci贸n.
De este 煤ltimo podemos desprender dos cosas; los planos, que guiar谩n al ingeniero, los obreros y todos los implicados. Y la ejecuci贸n de la obra; batir mezcla, pegar ladrillos, etc.
De ese modo, tenemos:
Ahora, enfoqu茅monos en estos dos 煤ltimos.
Los planos son el programa. Quien escribe esos planos (programa), es el programador. Ahora es muy obvio, 驴no?
Entonces, 驴Qui茅n ejecuta el programa?
Cuando se dice que la programaci贸n est谩 en todas partes, cr茅eme, es en serio. Tel茅fonos, computadoras, calculadoras, Smart Tvs, neveras, aviones, drones, motores de b煤squeda, sitios webs, videojuegos, 隆TODO!
Pero para no abrumarnos con las tantas aplicaciones de la programaci贸n, sinteticemos todo como "la m谩quina". Pues es alg煤n dispositivo, real o virtual, quien ejecutar谩 nuestro programa.
Como de lo que se trata es decirle a la m谩quina lo que tiene que hacer para resolver un problema, en la mayor铆a de los cursos que he visto se suele decir que las m谩quinas (las computadoras) son tontas. Pero volvamos a nuestro ejemplo.
Ya empezaron las obras de construcci贸n y los obreros est谩n enfocados en sus tareas. Pero hace calor y tienen sed; les da hambre y deben comer; el trabajo es pesado y se cansan. Las obras son cada vez m谩s lentas y se cometen m谩s errores. Lo normal.
Ahora supongamos que lo que tenemos a nuestra disposici贸n no son obreros humanos, sino robots. No se cansan, no necesitan comer o beber agua y son mucho m谩s precisos a la hora de trabajar.
Vale, no quiero iniciar una discusi贸n sobre el valor de la mano de obra humana o los derechos y deberes de los robots. Es hipot茅tico. Pero podemos acordar que comparados en esos t茅rminos, las m谩quinas son bastante 煤tiles para realizar tareas mejor y m谩s r谩pido.
Por ejemplo, ser铆a dif铆cil para la mayor铆a competir en un torneo de c谩lculo con una computadora. Y no es que sean tontas, es que son herramientas. Como un martillo, pero con algo m谩s de utilidad.
驴C贸mo le dir铆an a sus empleados robots que construyan una casa?
Vayan, construyanme una casa.
Podr铆a ser, pero ni tenemos empleados robots ni la programaci贸n es tan sencilla.
Construir una casa lleva muchos pasos. Tanto para construir sus diferentes partes como para preparar cada material a utilizar. As铆, cada paso lleva dentro de s铆 numerosas tareas peque帽as.
Pensemos, por ejemplo, en hacer mezcla de concreto.
驴Cu谩ntos pasos tienes que dar?
驴Cierto?
Pues no. Debemos detallar un poco m谩s.
Esto ser铆a algo m谩s cercano. Pero mientras m谩s lo veo, m谩s pasos intermedios me imagino.
Algo m谩s o menos as铆 piensa una m谩quina. Y nosotros tambi茅n, solo que ese proceso se hace de forma m谩s "autom谩tica". Por lo que en el ejercicio de la programaci贸n, debemos extraer y esquematizar todos estos pasos y las decisiones que debemos tomar.
Ahora, piensa en cualquier tarea que hagas: Tomar un vaso de agua de la nevera, cambiar una bombilla, encender una vela, limpiar una mancha... Y trata de dividir estas tareas espec铆ficas en los pasos que debes hacer. Luego, ve si puedes alargar la lista con a煤n m谩s pasos XD
Es un buen ejercicio que nos ayudar谩 a pensar de forma l贸gica y que, por lo tanto, nos acercar谩 m谩s al lenguaje de programaci贸n.
Bueno, esto ser铆a todo por ahora. Los espero en los comentarios. Pueden dejar, si quieren, algun ejercicio que hayan hecho y as铆 lo comentamos todos.
隆Hasta la pr贸xima! 馃榿
Recently, I have been inclined to the idea of learning new things. One of them, and one of those that caused me the most apprehension, was programming. Because I had no idea what programming was. The truth is that what came to my mind when the subject was mentioned were:
Yes, maybe it has something to do with some of these things, but we still fall WAY short.
But I've been learning one thing and another, my ideas have become clearer and my eyes have been opened to an overwhelmingly huge and, why not, fun reality. I have discovered in the world of programming an impulse to learn, make, create, discover, reassemble and play like when I was a kid. I'm so excited about the subject that not only I'm encouraged to write about it, but even the Markdown codes are written from "memory" and not with the usual copy and paste that I used to do. Just for fun.
However, everything is still a bit complicated for me and since teaching is learning twice, I would like to share with you my notes of what I am studying. That way, I will assimilate the contents better and possibly it can be useful for some of you.
So...
Everything is just complicated right now. The more I read, the more programming turns out to be. But if we take it down to the basics:
Programming is problem-solving.
Let me explain.
Let's imagine we want to build a house. That's the goal. Assuming we have all the tools and materials, what we need is to get down to work following the plans for that house.
Between the problem, which is to need the house, and the solution, which is to have the house, there is precisely the process of construction.
From the latter we can derive two things; the plans, which will guide the engineer, the workers, and all those involved. And the execution of the work; beating the mixture, gluing bricks, etc.
Thus, we have:
Now, let's focus on the last two.
The plans are the program. Who writes those plans (program), is the programmer. Now that's pretty obvious, huh?
So, who executes the program?
When people say that programming is everywhere, believe me, they mean it. Phones, computers, calculators, Smart TVs, refrigerators, airplanes, drones, search engines, websites, video games, EVERYTHING!
But so as not to overwhelm us with the many applications of programming, let's summarize everything as "the machine". Because it is some device, real or virtual, that will execute our program.
Since the point is to tell the machine what to do to solve a problem, in most of the courses I have seen it is often said that machines (computers) are dumb. But back to our example.
Construction work has started and the workers are focused on their tasks. But it is hot and they are thirsty; they are hungry and must eat; the work is heavy and they get tired. The work is getting slower and slower and more mistakes are being made. The usual.
Now let's suppose that what we have at our disposal are not human workers, but robots. They don't get tired, they don't need to eat or drink water, and they are much more precise when working.
Okay, I don't want to start a discussion about the value of human labor or the rights and duties of robots. It's hypothetical. But we can agree that compared to those terms, machines are quite useful in performing tasks better and faster.
For example, it would be difficult for most to compete in a calculus tournament with a computer. And it's not that they're dumb, it's that they're tools. Like a hammer, but with a little more utility.
How would you tell your robot employees to build a house?
Go ahead, build me a house.
Could be, but we don't have robot employees, nor is the programming that simple.
Building a house takes many steps. Both to build its different parts and to prepare each material to be used. Thus, each step carries within it numerous small tasks.
Think, for example, of making the concrete mix.
How many steps do you have to take?
Right?
Well, no. We need to go into a little more detail.
This would be something closer. But the more I look at it, the more intermediate steps I imagine.
Something more or less like that a machine thinks. So do we, only that process is done in a more "automatic" way. So in the programming exercise, we must extract and schematize all these steps and the decisions we must make.
Now, think of any task you do: take a glass of water from the fridge, change a light bulb, light a candle, clean a stain... And try to break these specific tasks down into the steps you need to do. Then, see if you can extend the list with even more steps XD
This is a good exercise that will help us think logically and thus bring us closer to the programming language.
Well, that's all for now. I'll be waiting for you in the comments. You can leave, if you want, any exercise you have done and we can all comment on it.
See you next time! 馃榿
