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.
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".
If you confuse easy to read with easy to understand, you aren't a skilled programmer.
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.
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