You cannot wait patiently for 3 days to download 8 GB?

Then you should not be on Comcast / Time-Warner.

It's not just the JVM. It's the fact that Java (and all JVM languages) have Garbage Collection.

When people (even in this Slashdot comments) talk about non-GC languages and compare then to GC languages such as Java, they are missing something important.

I have seen comments here comparing the language features, and concepts computer science students learn from either C or Java, etc. But they miss something very important.

When you have GC, you have something that deeply enables the ability to create vast libraries of code that interoperate well together. It is something so deeply implied in the source and binary ABI and APIs that you don't see it. Because of GC, there doesn't need to be any 'contract' in APIs about who owns what data structures. Who is responsible to delete what. What the protocols are for who is responsible for disposing of what, etc.

This cannot be overstated. This enables the creation of libraries that can create, or be passed external data structures, and can create and return data structures, without any concern for who owns what or who is responsible for disposing of what.

This is true whether the language is Java, Python, Ruby, etc, etc, etc. The GC languages are in an entirely different class than C or C++. Yes, I know that those languages have GC grafted on. But which GC mechanism? Do all of your libraries support it? Universally? What about some libraries use this memory management protocol and contract (maybe even non GC), and other libraries use a different memory management protocol and discipline?

The JVM does some pretty amazing things. It has some pretty amazing optimizations. You can run a lot of languages on the JVM.

Most modern languages now take garbage collection for granted. If you build your new language on the JVM, you get GC for free. And a GC that has been researched, developed and optimized for almost two decades. You get a choice of GC algorithms. Each GC has many tuning parameters. (More than you need.)

You're right. It's not Java that is cool. It's the JVM.

The JVM compiles the JVM bytecode to machine code. On the fly. It continuously dynamically profiles your code to determine what needs to be compiled to native code. It aggressively inlines functions. Even though all methods are virtual functions, if the JVM can prove that there is only one implementation that exists for this method, or only one implementation that could be the actual one that would be invoked at a certain point, then it compiles it as a direct non-virtual call.

But, classes can be dynamically reloaded during runtime. So other code that inlined methods from the class being reloaded now has inlined code that is obsolete! The JVM will ensure that those methods are recompiled (possibly re-inlining, or not) the code from the newly loaded class. And it will ensure that this recompile happens before the stale inlined code can be executed again.

All of this is cross platform. Because your code is compiled by a compiler that knows about the actual hardware you are running on, it can do optimizations that are impossible in an ahead-of-time compiler like C. It can use extended instructions from the instruction set of the actual processor you are using. Furthermore, since it knows the entire set of code making up the application, it can do global optimizations that are also impossible with ahead of time compilers. An ahead of time compiler doesn't know anything about the implementation of the libraries that your program will link against at runtime. If the compiler knew about the actual implementation of the libraries that your application code was calling, there are optimization opportunities that an ahead of time compiler cannot make assumptions about.

With the JVM you can have heaps that are tens of gigabytes (or hundreds with some third party JVM implementations) and have max GC pause times in the tens of milliseconds.

That is what makes 'java' cool. It's the JVM. It's also the JVM that makes Java so darned fast. Not the Java language itself. Nor the Java compiler to JVM bytecode. The JVM has a unique perfect storm of amazing features that make it so attractive.

How can Apple retain total, maniacal control by giving up some control?

While I personally like to deeply understand the languages I program in, I don't think it should be necessary for an average programmer to have to understand the entire language specification in order to use the language.

If you can't just grab some code online and expect it to work on your compiler, then this is a major design fail in the language.

I can understand a language having unspecified aspects, poorly specified aspects, or things that are well specified to act in a compiler defined manner. However those should be extremely obscure features that an average programmer, and average code would never use.

Even better, don't have any compiler dependent behavior in a language. Compiler extensions should be okay -- and they, by design, should cause a compile time error on a different compiler -- or alternately have a way of being ignored so you can stack compiler specific blocks together in a single source file. Although having a source file that only supports a specific list of compilers also seems like a bad idea.

I'm glad it is not an issue in the languages I use.

Yes, I should have put a smiley. And as another poster points out, I should not have put the semicolons. But It's been awhile since I used C / C++.

> We don't need sub-sets of languages. We _already_ have those when programmers don't use all the complicated and over-engineered parts of C++.

We don't need sub-sets of languages. We already have them when compilers don't fully implement the entire language. (Rewind to mind 1990's.)

There are optimizations you can use to improve your experience with C and C++.

Just insert these into your header files for both time and space improvements in your compiled code.

#define struct union; // uses less memory
#define while if; // makes code run faster

Now how can you say bad things about a language that is so easily improved?

> . . . all of this passion only exists because people are using ${SOMETHING}.

I feel passionate about SCO (in a strongly negative way), but not because they are important, popular, or their products widely used. I feel passionate about Clojure (in a positive way) despite that it is not presently one of the top programming languages. How many people use something can be irrelevant to the legitimate reasons people feel passionately about it.

How do you feel about the fact that Darl McBride said that SCO owns C++?

Source 1
Source 2
Source 3
Source 4

Blaming Snowden for NSA abuses is like blaming Al Gore for Global Warming.

It is shooting the messenger.

If that messenger didn't tell us, some other messenger would have sooner or later. It was inevitable.

People only keep secrets (like global warming) when they feel it is their patriotic duty to do so for love of country. When they see widespread abuse, contrary to the values of a democracy, little or no oversight, and their peers feel the same way, it is inevitable that somebody is going to blow the whistle about global warming. If it hadn't been Snowden, it would have been someone else, eventually. This was never going to stay secret forever.

The Mayans had predicted that we would run out of IPv4 addresses in 2012 -- and they were right.

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.