Back from vacation, school starting in a couple of days and there's a list of things to do before the kick-off, as usual. To make the menial tasks more fun, I decided to blog it.

• Buy book for functional programmming course
• if not available in the store, loan it from the library
• else order it online
• pay rent
• set up tennis with my old tennis partner
• pick up toiletries from Kruidvat
• get a hold of that fancy train discount card
• obtain the internet banking package from my bank so I can check my balance from home
• reset my school password at the student administration desk
• coerce the school to give me a certificate of credits earned last semester

I know it sounds glamorous, but it's just business as usual here at Kramerica Industries.

[thanks to a full page ad in Aftenposten] IBM stands for International Business Machines [Corporation]. Now I feel like a kid who's just been told there's no Santa Claus. It never actually occurred to me that IBM was an acronym, it just sounded like a cool name for the world's biggest computer company. Business machines? What the hell is that? It could be anything, from big lawn mowers to saw mills. It's probably the most abstract name I've heard for a company, literally doesn't say anything about what they intend to do (everything, apparently).

What's more, if you open wikipedia and you're looking for IBM without knowing the acronym expansion, you are presented with these choices, none of which seem especially plausible:

• Inclusion body myositis
• International Business Machines Corporation
  • IBM India [I guess this one gives it away]
• International Brotherhood of Magicians
• Intercontinental ballistic missiles

How is that for a metaphor? Investing funds (ie. time) to obtain assets (ie. knowledge), whose worth is determined by the free market. Or if you cut the bs, simply deciding which languages to learn based on knowing its current value.

The TIOBE Index is the place to be if you want respect and admiration. Surely something Yukihiro Matsumoto (on the right) is presently enjoying, as his creation, the Ruby language, is about to crack the Top 10. And we trust Japanese engineering, don't we? If you buy Japanese electronics, you know it's gonna be good.

TIOBE tells us that if there is one thing all those colleges and universities teaching Java can't be accused of, it's being business oriented. Java is the number one 'enterprise language' at the moment, and after 3-4 years of Java, most graduates have learnt enough about it to look for jobs in companies that don't use it.
So, looking at TIOBE in terms of owning stock, this is my break down.

01] Java -- well grounded, hope I never have to use it
02] C -- familiar, only done a little hacking
03] Visual Basic -- no knowledge
04] C++ -- have learnt it, never used it in a project
05] PHP -- quite familiar, a couple of projects
06] Perl -- very basic
07] Python -- very comfortable, favorite language
08] C# -- meaning to start a project in it, but haven't yet
09] Delphi -- the high school years, don't remember much anymore
10] JavaScript -- always been avoiding it, not a big fan of client side scripting
...
13] Ruby -- see C#
16] Lisp/Scheme -- see C#, but lost interest in it after I started learning Haskell
27] Awk -- barely touched
32] Bash -- intermediate skills
46] Haskell -- basic skills, will be seeing plenty more of it in school soon

I stumbled upon the magnificent How To Write Unmaintainable Code by Roedy Green the other day and it really is something else. There are lots of humorous essays on bad coding, but this level of detail is so far unmatched in anything I've seen before. The whole this is pretty long, but here are some gems for you to savor...

Using names from other languages...

Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.

Using names from mathematics...

Choose variable names that masquerade as mathematical operators, e.g.:
openParen = (slash + asterix) / equals;

Using downright creative names...

Choose variable names with irrelevant emotional connotation. e.g.:
marypoppins = (superman + starship) / god;
This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about.

Using misleading names...

Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x)
should as a side effect convert x to binary and store the result in a database.

Well, you get the idea... one last zinger for the road...

When implementing a very complicated algorithm, use the classic software engineering principles of doing a sound design before beginning coding. Write an extremely detailed design document that describes each step in a very complicated algorithm. The more detailed this document is, the better.

In fact, the design doc should break the algorithm down into a hierarchy of structured steps, described in a hierarchy of auto-numbered individual paragraphs in the document. Use headings at least 5 deep. Make sure that when you are done, you have broken the structure down so completely that there are over 500 such auto-numbered paragraphs. For example, one paragraph might be(this is a real example)

1.2.4.6.3.13 - Display all impacts for activity where selected mitigations can apply (short pseudocode omitted).

then... (and this is the kicker) when you write the code, for each of these paragraphs you write a corresponding global function named:

Act1_2_4_6_3_13()

Do not document these functions. After all, that's what the design document is for!

This entry basically adds nothing, but with the examples you've seen here you should now be eager to read the full story, it's worth it! :cool: