This summer, my little brother has been charged with learning to write a game. Being the software guy in our family, my mother asked me to teach him. What better language to work on a game than Python? :) So I purchased a copy of Beginning Game Development with Python and Pygame, and he's been hacking away, learning the basics for the past week and a half.

I must say that I'm quite impressed with how well python teaches common programming methods. I'd heard lots about it, but had already had my share of programming experiences long before I got into python. In less than a week, my brother knew enough to write simple madlibs, which is something it took me quite a while to do in Visual Basic.

My brother's blog can be found at http://mattalui.wordpress.com. He'll be publishing what he learns there. His project is registered on Launchpad as Mattalui's Quest.

A very dear friend of mine and I had a conversation yesterday. Somewhere in the conversation, he said (and I'm paraphrasing) "I'm going to make my own encryption algorithm, and it's going to rock." This struck me as odd so I responded "Why would you try to do that when so many really good encryption algorithms already exist?" By asking this, I didn't doubt his ability to write an encryption algorithm, per se, but more that the AES algorithm was the life's work of Joan Daemon and Vincent Rijmen, two doctors of cryptography. His response was that he just wanted to tinker, which is a valid response, and one that I'm sure every developer has had at some point in their career (and hopefully still have some variant of it).

So I thought long and hard about that. It's good to tinker. I remember the first time I wrote a linked list in C. Advanced concepts like pointers suddenly just made sense. I understand how you could make an array that changed its size. It was a to me. I optimized it as much as I could, and I still have that very code on my system today. Today, I have no need for it, and haven't looked at it since.

Why? Because I know how it works now. I can use someone else's linked list code, one that I don't have to maintain, and one that has had much more work than I'm willing to put into it to make it fast and efficient. I've moved on from that. I could spend my time focusing on how to make my own data structures and make them efficient, or I could make real software using someone else's library, and devote my ingenuity to that.

While still talking to my friend, I used the analogy of building a birdhouse (and did my best not to let my high school shop class experiences taint the analogy). If you write up plans for a birdhouse, and then write up plans for a hammer, and then write up plans for a nail, and then write up plans for a saw, then you'll have quite a mound of work to do. Chances are, you'll probably end your birdhouse project with a half-made hammer, and lots of grand plans. Everyone does this at least once or twice in their career, and if you're a developer, and you claim you don't have a single half-made project somewhere, I will say that you are a liar to supplement your developer title. --:-)

I no longer recompile my linux kernels from vanilla, or even the distro's patched version. I don't need to. The speed difference isn't all that dramatic, and frankly, there's really no purpose. But I know how to do it, should I need it, and I understand how the kernel works. It's not magic to me anymore.

Before I go on with this post, I need to lay my preferences down on the proverbial table. I don't loathe Java, but I definitely lean towards more dynamically typed languages for my own projects. I see Java as a corporate language that really has very little application in open source (which is where I spend most of my time). I'm not going to say anything like "Java sucks" but I will say "I don't much care for Java."

I've been doing a lot of JSP/Servlet work recently. It's more for research than for production use. As someone who's done GOBS of web development, I didn't think it'd be too difficult. Writing the code, getting the syntax under my belt, all these things were rather simple. I've just grown use to the idioms used in web development as a whole, and so that wasn't too difficult (Eclipse made it easier as well, once I found a good JSP plugin).

I think the biggest problem to learning a language is running the code itself. My 12-year-old brother was up and running with python pretty quickly, having Ubuntu's Synaptic installer take care of installation, and then using the python interpreter. C, C++ and Java are a little more complicated. They require knowledge of rather complicated tools, provided you're doing anything more than "Hello World!" There are compilers, linkers, etc. Shoot, in all fairness, even writing your own python modules requires knowledge of how import works.

So I'm writing my Java web app, and I'm getting Tomcat all set up to work. Then I realize that there's more to deploying this app then I originally thought. Now I've got to write an ant build file to automate builds (because compiling all these classes and moving them all to the appropriate directories just isn't practical). After that, I've got to deploy it to the Tomcat server. The barrier to entry is just too high.

When I first started playing with Django, the one thing that really grabbed me was the development server that ships with Django. No mod_python/mod_wsgi/mod_fcgi/whatever to mess with just to see if I wanted to invest more time into the tool. When I started with jQuery and ExtJS, I had the javascript terminal in Firebug to play around with the API and find its strengths and weaknesses.

I'm not saying that a language should necessarily be "so easy a caveman could do it," but I do think that there needs to be a low barrier to entry. If it gets complicated later on, thats fine. Shoot, make some really simple, easy to follow tutorials on how to use the tools. Make explanations on the really simple things, like how library paths are structured, etc. Create tools that don't require 200 different command line flags to compile anything more complicated then your standard "Hello World!"

I'm a dynamically typed language fan boy. I've dabbled in all sorts of languages, but got my first development job working with PHP and Javascript, graduated to Python, and then did the C/C++ and Java stints as well. One thing I'm quite used to doing is writing print statements for debugging. In large C/C++ or Java environments, I found this quite impractical, and eventually became quite intimate with debugging tools in those languages. Until recently, however, I continued using print statements for working with scripted languages like Python. Now I use pdb for almost every problem I encounter in python.

A while ago, I battled a nasty Entertainer bug. It was repeatable, but not consistently. I would start the backend, and the it would start indexing videos from the configured video folders. Then, for no reason, the backend would die. I was able to trace the problem back to the VideoThumbnailer, which would be my baby. Crap. So I started adding print statements, so that I could see if the thumbnailer was consistently dying on the same video (thinking it might have been a codec problem with GStreamer). What I found was that the backend rarely died in the same spot, and since the thumbnailer didn't create thumbnails for videos that already had thumbnails, once it got past a video it had failed on before, it never struggled on it again. However, with the multi-threaded environment of entertainer, it was quite difficult to debug.

Eventually, I followed the yellow brick road to see the Google. I typed in 'python debugger' and found the first page of results full of pdb articles. "Oh no," I thought, "anything but the confusing and difficult pdb!" Alas, once I forced myself to work with it, I found that it was very simple to use (and that the pydev eclipse plugin makes it so much more complicated than it needs to be). I'm still only using a small subset of the things that pdb can do, but frankly, I can't see a need for anything more than what I used it for (setting a breakpoint, reading local variables, seeing a backtrace, and stepping through code).

First, I decided where I wanted to have pdb stop and give me a debugging console (setting the breakpoint). When that was decided, I added the following code:

import pdbpdb.set_trace()

That's it! Now run the code, and you'll find that instead of complete execution, you'll be at the (Pdb) prompt. Above your prompt, you should see the pdb.set_trace() call that created the console. I'm not one of those people who fears a command prompt, so if you are, I apologize. However, this isn't nearly as complicated as a shell prompt. You've got only a few keys to worry about:

• n (next) - Hitting 'n' at this prompt will execute the current line of code and go to the next line.
• c (continue) - If you've gotten to the point where you know your bug is fixed, and you want to just close the debugger, hit 'c' to just continue executing the program. This will complete execution, provided that you have no more calls to pdb.set_trace()
• s (step into) - If you're at a function or method call on the prompt, and you'd like to see what's going on inside that function, stepping into it will allow you to follow execution into the function. If you don't want to see what's going on in the function, 'n' is your character.
• l (list) - Wait. Where was I in the code again? Yea, I guarantee that'll happen to you. Hitting 'l' will give you a chunk of code in the area you are, with a nice little -> where you are currently.
• bt (backtrace) - Okay, so now I know where I am, but how did I get here? 'bt' gives you a backtrace, showing you the start of execution, and all the function and method calls that got you where you are today.
• p (print) - Okay, so what's the value of variable foo? 'p foo' will print it's value, allowing you see how the variable is changing as you walk through the code.
• q (quit) - Ah! Found the bug. Let's quit this session and fix it!
• enter (repeat last command) - Tired of hitting 'n' over and over? How 'bout just using 'n' once, and then hitting 'Enter' over and over. It's a bigger key, and less likely to get fat fingered. I don't use it, but it's there if you want it.

Needless to say, debuggers are the tools that would make your life easier if you just learned how to use them. Since my experience with the debugger, I've chatted with a few pythonistas and developers from other languages, and to my surprise have received varying responses. I would say that if you've spent more than 5 minutes writing print statements and running your code, do yourself a favor and fire up the debugger. There might be a learning curve now, but you'll be a better developer for it.

O'Reilly's OnLAMP blog had an interesting article this morning entitled The Broken Metric of "Intuitive to the Uneducated" Language Syntax which I found very interesting. chromatic is a Perl programmer, and his argument comes from that background. I'll admit that I'm among those developers who say things like "I don’t like to read punctuation" but at the same time, I'll completely agree with him. The basis of a language should not be how easy it is for an unskilled user to pick up and use. And no, this is not about my worries for job security by some "silver bullet" programming language making everyone a programmer

The basic idea of the O'Reilly post is this: In english, I can say "Get out of here!" Depending on my intonations, my facial expression afterwards, and my body language, that phrase could mean many things. It's about the semantic application of the syntax that allows for proper handling by recipients.

Here's a great example: I work everyday in PHP. I work in web applications, and while I write in many other languages in my spare time, I feel most experienced with the standard web application languages (PHP, CSS, XHTML, JavaScript). With minimal training, anyone can learn to develop applications with PHP. It's easy. There's not much linking, compiling, and general headache that most compiled languages require, and there's NO learning curve when it comes to using outside libraries. It's just a simple include('foo.php'). The vast array of builtins also means that whatever you want to do is probably already at your disposal. The problem with PHP is exactly those things that make it so easy to work with as well. All of those modules, builtins, and tools all live in the same namespace. Many functions are merely aliases for other functions. The barrier to entry to PHP development is low, but the amount of expression is also low.

Until I decided to venture out of the php world though, I didn't realize any of this. I had no understanding of character encodings or proper design patterns. Why? Because PHP takes care of it all for you. Put your markup and logic in one file, who cares? Shoot, I care. My brain's context switching between HTML and PHP is taxing. PHP takes care of so much stuff for you that you never really know what you're actually saying.

I've been going through the MIT OpenCourseWare recently, and the first class they teach you in the Computer Science department is all about expressing algorithms in computer code. They start you out with Scheme, which I had heard many zealots talk about, but have never felt to go out and learn it. Now that I am learning it, I see it's power. Scheme allows expression, but the syntax is incredibly simple. You simply cannot become an expert in Scheme by becoming an expert in its syntax. That's not where the power is. Bob Poweruser definitely couldn't just pick up Scheme (or any variant of Lisp) and figure it all out in a few days. The simple lack of a for loop would stop even the most advanced un-programmers.

Learn another spoken language, and this will make even more sense. The ability to express what you're saying is more important than just saying it. Having that flexibility will prove incredibly helpful in the long run.