lunedì 1 febbraio 2010

A new programming language. How do we approach it?

Welcome back my readers, this is part two of my series of theoretical lessons on basic programming knowledge and this time I'm going to expand on last week's post about different programming languages/dialects and where to start.

First of all, if you haven't read the first post I highly suggest you to go and read it to get a basic knowledge of what we'll be talking about this time; if you feel like going on anyway, just be sure to at least read the list of many different programming languages I posted, it will come in handy.

Ok, let's dive in the crucial points of this lesson:

How do I choose a programming language?

Some of you may already know that planning ahead what you want to build is always a good practice, this applies to every aspect of real life as well. A carpenter does not build a piece of furniture by adding random wood pieces together, he researches what type of wood fits best his uses and, to know beforehand what he'll be needing, he has to know what he wants to build. This rule of thumb is fundamental in computer programming because more often than not you will find yourselves trapped inside a project bigger than yourselves and you may be forced to restart everything from the beginning with a different approach till you get what you really wanted. Something like this cannot be completely avoided, but a bit of reasoning behind your whole project will help fixing it. Going back to the carpenter example, though, there is one fundamental detail that must not be skipped: to know which wood fits best his project he has to know all different types of wood qualities/uses and how to work them, hence he won't have a limited array of choices to choose from, which is something not suggested.

How can I learn all the programming languages on Earth in no time?

This, my friends, is the most important information you will need in this lesson:  all programming languages are the same, there are only minor differences from each other and the theory behind them all is just one. What you now have to learn is how to handle the theory behind computer programming well and you will be set for life. That is the hardest point to manage and is what screws many newbies in software development. The average home-schooled programmer will learn, in his lifetime, at most two or three different programming languages (plus dialects and different implementations) and will feel like he has mastered them in no time, however when facing a new language or piece of code, he won't be fully able to understand it because he'll be lacking the theory behind it. This is something you'd want to avoid and that's the reason why I'm trying to give you a complete and competent view of all the different possibilities ahead of you. If you'd rather just start programming straight on, without knowing what you are doing, Google has got plenty of tutorials for every programming language you may want.

The universal language.

Unlike real life, in software development there is a language that every well-schooled developer understands which is called a Flow-Chart. Technically, a Flow-Chart is not a language, it is a diagram. A picture used between software engineers (and also in industrial engineering, where the Flow-Chart was born) to exchange informations regarding a process, a certain number of steps, from the problem to the solution of the said problem. But what does this have to do with computer programming? Everything, and here on read why:

The Algorithm, let the computing magic begin:

What is an Algorithm? This is what probably most of you are asking yourselves while reading this, and that's why I'll try to be the most explicative I can without going into too many details, because it could get pretty complex. Quoting wikipedia: "In mathematics, computing, and related subjects, an algorithm is an effective method for solving a problem using a finite sequence of instructions".This is really all you need to know about it. This is what computer science is all about, finding a solution to a problem through the means of an algorithm that tells a calculator (our computers) how to walk from the problem to the said solution. This, actually, is what everybody does in real life as well when approaching different scenarios in their everyday's life.

Understanding algorithms before everything: how to program breakfast?

Before I explain how a Flow-Chart works and how to approach different programming languages, I want to get the concept of Algorithm and problem-solving stuck inside your head with a nice example to make it even easier to understand. One thing everybody does in their everyday's life is having breakfast, so let's try to understand this common scenario with a problem-solving approach and see how it works:
Imagine a guy comes to you with a statement and expects from you a direct, informative answer; his statement is: "I have a problem, I want to learn how to make breakfast for myself every morning, however I can only follow a definite number of steps and actions and I cannot learn them, I have to read them on a piece of paper everytime I do them and I need your help: I want you to write down every single step to have a nice breakfast, how can I have breakfast?".
First, we'll have to understand what we require and where we want to go, in order to give informative answers to this poor breakfastless guy. The problem we have here is the following: How to have breakfast? We need to find a solution to this and, to most of you, the solution should be pretty clear, it can be divided in these steps:
1) Wake up. (we'll be skipping all the prior-breakfast activities here)
2) Walk to the kitchen.
3) Take every item you need for your breakfast (it may vary depending on your breakfast).
4) Set the table.
5) Prepare the food you like.
6) Put food inside a plate/bowel/whatever.
7) Hold spoon/fork/knife/chopsticks/whatever.
8) Use said tool to get food from the plate to your mouth.
9) Chew.
10) Swallow.
11) Rinse and repeat till breakfast is over / you're full.
12) Clear the table.
13) Wash dishes.
14) Done.

