Pyrge Tutorial 2: Sprites and Input

in Programming

In part 2 of our little tutorial, I’m going to show you how to build on the game from the previous post by adding a sprite that can be moved by the arrow keys or mouse clicks. It’s still nothing to write home about, but it will introduce you to more of the objects available in Pyrge, as well as the event system.

Creating a Sprite

While the text from the last program was certainly informative (well, not really), it doesn’t do anything, and any game except Zork is going to need graphics. So, without further ado, here’s Tutorial Game #3:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
from pyrge import *
 
class TutorialWorld(World):
    def __init__(self):
        super(TutorialWorld, self).__init__()
        self.add(TutorialImage())
 
class TutorialImage(Image):
    def __init__(self):
        super(TutorialImage, self).__init__(100,100)
        self.load('pygame_icon.bmp')
 
theGame = TutorialWorld()
theGame.loop()

I’ve removed the text object, since we don’t really need it anymore. We’re moving on to bigger and better things. Anyway, when you run this program, you should get the usual screen of nothing, with a small picture of a snake (specifically, the Pygame logo) near the top-left corner.

Going line by line, you can see that the first 5 lines are the same as before: importing Pyrge, making a world subclass, defining a constructor, and calling super. These four things will probably be in every game you make with Pyrge. The only real differences will be the name of the class and–maybe-the constructor’s parameters.

Line 6 is where the real fun begins. Instead of the stock text object from before, we’re adding a new TutorialImage object to the game world.

Starting on line 8 is, surprisingly enough, the definition of the TutorialImage class. It derives from Pyrge’s Image class, which is the base for every visible object in the engine. Image contains all the bits necessary to make a sprite: position, size, animations, collision detection, and so on. In short, every little thing Pyrge offers except two: motion and tweening. These are split into several classes, so that you only use the functionality you need. Non-moving images don’t need to run physics code constantly, so those objects are made faster by not even having the option. (We’ll see the more specialized objects later in the tutorial.)

Back to the tutorial, and the code. Line 9 starts defining the constructor, done in the same way as for the world itself.

Line 10 contains the super call, which is different because it has two parameters: 100,100. Images can be created in lots of different ways. If there aren’t any parameters (just plain Image()), then you get a sprite centered on (0,0). Two parameters, like here, tell the sprite to be centered on that location: (100,100) in this case. Four parameters specify both the position and the size, which is useful when you want a blank canvas instead of a pre-drawn sprite. (There are also keyword arguments for Image, most of which are the same as these: x, y, width, height.)

To summarize:

  • Image() (no parameters) creates a blank sprite with no size centered on the upper-left corner of the screen. Not too useful until you load something into it.
  • Image(x,y) (two parameters) makes a sprite that’s still blank, and still has no size, but now has its center somewhere else in the world, namely the position (x,y).
  • Image(x,y,w,h) (four parameters) creates a sprite whose size is (w,h) and whose center is (x,y). Again, it’s still blank.

You surely have noticed that, no matter how you call the constructor, there’s just not going to be anything in the Image. Line 11 changes that. Here we call the Image.load method, which takes a filename, loads that file, and puts it into a property called pixels. That’s all you have to do. Pyrge will figure out what kind of file it is, and load it into the sprite, and start drawing it.

Lines 13 and 14 finish up this game the same way as the last two tutorial programs. Like the first few lines, these last two will probably always be here in some form.

Action and Reaction

While it’s all well and good to put up pretty pictures, we need them to move, to react. The next program, “tutorial4.py” if you’re following along at home, will do just this.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
from pyrge import *
 
class TutorialWorld(World):
    def __init__(self):
        super(TutorialWorld, self).__init__()
        self.add(TutorialImage())
 
