Faster is both a characteristic of execution runtime, and time required for software development / maintenance. That development time has become a major important factor. Time to market. Beat competitors. Also programmer time is now vastly more expensive than hardware time. Just throw a few hundred gigabytes of RAM and a few racks of CPUs at it. This is still WAY cheaper than adding another programmer. (And more programmers add a certain drag factor on the development.)

But overall, with an outstanding GC, and with JIT compilers that are the work of over 15 years of research (see JVM), you can achieve excellent performance. (See elsewhere in this slashdot where I describes some of the amazing things the JVM does. Also Google for why organizations, like Twitter, switched to Java. It may seem counter intuitive, but the results are real.)

Yes, that!

Would you rather have your next whizbang software package one year sooner, but with let's say, 75% of the performance? Or would you rather wait an extra year (or more years) for a version that has somewhat faster execution? You can substitute any reasonable number for the 75%, like 50%, and this question might still get the same answer. Not only is software delivery faster, but less buggy. You can write bugs in high level languages, but you tend to write fewer of them because the abstractions are designed to protect you from certain classes of bugs. Structured programming to avoid GOTO spaghetti. Type checking. GC. Functional programming. Immutable variables. Immutable data structures. Automated reasoning. Logic programming. Computer Algebra Systems. Automated theorem provers. Etc. Pick whichever level of abstraction is suitable for your project. C is not perfect for everything, but it is simply wonderful for certain things. But that can be said for other languages as well.

Entire operating systems are written in C -- as they should be.

But C is a low level language. Not the best tool for writing applications.

Higher level languages and managed runtime systems have gained so much traction for a reason. They are very productive to use. They protect you from simple mistakes. The relieve the burden of memory management. GC simplifies library APIs by making the question of who should dispose of what become irrelevant. We could still be programming in assembly language instead of C. Why aren't we? Why aren't OSes written in assembly? Because C is more productive and higher level. Similarly, there are higher level languages than C, and they have their place. C is not the end all of abstraction.

So much fail about Garbage Collection.

GC is not about forgetting to free memory. It's about higher level abstraction removing the need for the programmer to do the bookkeeping that the machine can do. Why don't we still program in assembler? Because it's less productive. It's about productivity. As data structures become extremely complex, and get modified over time, keeping track of the ownership responsibility of who is supposed to dispose of what becomes difficult to impossible, and is the source of memory leak bugs. In complex enough programs, you end up re-inventing a poor GC when you could have used one that is the product of decades of research.

The article fails to understand that you can also run out of memory in a program using GC. Just keep allocating stuff without and keeping references to everything you allocate.

Reference Counting is not real GC. Cyclical data structures will never get freed using reference counting.

One of the major, but under-recognized benefits of GC, which the article fails to mention, is that GC allows much simpler ''contracts' in APIs. No longer is memory management part of the 'contract' of an API. It doesn't matter which library or function created an object, nobody needs to worry about who is responsible for disposing of that object. When nobody references the object any more, the GC can gobble it up.

On the subject of Virtual Machines, the article could mention some of the highly aggressive compilation techniques used in JIT compilers. So every method in Java is a virtual call. But a JIT compiler knows when there is only one subclass that implements a particular method and makes all calls to the method non-virtual. If another subclass is loaded (or dynamically created on the fly) the JIT can recompile all methods that call the method such that they are now virtual calls. Yet still, the JIT may be able to prove that certain calls are always and only to a specific subclass, and so they can be non-virtual.

The JIT compiler in JVM can aggressively inline small functions. But if a class gets reloaded on the fly such an the body of an inlined method changed, the JIT will know to recompile every other method that inlined the changed method. Based on the changes to the method, it may or may not now make sense to inline it -- so the decision on whether to inline the method can change based on actual need.

The HotSpot JVM dynamically profiles code and doesn't waste time and memory compiling methods that do not have any significant effect on the system's overall performance. The profiling can vary depending on factors that vary from system to system, and could not be predicted in advance when using a static compiler. The JIT compiler can compile your method using instructions that happen to exist on the current microprocessor at runtime -- something that could not be determined in advance with a static compiler.

