« Swanson's Rules of Management - Rule 3 | Main | Bottom Story of the Day »
December 09, 2005
Learning a new programming language in 10 steps
Having had to learn 4 new programming languages/environments/whatever in the last year, I've gotten some practice with mastering them quickly, and without buying a bunch of books, or going to classes or anything cool like that. Just think how much you'll impress your boss when you demonstrate mastery of a new language for less than $50!
So you want to learn a new language.
1. First, I have to find a motivation. Usually for me, the motivation is "Learn this language, or the company is doomed." Other times, it's "Learn this language, or the cool kids will laugh at you." Still others, it's "Learn this language, and you will be granted the dark powers of the Chaos gods, and hold dominion over the Earth!"
Er... maybe I shouldn't have mentioned the last one. Anyhoo, once I have a motivation, it's time to move on to "Okay, now what"
2. Okay, now what - Download the language environment/structure. This varies a lot these days, from the massive behemoth that is Visual Studio or Macromedia Studio, through the medium-sized OpenLaszlo and/or Java environment, and then down to the svelte Ruby, Ruby on Rails or "R" style environment. This is usually one of the easiest things to do, as long as you use the operating system that the developer(s) of the language want you to use. For example, Visual Studio doesn't work particularly well on NetBSD. Be aware!
3. Once you have the environment, there may be some setup involved in getting it to work. This could take minutes, hours, or days, depending (again) on what OS you're installing on, whether you have root/admin privileges, and if your disk is large enough to hold all of the documentation and sample code and so forth. This seems to vary directly with size - the longer the download, the longer and more frustrating and complicated the install will be.
4. Now, on to the good stuff. Hello World! Yes. Hey! Stop rolling your eyes! It's a perfectly valid way to make sure that your installation is working properly. Also, using the principles of agile software development, once you write a test to verify that your Hello World function returned the string "Hello World", you are well on your way to building any application imaginable, just by properly refactoring and writing enough new unit tests. I am currently writing an application in C# which will solve the travelling salesman problem in polynomial time. Just as soon as I find the right COM object to include to get the #$(* thing to compile.
5. Once you have Hello World working to your satisfaction, it's time to choose a more complex application. For example, Hello {your name here} or somesuch. Why? Because input is often just as hard as output. I've spent hours trying to get some languages to do this properly. Of course, I'm often asleep, or off doing something else for most of those in-between hours but, still, it's worth doing.
6. Now you know how to print output, and get input. Can you do it in an "approved" manner? For example, with Laszlo, if you aren't creating a web-based Flash app with a floating main window, you're not really writing Laszlo. If you're not building a context-sensitive Excel plugin .Net object with a 300 meg install and a license agreement that would make Ramsey Clark blush, you're not really writing C#.
7. Now, it's time to include some libraries/modules/third-party elements to your solution. This can either be one of the most frustrating, annoying, confusing things you've ever faced in your life, or it may just simply be impossible on your chosen platform. You never know until you try. Some language environments will claim that they make this step easy. Unless they involve the name 'Ruby', don't believe them. And even Ruby has its moments.
7.1 Hey! You're not done! You have to use those libraries you just included. Aha. I see that downturned look! Just including them isn't nearly enough, oh no. I don't care how long it took you! You're not done until you're using a library to reverse the order of the letters in your name, or some other ridiculous stunt. Get back to work!
8. At this point, you're probably tired. Rest.
9. Now, it's time to start really letting yourself get confused. There's probably a reason you need to learn a new language. Now's the time to figure out the major techniques you'll need to master, and prototype them, one at a time. For example, I had to learn how to manipulate spreadsheet cells in Excel via an application. So I started by Googling for 'Excel C# API'. Eventually, I found some examples. Warning. The examples never work properly. . Fact of life kid. Deal with it. Figure out why your environment is different. Are you using C# 2003.18.5.4.4.5.4.3? Maybe the example was written in C# 2003.18.5.4.4.5.4.3 instead. Those are the same version, you said? Hah! It's unlikely the author of the original example actually knew what he was doing anyways. Maybe it was a different of glibc or one of those fancy ultrathreaded processors. Who knows?
9.1 Repeat this, step by agonizing step, for every "fuzzy" thing you know you'll need to do that you don't know how to do now. Web Services? Database connectivity? Image generation? RSS feed processing? Active Directory integration? Solving the Travelling Salesman problem in Polynomial time? Keep plugging away! Eventually you'll get it (and if you get the last one, send me an email with the source code.)
10. At this point, you don't really have any excuses. It's time to look at the API documentation. I know, it's for wimps. It's like asking for directions while driving. It's like putting the iPod Nano back in the box, and handing it back to the salesperson and saying 'I can't afford this right now. It sucks.
I have spent a lot of time trying to figure out why trying to follow API documentation sucks. And I think the answer is - because you have to understand how the API writer's brain works. Ironically, once you spend enough time to figure out how the author's brain works, the API no longer seems complex.
So why not skip the middleman? Instead of trying to figure out the API, figure out the author of the API. Follow him in your car. Rifle through his trash. Steal his passwords and examine his del.icio.us bookmarks. At the very least, it will teach him a lesson for writing such a bewildering API document. And, who knows, you may find some cash, or some cool pr0n sites, or even a new job opportunity, at which point you'll be able to tell your boss "You know that language you wanted me to learn? Well, I found a great new job instead, so I quit!"
If you have any ideas on how to learn new programming languages, please, share them with me (johnbr@gmail.com). And don't forget about that Travelling Salesman thing!
Posted by jb at December 9, 2005 01:53 PM
Trackback Pings
TrackBack URL for this entry:
http://www.undefined.com/cgi-bin/mt/mt-tb.cgi/397