class TutorialImage(Image):
    def __init__(self):
        super(TutorialImage, self).__init__(100,100)
        self.load('pygame_icon.bmp')
 
    def update(self):
        if Game.keys[Constants.K_LEFT]:
            self.x -= 2
        if Game.keys[Constants.K_RIGHT]:
            self.x += 2
        if Game.keys[Constants.K_UP]:
            self.y -= 2
        if Game.keys[Constants.K_DOWN]:
            self.y += 2
 
        super(TutorialImage, self).update()
 
theGame = TutorialWorld()
theGame.loop()

The first 11 lines, and the last 2, are exactly the same as in the previous example. (Seriously, I just copied and pasted them.) The real meat of this program starts on line 13, with the TutorialImage.update method.

Every Image in a Pyrge game has to update each frame. Most of this is tracking changes in position, switching between frames of animation, and a lot of other low-level things that most people don’t need to be concerned about. That’s what the super call on line 23 does, is tell Pyrge to go ahead and do all of that boring stuff for us, we’re just adding on to it.

What we’re adding on is contained in lines 14-21. It’s pretty much the same code repeated four times, with only slight changes. Each time, we’re looking at an entry in a list called Game.keys. This list holds all of the different keys that Pyrge (actually Pygame–well, actually SDL, but that doesn’t concern us) can understand. These are all assigned a keycode, but to keep us from having to look up the number of each keycode, Pygame has graciously given us a bunch of names for them. Pyrge imports these (along with a bunch of others) all into the Constants object.

So the four ifs on lines 14, 16, 18, and 20 are testing the keycodes K_LEFT, K_RIGHT, K_UP, and K_DOWN, all of which should have obvious meanings. Each of these values will be set if that particular key is being pressed at that time. Lines 15, 17, 19, and 21 react based on which keys are being pressed. If the left arrow key is down, the sprite’s x value will be decreased by 2, making it move to the left. The other arrow keys work the same way: right is x+2, up is y-2, and down is y+2.

If you want to change that speed of the sprite’s movement, all you have to do is change the amount that is added to (or subtracted from) the x or y value. We could, for example, make the sprite move really fast by setting it to 10, or really slow by making it 0.25. We could even reverse the movement (make the left arrow move right, etc.) by using negative numbers, a quick and dirty way to make “inverted axis” controls.

Now, if you wanted to use different keys, say the familiar WASD format, you just need to change the key you’re testing in the if statement. The A key is K_a, and the other letters are the same: K_b, K_c, all the way to K_z. Numbers work the same way: K_1 across to K_0. Symbol keys, like the comma or at-sign, have spelled-out names: K_COMMA, K_AT, etc.

Click Here

So we’ve covered the keyboard, now we’ll tackle the mouse. Here’s “tutorial5.py”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
from pyrge import *
 
class TutorialWorld(World):
    def __init__(self):
        super(TutorialWorld, self).__init__()
        sprite = TutorialImage()
        self.add(sprite)
        self.addHandler(Game.events.MOUSEBUTTONDOWN, sprite.onClick)
 
class TutorialImage(Image):
    def __init__(self):
        super(TutorialImage, self).__init__(100,100)
        self.load('pygame_icon.bmp')
 
    def update(self):
        if Game.keys[Constants.K_LEFT]:
            self.x -= 2
        if Game.keys[Constants.K_RIGHT]:
            self.x += 2
        if Game.keys[Constants.K_UP]:
            self.y -= 2
        if Game.keys[Constants.K_DOWN]:
            self.y += 2
 
        super(TutorialImage, self).update()
 
    def onClick(self, event):
        self.position = event.pos
 
theGame = TutorialWorld()
theGame.loop()

This doesn’t add much in the way of functionality. The only thing different is that now the sprite will not only move with the arrow keys, but it will also “jump” to where the mouse is clicked.

Little has changed on the code side, as well. On line 7 you can see that we “split” the process of adding the sprite to the world. We now actually assign the sprite to a variable named, well, sprite.

