Slashdot Mirror
The Reason For Java's Staying Power: It's Easy To Read
jfruh writes: Java made its public debut twenty years ago today, and despite a sometimes bumpy history that features its parent company being absorbed by Oracle, it's still widely used. Mark Reinhold, chief architect for the Oracle's Java platform group, offers one explanation for its continuing popularity: it's easy for humans to understand it at a glance. "It is pretty easy to read Java code and figure out what it means. There aren't a lot of obscure gotchas in the language ... Most of the cost of maintaining any body of code over time is in maintenance, not in initial creation."
Solving problems can be done quite quickly with Java as a lot of the frameworks/tooling for solving common problems have already been built. Including:
- Distributed Configuration
- MapReduce
- Spark
- Large portion of the NS math libraries have been ported (think of all the Fortran libraries)
- Networking
- Embedded devices
- First-class support for many app hosts
- Concurrency libraries (including standard)
- World-class web application serving (Jersey, DropWizard, etc.)
These are things that are proven and enterprise ready with large communities supporting them.
Not as easy to read as Python though
And that's a good thing.
A huge standard library that has been stable for 20 years (backward compatible as much as humanly possible) has a lot to do with it as well.
In other languages, I feel like I have to re-learn basic elements every decade to "how it's done now"...
Your mindset is exactly what causes problems with other languages. What you expect isn't readability but a higher power density. If you push this too far, you get too much implicit functionality, and that makes code difficult to read, because you can no longer understand what's going on if you're not familiar with all the idioms.
There are fundamental differences between a stream and a string (hence the existence of separate classes), so something has to give if you want to use a stream where a string is expected. If you make this implicit, then someone who doesn't know the semantics first has to realize that there is something implicit going on, and probably look up what it is, while in Java the conversion is explicit. Java isn't "surprising".
final T up = (T) throwable;
throw up;
I'll see your senator, and I'll raise you two judges.
If you confuse easy to read with easy to understand, you aren't a skilled programmer.
Give him a break, he's been programming in java for 15+ years.
A cylindrical reference is like a circular reference, except it happens when your code is three dimensional.
I think you prove the author's point. Where the fuck is your pascal snippet reading from? How does it abstract bytes to characters? Why is there only an input with no output? Is `read` taking an integer and doing something with it? How is data getting out? In the java snippet, everything is laid out. You're reading from standard in. You're line buffering (with default encoding, but that's fine when reading from STDIN and not a file. Usually). You're reading exactly 1 line, then parsing that line for an int value. It's extremely explicit what's going on and has no magic. The whole passing in an outvalue thing that C and Pascal do is an AWFUL KLUDGE OF A DESIGN. It makes code harder to read and harder to understand.
You'd think that the industrial strength JVM might also have something to do with it.
You can have a JVM with a heap of tens of Gigabytes and with a modestly tuned (not extremely tuned) configuration, have Garbage Collection times in the tens of milliseconds. If you need hundreds of Gigabytes in your heap, Azul can sell you a JVM that can do this with GC pauses of about 10 ms.
The JVM dynamically compiles the bytecode down to native code. Not like a C compiler does ahead of time. But it compiles it for the actual processor and features that your hardware has. The JVM compiler aggressively inlines methods instead of making function calls. So there is no drawback to writing lots of small methods. Even tiny methods like getters and setters. You can dynamically reload a class binary at runtime. But what if the new class has a new implementation of a method that some other foobar method had inlined by the compiler? No problem. The JVM knows this and it de-optimizes the class that had the foobar method so that it no longer has inlined a 'stale' version of the code in the class that was just now dynamically reloaded. If dynamic profiling reveals that the foobar method truly is a hotspot for the cpu, then the JVM will again compile it to native code -- based on the now current conditions of what code is in the overall system. It's like having a global -O 5 optimizer that can dynamically change / recompile any or every thing based on any code changes dynamically made to the running system. Want to change from a carburetor to caffeine injection while driving down the road at 70 mph? No problem.
Call me when a dynamic language or other system can do that.
Is it any wonder that so many languages other than Java also run on the JVM? The JVM might even stick around longer than the Java language.
The JVM and Java run on the smallest systems to big iron. The SIM card in your phone is a tiny self contained secure tamper proof computer -- running Java. It verifies certificates using a private key that was forged inside the SIM and never leaves the SIM. Your Blue Ray player runs Java. You can write a Java program that provides the 'menu interface' for your disk. Old flip phones from 2000 run Java.
I'll see your senator, and I'll raise you two judges.
Agreed.
The whole "convention over configuration" theme is maddening, because if you don't know the conventions - or haven't figured out the new conventions that a particular project uses to drive execution and data flow, you're going to be lost. What is gained in brevity is added cost on the maintenance side. I once spent 2 days helping someone troubleshoot a currency formatting issue on a RoR app; someone had created a mixin to extend a base string class method, in a file describing a service. Fixing the code took all of 5 minutes, but finding it took forever.
With Java, it's worse now than it used to be. A decade ago, your major threat to readability was someone with pattern prejudice; those who ended up encapsulating everything in a factory-factory to factory to interface to abstract to etc, etc, etc, making every data object change require changes to 5-10 files just to surface the changes to the end methods using it, just for the sake of doing it.
Today you've got stuff like Spring. Ever try to do a manual, non-runtime code analysis of a project of decent size that heavily uses Spring, even where it's not necessary (like interfaces that will only ever have a single implementation)? Or worse, have you guys seen the OSGi development model? Let me put it this way; imagine using the original J2EE bean model, with home and remote interfaces and all that, only we've decided to use CORBA as our architectural focus. So every method can be a dependency-injected service-provided module, ready for you to call the service factory and grab an instance of the feature you want, which incidentally makes static analysis of code by humans more or less impossible.
Yes, I understand the concepts for these features, and OSGi actually has some neat capabilities (that we've had since the mid 90's via similarly laborious mechanisms like CORBA or more often, DCOM), but they do detract heavily from both the readability and maintainability of the code. If a new developer can't determine the execution or data flow for a given scenario in a few minutes, it's going to be onerous for them to maintain the system. That pain for the benefit of what we all know is the patent myth of polymorphism; that every project is going to have a need for unplanned sibling code modules in the future - it doesn't seem like a good trade off to me.
I've started to really appreciate code that I can use tools - often just the 'find in files' feature of an IDE - to trace through execution and data flow. It's becoming less and less common, and sourcing and correcting bugs is taking up more and more of my time because of that rarity. I sometimes look back on 'tricky' C code that uses/abuses pointer arithmetic and requires complex memory management, and I feel wistful for when it was that simple, that you could know what the code was actually doing. .. aww crud. I'm like a few years away from complaining about those darn kids on my lawn, aren't I?
Actually, it's easy to read because it is verbose and inexpressive as you put it. Generally speaking, the more information you pack into a sequence of characters, the harder it is to understand. There are also relatively few syntactic constructions to get your head around and tokens are not usually overloaded with different meanings. It doesn't take long to learn the whole language, which means that even a newbie has a good chance of reading a piece of code without coming across something they haven't seen before.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe