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

[Anonymous Coward]

Don't know about Ada or Pascal, but VisualBasic is not easy to read. It's a mish-mash of different syntaxes ranging from GWBASIC to Smalltalk to C/C++ - depending on which was hot at the time, or should I say MyGWBasic to MySmalltalk to MyC/C++. A poor programmer can make any language difficult to read without really trying.

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

[Anonymous Coward]

Mod parent up, code readability is a trait of the programmer, not the language.
the reason Java stays is, imo, because it was every educator and manager's wet dream. Yet I still have to find a single coder that knows more than 5 languages who prefers writing Java over anything else.

Personally, I'd rather have my nutsack removed without anesthetic than write java

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.

Re:"Easy to read" is non-sense

[Anonymous Coward]

"When you use a command in Java, it does what its supposed to do."

Does it? Because I don't think it does.

Foo bar1;
Foo bar2;

bar1 = bar2;

int bar1;
int bar2;

bar1 = bar2;

One of these is a copy assignment, the other one is not.
No way to tell by the syntax.

foo(bar); where bar is an int vs foo(bar); where bar is an object - pass by reference, and again no way to tell by the syntax.

The _exact_ same syntax, often means two completely different behaviors.

In c++, if you want a pointer or a reference you have to explicitly say so.

When I make a function taking a Bar&, I want a reference to some damn Bar.
I'm explicitly telling you I do not wish for you to give me a null pointer.
No 30 lines of boilerplate null checking required.

In the same way, if i'm calling a Foo( Bar bar ), I do not expect for the function to change the state of my bar.
In java, there is no way to be sure of this.

In Java you have to be constantly on the lookout for someone to screw your objects up in a way you did not anticipate.

I don't call that "doing what it's supposed to do". /end of rant

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

Not easiest to read, but forgiving...

[CraigCruden]

The popularity of Java is not because of it's "easy to read" nature, but because it is fairly forgiving for programmers that don't really know what they are really doing.

I programmed in Java for 15+ years and it is not the best language now (more of a legacy language) that tends to get riddled with boilerplate code which requires code generation and produces an outcome that is not as clear and concise as it could be.

It is however a forgiving language where if you don't understand memory management -- it is not a big problem. For example I remember a system written by programmers in another language that was riddled with memory leaks because of cylindrical references. The code was literally translated into java and all the problems disappeared. The programmers on that project just figured that the language that they programmed in was the problem -- but in reality java saved them from their inability to understand the basics of what they were doing.

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:Not easiest to read, but forgiving...

[Anonymous Coward]

Hmmm. I enjoy driving my modern car because it has an fuel injection and an engine management CPU. I guess I'm just not a real "driver" because I drive such a forgiving car. If I really knew what I was doing, I would drive a car more like a Ford Model A with a crank start, manual choke, and manual spark advance on the steering column.

