Slashdot Mirror
Java Named Top Programming Language of 2015 (dice.com)
Nerval's Lobster writes: What was the most popular programming language of 2015? According to the people behind the TIOBE Index, Java took that coveted spot, winning out over C, Python, PHP, and other languages. "At first sight, it might seem surprising that an old language like Java wins this award," read TIOBE's note accompanying the list. "Especially if you take into consideration that Java won the same award exactly 10 years ago." Yet Java remains essential not only for businesses, it continued, but also consumer-centric markets such as mobile development (i.e., Google Android). That being said, even big languages can tumble. (Dice link) Objective-C tumbled from third place to 18th in the past 12 months, thanks to Apple's decision to replace it with Swift. In 2016, TIOBE expects that "Java, PHP (with the new 7 release), JavaScript and Swift will be the top 10 winners for 2016. Scala might gain a permanent top 20 position, whereas Rust, Clojure, Julia and TypeScript will also move up considerably in the chart."
What has been your most-used (or best-loved) programming language of the last 12 months?
As it is most unsuccessful. C++ and Scheme are where you want to be. Ideally your C++ program should use Scheme as an extension, or your Scheme should be implemented in C++.
As TFS points out: ANDROID. That's why Java is #1. We're still stuck with this shithole as long as Android continues to dominate mobile and they continue to focus almost exclusively on Java.
Hardly anybody is a "rabid fan" of Java. It's a mature, full-featured language with a healthy (perhaps leading) ecosystem of APIs, tools, developers, and training materials, that is considerably faster compared to scripting languages in many situations. This is reality, not fandom.
Wheels on my car do the job and have improved a lot. However, it's a bit disappointing that there isn't something new in 2015.
(Actually not that enamored of Java, but just feel like 'not new' should not be some automatic disappointment in a technology).
XML is like violence. If it doesn't solve the problem, use more.
Java is the new Cobol.
On the good side, it's a general purpose language so can do anything.
On the down side, it's a general purpose language so is bad at everything.
James was at Google very briefly many years ago, but he wasn't a good fit for their culture so left quickly. More likely influences on decision to use Java were Eric Schmidt or Wayne Rosing, or even Tim Lindholm. All were intimately involved in Java at Sun and were probably favorably inclined toward the language.
But then again, none of you give a rat's ass about actual knowledge of the situation and people involved so I'll just shut up now.
It won because it's the best programming language. You can go cry to your mama about that if you want.
Democracy Now! - your daily, uncensored, corporate-free
Most Java "fans" I know are considerably less "rabid" than devotees of more trendy languages (I'm looking at you, Ruby). Just my experience.
From a project management perspective Java is a pretty safe choice for a new project. On long projects people come and go - I can find replacement Java programmers in short order. As much as I love clojure, I would never do a large project with it at work because it's too difficult (and expensive) to find competent lispers.
Sure, Perl writes terse programs... but to me, valid Perl code is indistinguishable from line noise!
They don't have to be terse / line noise and mine aren't. I learned that lesson a long time ago when I looked at some code I had written a few years prior and thought WTF does that do? All my code, regardless of language, is pretty well documented and structured, especially when I *have* do something weird or *want* to do something extra concise. I have a pretty consistent and logical style - which I think is important - to all my code and, in fact, many co-workers can tell it's mine just from looking at it.
In short, one can write good and bad code in (almost) *any* language.
It must have been something you assimilated. . . .
I hate Java but is a hardcore fan. Why? Because it's the language that sucks the least. Slow and buggy "native" runtime gets replaced by Bytecode in my systems as fast as I can manage.
There are lots of people spewing shit on Java every time it's mentioned but not a single person I've talked to can point out a single disadvantage with choosing Java.
Yeah in time there will probably be something better. I even have designs that many developers would prefer over Java. But until there are something available that can create as stable, fast and easy to debug executables as Java while providing at least as productive development environment...
As for .NET it was unavailable for the hardware Google where targeting and still has to many bugs to be stable. And when it comes to servers and desktops same things... come back when it works as well as Java on SPARC/Solaris and various IBM platforms. To name a few targets most developers have to support.
And when it comes to anything that doesn't JIT code. That increases development, deployment and maintenance costs. C++ binaries are to slow compared to C++ because SSE and other advanced CPU features they don't support. Yeah most code doesn't get recompiled with modern compiler's and redeployed. Bytecode however does. Therefore the average deployed Java code is way faster.
And that even gets worse because native code optimized for old processor's may actually be a lot slower than non-optimized code.
And when it comes to Android nothing beats Dalviks performance. Native code is super slow because it use more memory and OpenJVM can't run on android-supported hardware. Yeah that doesn't apply to my Samsung S3. But guess what, early android phone didn't have a fraction of that hardware. So to all of those saying that Dalvik was a bad choice, find some original Android phone and prove that you can make anything faster.
So yeah I don't like Java at all. But people saying that it sucks without providing me with an alternative doesn't help me switch to another language.
The attitude in the summary is just stupid. "Surprising that an old language"... but then ignoring that C is in second place. And really there have not been great languages coming out after Java and no realistic replacements for C. Sure, there are scripting languages but that's a different niche. Not everything that runs programs is on the Web or a PC.
The new programming paradigm that Java excels at is to stop programming and just tie together existing frameworks and libraries like it's one giant lego monolith. Of course somewhere someone has to write the stuff in those libraries; which is more Java and if you get low level enough it's C.
Python replaces some of this but comes with it's own headache (gotta make sure your customers can run it and are configured with the right versions, etc. C# has many problems and is a clumsy hybrid, and also never really caught on outside of the OSX/iOS/NeXT worlds. C++ is stuck in the middle, not quite being as easy as Java and too much feature creep to replace C. Swift is too new, not very portable, etc.
What really happens is that people have a language that works, so stick with it. Why through out ten years worth of code base just because there's something newer? An utter waste of time. The vast majority of commercial programmers never start writing code from scratch but instead are fixing bugs or adding features to an existing product.
Correct. It is possible to write good java code and it does encourage inefficient practices. This stands in contrast to C++ which makes it rather difficult to write good code (assuming similar algorithms and data structures in both programs), but strongly discourages or even prevents things that cause sloth-like performance. By "good code" here I mean code that is secure and doesn't crash. Complex C++ codebases are invariably riddled with various kinds of exploitable overflows or code paths that trigger segfaults that tear down the entire process. It's especially unfair that Java got a bad rap for security partly due to bugs in the C++ code in the JVM!
That said ..... things are changing. There are actually high frequency trading firms that use Java, believe it or not. Some of the things they make the JVM do are quite impressive. Java's poor perceived performance on the desktop has historically come from several areas. To name just 4:
1) Excessive memory usage leading to swap hell. Garbage collection doesn't play nice with swapping either, due to lack of the right kernel support. A big offender here is the profligate use of pointers and especially inefficient representations of strings (always UTF-16). Also, garbage collectors that were tuned to look good in benchmarks by using larger and larger heaps didn't help.
2) Poorly optimised graphics stacks. Note that if you use Linux you suffered from this very badly because you probably got OpenJDK which used an open source but much slower 2D rendering system, vs the proprietary Sun/Oracle JRE which used a proprietary but much faster licensed renderer called Ductus.
3) Older JVMs weren't well optimised and did things that made them start slowly, like storing all their code as .class files inside zip files. Also, JVMs are huge downloads.
4) Java code has historically not had access to things like vector instructions, advanced data layout and inline assembly, all of which can be exploited to give huge performance gains in things like multimedia apps.
All of these things are being tackled quite energetically by the JVM team, however. The latest JVM can now do things like deduplicate strings in the heap, and in Java 9 (in development version) there's new code that switches the character encoding of strings between Unicode and non-Unicode depending on what's needed at the time. This change is especially impressive because it not only reduces memory usage but actually makes software go faster too due to better cache utilisation and less GC pressure. There's a long term project called Valhalla to upgrade the JVM with value types, which is where C++ gets a lot of its built-in advantage from, by giving the developer better control over data layout. There's also a project called Panama which is adding support for, amongst other things, inline assembly to Java. A prototype was recently posted to the OpenJDK lists. A new open source graphics rasteriser has been built that's faster than Ductus, so even the open source only OpenJDK users will soon have faster graphics, and a new UI toolkit to replace Swing has been developed called JavaFX. It uses hardware accelerated graphics everywhere via OpenGL and DirectX.
Also, Intel have been contributing much more advanced auto-vectorisation logic to the JVM's compilers, the Jigsaw and "minimal JVM" projects are allowing developers to statically link optimised JVMs with their app which then pre-process JARs into special file formats so the loading process is much faster, and there's also work on ahead of time compilation being done to get rid of the slowness at startup before the JITC has compiled all the code.
These are all projects that are either shipped already or in development now. The JVM guys do understand the causes of Java's slowness, they just aren't willing to sacrifice the convenience and robustness the platform offers developers in order to fix things. So, quite often, they find they have to develop new technology and do new research to find ways to have their cake and eat it.