Why we do this is evident in line 9. Here we are calling the world’s addHandler method. What this does is set up a function that will be called whenever a specific event happens. Pyrge uses the Pygame events, which include motion for mice and joysticks, button presses and releases for the keyboard, mouse, and joystick, quitting the game, resizing or focusing the game window, and a number of “user” events that can be used by a program.

In this case, we want the MOUSEBUTTONDOWN event. Like its name suggests, this event happens whenever a mouse button is pressed. We’re telling Pyrge here that, when this event occurs, we want to call the sprite.onClick function. (If we had just added an anonymous object, we couldn’t refer to it here.)

Lines 27 and 28 make up this method. First, we define the function, which takes a parameter containing the event that caused it to be called. Inside the function, all we have to do is set the sprite’s position property to the position where the mouse was clicked. Happily, the “mouse down” event tells us this in its pos property. And that’s it. The code was actually cleaner and more concise than the plain English description.

Bonus Feature: More On Events

According to Pyrge and the underlying Pygame/SDL system, clicks and keyboard presses come in pairs: a press or “down” event, and a release or “up” event. Usually, the “down” event is what you want. Also, there is no “held down” event, which is why we used Game.keys above. There’s no simple solution like that for the mouse, so the common practice is to set a flag in the handling object when you get the MOUSEBUTTONDOWN event, and clear it on the MOUSEBUTTONUP event.

Both of these events have two properties. We saw the pos property in the example. The other is the button property, which gives the number of the button that caused the event: 1 for the left button, 2 for the middle button (or clicking the scroll wheel), 3 for the right button. 4 and 5 are used for scroll wheel movement up and down, and button 6 is used for the “squeeze” click on some Apple mice.

MOUSEMOTION events have the pos property, a rel property that gives the position relative to the last MOUSEMOTION event, and a buttons property. This is a tuple with three members, each of which will be set if that mouse button is pressed, so you can detect click-dragging.

KEYDOWN and KEYUP events both have a key property, holding the keycode of the button that was pressed. They also have a mod property, which is a bitmask of keyboard modifiers like Shift, Ctrl, and Alt. (These have keycodes like KMOD_ALT.) But KEYDOWN also has the unicode property, a string representation of what was typed. This value will be the string representation of the key, or what would show up in a text editor. So Shift-A, for example, will have a unicode value of “A”.

The other events aren’t quite as useful. Not everybody has a joystick, and few games support resizing. For all of these, I’ll refer you to Pygame’s event module.

Last but not least, if you’re familiar with Actionscript or Flash, you might be wondering where the ENTER_FRAME event is. The simple fact is, Pygame doesn’t have one. But that’s OK, because Pyrge gives us something similar: the “updater”. Instead of calling the world’s addHandler method, take out the event type argument, and call addUpdater. This will cause the given function to be called each frame, though there’s no guarantee exactly when in the frame it will be called. The only other difference between handler functions and updater functions is that handlers have an event parameter, but updaters don’t, since there isn’t an “update” event.

I’m not sure where this tutorial is going, so I’ll see you next time!

Pyrge Tutorial 1: Up and Running

in Programming

Now that Pyrge is officially released, I need to write some documentation for it. So this is the first in a series of tutorials about using my glorious creation. First up, we’ll get everything installed, then we’ll start making a game that does nothing. I know, I know. Bear with me here. This is mainly for people that haven’t coded much, if at all.

Installing Pyrge

The first thing we need to do is download Pyrge. The link to the latest version should be in the sidebar of this post. Now, extract that ZIP (or tar.gz) file wherever you want.

Make sure that you have Python (2.5, 2.6, or 2.7) and Pygame (preferably 1.9.1) installed, because Pyrge needs those to run. If you have everything set up just right, then running the command “python setup.py install” in a command prompt or terminal should do everything you need. If not, check that you have all the necessary requirements, and that you typed the command correctly. If something’s still wrong, let me know and I’ll see what I can do.

Alternative: No Installation Needed

(Feel free to skip this section if the above installation worked for you.)

If you can’t install Pyrge for whatever reason, don’t worry, because there’s another way to use it. Move the whole installation to a subdirectory called “pyrge” under the main directory where your game code will live. So if you want to put your game code in the “C:\Documents\mygame” folder, Pyrge needs to be in the folder “C:\Documents\mygame\pyrge”. The tutorials and examples won’t work, but anything you run will. (The problem with this approach is that you might need multiple copies of Pyrge, one for each game, and that other users on your computer can’t access Pyrge.)

Does It Work?

Now that you have Pyrge installed, let’s see if it actually works. Our first game, if it even deserves the term, is as simple as this:

from pyrge import *
theGame = World()
theGame.loop()

Save that as a Python file (I called it “tutorial1.py”), and run it. It should pop up a black screen that does absolutely nothing until you close it. Not much of a game, I’ll admit, but it does let us know that Pyrge is correctly installed and works. (Or, at the very least, gives us an idea of what went wrong.)

The Real First Test

Not only is the previous “game” boring, it’s not even good from a programmer’s point of view. So we’ll make a new one (I’m using “tutorial2.py” for this one):

from pyrge import *
 
class TutorialWorld(World):
    def __init__(self):
        super(TutorialWorld, self).__init__()
        self.add(text.Text('Hello, Pyrge!'))
 
theGame = TutorialWorld()
theGame.loop()

Again, save and run. This time, we still get a black screen that doesn’t respond to any input, but this time that screen has text! Hey, everybody starts somewhere!

Let’s go through our little program line by line, since it shows most of the things that every game using Pyrge will have. First, line 1 imports the everything in the game engine. We can do this in two ways: import pyrge or from pyrge import *. With the first way, every time you use something from the engine, you’ll have to prefix it with “pyrge.“. In this game, that means that World would have to be written pyrge.World and text.Text would become pyrge.text.Text. The second method saves typing, but it means that you’ll have to be careful with the names of your own objects. If, for example, you called a variable “text”, it would hide the text module. For these simple tutorials, we’ll use the from pyrge import * form, saving typing at the expense of namespace pollution.

Continuing on, line 3 is the start of our “world definition”. Pretty much every Pyrge game will be defined as a subclass of World. In this case, we’re calling it by the unimaginative name of TutorialWorld.

Line 4 starts the definition of our game world’s constructor. This is the function that will create the world, so anything that needs be done before the game is started will go here.

Line 5 uses the super function to tell the parent World to do its own initialization. Almost all of your objects will have a call to the parent method to let the engine do its work: setting up variables and properties, initializing data, and so on.

On line 6, we are adding something to the world. (You can tell because the method is called self.add.) Specifically, we’re adding the text “Hello, Pyrge!” to the world. Since we don’t say otherwise, the text goes at position (0,0), the top-left corner of the screen, using the default font, size, and color.

Lines 8 and 9 actually run the game. We create an object and then call its loop method, which runs through the business of rendering a game each frame.

Pyrge – The Python Retro Game Engine

in Programming

Last year, my brother began to show an interest in games. Well, he already had an interest in games, but now he was interested in the “other” side of them: making games. While his reasons for this are still a bit unclear even to me, I dutifully played the part of the big brother, and tried to help him get started. Immediately, we ran into a pretty big problem, which I spent quite a while describing in the earlier “first programming languages” post. My personal favorite was (and still is) Python, but he wanted to make Flash games, because the Flash platform does indeed have better tools for game development.

So, after that aborted effort in education, I set to work on solving a problem. Python’s Pygame is a wonderful thing, but it is both complex and low-level; in other words, it might be, for a first timer, too much work for too little gain. I know this from experience as a user and, now, a teacher of the library. To be fair, Actionscript is the same way, but there are so many Flash game developers that that problem has been more or less solved, many times over. What I needed then, was a Flash game engine, but written for Python. And thus Pyrge was born.

