Stirring up some interest for the Austin Game Crash course

We’ve started announcing the Game Crash bootcamp due on February 18th in Austin, and we’re finding there’s quite a lot of interest out there! Here are some selected reactions and questions:

“I’m very interested, in fact I’m just a few clicks away from signing up, but I wanted to check and see if the cost of the hotel is included in the course registration fee, or if we have to make our own arrangements. Thanks!”

Read the rest of this entry »

Gamecrash: new hyper-intensive game development boot camps

I am happy to announce that I have joined forces with the awesome Jean-Paul Boodhoo, of Develop with Passion fame, and we are going to start offering a revolutionary new type of crash-course on games development. Combining his concept of highly-intensive one-week bootcamps, and my game development and teaching skills, we are going to start offering extremely high value courses for general developers to gain all the core game development skills as quickly as humanly possible.

The focus will be on combining a strong grasp of the fundamentals of games development with a highly practical approach. The goal is that developers with no previous experience in games or graphics programming will come to the course on Monday at 9am with all the motivation and energy, we will turn on the turbo and work for 12+ hours a day until Friday, and they will be leaving having learned and actually applied all the main elements of game programming on Friday evening, with a simple but nice and working game under their belt (it’s best if you bring your own graphics!), and with all the necessary core skills to develop your own games personally or professionally!

We’ve decided to work using OpenGL, basic C without pointers, and work on 2D games, so that any reasonably proficient general developer can become productive as a games developer in one week. You will need to be ready to put in all the necessary effort and energy, but if you know your way around variables, loops and functions, you will be developing games by the end of the course!

The first course will be starting on Monday February 18 in Austin, Texas, and it will last until Friday, February 23. This first edition of the course is offered at a discounted pricing for Develop with Passion courses, so take advantage of being an early adopter! We plan to offer the same course in other cities in the US, Canada and Europe. If you’d be interested in having this in your area, let us know and we’ll try to address that.

You can see JP’s announcement here, all the Gamecrash course details and contents here, and you can see the Eventbrite event page with the location and pricing details and the sign-up options here, and I will be happy to respond by email to any question you may have. We will be posting more details over the coming weeks. Be sure to sign up if you want to turbo-boost your game development skills. See you in Austin!

Is your compiler throwing onions in the varnish?

In a by now well-known anecdote, Primo Levi, an Italian chemist-become-writer from the early twentieth century, was reviewing how varnish was produced in an industrial facility. The recipe, involving many chemical components, included instructions to throw in a raw, peeled onion in the varnish. This was puzzling to him: he couldn’t figure out why the onion could be needed, or even how such a small amount of material could affect the resulting varnish. Nobody he asked at the factory knew why it was needed. Seemingly, it had been done like that forever.

Intrigued, he researched where this came from, and after some heavy digging, he discovered the reason: in earlier times, when varnish was produced in a less industrialized fashion, varnish-makers would throw in the onion, they would look at it, and when it become brown from being fried, they’d know the varnish was in the right temperature for the next step. When the production system had gained thermometers and automation, someone had just kept on throwing the onion out of habit, and thus it had become an ingredient of the varnish.


As an example of a modern varnish recipe, let’s have a look at the canonical MAX function: let’s see how you would find the maximum out of a list of numbers in any modern imperative language:

This loop finds the maximum value in the input array and returns it.

And you may ask, what is the problem with the above code? Isn’t it just pretty conventional code to walk an array and extract some information from it? Isn’t that how programming is supposed to be done?

Read the rest of this entry »

The undecidability of the halting problem is not very important

Many a programmer, when confronted with a difficult computational problem, claim that it doesn’t make sense to investigate it further, since it is just a special case of the halting problem, and as proved by Turing back in the day, this is just not solvable in the general case. But I will try to show tha this is not a very useful or smart way of looking at things.

There are two important and opposite approaches that show the little utility of this thought process. They are two distinct attacks to the same area, both demostrably valid, and I hope to make them both easy to understand in this blog post.