All of this may seem very complex. But it's why big Java systems run so darn fast. Not very many languages can have tens or even hundreds of gigabytes (yes GB) of heap with GC pause times of 10 ms. Yes, it may need six times the amount of memory, but for the overall benefits of speed, the cost of memory is cheap.

Copyright enforcement and due process seem to be mutually exclusive.

You could even say copyright enforcement is mutually exclusive with justice and proportionality.

Look, crimes actually CAN be committed using computers.

Don't believe me? Just ask anyone who has been hit over the head with a computer.

If we pay you to spy on our citizens, because we're not allowed to do it ourselves, then will you pay us to spy on your citizens because you cannot do that yourself?

It's good for the global economy because money changes hands. (Nevermind that no actual goods or benefits to society are procduced.)

Everyone is happy. (Nevermind citizens in the global police state.)

They can be open about it because the citizens no longer have any recourse against them. Voting? Don't make me { laugh | cry }.

Lenovo is a Chinese maker.

And they are offering these at low prices -- in the developing world -- because nobody in the western world wants this Windows 8 crap.

It's not the size of your screen, it's how you use it.

But I guess that line is only said by people with small screens.

They have to firesale those devices in developing countries. In the US, the EPA isn't going to let them just bury them in a big hole in the ground. The Windows 8 software might leak into the soil causing a massive ecological disaster.

And Microsoft seems to just love, and perhaps even encourage this particular confusion. In fact their poor branding would seem to have been deliberately designed to cause confusion leading to people buying an RT device and then discovering that it doesn't really run Windows apps. It only runs the tiny library of Windows 8 RT apps.

Your own argument about western culture arriving slightly delayed in the developing world should have caused you to conclude that the developing would would think something like:
1. If westerners aren't buying this Windows 8 crap, then why are they sending it to us?
2. If westerners are using non-Windows tablets, then we should be too (but perhaps just a bit delayed)

Yes, it's hammer time. For Microsoft. And it's about time.

> And yet, they are still making gobs of money. In fact, they are more profitable than ever.

I remember in the late 1970's when IBM people were laughing at these 'toy' microcomputers. HA HA! Those toys will never be like real computers. Certainly not a threat to IBM which is making gobs of money. In fact, IBM is more profitable than ever.

IBM introduced a PC in 1981. Thinking they might sell up to two million. By the mid 1990's IBM had lost the PC market, abandoned the PS/2 attempt to re-monopolize it, and eventually got out of the PC business completely. Before the end of the 1990's IBM had re-invented itself. Think the same thing won't happen to Microsoft? You may be too young to remember, but in the 1980's, even by the late 1980's it was completely laughable to even consider that IBM might find itself on hard times. But it happened. And just a few years ago it was laughable to suggest that Microsoft might lose its industry dominance. Not so much laughable anymore.


> Moves like this don't really help anything.. not even the bottom line, since the massive cuts crush morale and limit the ability of the company to innovate to keep ahead of the competition.

Moves far more radical than this may be the only way Microsoft stays around in the long term. We'll see what Microsoft looks like in a decade.

You lack faith in Microsoft, sir.

Windows 8 is going wonderful! Everyone loves the new UI. That is why Windows 9 will never bring back the Start menu. Just watch, you'll see!

PC Sales are not being affected by the new mobile device trend. Microsoft will dominate mobile devices and phones any day now! You'll see!

Oh, and some day Microsoft will make a dent in data centers, and Microsoft Azure Cloud will become important. Of course, Azure Cloud is the only cloud service that was built for Windows instead of Linux workloads. And Windows is used by some large* computing cluster users, um, somewhere. And businesses using Linux workloads would be happy to trust their business built on Linux to Microsoft, a company that to this very day is working to destroy Linux.

(*and by large, I mean much larger scale than you are thinking if you are thinking of Windows)