Pyrge (pronounced exactly like “purge”), the Python Retro Game Engine, is my way of bringing the idea of Flash-style game engines together with the simplicity of the Python language. It’s called “retro” because it’s entirely 2D, just like all those wonderful games for the NES and SNES, but with the power that comes from modern computers. My biggest inspirations were two of the great Flash engines: Flixel and FlashPunk.

Now, I’m announcing the release of Pyrge version 0.3. I consider this to be an alpha release, mostly because there are still things I want to add, and because there is a distinct lack of documentation. But the heart of the system is in place, and it already has a number of features:

  • Static and animated images with support for rotation, scaling, and (optional) physical motion.
  • Interpolation (“tweens”) for movement, animation, or general use.
  • Sprite sheets that let sprites use the same image, for lower memory usage (and retro-style special effects).
  • Platformer-style tile maps
  • “Old-school” special effects, like parallax scrolling, fading, and camera shaking.
  • Particle emitters for fireworks and explosions.
  • Much, much more!

There’s still a lot more work for me, but I think there’s enough there for a public release. To use Pyrge, you’ll need Python, at least version 2.5 (I’ve tested on 2.5 and 2.6, and I know it won’t work on any Python 3 version), and you also need the latest version of Pygame (at least 1.9.1). Once you get all of that, you can download Pyrge at github in a number of ways:

Installation is fairly simple: download, extract, and then run “python setup.py install” from the directory where you extracted Pyrge. I’ll try to get a Windows installer uploaded, but I don’t run Windows, so that’s easier said than done. Last but not least, Pyrge is licensed under the LGPL, which basically means that you can use it in any game you like, and you only have to release changes that you make to the Pyrge engine itself.

Now, go and make games (and find all the bugs that I missed)!

Back in Business

in Admin

The main Potter PC Services site is back up and running as of 10/14/2010, with more business content, including pricing and contact information. It’s still the same old design, though. That’s the next step, and it can wait a while longer.

The First Step is the Longest

in Computers

This is a post I’ve been wanting to write for a while now, but I just can’t seem to make myself do it. Now I’m going to try, though. It’s a really long post, so bear with me.

It’s been about 20 years since I wrote my first line of code. That might not seem like a lot of time for an old, experienced coder from the days of yore, but, well, I’ll be 27 in three weeks. OK, I’ll admit, my “first line of code” was really in BASIC: 10 PRINT "HELLO" or something like that. It wasn’t much, but it was the beginning of a journey that hasn’t yet ended. And over these past two decades–that phrase just makes me feel old–I’ve grown as a person and as a programmer.

That graduation from BASIC to C++ to Python, Scala, and whatever else I find myself using is a tale for a different day. But I’ve been thinking about that journey: the way it started, how I, personally, progressed from simple BASIC programs to something as complex as a game engine in Python, or a simulated processor in C++, two projects that I hope to elaborate on one day. Thinking about that, as well as reading a few recent Slashdot articles, has turned my thoughts in another direction: programming as education.

I’ll admit it, I want to teach. Not as a teacher in a formal classroom, burdened by bureaucracy and paperwork and unions and all the rest, but in the Socratic sense–more a tutor than a teacher, if you will. I have, I feel, been given a gift of knowledge, but that gift comes with strings attached. Well, more like I attached my own strings, because some part of me feels that, having been gifted this knowledge, it would be selfish of me to hoard it all to myself. Instead, I should be sharing it with the world.

But I digress, as always. I’m interested in teaching, the sharing of knowledge, and I’m also interested in writing programs for a computer. So, putting the two together, I have been researching the idea of programming education: how to teach others to write code. Not many people want to learn that, but those few that do likely need something better than what I had: BASIC and a lot of reading.

