I think for many of us who grew up on home computers, Assembler was our first language; and we used it to write games and demos on C64 and Amiga's. Things don't get any simpler than assembly language (few concepts and a very finite set of instructions) and it's great for getting a gradual but very deep understanding for what a computer is and how it works. We did it in 68K and it was the ideal set-up for growing into higher-level languages (as it showed you what a higher level language is trying to help you with.) The problem with learning a higher level language first is you'll be too easily intimidated by lower-level concepts (pointers, call-stacks, hardware interfaces or just the way things are laid out in memory) and avoid those things for the rest of your career - I'm sure we've all seen the type of 'professional' programmer I'm talking about.

Having said that, the amount of shit ("work") you need to wade through to get anything done these days in assembler means it's no longer an option; definitely not for a "from-scratch" type of program, and definitely not for getting quick experimental results; so it's today pointless for teaching a kid how to code as he'll get bored before anything exciting happens (unlike the Amiga days when the code to get some copper bars going would fit on your screen.)

I would definitely not suggest you're a PHB, you sound like a good team leader. It is however very rare for a group of people to all have the same opinion; which is exactly why a 360 is so damn interesting.

Work up your courage and do an anonymous 360; you'll be surprised. I'm assuming the team you're managing is of a meaningful size (eg. 15-20) the diversity of comments you get back is amazing and educational. People tend to have diverse needs from their superiors but face to face you usually get mostly smiley faces.

Gave me some new insights, so I bought Venkatesh Rao a coffee (link at the bottom of the article.)

Interesting how easy it is to classify (former) colleagues as sociopath, clueless or loser, yet how this gets harder to do on ourselves.

Actually in some countries there's a good financial reason for getting a Prius; eg. in NL there is a 40% tax (called BPM, it's in addition to about 20% VAT) for every car sold. This tax is waived on the Prius and, needless to say, makes a huge difference in price.

Now if only we could convince goverments that optimal aerodynamics "save the planet", we'd be getting somewhere....

That admittedly is pretty cool - but IBM has (last time I checked) 320,000 employees; so would you agree the point I'm trying to make still holds?

Parent is absolutely right, and this is true of many large companies today. Within IBM, there is too much focus on saving a dollar and doing things on the cheap, while missing the bigger picture and becoming ever distant to one's customers through intertwined cogs and wheels of process bureaucracy. There is a very strong innovative drive by doing your development in regions that have strong universities, a culture for innovation and local use and appreciation of the end product. Where that is depends on what you're doing. For cars, southern germany, for the web, california, for finance NYC and London.

However, by outsourcing everything to China and India, you loose that innovative drive, which erodes your longer term growth.

This is fine in only two cases I think, A) you don't care about the innovation of what you're developing (it's not your core business), or B) the type of work you're doing is extremely expensive *and* specialized (eg. chip design & manufacturing,) making it hard for an upstart to compete with you, even if your work is sloppy.

IBM rarely innovates anymore aside from some of its hardware, I'm not aware of any genuine software innovations from IBM in, say, the last 10 years.

The way large companies seem to be doing it now is by acquiring their way into innovation. I'm happy they do, because it makes startups that more valuable to do. Perhaps if large companies are changing their game, we engineers should wake up and adapt ours.. do more startups?

I must be amazingly stupid because I rather like Apple products.

Proprietary extensions are done for (arguably) the same reason by Microsoft; the goal should instead be to work on better iterations of language standards (C/C++) and not on introducing arbitrary language extensions that are not portable across compilers - especially not really extremely awkward ones like 'anonymous function pointers.' There's a similar argument to be made for 'encouraging' developers to use C# and Objective C.

The problem with multi-threading isn't in laborious API's, it's also not in language support for nifty features. The problem with multi-threading is that some problems are damn hard to multi-thread, either due to algorithms, or more commonly due to the way the internal structures are linked together. This will only make overconfident developers shoot themselves in the foot more quickly (and provide some vendor lock-in for apple as things get increasingly less portable.)

I'm going to have to disagree a bit here.

The issue with raytracing is memory access patterns; this is not so much an issue with GPUs vs CPUs, but rather that both CPUs and GPUs rely on linear prefetch patterns through memory, which raytracing breaks as you traverse the spatial subdivision structure.

Secondly, ray tracers scale very well with resolution O(n) where n = number of pixels; we currently still have a relatively high constant cost, but assuming moore's law keeps up in performance and we find an answer to the memory problem, it is superior.

What makes the move to raytracing somewhat an inevitability, however, is not raytracings ability to very straightforwardly do more sophisticated lighting (many of which can be mimicked in awkward ways), but its ability to scale to massive amounts of geometry; eg. when using octrees, we're looking at O(log(n)) for n primitives - this is better than GPU rasterizing hardware where it is O(n).

The one critical failure of raytracing - and the reason it is hard to do games - is that to get to O(log(n)) you (currently) have to have static geometry - it cannot animate dynamically in realtime as you need to rebuild the spatial subdivision structure for the animated geometry on a frame by frame basis, and that gets expensive..

Perhaps some kind of mix will ultimately be used, but the geometry benefits of raytracing do still make the technology inevitable.

Having said that, Larrabee will be a stillborn for the first reason outlined.

Any sufficiently advanced technology is indistinguishable from magic; however you'll see these types of things pop up more and more.

Things to google for if you want to implement this yourself:

- "Point Matching" - when given two frames, which points are matching?

- "Five Point Relative Pose Problem" - this helps correlate camera motion from frame to frame when given 5 matching 2D points

- RANSAC - this helps filter out those matches that correspond to different moving objects - you'll burn through a lot of 5 point combinations and eventually the majority winner stays on.

Where I hope this area of technology goes is in the development of highly efficient HD codecs; I personally can't wait!