Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×

Comment Re:Basic? are you killing future competition? (Score 1) 215

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.



Wii 2 Delay Is Hurting Nintendo 310

BanjoTed writes "Michael Pachter's ongoing spat with Nintendo regarding the Wii 2 is well documented. Pachter is sure it's coming, Nintendo says it's not. Now the analyst has gone one further by claiming that the declining sales of the Wii documented in the platform holder's recent financial statements will only get worse unless it speeds up attempts to get its successor to market. He said, 'The reason for this is clear: the software being created is just not interesting enough or compelling enough to drive Wii owners to buy more than two [games] per year, and most of those purchases are first party software. We can blame the third party publishers for making shovelware, or for misjudging the Wii market, but the simple fact is that the publishers have to develop completely separate games for the Wii because its CPU is not powerful.'"

Comment codebase awareness (Score 1) 198

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.

Comment code reviews are too late (Score 1) 345

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.

6 Curses = 1 Hexahex