Machines (I'm including computers in this category) that provide useful abstractions that relieve the machine's users from having to be concerned with details of the machine's operation that are not germane to their primary purpose in using the machine are valuable, not props for the weak-minded.

If we all still coded by hand in machine language or (slightly better) assembler, we would not be able to produce code at anywhere near the rate we do. Languages that are forgiving in the sense that they take care of the details that machines are good at taking care of, and allow the programmers to focus on solving the real problems are a tribute to our ability to continually improve. The implication that programmers using such a language "don't really know what they are doing" naively assumes that what programmers should be doing is worrying about memory management instead of understanding the actual problem to be solved using the computer.

Re:Not as easy to read as Python though

[Anonymous Coward]

ROFL

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?

Readability is crucial for new languages

[Anonymous Coward]

Java's readability is part of its staying power, which is part of the reason that Java is able to overcome its severe age and lack of features. As a software developer, I spend 90% of my time reading other peoples' code and 10% of the time writing my own. I also need to read code that I read over 6 months go, which I largely won't remember writing.

This is a major part of the reason why languages such as Scala haven't taken off. Scala, Perl, and other similar languages are largely "write-only" in my opinion. Newer languages must be designed primarily for readability.

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 as easy to read as Python though

[engun]

Exactly. Having used Java in an enterprise setting for many years, and having had the good fortune to move to Python, I couldn't be happier. I realised how much more verbose Java was than its Python equivalent. Even if you overlook that - there's an inherent structural complexity that Java engenders to its code - one only need look at the Python equivalent to see why. For example, take a look at a basic Hadoop WordCount example here: http://wiki.apache.org/hadoop/... Now compare a rough Python equivalent here: http://mrjob.readthedocs.org/e...

It's not just stuff like the lack of lambdas (it looks like Java 8 has fixed this), or the static typing that contributes to this complexity. I suspect that the culture that has sprung up around Java favours over-architecting and over-engineering, which is exacerbated by its statically typed nature. The Java language itself is simple enough.

In contrast, there is a cult of simplicity around Python, and the language itself has a high-level of expressivity, allowing for a clearer exposition of one's intent - instead of burying it in layer upon layer of abstraction built to please the language and its type system. C# is a language that fares much better than Java in this regard - it's a lot cleaner. For starters - no type erasure!

Re:Easy to read?

[Dog-Cow]

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

You must be joking

[joseph90]

I am sorry but can I just say:

  BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(System.in));
  input = bufferedReader.readLine();
  number = Integer.parseInt(input);

In Pascal (1960's) you could just do something like:
integer number;
read(number);

See if the compiler knows number is an integer do I really have to tell it to create a stream and parse it as an int? seriously?
Java is an abomination.

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.

Libraries tools and 3rd party, oh my !

[Anonymous Coward]

Libraries tools and 3rd party support in the form of books, articles developer know how, WORA, etc. It's very very fast no matter what people around in the 90s may still think, it has an unbelievable number of extremely high quality, battle proven open source libraries for highly specialized and useful functions and of course the tools supporting it like IDEs are out this world good. So I can do anything I want, I can run in most anywhere, I have vast libraries at my disposal and best in class documentation from multiple independent sources.

Pretty much sums it up.

I use other languages, sure, but I get sick when I see people (evangelists, consultants) ushing some new "better" language because frankly they have positioned to make a ton of money off it shuld demand for it sky rocket. It's software engineering's own secret sin- people reinvent a non-broken wheel in order to profit. It happens all the time. There's gold in them thar hills if you can just "create a buzz" and reach enough developers by co-opting enough "thought leaders" to create a "tipping point" in demand for your new "break-through language / platform / way of programming".

James Gosling recently said it best when he said that new important innovations aren't going to come from inventing new computer anguages, they're going to come from the world IoT and how create devs use languages.

Yes, I am posting the AC for a reason. Let the onslaught begin...

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:Not as easy to read as Python though

[Anonymous Brave Guy]

I've been programming in Python professionally for something close to a decade now, and in all that time the number of tab/space bugs I've seen in production is: 0.

Get a good edit -- any good editor -- and worry about problems that actually matter. This one was solved in about 1927.

Re:C++ Template Syntax

[Anonymous Coward]

The syntax isn't what makes C++ templates hard. They're hard because they're templates.

However, they're powerful because of it. There's no "generics meta programming" because generics don't offer any sort of comparable power. That said, the reason template meta programming is so useful is because C++ lacks reflection.

Dumb Slashdotters

[bigsexyjoe]

This is an article about why Java has decent staying power, not about why it is the perfect language, nor most readable language possible. The article does not say people will be using Java in 1,0000 years. But Java became popular and continues to have strong staying power for an old language. There are reasons for that, even if it isn't your cup of tea.

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.

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

[Anonymous Brave Guy]

Generally speaking, the more information you pack into a sequence of characters, the harder it is to understand.

By that argument, doesn't any powerful abstraction make code harder to understand? Similarly, doesn't any verbose style make code easier to understand, even if the boilerplate contributes no additional meaning? Sorry, but I can't agree with this sort of reasoning at all. If it was that simple, we'd still be writing large software systems in assembly language and no-one would use any sort of libraries or modular design.