So now, in the fifth paragraph, we come to the real meat of the post. What is the best way to teach someone to program? Most importantly, which language should we use? I know all about Turing machines and how any language is equivalent to any other, but the question is relevant. Giving an aspiring coder something like Erlang (to take one example) isn’t really going to help anybody. People need a gentle introduction; they don’t need to be thrown into the deep end. So, with that in mind, I’m going to give my opinions on a few different languages that I’ve used (for real work or simply playing around) and their suitability as a first programming language.

Scratch (plus Alice and a bunch more)

Scratch, for those who don’t know, is a “graphical” programming language designed by MIT. It’s built specifically for education, especially for kids in the 8-12 range. Instead of writing code–or, indeed, writing anything–Scratch programs are made by dragging and dropping “code blocks” that contain things like numbers, text, and programming constructs. Not only does this make programming more colorful, it also makes it much less error-prone. After all, if you don’t have to type, you can’t make typos!

Scratch isn’t the only one of its kind in this respect. Stanford’s Alice environment, for example, was made for much the same reasons, and with many of the same goals. The building-block approach has also been ported to run on top of Java as StarLogoTNG (also made by MIT) and Google’s Android App Inventor (still in a closed beta, so I don’t really know much about it).

Pros: I’ll admit, building programs by putting together Lego-like blocks has its appeal. It’s fun, most of all. Scratch has done the most to make it look cool, but all of these “graphical programming” environments share this same sense of, well, wonder. More specifically, things like graphics and sound–two of the hardest coding jobs–are taken care of easily, and there is a sharing platform where you can upload your creations and download those of others. Although Scratch doesn’t support 3D, some of the others, like Alice, manage to make 3D graphics fit into the drag-and-drop scheme. To put it in as few words as possible: if all programming was like Scratch, everybody could be a programmer.

Cons: Building blocks have their limitations. Put simply, making a house out of Legos isn’t going to give you the same results as making one with wood and nails and all the other building supplies. Plus, Scratch, at least, has built-in limitations, like a complete absence of functions, something modern programmers in essentially every other language take for granted. To be fair, there are forks of Scratch (BYOB and Panther, to name the most popular) that add more complex features while still retaining the “block” idea, but these very additions make them not Scratch, which sort of defeats the purpose.

Processing

Processing isn’t so much a language as it is a concept. The original Processing platform was written in Java, and the language itself is essentially a Java wrapper. But people have ported it to other languages and platforms, including Python, Javascript, and Flash. Processing wasn’t really designed for education, but it’s simple enough to be used that way. Originally, though, it was intended for data visualization and similar uses, and it shows. (For example, the standard library is mostly made up of graphics functions.) Processing itself is a Java application that holds the language, compiler, and your scripts (called sketches, again showing the graphical heritage), though the “ports” like PyProcessing, Processing.js, or Processing.as are little more than modules or libraries for their respective languages.

Pros: Processing is Java. Since it’s Java, Processing runs pretty much everywhere. Also, even though there’s not much of a standard library (outside of graphics), you can still use quite a bit of the Java library. Other good things include a very easy-to-use animation framework (sketches are animated pretty much by default), both 2D and 3D graphics support, built-in sound and video libraries, and a general feel of “We want this to be easy enough that Fine Arts majors can use it.”

Cons: Processing is Java. I know, I listed that as a Pro, but it’s both. Processing is Java, which means that it brings in all the Java baggage: verbose code, slow startup, and (subjectively) the general uncomfortable feeling I get when writing Java. In addition, parts of the standard library are platform-specific, which is always a bad thing. Worse than that, though, is that some parts are platform-specific to Mac OSX. Some of you might think that’s a good thing, but for the 95% of us that don’t have a Mac, trust me, it’s not.

Javascript and Actionscript

Javascript and Actionscript are two different languages in the same way that American and British English are. They’re both dialects of ECMAScript (but of different versions), so they share a common ancestry. The main difference is that, strangely enough, the language that doesn’t have “Java” in the name (Actionscript) is the one that is more like Java. If you learn one, though, you’re halfway to learning the other. For Javascript, though, you’ll probably need to learn at least some HTML and CSS, as well.