The first issue involves the fact that, even if something is not tractable in the fully general case, it doesn’t mean there are not many useful cases where it’s not only perfectly tractable, but also well worth doing it. Let’s take static code analysis for example. Here is a nice piece of C code to find the maximum value in an array of unsigned integers:

This code has a subtle but important bug: it will just never terminate. It’s actually an infinite loop. Why? Because the loop counter is not incremented. There is a typo, we missed a “+” sign in the “++i” expression, and thus the expression meant to increment the counter does nothing. Thus, the loop counter will stay at zero, and the code will loop until the sun goes nova.

Read the rest of this entry »

The HOW and the WHAT

No, a low-level programming language is not defined by being closer to the metal. And high-level programming is not defined for being closer to English. Heck, BASIC was probably the closest to English, and you’d be hard pressed to defend that it’s higher-level than Haskell. Which is probably as difficult to understand for a native English speaker as any real programming language can get, with the sole exception of APL.

Anyway, indeed, some of those things are true. But they are only secondary attributes. They are like the fact that vi allows you to do much more in less keystrokes than any other editor: the core reason is that vi was designed to work over 300 baud phone lines, and this involved, among many other things, reducing keystrokes – but this was not the goal, but a side-effect.

Lower-level programming languages are created first, higher-level programming languages are created afterwards, in order to make programmers’ lives less painful. You know, programming is in some aspects very similar to being tortured: you have to keep dozens (if not hundreds) of things in mind while you write every line of code. And if you forget any of them, you write a bug – and you don’t know right away. Back in the day when the web wasn’t gobbling up all other platforms like The Nothing in Michael Ende’s The Neverending Story, you used C++ and the compiler would punish you with a basic warning or error for most cases, which is similar to getting a little pinch. Nowadays, it’s Javascript or Python, and you will be punished for the bug with a crash in front of your user or customer, which makes the minimum torture threshold more similar to getting a nail torn out.

Read the rest of this entry »

Why is people’s code so bad? Even after getting a degree in CompSci?

I’m fixing code written by some quite junior programmers. I’m always amazed at the code people write. Only in these moments I really see what good code is about. When you read or write good code, it just seems the obvious thing to do, and no big deal.

Principle #1: if one small piece of code is repeated, and it would be wrong if you changed it in one place but not the other, then THE CODE IS BAD! You have to REWRITE it. Just so that you can’t change things in one place and not in the other(s)! It’s that simple.

The simplest case, and one I STILL see too often is numeric constants. You are adjusting some things (say, things in a UI layout done programmatically). You change it in one place, run the program, and it doesn’t work. Or you do something non-direct (like rotating the screen and then going back to the original place), and things break up. You check it, and the position is set in two places, to a numeric constant, and you had only changed it in one place!

The solution is obvious: have a #define at the top giving the right name to the value, and use the constant name in both places. In Java, you can just use some “private final static int” or so. Whatever your languages buys you, but there’s certainly a way (or switch languages, pronto!).

I had this idea that if someone indents code wrong, you should stop looking at it, because the rest will be wrong too. If a developer can’t get indentation right, it’s impossible they’ll get conceptual consistency right. I’m expanding on this idea now: if someone repeats small non-independent pieces of code or numeric constants, instead of refactoring to some simple function or definition, then I won’t bother with it (unless totally unavoidable).

May you never break the DRY principle: Dont Repeat Yourself. I have a theory that every good development practice boils down to just a circumstancial version of this principle. There is one practice that doesn’t fit the bill, so that’s why I’m withholding from sharing until I can really prove the elegance. I can boil all down to “WRITE HONEST CODE”, but that just isn’t so catchy.

Live hard, pivot hard

From my days as a games developer for PC, PlayStation 2 and Xbox (classic), about 10 years ago, I remember reading some interesting advice from the famous game designer Peter Molyneux, which may come handy now in the world of startups.

