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.
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.
Not as easy to read as Python though
And that's a good thing.
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").
Antisthenes: "Wisdom begins by examining the words/names." - excuse my English, i am (slightly...) better with my Greek!
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.
Maybe it's improved with the new versions of C++, but I coded in C++ for many years before transitioning to iOS development, and I never wrote my own templated classes, mainly because I would never be able to understand what any kind of semi-complicated template would do. So, I just used STL and Boost, and only with the templates I was comfortable with.
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"...
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.
Please direct all bug reports to
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.
That's what I thought.
It was purely serendipity, and now the install base is so large you can;t get rid of it.
I am very small, utmostly microscopic.
I could sure do without the { }.
Almost all programming languages are easy to read. This is not the reason of Java's success at all. A complicate algorithm in first place will not make a program easy to read whatever the language you pick to program it. If you find Java easy to read, it is only because you cope with trivial algorithms.
Achille Talon
Hop!
final T up = (T) throwable;
throw up;
I'll see your senator, and I'll raise you two judges.
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.
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...
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.
Like most people I thought pythons enforced white space and avoidance of braces and elimination of semicolons was constricting. Then I realized how easy it was to read other people programs. Python used to be even simpler to read when it only provided one idioms for one job (avoiding a dozen way to do the same thing resulting in dialects). Now it's adding new idioms and genres so it's a little more opaque. But it's still easier to read than any language with comparable expressiveness. (Lua is refreshing for similar reasons).
Some drink at the fountain of knowledge. Others just gargle.
I'd agree with the ecosystem being a huge factor in Java's success.
More than that, it is a relatively closed ecosystem. Tools like JNI are available, but in practice few projects seem to use them. Mostly, either you're working in JVM world or you're working somewhere else. That's a lot of momentum to overcome for any long-standing project or development team to move to another language, tool chain, standard library, and so on.
I also think the summary's claim that Java is easy for humans to understand at a glance because of its simplicity is a mischaracterisation. Java is a relatively verbose, inexpressive language, so actually it can take quite a long time to figure out how any given piece of code works. What Java does offer is that an average developer can reliably figure out how any given piece of code works, even if it takes a while. For long-running, large-scale projects that is a valuable attribute for a programming language.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Yes, Java is pretty easy to read. It contains all the standard control structures, and not a lot more. Aside from inheritance (which, by now, pretty much all developers understand), there isn't a lot of hidden functionality: See the code, understand what it does.
This is one reason that I object to the introduction of Lambda's in Java 8. Lambdas belong in functional languages, where they make sense in the context of the language. Java is not functional, so lambdas break the paradigm. Moreover, they are unfamiliar to most developers, and they are cryptic in a way that hides functionality.
Enjoy life! This is not a dress rehearsal.
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.
Democracy Now! - your daily, uncensored, corporate-free
What makes "Java" or anything object oriented difficult to read is that objects tend to produce more spaghetti code and have a ton of easily overlooked side effects. Debugging can be a nightmare. I see more "pitch till you win" code maintainers.... so much so, that some consider it normal to just keep trying stuff until it "works". I'm not saying you can't create "good" object oriented code.... I just haven't seen any yet.
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.
-1, Too Many Layers Of Abstraction
It is pretty easy to read Java code and figure out what it means.
Many who deal with the "enterprise" software would simply laugh at the statement.
But hey, the same argument was often made about the BASIC. And I always said that Java and BASIC users are very similar.
All hope abandon ye who enter here.
It is not difficult to be "clever" at all. Look at various "bean" frameworks. Use their object marshaling features. Throw in some of their aspect-oriented programming features.
Now you usually have a bloated, incomprehensible mess. Sure you can easily read any couple of lines of code in isolation. But the system as a whole is a huge pile of gratuitous redundant layers of abstraction and confusing action-at-a-distance creepiness.
I see this sort of mindset a lot, but it's illustrative of short sightedness.
If you can't understand the importance of namespaces and structures, then you can't have worked on anything but the most trivial and small of codebases utilising little or no external libraries. If all you know are CS101 examples then sure, having to declare namespaces, methods, and so forth might look relatively bad.
If however you work on anything that actually matters then methods, namespaces and so forth become kind of important.
I don't see how endif is superior to }. Why would I want to type more than I have to to convey the exact same meaning? Curly brackets are meant to be jarring and to stand out, they do that to tell you a block has ended.
What amuses me is that many people rave on about how great C# is, while denouncing Java. Yet other than a few minor syntax tweaks (like the way you write getters/setters and the "?" indicator for nullable attributes), they are virtually identical right down to the API.
They're both very easy to read and code with, and if you know the packages/libraries of one you'll find the equivalent in the other in short order, with very, very few differences in the details of the APIs.
Yet C# is "great" and Java "sucks".
Go figure.
I do not fail; I succeed at finding out what does not work.
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
I guess we're not talking about working with Java Struts. When you do, turn on mysql logging, and then tail -f mysqld.log, you'll see garbage like this: select column_623 from table_943 where column_142='xxx'; ---- is that readable to you? Is that supposed to improve readability by abstracting so far away from the database that no one can understand what is going. I basically have to grep for values inserted or updated or selected from tables in order to figure out what table stuff is being written to. It's not ugly, its an abomination. Who ever thought up the idea doesnt know what they are doing. Easy to read..... YEAH RIGHT -- its a joke. It takes 5 times longer to reverse engineer this spaghetti mess than any other languages. Straight Java code is easy to read, if you don't intrude abstraction layers on top of the language, like Struts.
Totally agree. The expressive languages that let you do a lot with relatively few lines often count on implicit behaviours that are not at all obvious unless you are familiar with them. It's a drag on coming into someone else's codebase and understanding what's going on. "Oh, I see, you're counting on this to fail in *this* certain way such that *that* happens."
COBOL was relatively readable when it was invented, compared to the other languages of the time. The purpose was to be so readable that even managers could understand it
Well written COBOL is understandable. The biggest complaint is that it's overly verbose (other problems like "no re-entrant functions" aren't problems anymore). In many ways Java seems like a modern version of COBOL.
"First they came for the slanderers and i said nothing."
throw up;
That one never gets old. My favorite is:
public void loveYou(long time);
You can add an extra pun by adding a comment // this function takes a long time.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Yeap, of course repeat the type of the object twice, the ugly diamond operators, use else if instead of elif, etc, produces verbosity, but this is not related to be easy or not to understand.
The thing is, I think it is related to how easy something is to understand.
If I can express an algorithm as a single function of 10 lines then, other things being equal, that will be easier to understand than distributing the same algorithm across 5 functions each of 20 lines. You can see the whole thing at once, instead of jumping around within or between files. You don't have overheads of passing around and returning values.
Similarly, if I can express a simple bit of logic as a clean one-liner, while a verbose style requires 6 lines of manual loop/conditional logic and maybe a function wrapped around it, then I'm thinking about what that logic is doing and it how it fits in with the other logic around it while you're still worrying about loop counters.
Here's a version of finding all the items less than 10 in a list, written in Haskell, a relatively powerful language:
Here's a slightly more verbose version, written in Python, also a language known for being clean and expressive:
And in contrast, here is the best Stack Overflow has to offer about implementing this sort of requirement in Java.
Spoiler: There are basically three kinds of replies. Some write out entire functions to implement the filter using a manual loop. Some use a third party library to do a more clumsy variation of the Python and Haskell examples above. And a few recent ones use Java 8 to do a slightly less clumsy variation of the Python and Haskell examples above. The clear trend is to try to get away from classical, verbose Java to something more powerful and expressive. Like Scala, according to the first comment on the original question...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Totally disagree. If I see
I know exactly what it does. Anyone who has done any programming in any language can guess what it does. Its simple, easy to read, and if you want can be pulled into a function. Your haskell and Python implementations are unreadable and requires the user to think about each line. They're inferior to straight forward programming by orders of magnitude and should never be used.
I still have more fans than freaks. WTF is wrong with you people?
Are you saying that
256 * 2 = 512
is harder to understand than
two hundred fifty six multiplied by two is five hundred twelve
For C users:
// makes code faster // makes data use less memory
#define while if
#define struct union
I'll see your senator, and I'll raise you two judges.
I've never used any of the three languages in discussion here, and would barely count myself as a programmer at all, and upon initial reading of each of these routines this was my interpretation:
Java (I assume yours is): For every integer (call it "i") in the set "items", if "i" is less than ten, do whatever the 'add' function of the 'results' object does to it. (No idea what that function is, but my first guess would be to do the math of "results" + "i". Upon reflection after seeing the other languages' versions of this routine, I get now that it means "put 'i' as a member into the set 'results', or more loosely, "add 'i' to the set 'results'".)
Haskell: The set "items" contains members 1, 15, 27, 3, and 54. The set "results" contains every member of that set ("items") that passes the filter of being less than 10. (This is the clearest to me, and the one that shed light on the purpose of the other two).
Python: The set "items" contains members 1, 15, 27, 3, and 54. The set "results"... uhh.... assuming this does the same thing as the Haskell function, I'd guess it means that "results" contains every "item", where "item" is any item in the set of items, but only if "item" is less than ten; a roundabout way of saying, in a more Java-like fashion, "for every item (call it 'item') in the set 'items', if 'item' is less than ten [then that is part of what the set 'results' equals]".
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
There's a sweet spot for conciseness versus verbosity. If something gets overly concise, then what you say is true. However, there's a such thing as too verbose as well, where it's so indirect that it becomes difficult to read.
Not to mention, Java has a lot of things that are absent from other languages due to being relatively pointless or having better alternatives like public vs private things. On top of that, the fact that Java best practices dictate using getters and setters whenever possible mean lots of additional code. What's easier to read, "object.x = 5" or "object.setX(5)" plus the boilerplate function that actually does the setting? Yes, I'm aware that IDEs can take care of this, but when a language has so much copy-and-paste boilerplate code that an IDE can eliminate a huge chunk of it, that doesn't exactly reflect well on the language.
He's probably a COBOL programmer.