Now, you know of both of these languages already. You can’t browse most web pages without Javascript, and Actionscript is the programming logic behind Flash, which is everywhere except the iPhone. Anybody can write Javascript, since you don’t even need to download anything: stick it in a web page, and open the page in your browser. Actionscript, on the other hand, has to be compiled, either by using the ($700) Flash IDE or the ($0) Flex SDK.

Pros: For Javascript, the main Pro is availability. If you can surf the web, you can probably run Javascript. The available libraries, like jQuery and Prototype, are also a big draw, as are the up and coming features of HTML5, like canvas tags and geolocation. On the Actionscript side, the main advantage is Flash. The IDE, the runtime, the standard library, all of it. If you’re using Flash, then a lot of the work is done for you. Even just using the free Flex SDK, you can still make use of Flixel, Box2D, ASWing, and countless other libraries.

Cons: Javascript’s biggest downside is that it has to run in browsers. Not a browser, but all browsers. And what Firefox does with Javascript is subtly different from what Chrome does, or Opera, or Safari, and nothing does things the same as Internet Explorer. Also, Javascript can get to be downright unreadable, even before using a “minifier” to lower download times. Actionscript, by contrast, has its major flaw not in running everywhere but in being restricted to one platform. It’s completely controlled by Adobe, and its programmers are at their whim. Also, Actionscript, like Java, can get baroque; you’ll have a lot of typing to do for even the smallest programs.

Python

Let me first say that Python is, right now, probably my favorite programming language of all. It’s what I do most of my coding in today, whether a quick script or a 10,000-line project. That said, even I won’t claim it’s perfect. I do think it’s a good teaching language, even with its flaws.

Python, of course, is one of the top 5 most popular programming languages right now. Google uses it, game developers use it, just about everybody uses it. Most important for our purposes, though, is that Python was originally intended to be a teaching language, but it became popular enough to use outside the classroom, and now has the same capabilities as any other “serious” language: graphics, databases, math libraries, etc.

Pros: More than Java and most other “big” languages, Python looks easy. This is a bit subjective, but there’s some objective truth in there. There’s a lot less punctuation, for one thing. The libraries are almost as big as Java’s, meaning that most of the things you want to do have already been done in some way. (Also, Pygame by itself deserves to be mentioned as a Pro here.) Python is supported on most platforms, too, though not quite as many as Java. Finally, for me, Python often matches the way I think. Maybe it’s because I’ve used it so much, or maybe it’s just made that way, but I can write “stream of consciousness” Python, which is something I can’t do with any other language. If anybody else has the same feeling, then I think that makes it a good teaching language.

Cons: The Python language is split right now. There are two versions: Python 2 and Python 3. The older version is more supported by libraries, but Python 3 is rapidly gaining ground. Personally, I feel that the old Python is better for writing programs (mostly because of the library support), but the newer Python might be better for learning to program. Furthermore, I would be remiss if I didn’t mention whitespace, since that is the standard argument against Python. Namely, blocks of code are denoted by how much indentation whitespace they have. I personally don’t mind the whitespace, since it helps visually organize code, but I can see why others are annoyed it. Finally, though it isn’t a mark against using Python to teach, it is very, very slow.

All the Rest

Those five–Scratch, Processing, Javascript, Actionscript, and Python–are my main favorites for a “teaching” programming language. But there are a number of others that people use, want to use, or have had to use. I’ll briefly look at some of them here.

