Basic is a good language for learning programming. It allows you to focus on core mechanics (flow control, predication, logic, arithmetic, loops, recursiveness, etc) without focusing on higher level language concepts. As long as a program remains small (which is the point here), GOTOs are fine.

Higher level languages can be more confusing to kids. Objects, factories, inheritance and all that stuff is easier for adult minds to comprehend since their idea is modeled after real world concepts, but kids don't have those concepts fully absorbed yet (or at all) anyway.

In fact, what I've observed is that kids don't have too much trouble with assembly either. It's low level, simple and repetitive. You have "boxes" you put stuff in, operations you do on them, etc. As long as you don't get into the more exotic instruction sets, you're fine. And sure, and all address based operations might be a little complex.

That's why I actually find basic quite good as a learning language. A kid who starts learning about programming concepts at 8-10 years old has a chance at becoming a very strong programmer later on. I have seen it many times. So basic is a really good idea. In fact, I've used basic256 for one of my kids.

Don't snob the language. You want something barebones. It's the computer science concepts they get exposed to at an early age that are important. Writing a "guess my number" or "guess my animal" game is a great growing exercise.

Cheers,
Alban

Programming the SPUs is super interesting, and you need a cell for that. The GPU on the ps3 is not even that interesting. But the SPUs are. Writing for SPUs is a great programming exercise. It sucks if that capability goes away.

There is something to be said about knowing the structure of your codebase. I already see intellisense users jumping around and editing code from locations they have no idea about, this will be even worse. It really pays off to understand the file/directory/package structure of your codebase, as opposed to jumping to unknown locations, making an edit and bailing out. Intellisense/ctags are great when they extend your knowledge of the codebase, but they shouldn't be a substitute for having some amount of awareness.

Code reviews are somewhat useful for small changes. But I find that for large changes, they are TOO LATE. If someone has gone forward and made non significant changes to your software, and you happen to catch his misconceptions during the code review (dependencies he shouldn't have pulled in, improper encapsulation, volatile and frequent usage of memory, etc), he won't be able to just "address" your concerns with a few changes. He basically has to scratch most of his work. And unfortunately, few managers will see the benefit of "implementing something" better since that requires more time, and the feature as implemented "works".

Likewise, when the software design is done too long before the actual task gets to the implementation phase, the design may be out of touch by the time you get there because new constraints and problems have been discovered since the design phase.

That's why I like to have quick whiteboard sessions before someone starts implementing something. I like to know the dependencies their module will pull in, the services it will require, I want to make sure the module is kept as ignorant as possible in terms of what it knows about the rest of the system, etc. When those things are caught early on, is it almost free to correct them. But later, there is a cost. If the task is long, I like to see multiple snapshots along the way to again course correct anything before it gets too far down the road.

I work at a large video game company. I don't believe things always were the way they are now, but right now everything is tasked against "features" and it is hard for most managers to understand the necessity of infrastructure work, of unit tests, of proper module encapuslation and definition of dependencies (otherwise you find your unit tests impossible to write using your module's public interface). Every sees the short term. It is easy for them to understand that something is done when they see it in the game. But it is harder for them to understand that you want to make the process of software development more predictable, you don't want half the features in the game to be broken half the time and the shipping product to just be an instant snapshot of working features that will break as soon as the next cycle starts.

So, code reviews are useful, but they really aren't the most useful thing since they occur TOO LATE.