This is playing off of this post on Reddit: http://www.reddit.com/r/netsec/comments/7u9mx/hey_reddit_think_its_easy_to_link_an_online/

The joke of course is that my name is plastered all over this website and the web in general. I was planning on donating to the EFF anyway (and, hey, so should you.) But it got me thinking about identity online. (more…)

I posted this Python cheat sheet before in my PyBat post, but several people found it useful so I wanted to give it it’s own post for emphasis.

And if you just want to see some simple samples of Python code, you can always look at the example programs from my free book for non-programmers, Invent Your Own Computer Games with Python (released under a Creative Commons license).

Code reviews are the single biggest thing you can do to improve the quality of your code, as Jeff Atwood says. Code reviews force you to show your code and justify your design decisions to someone else, and the extra set of trained eyes can reduce a large number of costly defects. But how can you be sure that your code reviews are as effective as many claim them to be? (more…)

“The time for jacking around with Tesla coils and ball lighting in the garage is over.”
-From the sci-fi movie, Primer

Many people get into software development because it’s fun. They start programming or web applications or how to get the computer to do interesting things, and the learning begins to grow from there. It’s also a well-paying career, so many people make the transition from hobbyist to professional.

But the job usually isn’t as fun as the hobby, for reasons that are already stated in your average Dilbert comic strip. As such, many software developers continue to do their own side projects in their spare time (at least, developers who chose their career from their preexisting interest, instead of choosing their career as an alternative to accounting or dentistry.) Much of the open source movement is powered by this phenomena: the collective work of developers who have an itch to scratch and a desire to share their creations.

But if you look at many of these projects, most of them aren’t anything new or groundbreaking. Most of them are reworkings of already existing pieces of software, perhaps written in another language or for a different platform. I call these projects “building Tesla coils in the garage”; they are fun and cool and braggable, but ultimately nothing new and not very practical.
(more…)

How should we teach programming?

One of Shimon Schocken’s colleagues says that “Computer science is a thousand layers of abstraction.” This is quite true, and the same applies for programming.

Recently I’ve been thinking a lot about how we can get more people involved with programming. I don’t necessarily mean programming as professionals, but just to develop enough of an understanding on what software is and how it works. So I wrote a book aimed at teaching games programming in Python to the 9 to 12 year age range (get ‘em while they’re young). In my “Python is the new BASIC” post, (which was a plug for my free, Creative Commons-licensed book, “Invent Your Own Computer Games with Python”) I received this comment:

You know, I took a look at that game book and it struck me how so 1980s the thing was. It brought me down to memory lane.

Now, looking at the alternative (Squeak), which is fully OOP all the way down to the very menus and icons, buttons, which has a much richer environment and is totally ready for multimedia, along with the derived (written in Squeak) Scratch language, I think it’s very bad that we’re returning to Basic.

Kids deserve something better in 2008, and we can deliver it, just as long as we keep our prejudice at bay against Smalltalk (because it really is about prejudice and lack of information).

1980s would be right. I based the book I wrote on a 1983 book that taught me BASIC programming (adding Python’s modern features). However, my book specifically avoids higher-level concepts such as object-oriented progamming, event-driven applications, and graphics. I thought these concepts would hide the actual underlying workings of the programs. By using textual input and output from simple raw_input() calls and print statements, my book could focus on variables, expressions, and flow control. I wanted as little “magic” as possible.

“Programming is a thousand layers of abstractions.” I’ll argue that to really understand software, one has to go down this rabbit hole all the way to the bottom, as far as assembly or machine language. But one doesn’t need to understand assembly (arguably the lowest of the programming abstraction layers) in order to actually write useful software, even professionally. And for the purpose of teaching programming, those layers of abstractions save us a lot of tedious details. The key to teaching programming is to find that ideal middle ground: low enough to pull back the “automagic” curtain, high enough to stay above minutia.

My book aims low. There are already several high-level game engine SDKs and drag-and-drop game creator packages to make programming easy (well, easier). I would lose the appeal of graphics, animation, and sprites, and instead rely on text and ASCII art. I would use function calls and loops, a level below recursion and callbacks but above dread goto statements. The high-level space already has lots of ink or bytes devoted to it already, so I aimed low.

(more…)