Perl, PHP, and Ruby: These are three fairly close languages, at least based on looks alone. They all have great advantages: Perl has CPAN, which is every library you could ever want, and then some, while Ruby has the support of a rabid base of followers, as well as many web hosts, and PHP takes a little from both. As far as using them to teach, though, there are problems. Perl’s syntax is arcane to the point of absurdity (and the much-simplified Perl 6 is probably still years away from a full release). Ruby is slower even than Python, and is very rough around the edges; specifically, it seems like the more you get into “uncool” programming, the less help you get. PHP all but requires a web server, and in many cases is a textbook example of how not to do things. For education, I don’t think any of the three of them can match Python, but a more experienced programmer can use any or all of them to create something great.

Basic: It’s lost its all-capital look over the last 20 years–as well as its line numbers–but it’s still the same old BASIC at heart. Gone are the days when some form of BASIC was included with every computer, but there are still compilers and interpreters being made. Modern Basics (like FreeBASIC) really look much like any other language, but with fewer parentheses and more capital letters. They can still be good for teaching, but a lot of people continue to believe Dijkstra’s line about BASIC causing brain damage. (As any 90s programmer knows, only Visual Basic did that.)

Pascal: The original educational language still lingers here and there, but not the way it once was. Turbo Pascal was once the favorite of budding coders, but is now long gone. Even Delphi is dead, but it has risen again as the Lazarus project. Like modern Basics, modern Pascals try to turn something old into something new. Like any other fad from the 70s, it works for a while, then everybody that’s old enough remembers why they stopped listening to disco the first time. Although the new, modern features are interesting, Pascal is, like Basic, just too old-fashioned. We’ve learned more about how to teach since then, and we’ve moved on. (Amazingly enough, I still use one Delphi app every day: XNews.)

C and C++: Every list like this has to have a joke option, right? Seriously, although we all use millions of lines of C and C++ code every day, I would never dream of giving either language to someone as their first glimpse of programming. C is too low-level, and C++ is too much of…well, everything. They’re just too dangerous, like giving an 8-year-old a Ferrari instead of a go-kart.

C# and other .NET languages: I’ll admit that C#, at least when used with XNA, has a certain appeal. After all, it’s the only way an independent programmer can put something on a game console. And it’s actually a pretty good language, from what I’ve seen. It’s like Java, but without so much of the Java-ness that causes programmers to run away. But as far as teaching goes, I can’t recommend any of the .NET languages. Sure, they’re cross-platform, to both Windows and XBox! Mono and Moonlight are good ideas in theory but they suffer the same problems as WINE and any other “clone” project.

LISP, Scheme, Haskell, and many more: A lot of people like to start a computer science curriculum with one of these languages. I’m not one of them. Yes, the functional programming concept has its benefits, but it is such a departure from any intuitive notion of a program that I think it would be more likely to drive potential programmers away. Too many people already hate math, so showing them that programming is math is just a monumentally bad idea.

Conclusions

So, this big, huge post has had a lot of me babbling, and not much actual deciding. I still haven’t answered the question, “Which first programming language is the best?” To be brutally honest, there isn’t an answer, at least not one I can find. Everyone is different, and everyone has different needs. For a young person that wants to make the computer do things, a graphical programming environment like Scratch or Alice would be the best, if you don’t mind their limitations. Somebody that wants to make web pages would be better off with Javascript, but that is really like learning three languages. People that want to make a Flash game obviously have to use Actionscript (or something like HaXe, which is not much more than an Actionscript clone), but they’re not that bad off. If you don’t have any specific needs, and you’re an adult or a teenager, then I would personally suggest Python, along with either Pygame or Pyglet, the two major Python “game” libraries.

Last, but certainly not least, my suggestion to anyone wanting to learn a programming language is to do one better: learn the “art” of programming, the ideas shared by every language. Almost nobody uses Basic or Pascal anymore, and there’s essentially no new code written in COBOL or Fortran. A programming language is a fad, and coders are worse than teenage girls when it comes to fads. Don’t learn a language just because it’s popular now, because it might not be popular when you’re done.

No matter what you choose, what language, platform, ideology of programming, it’s the first step on a journey that can last the rest of your life. But as we all know, it’s all about the journey, not the destination.