Death notice: Moore's Law. 19 April 1965 – 2 January 2018

Seriously, outside of Android, smart cards and the mentally insane, the JVM is kinda dead.

"If you asked someone to build a bridge, and the result was constructed out of twine and empty kitchen roll holders, even if it was demonstrably able to cope with the weight you'd still be wary of using it."

Unless, of course, you were in a hurry, which unfortunately is the standard state of most businesses these days: get there before the competition does. Doing it fast is more important than doing it right because missing a deadline is obvious; you can fast talk your way out of something wrong most of the time.

"The slowdown happened because the IT industry has grown far faster than the ability to train competent software engineers."

To say nothing of the ability to find candidates capable of becoming software engineers. However there's the equivalent of Moores Law at work here. You just add more cheaper, part trained, not necessarily talented engineers.

The slowdown happened because the IT industry has grown far faster than the ability to train competent software engineers.

Or to put it another way: "Competent software engineers have repeatedly failed to deliver on their promises to create tools that would put the great majority of computing tasks within reach of any reasonably educated layperson."

PERMANENT SLOW MOTION REPLAY ?

At the age of 74, I was born slightly too early for the digital age. I can still remember seeing those giant spools of computer tape spinning in massive cabinets in the background on the TV show: "The Man From Uncle." And apparently, when the Americans first went to the moon when I was 25, the memory of the on board computer systems was about a tenth of what is now in a smart phone.

However, I'm fascinated by all things IT wise even if I'm not up to speed with all the subjects discussed by the very highly qualified experts on this site. But the analogy you've given is spot on and I can't believe that this problem wasn't anticipated years ago. If I've got it right, then even if hundreds of thousands of software engineers, programmers etc were trained up to the degree required, it would take years before any difference was noted. And because of this deficit, all things IT are going to be relatively sluggish from now on.

Trevor.

P.S. Does this also mean that 'A.I.' will come grinding to a halt and so we can all sleep sounder now that super advanced Androids won't take over mankind after all.

Don't understand people who keep on about Java being 'slow' (whatever that means...). It's nonsense and anyone with half a brain knows that.

It actually was comparatively slow 15 or 20 years ago. The issues were solved quite some time ago, but the reputation remains. It also probably doesn't help that there are a lot of inexperienced programmers using Java to write poorly optimized applications because it's the language used in most intro to programming courses. You wouldn't think many of those programs would be in the wild, but they are.

Re: so Desperation

RIP Microsft!

I, for one, welcome our new Erlang/OTP overlords.

Re: It would seem that code will need to be tighter

Instead of bloatware and throw big tin at it, how about actually learning how to write good code?

But we've been saying that ever since MS brought us the "Too slow? buy a new machine. Uses too much memory? Buy more!" mantra in the mid 90's.

And nothing ever happened, until 'almost-smart' phones became available, and suddenly everyone was concerned with lean, efficient programming. Then phones became more powerful, and once again, that philosophy died.

Same will happen this time around. Lowest-common-denominator programmers and techniques will still be employed - "You just need to but a more expensive machine! More cores, more Mhz!"

"As memory increased, these skills withered and atrophied."

In the world of desktop/mobile/web coding, perhaps. The world of low-cost embedded coding still heavily relies on people understanding how to wring every last drop of performance out of the processor - in my near 2 decades in the business the most powerful processor I've ever used had 256KB of flash and 64KB of SRAM, and at the other end of spectrum I've also written firmware for a processor with 1KB of flash and no SRAM, just a handful of general purpose registers. Bloody good fun, and I get paid quite nicely for doing it too :-)

programmers learned to make neat and optimised code to work within the constraints. As memory increased, these skills withered and atrophied.

That isn't quite true. I don't deny that there are plenty of people lacking skills today, but there were good reasons for reducing that optimization. It was routine in those days to pack nybbles together for both inputs/outputs because you could fit two into a byte. This saved space, but it had consequences when it came to writing clear code, and debugging it.

One of the horrible habits that arose out of that era was mixing an error condition with the return value. so you'd check for the error (often -1) otherwise treat the return normally. It's so routine you still see that today, and it's awful compared to something like:

if (!getch(&ch)) { handle_error(); }

in which you separate the error from the return value, and are more likely to realize that there IS an error possibility.

"...Back in the 8-bit days of 64kB of RAM and no HDD, programmers learned to make neat and optimised code to work within the constraints. As memory increased, these skills withered and atrophied..."

I remember reading an article back in the day about the guy who was tasked with converting Sim City from the Amiga to the humble BBC.

Apparently, there was one routine in the Amiga that used considerably more memory than was wholly available on the Beeb.

And yet (apart from graphically of course), he pretty much nailed it with a like-for-like reproduction.

At college I had to learn to program in assembly - in hex - on "development boards" with <8KB RAM so it was imperative that anything you tried to do was neat.

Mind you I was never very good at it myself but some of the others there had a natural gift for it that was staggering.

My guess is the compiled code is still relatively small, but that 339MB is assets ( high res images, "Welcome to Kindle" videos, etc )