See, when creating video games, one of the most important elements to giving players a compelling experience is to reach the correct balance. All the different parameters in the game have to be just right: difficulty, rewards, comparative power of the different options available to players, etc…  it’s really hard to get this right, and a significant part of the development process must be devoted to getting this right. Game developers and designers who can do this well outshine the competition.

In thist context, the advice from Peter Molyneux was something like this: “When you are balancing a game, don’t do small adjustments. They take you nowhere, and you can’t really even know if you are on the right path. If you need to increase the cost of some element in the game, do not add or remove 10%, make it double or half.”

This stroke me back then as genius advice, and it came from someone who really knew what he was doing. It has stuck around in my memory since then, and in twisted comeback, it has resonated with me lately, as it is quite applicable to our situation in our start-up. Let me explain.

Read the rest of this entry »

Quick reflections on yesterday’s post

I really enjoyed the conversations resulting from publishing “I want to fix programming“, and I’ve come to a few quick conclusions I want to share:

  • It’s great to have so much intelligent feedback, both on Hacker News and on the post itself. Very smart and knowledgeable people, some of them having explored the same area. Lots of insights. Lots of pointers to interesting projects. Proposals for approaches to get somewhere. I’m really happy to have brought this up in the open. There are a few “haters” there too, but I guess it’s the price of being out there – and this is key to getting the invaluable feedback from other people!
  • Raganwald suggested that just the notation could be useful. Invaluable advice. Maybe that should be the first goal. Still, I plan to publish the full series with my progresses so far before really getting down to work, so this is some time away. Also, Raganwald is probably the only person who uses github as a blogging platform.
  • Gruseom suggested the great idea that restricting things to a given problem space could be a great way to get somewhere practical.
  • There is interest out there. Many people are (more than reasonably) skeptical, but many other people would love to see some advance in this area and are happy to contribute ideas, etc… this is great.

I do not have an academic background, and I sure lack some or many of the necessary skills. But I’ve done my homework, or at least a lot of it. I have insights and approaches that can add some value. I may be able to contribute a “general sketch” that can help in building a practical tool. But in any case, attempting this here in the open and without any commercial interest can be the best way to advance!

Now, since we are launching a new startup and product later today, please excuse me from this topic and I’ll get back to posting on this topic in a few days. Thanks for all your comments.

I want to fix programming

(The SB series, part 1 of 7)

Programming is broken. Completely broken. The very way we write code today is just so broken that it makes you want to puke. I’ve been saying for years that I hate programming. I am and have been a fulltime developer for over 20 years, I don’t regret it, and I still love what you can do with programming. Still, I hate programming.

The way code is written is just braindead. At each step of the process, you can crash the program, be it by filling up all available memory, accessing a stray pointer or reference, or entering an infinite loop. No doubt programming feels like walking barefeet in a floor filled with broken glass. One tiny inch out of the right place, and bang, you nearly lose one of your toes.

Every step of the way, in every statement, line of code, function call or sequence-point, if you want to write good code, you need to think about all the different possible states of the whole program. This is invisible and impossible to define. Provably. Always. In all existing languages. That’s the reason 100% code-coverage unit-testing doesn’t guarantee bug-free code, and it never will. This is also the reason bad programmers don’t become good: they just can’t think about all those possible cases in a structured way.

(By the way, this only gets about a thousand times worse with multithreaded code – so it’s not getting better, it’s getting worse.)

The problem is that the fundamental way that code is written is wrong. It’s just wrong. You write a bunch of instructions, step by step, which supposedly result in a given wanted state. But each step is separate from all others, it is only understood by the compiler/interpreter separately, and it’s almost easier to screw things up than to get them right.

Read the rest of this entry »

Starting a new blog

I have reflections to share. Stuff I’ve been mulling over for the past few years. Let’s see if I can share these matters in a way you can get some value from what I write. I’ll be happy to host, read and respond to your comments. Mistakenly, I’ve done too much one-way communication in my life. It’s now the time to try and get some two-way communication rolling.