Actually, young folk do tend to see hacking as a perfect good coding style. It's the grey heads in the universities that keep beating the drum for better practices, and they're occasionally joined by seasoned devs who just get sick of the utter slackness of current coding practice.

But he isn't talking about user software -- he's talking about programming languages. He's pointing out what every university computer science department has been saying for decades: there are vastly better ways of programming that have been researched and developed, and no-one's using them because they're unwilling to leave decades-old programming design behind. Design decisions that were a practical compromise made when memory was measured in kilobytes and compilers didn't have the grunt to optimise. Right now, programmers are going through a painstaking process of telling the computer each and every step to take and in what order, and the compiler is increasingly ignoring them, because it can easily refactor the code to be more efficient. We spend half our lives working out how to code up trivial little bits of code that are required for the "big idea" to work.

Now while this is not about incompatibility in the user space, in the end it does indeed have a knock-on effect. Userspace incompatibility arises when the source of the previous version is so hacked-up, patched and kludged that the coder of the new version can't see how it works. Not understanding the source code means he can't replicate the behaviour. The sort of good practice my uni lecturers always went on about would eliminate the problem. In current architectures, though, it would take too long and be too expensive... which is why we need architectures based around those good practices, actively promoting them.

This premise is correct.

But...

...your conclusion is wrong. With massive hard drives, we can in fact have our cake and eat it. Any modern compiler is a tiny piece of code compared to the average project built with the same compiler, so there is no reason we can't have a compatibility mode. Have a look at the first line of any shell script -- it tells you what shell it needs. A Bash script can call a Korn shell script, which can call a C shell script, which can in turn call a Bash shell script, and all without any knowing what goes on inside the others. They can do this because they are all built on the same typing system and function call system.

We could apply this principle to programming languages: when a new version will not compile the previous version's code, you don't want a whole new compiler -- instead you keep the old one alongside a modified version of it. If a file header identifies it as v 1.53, compile it with the latest compiler for version 1. If another file in the same project is v 2.04, compile it with the latest compiler for version 2. All you need to do is keep the type system and function calling backwards compatible, and the two will happily communicate. No code is broken. Old code stays as old code until and unless the update is needed, and new code can be written in the new way.

Of course, the change to the object model between Python 2.x and 3.x means that this wouldn't work with Python, but that's only because Guido chose not to develop it that way.

True, but the AC was conflating "C++isms" with "OOP". That's like looking at one country with a malfunctioning parliament and declaring democracy a bad idea.

It's in the deleted scenes on the special edition Bluray.

There is a huge difference between "crash landing" and "being hit by an anti-aircraft missile". You might as well complain that being forced to wear a seatbelt is a waste of time because it doesn't protect against IEDs in Fallujah.

There are more factors to it than that. If going rag-doll means having your head battered off two seats, that's a problem. Going limp presumably only reduces damage to muscles and tendons.....

Most crashes occur during landing and takeoff, and there are good odds of at least some survivors. Crashes that occur mid-flight are far less likely to have survivors, but that's not the type of crash this article is interested in.

Repeating the GP:

If there is a problem, they want you to hear. If you don't know you're about to crash, you might not brace. Ouch.

However, your book does not have a sheet of glass on it. In the event of a crash, it isn't likely to pose a great threat. The bulk of the book isn't much of a problem either, in that it will probably fly around with the pages spread open as it is launched across the cabin (well, you were reading it, weren't you?) An iPhone, on the other hand, is a very dense piece of kit, and even if the glass doesn't break in such a way as to pose a threat, it will be like being hit by a rock.

But can they hold it above their heads for a while, making relatively finely controlled movements?

Well... yes, that's basically what it is. But it is still an exoskeleton, as it has solid load-bearing elements outside of the body. I'd love to see a video myself, but I also trust a company like Lockheed Martin when they say it is designed for mobility. The tech has existed to create semi-mobile ones for a looong time now, but it's never been an attractive proposition. People have been working on this stuff for decades, so I'd say that they've probably done most of what they claim.

Nothing in the article says that the arm is innovative. The arm is a product that has been available for some time. The "added linkages that can transfer the weight of the harness to the ground" is the product. It's an idea that people have been trying for for decades, and now finally they can make the structure stable and usable. That's the news. Saying this is nothing new is like saying the moon landings were nothing new because people had already been up in space, and landing on the moon was just "adding a few maneouvers" to a normal spaceflight.

The arm you see is already in use, and yes, it operates on the same principle as the steady-cam rig. Steadicam transfers all the weight to the hips which protects the operator's spine and to aid dexterity by reducing the load on the arm muscles, but the legs still have to carry the weight (most steadicam operators are shadowed by a colleague and as soon as the director shouts "cut", the colleague takes the camera off them and puts it down for them). The logical next step was to built a structure that transfers the weight to the ground without using the operators' legs. This has been an active field of research for as long as exoskeletons have been under research. The problem used to be resistance in the joints being too high (unless the joint was too weak to take the load), so they tried looking at low-power models rather than zero power, but they weren't happy with the results. Essentially, the idea was just waiting for manufacturing technology to reach the point where the required joints and bearings could be produced.

I'm curious as to whether this is a noisy or silent solution -- if it's quiet enough, expect to hear of Hollywood picking them up to keep their steadicam operators running longer between breaks....

It sounds like what you're looking for is... object oriented programming!

Seriously, the problem with OOP is bad teaching, which leads to bad implementation. I never understood OOP until I found a task that was best modelled in it (and none of the tasks I was presented at uni were). But more to the point, everyone forgets the principle of Smalltalk -- OOP as "message passing". You weren't supposed to be thinking of calling code (which can arbitrary) but of sending messages to other "agents". Does it make sense for me to change someone's clothes? Not really -- I should be asking them to do it. When you're thinking in terms of what is a reasonable message to send, you naturally restrict the interface. When you think in terms of "calling code", you tend to favour flexibility without considering what purpose it serves.