This is what an algorithm looks like and is what our computer asks us, in the form of a written (well, typed) programming language, in order to solve our problems for us. We give it the problem, an algorithm, and it gets us straight to the solution (if it's possible). Our task as software developers is to define the algorithm for the given problem and code it in a way the computer can understand it.

Algorithm and Flow-Charts go hand in hand.

For every algorithm, there exists a Flow-Chart describing step by step how to get from point A (the problem) to point B (the solution), this is upon what we will be basing our programming experience. Except some easy, down to Earth, algorithms, you will need (trust me, you will) a Flow-Chart (or similar) to describe every step you have to approach/code in your projects before you get down to the actual programming part. In most projects, the stages behind the coding are the most difficult ones but also the most important, with a well written plan and nice Flow-Charts describing every algorithm you will need, you will see your project taking shape way faster than expected and with less bugs than usual. I won't really go into how to understand a Flow-Chart (regardless of how simple it is) and if you really want to, there are lots of tutorials on Google about it (Wikipedia is nice as well), I will just tell you how to read it showing you an example of the breakfast algorithm:

As you can see, all you just need to do is get from point A(top) to point B(bottom) in the simplest number of steps.

Unfortunately, even today I wrote more than what I expected, so I can't get to the "fun" part yet. I will have to postpone the presentation of the languages to the next lesson. I'm really sorry, but these posts are really bigger than what I thought. 
Next week I'll talk about all the languages I mentioned in the first post and how to transform a Flow-Chart into a code the computer can understand. In the meantime, I'd suggest you read up a little of Algorithm theory and Flow-Chart designing, there are some interesting links on Google which you can't miss. See you in the next lesson! 


lunedì 25 gennaio 2010

Programming, this obscure science. The basics.

Hello everyone. I'm Morg, a programmer and student currently studying to obtain a Degree in Computer Science at the University of Bologna, Italy.

Today I've decided to start a new blog (among a ton of other projects) to help the newcomers join the awesome, mind opening, magical world of computer development. Probably if you stumbled upon this blog page, you either:
a) Hit the wrong link
b) Got spammed by me
c) Are mildly interested in learning how to program a computer.

Now, given the majority of people will probably be just from point a and b, I'll try to capture the interest of everyone, even the ones not really focused on learning how to program.

This post will be the first of a long (hopefully) series of tutorials related to general programming techniques and terminology (for starters) that will not be focusing on a single programming language to give the readers the possibility of choosing their own pace/language when learning. There are so many dialects out there that it's probably best not to get focused on a single programming language; in the end being flexible (especially in software development) pays off a big deal and if you ever plan to keep going this way, you will learn it.

To get started, I'll be covering some aspects of programming theory, laying in front of you readers a few choices and ways to get engrossed into the world of computers.

What is a computer?

What most of you refer with the word "computer" is a tool that allows you to get linked and connected to the net, to browse forums, blogs, facebook, twitter and keep in touch with people from the other side of the globe through Skype and MSN. If you ever wondered what's inside the plastic box and how does it work, then you're on the good track and have the will to become a real programmer. The "how" is always (and I mean, always) the first and most important question you should be asking yourselves, in every context, both real life and IT.
Back to the topic, inside a computer's case there are some stupid magical entities (fairies) that, while they are not working, wait for someone to tell them what to do. I won't go into many details here because I'm not enough qualified and it's way too complex to cover in a single blog post, however the most important part you have to remember is that every single fairy in your computer has got a "work context" and it's only proficient with that. All the fairies are allowed to speak with each other but they all (most likely) speak different languages and every single one of them is fundamental for the machine.

But... how does a computer work?

