To learn a new programming language when you already know another, that is the problem.

I had an old approach and I have, over time and serendipity come up with a new one. This post discusses the old approach. The next one will talk about the new approach.

Introduction

By learning a new programming language, I do not mean "pure" programming stuff - semantics, grammar and syntax; rather, learning stuff that you can apply in a fairly real world scenario - this also means doing menial tasks etc.

The idea is that if you were to waterfall from "semantics and syntax" to "application", the learning process will become too boring and too long to be productive. So, we need an approach that can:

1. Fast track the learning (even if by a small bit) and keep the interest alive

2. Force you to understand the essential parts of the language

3. Result in something that has more value in the real world than just the language learnt. You should be ready to build some applications with the language, work in a professional setting and be able to rely on your new skills "on-the-job". Being competitive, mind, is a different ball game, that will come later.

It was by a neat chance that I bumped into this excellent post: 15 Exercises for Learning a new Programming Language.

[The same post is also available here.]

Although some of the comments on the post look really dubious, even the post itself seems to be the only good thing on the blog, the post is a gem. Kudos to the author!

Each time you learn a new language on your own, there is always the problem of knowing when enough is enough (it last happened to me with Ruby, a few months ago). So one would need a measure to determine that what has been learnt is enough to start swimming and that the rest can be learnt "on the job", as you go forward.

Typically all I've ever recommended is to build a medium scale project in the language you are learning. It struck me, while reading the post, that there was another approach. A more fun way, breaking the larger chunks into smaller, funner material. It also highlighted the flaws in my approach. I have since adapted the new proposed "fun" approach, added a few extra steps in it and am good to go.

To properly understand the updated approach, let me first type in my old approach and the logic behind it:

My (old) Approach

Keeping in mind the language and the platform, build a medium scale project. Search the web for possible ideas, but the project must have/do the following:

0. Install the bloody thing:

You'll not be comfortable with the development environment from the word go, but, you need to be comfortable enough doing the regular tasks: punching in code, compiling and running the programs etc. See if there is an eclipse or NetBeans plugin available. Google to see the other IDEs commonly used for the particular language. Try and stick to free/open source here.

My experience is that lack of sufficient proficiency in this area becomes a very big initial barrier to learning. So attack it with full force and ensure that you are comfortable with the environment before you start exploring (I know, it sounds paradoxical to start with!). Put your head to the task and just get it over with. Know the compiler command line and common deploy/execute options.

1. A graphical UI, with atleast one tabular display of formatted data:

Even after almost 20 years of work in this field, GUIs are still a challenge. From basic HTML/Javascript to native windows, Java AWT, Python and even ActionScript, no matter how simple they make GUI programming, there is always a nuance to catch.

Events, coordinate spaces, z-ordering and screen refresh - each a typically tricky aspect.

2. Create/retrieve data from a database:

This to me is the dumbest, foolishest part of learning a new language. It gets hard to configure at times and can be really confusing. Prime example: JAVA - don't you just hate it when as a novice you have to struggle with "drivers" and "connections" and such like?

I do not regard SQL as a language. It takes a day to learn it. Granted there may be nuances between SQL server, MySQL and Oracle (fck! spare me!) but that is all they are: fine details, that you can learn as you go.

So with SQL and your new programming language, you should be able to create a random database.

You'll have to learn to "connect" to a database driver/engine/manager/whatchamacallit, supply the SQL query to it and finally execute the query and output the results or confirmation.

Popular choices: Employee database (programmer, manager, employee), Accounts database (Chart of Accounts, Journal entries, create a balance sheet), Library database (book ID, details, locator), Shopkeeper's, Doctor's etc etc.

In case you are onto something like ActionScript or JavaScript, you'll have to rely on some of your previous programming experience for this part. If you can't figure a database out, just forget it and move forward.

3. Some form of sorting and searching:

[...and this was a weak step, but, most pseudo-programmers get by anyway - they delegate all algorithmic jibber-jabber to custom libraries, open source projects, google searches and/or SQL - they never develop an appreciation for the concepts. Even if you are one of these, do try this step, it helps.]

You need to have some idea of how to get your algorithms right. The boundary conditions, the speed, the limitations. The "Off-by-one" errors are the kind that I see coming up most often with most programmers. The loops run a cycle too long or a cycle too short, the comparison is not valid on the boundaries, adding an extra 1 results in invalid value-space etc. These errors are even more frequent

Not SQL based, but sorts and searches in the language you are learning. Even if this is just simple, you need to know the different ways you can do this.

4. Networks, HTTP, native code and remote objects:

You need to know how to talk to other environments. This is where you do it.

ActionScript should be able to get and set data from the HTML page/JavaScript method calls, JavaScript calls to the server, AIR calls to the native system, Python native code, Java and C talking to each other, remoting in .NET and so many other things lie in this domain.

Just think it this way: Pick up a feature in your project where something in the new language you are learning will talk to something else in one of the languages you already know. Simple.

If your language can handle HTTP, then try to understand how you can harness it. Try to add a feature that uses HTTP, even if it is simplistic.

5. Text formatting:

HTML based or native, have a fairly funky scenario where you display formatted text. One of the good ways would be to create a report on some of the statistics from your database and display it with proper formatting.

6. Multimedia [optional]:

It's a "nice to have". If your language can load/support images, audio and video, then throw some in. Just for the heck of it. It is important to know how you can load large files, manage streams of data and just plain render these on screen.

7. Data handling - Binary, text-string, streams :

Today, you need to handle binary data, JSON, XML/SOAP etc.  Seriously. So try to factor in some data throughput (maybe binary data write to a location of user's choice, save the UI layouts or read json/xml configuration strings or create application event logs or save user preferences etc) in your project.

8. Automated testing and build management:

This may seem like overkill, but, reality is that if you cannot test it, you cannot deliver it, period.

Explore if you have unit testing frameworks available for your language, or try to write small tests on your own. Ensure that you do some test-writing before you declare your readiness for the rest of the world.

ANT, Maven, Hudson, Make and such like also help. What is even better that their working does not change much from language to language. It becomes, after a while, extremely important to know these well.

All set? Develop. Around mid-way on such a project, you will cross the threshold of knowing enough about the language. Finishing the project will just add value to your learning.

In the next post, I'll share the newer, funner approach.

There may be more ways of doing this. There may be areas that I have missed, so do enlighten me. :)

Till the next 'un then!

Shaurya