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."

Comments

Yes & the sheer amount of existing code/framew

[Anonymous Coward]

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.

"Easy to read" is non-sense

[Anonymous Coward]

I am tired of hearing languages are "easy to read". If a piece of code is well written and identifiers are well named anyone who is accustomed to the syntax or syntax that is SIMILAR will be able to read it. The point is that C style syntax have been what the majority of programmers have been used to so it has become a staple. However, if it was down to pure logic and an understanding of the English language Ada, Pascal, and (Visual) Basic would be the most readable.. and who here thinks that -- we've all been brainwashed by CS101.

Re:"Easy to read" is non-sense

[jfdavis668]

His point is that it doesn't contain strange syntax that isn't easy to follow at first glance. One of the original purposes of Java was to eliminate the complexity of C++ has from its C legacy. When you use a command in Java, it does what its supposed to do. They are not using it as some obscure purpose to take advantage of some quirk in the hardware. Java did this by defining its own hardware of sorts, the JVM. It moves the complexity of the actual system to a group of programmers who specialize in that arena, the JVM developers. It's not that all Java is readable, we maintain one system we inherited that was developed by a poorly trained group of developers. The names of classes provide no help in understanding the code. One of the main classes is "M". They also put things together in classes that have nothing to do with each other. We are re-developing that system from scratch to fix it. Even with this, there are no commands in the system that we don't understand when we read them.

Re:"Easy to read" is non-sense

[jareth-0205]

I am tired of hearing languages are "easy to read". If a piece of code is well written and identifiers are well named anyone who is accustomed to the syntax or syntax that is SIMILAR will be able to read it. The point is that C style syntax have been what the majority of programmers have been used to so it has become a staple. However, if it was down to pure logic and an understanding of the English language Ada, Pascal, and (Visual) Basic would be the most readable.. and who here thinks that -- we've all been brainwashed by CS101.

Clearly a language can be easy or hard to read - Or do you think well-written Brainfuck is easy to read? Since programs are written by actual flawed humans who make stupid mistakes or have weird style preferences sometimes, it's generally a good idea to have a language syntax that doesn't let them shoot themselves in the foot.

Re:"Easy to read" is non-sense

[Giant Electronic Bra]

Right, but I would argue it extends far past easy to read. Java is easy to grasp. It is very clear which method will be invoked when you make a method call. It is very clear what the lifecycle of a memory allocation is and there's no question about who is responsible for managing that chunk of memory, etc. Its just VASTLY easy to code in Java. Now, the development tools/environment may not be as simple as scripting languages, which tends to push untrained 'do-it-yourselfers' into things like PHP where they can see some results on day one, but for the organization which has real business needs and develops code to meet them, Java is an excellent choice because in all respects its clear what things do and how they work. I can look at virtually any piece of decently-written Java code and understand it. At the very least I won't find out that it does something totally different than it appears, which is COMMON in C++.

Re:"Easy to read" is non-sense

[Capt.Albatross]

If a piece of code is well written...

This is not an article about what is possible, it is about what actually happens. I have seen incredible abuses of operator overloading, for example. I have also seen some highly confused Java, but its pedestrian syntax seems to make it a little harder to write cryptic bad code in.

Corollary: It's difficult to be "clever" in Java

[Anonymous Coward]

And that's a good thing.

verbose enough to be easy to read

[antiperimetaparalogo]

Yes, while verbose, i find Java easy to read - and i think its verbosity helps in this (after a while you know what/how to read Java code, and your reading becomes "smooth").

Stability

[Anonymous Coward]

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"...

Verbosity is easy?

[DJ Rubbie]

Really? Having a pile of needless verbosity makes it more difficult to read in the long run simply because one needs to figure out what exactly is being done even for the most trivial client application. To do even just simple fetch of some resource over HTTP requires rather laborious conversion routine from a stream to a string type before most common JSON libraries would be able to use it. In any more modern language it can simply be used right away rather than having to figure out which JSON libraries to use or why toString() doesn't seem to work on InputStream (I mean intuitively shouldn't toString() on a stream get back a string?).

Granted the Apache commons can make this a bit easier, I find it extremely annoying to have to cast things into the right object type just to access some simple JSON object, instead of just doing something like result['collections']['links'][0] which is much easier to understand. Dumbing things down does not necessary make better programmers.

Re:Verbosity is easy?

[Anonymous Coward]

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".

Re:Verbosity is easy?

[quietwalker]

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?

Yeah right. Then explain COBOL.

[gatkinso]

That's what I thought.

It was purely serendipity, and now the install base is so large you can;t get rid of it.

Re:Not easiest to read, but forgiving...

[invid]

A problem with Java and C# is that it is possible to create memory leaks in those languages, but since people rely so much on garbage collection they don't think about it and get bit in the ass. Event handlers shared across processes are particularly dangerous.

Re:Easy to read?

[Dog-Cow]

If you confuse easy to read with easy to understand, you aren't a skilled programmer.

Re:You must be joking

[Anonymous Coward]

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.

Re:Not as easy to read as Python though

[Marginal Coward]

I agree: that seems to be the thing that Python does better than any other language, IMO. That also points out a fallacy of the premise in TFS: it doesn't really make sense to attribute the success or failure of a given language to any single factor. Instead, programmers evaluate each on a combination of factors, and each has strengths and weaknesses compared to others. Therefore, each language fits into different areas, and a language thrives and prospers according to how many such areas there are and how important those areas become.

IIRC, the original strength of Java was supposed to be "write once, run anywhere." I think it was the first language to feature that as the primary selling point, though others have followed. It's surprising that its primary initial selling point would now be eclipsed (tee-hee) by supposedly being "easy to read" - especially since that could be said about several other languages, depending on one's personal preferences in that regard.

Re:Corollary: It's difficult to be "clever" in Jav

[firewrought]

It's difficult to be "clever" in Java

To the contrary, Java's lack of expressiveness resulted in people writing tons of external XML files, code generators, DI frameworks, and build tools to glue the whole mess together. Instead of small, judicious bits of cleverness in the main language/runtime, it's been pushed to very clever tools on the periphery that come with relatively large learning curves. That's not really a win from the readability standpoint.

Re:Yes & the sheer amount of existing code/fra

[jeremyp]

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.