A computer, an assembly of magical fairies, is stupid. It doesn't know how to work or what to do. When you press the power button it doesn't learn anything. When you repeat the same combination of buttons over and over again, every day, the computer doesn't understand. It doesn't recognize you and isn't aware of his surroundings. No matter how advanced, interactive and "alive" it seems to be, a computer is just a stupid, motionless (mostly) piece of metal lying on your desktop. There is only one (one and only) thing it's good at: following instructions. All it does, every day, from boot time to poweroff is following instructions. To put it bluntly, it's your little bitch. If you know how to hand it informations, instructions and commands, it can basically do everything in its power.

How do I make a computer follow my instructions?

This is the first question a real programmer asks himself (I already told you, the "How" is more important than the "Why"). Sometimes you get frustrated when some software on your machine is not working, when there's a bug or when your computer gets stuck and you can't do anything short of restarting. That's when you start asking yourself if you could've done it better than the person who programmed it. Most likely than not, nope. The guys developing software for home uses are usually proficient enough (save few exceptions) that you will never top their products before at least 10 years in software development. Anyhow, you have the good spirit to start and build something upon it; all you have to do is keep reading and you will learn how to transform your machine into your machine.

The language of the computer.

Currently, I'm writing in English. Why is that? Because I'm trying to give you some informations and the only way I can transfer the thoughts from my brain to yours is using a standardized communication channel that the receivers (you readers) are able to understand and decode into thoughts. That is the language. The same thing is applied to computer development (IT = Information Technology) where we, the programmers, are going to manipulate data (thoughts) and communicate it to the computer through a language. Mostly all the computers (the ones in your houses at least) speak one single language: Binary. The binary language is a "simple" (not easy) language formed by sequences of '0' and '1'. Every 0 means off and every 1 means on, but on/off what exactly? Those numbers (called bits - do not confuse them with Bytes!) keep track of the state of the mind of a computer. Through the combinations of different bits you get different states in the mind of the computer and through the shifting of those little on/off buttons you can tell your machine to compute algebric functions, or display stuff on the screen.

You're telling me I have to write in a bunch of 0s and 1s?

Fortunately, the great developers of the past eased the work for us and made our life as computer programmers easier (sometimes it's way too easy actually). They invented linkers and compilers. Those are programs (yes, other software made of 0s and 1s) that take a bunch of typed words and symbols and transform it into binary code for us. Those binary coded lists are executable files (.exe if you are under a Windows-based System) which, if double clicked, will inject their code into the computer that will read it and run it. To be more specific, the compiler is the software that takes your written words and transforms them into Assembly code which, then, will be "eaten" by the linker that will turn it into machine code (your .exe).

I got it, where do I type my instructions then?

Whoa... hold on a second, don't be too impatient here. The first steps of learning programming are the most important ones, a bad background usually leads to spaghetti code and horribly implemented algorithms, so please, hold your horses and keep calm, you will learn how to program well one day. After all, Rome was not built in one day now, was it? Anyway, as I was trying to say earlier, there are a lot of different dialects with their related compilers that can be used to develop software on a computer, the choice of which usually depends on the programmer himself. You have to keep track of what you are trying to achieve, how you want it to be done and how much hours/days/weeks/months/years/decades are you willing to invest in the project. Every language has its own pros and cons and that is the reason why there is such a huge array of choices out there, because there can never be a best programming language.

Here I will list some good programming languages among which you can decide what fits your interest best:


- C / C++

- Pascal / Object Pascal

- Perl

- Python

- Basic / Visual Basic

- Java

- C# / Visual C#

- Javascript



- Ruby

As you can see, there are a lot of different programming languages / dialects and this post is getting bigger and bigger as I keep typing. That is the reason why I decided to cut my first tutorial lesson here and let you readers flick through all those wikipedia articles. That will give you a better idea of what you want to actually accomplish and how. In the next tutorial I will quickly go over most of these languages listing some pros and cons, then I will continue defining different programming techniques. Please stay tuned for the next chapter of this tutorial.

I hope this was useful to some of you, if it was please feel free to comment for positive feedback or criticize my work, I'm always open to debate and negative feedback as well. I'm still a student so please (PLEASE) do not EVER take everything I say for an absolute truth. I make mistakes, you make mistakes, everyone does.