The main car would need a cable for the full length of the building. The problem with cables (if I understand the article correctly) is not the infeasibility of the length, it's the weight that comes with it. The point of counterweights is to have roughly similar weights either side of the fulcrum (ie the winch), but when there's a lot of cable, the long end is going to be heavier than the short end. My point isn't to reduce the cable length of the main car, but just to compensate for the change of weight as the cable moves from one side of the winch to the other.

Only if you do a one-for-one mapping of instructions. The x86 can take advantage of more sophisticated opcodes (eg MULT) to cut down on the number of instructions and its general purpose registers to reduce Load and Store calls (with the associated address bytes). I'd expect x86 to be shorter, if programmed correctly....

Which is exactly his point. Even 16-bit x86 processors have more general-purpose register space than z80, so there should be fewer memory calls required. x86 has a more sophisticated instruction set (z80 has no multiplication instruction), so program the exact same algorithm in the two assemblers and you will get a smaller program in x86 than in z80.

No we're not. We're talking long-distance elevators. Or do you think someone will ever get to the top floor of a 1km high building if the car stops at every floor. Every time you're almost there, you'll have to stop for a pee break then wait for the car to come back.

Various skyscrapers have extremely high capacity lifts -- the Petronas Towers have double-decker lifts with a capacity of 52 passengers.

Yeah, but the lag on the satellite broadband suddenly drops away...

Actually, if you're building a tower that high anyway, you'd be just as well using it as a pseudo-satellite broadband provider -- the horizon is over 100 km away when you're a kilometre up. You can serve wireless internet to a small country from up there....

...or in the case of a building over the height of 1.6 km, the "Mile High Club".

You have failed me for the last time, Admiral.[Chokes Admiral Ozzel using the force.] You are in control now, Admiral Obvious.

The beauty of the current brake is that it engages immediately on failure, regardless of what the elevator is doing at the time. If the cable breaks, the car stops. If you rely on an acceleration fired mechanism, the car will have to start falling before the system knows to shut down, and that could lead to serious injury. Power failure is also only one failure mode -- the next issue is loss of traction. The current system has one mode of failure and a brake that is physically bound to it. There is no safety mechanism comparable.

Elevator brakes are one of the most elegant solutions known to man, and perhaps more crucial to the continued popularity of the cabled elevator. The brake is held open by spring tension generated by the interaction of the elevator and the cable. If the cable gets cut, the brake engages. That's it. Any other type of elevator would need a more complicated break system. Detection of fault conditions would be a separate action that triggers the brakes. That means delays, and the possibility of errors. It is practically impossible for a properly built cable elevator to plummet. You cannot say the same for any cableless concept design. One of the simplest ideas in legal liability is that if you opt to do something the more dangerous way, you're liable. You must have very good grounds to justify the risk.

Ah, rampant speculation -- I'm game. I'm wondering about the possibility of a three part lift -- a car with two independent cradles. The first cradle is cabled for a third of the height of the building, and is left behind when the lift goes above that point. The second cradle is cabled for two-thirds of the building, and disengages once the car ascends above two-thirds of the building. On descent, the car reaches the cradles again and continues down. Each of the cradles is counterweighted to provide a displacement load for the shifting weight of the cable. Each cradle would have its own independent brake (as would the car), which would add extra safety mechanisms to the lift

Now I'm also wondering if there's some way of using waste water from the upper floors as additional ballast, carried partway down the building alongside the counterweights before being released into the sewage system on a lower floor. Or maybe a partially-passive aircon using a liquid medium that is cooled by high-altitude winds before being shuttled to the centre of the building for circulation.

The current system is very simple, and very reliable. The car is suspended from the cable via the brake. The tension generated by the weight of the car disengages the brake (because even when going down, the car still accelerates at less than the rate of gravitational acceleration. If the cable fails, the tension vanishes instantly, and the brake is engaged. This mechanism works instantly, even if the car is at rest when the cable breaks. Your suggestion works when the mode of failure is power loss, but in a self-powered electric lift, the loss of power would be less of an issue than loss of traction. The safety mechanism would only be able to detect loss of traction when the car is in motion, which means losing vital seconds as the elevator gains momentum, and therefore will result in needing a more powerful brake. And that means adding in more powerful, heavier systems to hold the break open, as opposed to the current system which just uses the weight the elevator already has. So now you're shifting more bulk again.

And all that for what? To create a lift that is far, far less efficient than the current model, because as the GP AC said, elevators use counterbalancing weights so that the only work they're doing is in moving the contents of the elevator -- the lift car and the counterweights practically move themselves.

Because nobody has been bitten by a corgi on slashdot.

Although I'm starting to wonder if Prince Phillip is here, given the amount of casual racism arising in AC posts at the moment.

...because a multiple-gigabyte behemoth of an operating system on a multicore 64-bit CISC processor is just as easy to understand as a 16K rom chip in a computer with an 8-bit instruction set.

Do you know how many office-jockeys take VBA courses? Lots of them. Simple coding is a basic skill for many white-collar jobs now.

Indeed, but this is like bad spoken language teaching too. "What is the first-person singular subjunctive present suffix of third conjugation verbs?" may get the right answer, but the skill the learner really needs is to be able to say "I ask" in Latin. Any teaching that focuses on structure without meaning is hopelessly lost. The reason that coding should be considered a fundamental skill is that the alternative is to have a specialist class of coders who have no subject knowledge. How do you learn a language if you don't have anything to say?

There were a lot of computer concepts that didn't make sense to me until I found a real-world problem they modelled. I hated OO with a passion at university, because the examples and tasks we were given were contrived, rather than demonstrating a real-world need. As such, I think coding would be far better taught within the context of a content subject -- engineers have different problems from biologists, who have different problems from linguistics researchers. That also leads us down the road to declarative programming, because our beginners' programming skills courses are currently dominated by various fiddly technical details of the imperative language we're using that we have to deal with before we get to deal with our first problem.