Dude, they're not talking about drug tests where your employer wants to check if you're high on crack cocaine.

They're talking about drug tests where a new experimental drug needs to be tested, first on mice and then humans, to see if it's safe enough for FDA approval.

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.

I don't know any Comcast customer who has had a positive experience with their customer service. I also know some who've had Comcast blatantly disregard the details of their contract with respect to price and features a few months into a 12-24 month contract. Frankly, what Comcast needs besides competition from more companies and municipal broadband (via utilities) is a few strategic arrests of employees and executives for fraud. Put a few of their guys in prison for fraudulent business practices, and I'll wager their billing and sales people will wake the f#$% up and do right.

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.

cos the factory makes cars that run on 1.21 gigawatts at 80mph.

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.

Google got the message and Samsung killed most of their Tizen team and went back to focusing on Android.

They killed their engineers? Can't Google just call their bluff now?

>Haven't Android and iOS completely cornered the market?

Yes.

>Is there any hope for the likes of Tizen,

No.

>Firefox OS,

No.

>and Windows

Yes.

My Nexus 5 thinks you don't know what you're talking about; it works just fine on T-Mobile, AT&T and Sprint. Get with the times, man; it's ALL ball bearings now!

But probably not many. Slashdot admins could run a query to see; that would be vaguely interesting, but I've seen comments from several people who say they're using the site under a newer login than their original.

Our problem is that we have given a generation of attention-deficient gadgeteers who think that a reader-edited encyclopedia was a good idea public forums to spew their gerontophobic bias.

If only tablets had on-screen keyboards or supported Bluetooth keyboards or keyboard docks! Those poor students with tablets! They're unable to do anything but watch Netflix!

This sort of commentary just sounds stupid. Even if you want to make a point that tablets don't have good native input solutions don't go full hyperbole. All you're doing is reducing the impact of the point you're trying to make.

In the real non-hyperbolic world tablets are perfectly capable of being typed upon. I would even suggest tablets (especially higher end ones like iPads, Nexuses, and Galaxy Notes) can be more capable than laptops in some situations when given to students.

It's entirely possible for a kid and with iPad to produce their own podcast or video presentation for a class. They've got an audio recorder, video camera, and still camera in their hands. There's also plenty of apps that let them splice all of that together into something coherent and interesting. They can also use that same device to type up a more traditional report.

The idea of kids putting together multimedia presentations has been around for a long time but the technology to do so has really sucked. It's either been overly complicated or vastly underpowered. There's room for both traditional written reports as well as multimedia projects. Having devices that can handle all of them is a good investment.