Some thoughts on how to start learning to program.
My brother Joseph recently commented that while he was following my “Unlocking Programming” posts, he was uncertain how to begin actually learning to program. I confess I’m uncertain too. My own approach was to pick a language (Perl), read an online tutorial, hammer madly away trying to get simulations of ocean waves and bipedal motion coded, then start taking college classes. Assuming you don’t have college classes on hand, I do not advise that approach.
One thing seems abundantly clear at the time of writing: to learn to program, you have to learn a programming language. I don’t like or believe in programming languages (for reasons I hope to write up soon) but besides a few shaky programs like Alice and BYOB/Snap there isn’t really an alternative. So, what language do you pick?
The answer is, pick a language that makes it easy to do what you want to do. Want to write cheesy little games? BYOB/Snap might be fine. Like processing text? Try Perl. If you think about matrices and vectors, Matlab or, for my preference, the open-source duplicate Octave is the main language in the game. Want flashy web pages? It’s all about Javascript, but that’s an ugly language for the serious student; I’d advise a compiles-to-Javascript language instead, like HaXe.
If don’t know what you want then Python is a decent default; for now, go with the latest version 2.*, not 3.*, as the 3.* is much less supported. There are many different Python builds available; I prefer the PyPy build for big programs and the online skulpt for playing around.
Getting a programming language up and running is not always easy. If you don’t plan on doing big things right up front, you might check out codepad, which allows you to run short programs in a variety of languages, save them, and share their URLs. If you do want your own copy, follow the directions on the language’s web page (if there is one). They are usually detailed and involve more than a simple “download and run”, ending up with some sample program (typically named “Hello World”).
When meeting your language,
know that it was designed based on the very old assumption
that there is only the keyboard, nothing else.
Every program is just a sequence of letters, numbers, and spaces.
It’s been that way since the late dawn of programming computers
and shows no signs of going anywhere else anytime soon.
So look early on for comments:
text that is not for the computer, it’s for the human.
Typically comments run between a /* and a */,
or they start with one of #, %, ;, //, or --, and end at the end of the line.
Blocks are also important,
but I’ll cover them in a future Unlocking Programming post.
Most languages have an online tutorial. I’d suggest walking through it, at least for a few hours and then picking some problem and trying to solve it. Having a problem in mind narrows the focus and helps you to learn and internalize ideas. Another good idea is to grab bits of code from the web, read them, change them, and play about with them.
Never forget, though, that knowing a language is not the same as knowing how to program. Programming can be divided into several parts:
Knowing a programming language only helps with the third part, and with most programmer I know that takes up very little of their time. It’s the first two that matter most, and the first two that many books and most tutorials skip entirely. Hopefully I’ll talk more about them as I go along.
Looking for comments…