The Reason For Java's Staying Power: It's Easy To Read 414
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."
Yes & the sheer amount of existing code/framew (Score:5, Insightful)
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.
Re:Yes & the sheer amount of existing code/fra (Score:5, Interesting)
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.
Re:Yes & the sheer amount of existing code/fra (Score:5, Insightful)
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: (Score:3)
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 lot
Re:Yes & the sheer amount of existing code/fra (Score:4, Funny)
He's probably a COBOL programmer.
Re:Yes & the sheer amount of existing code/fra (Score:5, Interesting)
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 [stackoverflow.com] 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...
Re:Yes & the sheer amount of existing code/fra (Score:5, Interesting)
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.
Re:Yes & the sheer amount of existing code/fra (Score:4, Interesting)
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]".
"Easy to read" is non-sense (Score:4, Insightful)
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.
C++ Template Syntax (Score:4)
Re: (Score:3, Insightful)
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.
Re:"Easy to read" is non-sense (Score:5, Insightful)
Re:"Easy to read" is non-sense (Score:4)
On the other hand, in terms of "readable" I still think calling Java readable assumes a familiarity with C style syntax. I think if you took someone that never read or wrote code before and showed them 100 line, idiomatic programs in Java, Javascript, Python, Ruby, PHP, Perl, Lisp, Haskell, C, Fortran, COBOL, Basic, and a few other languages that Java would not top the list for readability. My guess is that the winners would be Basic, COBOL, and Python.
One of the biggest reasons C++ became popular was that it was a relatively small step away, in terms of syntax, from C. I really think Java became popular mostly because the syntax is a small step away from C++.
Re:"Easy to read" is non-sense (Score:5, Funny)
Yes, and if you gave someone who never read or wrote code before and gave them a printed sheet of Perl... they might wonder if the sheet is upright or upside down.
Re:"Easy to read" is non-sense (Score:4, Informative)
I'd put it differently: When you keep legibility and understandability in mind as a goal when writing in perl, the many syntax constructs available in it which are not in Java (for example) allow you to write much more understandable code in perl than you could in most other languages.
The fact that it also allows you to write stuff non-perl people cannot fathom is a problem, and any coding projects started in perl need a day-two code review and some conversations with the people involved. They need to know they're coding for the next user of the software more than they're coding for themselves. If they have trouble with that, then they're too young to be trusted with your business.
Re: (Score:3)
Don't worry- Java people are learning how to make up for that by creating whole incomprehensible sublanguages based on annotation processing that make C macros look good.
Re: (Score:3)
part of that is the fact that it explicitly doesn't support operator overloading
I would argue that this creates as many problems as it solves. E.g. when working with BigInteger or BigDecimal, a.multiply(b) is less readable than a*b.
Re:"Easy to read" is non-sense (Score:4, Interesting)
Re: (Score:2)
Is there one called DTN [keepcalm-o-matic.co.uk]?
Re: (Score:2)
You really cannot refactor something like this with a modern IDE and change the class names to something sensible? Ugh.
I totally agree with you about Java though, its quite readable. I have a LARGE code base and I can hand pieces of it to people and they can grasp what it does. I won't pretend its a model of perfect design, like any large old code base it has plenty of stupid in it, but the classes make sense, the overall organization and design is pretty good, and even if some of the APIs and such aren't e
Re: (Score:3)
Re:"Easy to read" is non-sense (Score:5, Insightful)
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 (Score:5, Insightful)
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++.
python white space (Score:4, Interesting)
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).
Re: (Score:3, Interesting)
Re: (Score:3)
Are you joking? Ada is easy to understand because it was designed to be. It is verbose and partially redundant by design as that is known to 1) increase understanding of programs 2) decreases some types of common errors.
Pascal wasn't really designed for ease of use (even though it is), one big problem is the use of semicolon as a separator: it isn't always obvious where they should go and misplaced semicolons can generate errors.
Re:"Easy to read" is non-sense (Score:5, Insightful)
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 (Score:5, Interesting)
I disagree that it is because java is easy to read. Java is easy to write. A good programer can write an app in Java and have it work really well. A bad programer can write an app in java it will work.
With C++ a good programer can write an app and it will work but you really have to watch for a lot of gotchas. A bad programer can not write a program that works in C++ because it will leak memory, stomp on memory, and have issues with pointers.
Java is better at stopping the little brain farts from blowing up in your face.
C++ is a lot more fun to write in IMHO.
Not as easy to read as Python though (Score:5, Funny)
Re: (Score:2, Informative)
Not as easy to read as Python though
Properly, consistently indented Java is. It's just that python has to be correctly indented to work, which is great, BTW!
Re:Not as easy to read as Python though (Score:5, Funny)
Two words: tabs, spaces.
Re: (Score:2)
Re: (Score:3, Interesting)
BTW, in case you haven't noticed, Python syntax is similar to Fortran syntax which is among the oldest, if not the oldest programming language still alive.
This. I think Fortran (and now Julia) strikes the best balance [iki.fi], because it doesn't have the tab/space issue that may produce problems, especially when sharing code. Like Python, it lacks the ugly {} ; punctuations, but it needs something to denote the end of a block, so it uses the English word "end" to keep things simple and clean.
Re:Not as easy to read as Python though (Score:4, Insightful)
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: (Score:2)
Except when you are trying to debug code where the indents are mixed with Spaces and Tabs.
Re: (Score:3, Insightful)
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: (Score:3)
And in development I have seen lots of python programmers who printed out their own code to meditate on where the one bug is they could not find on screen - only to waste another few hours because the tab/space bug was obfuscated by a page break in the printout.
Good for you. The last time I saw a programmer do that was... also never in my entire career, actually. If your programmers have trouble meditating on a print-out of a language with syntactic whitespace, you might suggest they instead use any modern text editor and a macro/plug-in that makes mismatched whitespace show up in bright red. Then they can become enlightened, spend less time "meditating" like programmers who work with punch cards, and spend more time making useful software.
Curious, which editor from 1927 would you recommend?
I doubt that there was a
Re:Not as easy to read as Python though (Score:5, Insightful)
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.
Corollary: It's difficult to be "clever" in Java (Score:5, Insightful)
And that's a good thing.
Re:Corollary: It's difficult to be "clever" in Jav (Score:5, Funny)
throw up;
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:3)
#define while if
#define struct union
Re: (Score:2)
Re: (Score:2)
It is, just as long what you are doing is similar to what everyone else is doing. Sometimes, you may need to break the mold. But that is actually very rare. And you need decades of experience to really know when you really should break the mold.
Re:Corollary: It's difficult to be "clever" in Jav (Score:4, Insightful)
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: (Score:3)
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.
verbose enough to be easy to read (Score:4, Insightful)
Not easiest to read, but forgiving... (Score:4, Insightful)
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: (Score:3, Funny)
Re: (Score:2)
I think he means circular reference ( http://en.wikipedia.org/wiki/C... [wikipedia.org] )
Re:Not easiest to read, but forgiving... (Score:5, Funny)
A cylindrical reference is like a circular reference, except it happens when your code is three dimensional.
Re: (Score:2)
Maybe it's where you create an array of circular references?
Re:Not easiest to read, but forgiving... (Score:5, Funny)
Re:Not easiest to read, but forgiving... (Score:5, Insightful)
Re: (Score:2)
You have just described why java has been such a pain in my neck. Otherwise nice looking software that functions until the memory leaks cause it to crash.
As for c# events, delegates, and event handlers in the msdn documentation is a mess it's not surprising it's a issue. I've read a few of the tutorial and I'm not sure the people writing them even understand what they are doing.
Re: (Score:2)
Yeah, but they are a class of leaks which are generally not that hard to sort out. Now, I've seen a few ugly leaks in my time that had no really obvious source, but even then it was very easy to determine WHAT was leaking and HOW, even if the exact explanation of WHY was rather obtuse. Your average programmer can understand most of the common cases though, like "gosh I created a static list of unbounded size and put 9 billion object references in it, that won't work!"
Re: (Score:3)
Re: (Score:2, Insightful)
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
Stability (Score:5, Insightful)
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"...
Re:Stability (Score:5, Interesting)
The people who make these incompatible changes vastly underestimate the cost of such incompatibilities.
The sheer amount of working Java code is not only why the language will stay around for a long time, but economically represents a very large amount of wealth.
Re: (Score:3)
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"...
No kidding - especially the socket libraries that let me write network code in the later 90s that would work on Sun, Mac, Windows, and Linux. Getting cross platform network code to work in C at that time was quite painful. And I don't recall any C++ libraries that I found pleasant to use before boost, and now Qt. And even now, while I consider boost essential, it's really only pleasant in the same way as no longer having to get your braces tightened qualifies as pleasant.
Verbosity is easy? (Score:4, Insightful)
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 [stackoverflow.com] (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? (Score:5, Insightful)
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: (Score:2)
Well, this implicit functionality is rather useful, that is why you see libraries like Apache IOUtils (like IOUtils.reafLine()) that bring some of that magic back. But the fact that you can go to the lower level is a good thing, I just wish the Java designers had these kind of utilities backed into the core of the language.
Re: (Score:3, Interesting)
Re:Verbosity is easy? (Score:5, Insightful)
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?
Re: (Score:3)
You may know the quote: "Premature optimization is the root of all evil," but the whole quote in context explains why it is so:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not
Re: (Score:3)
> I mean intuitively shouldn't toString() on a stream get back a string?
Yes it should return a String (enforced by polymorphism) but not the String you imply.
From the API [oracle.com]
Returns a string representation of the object. In general, the toString method returns a string that "textually represents" this object. The result should be a concise but informative representation that is easy for a person to read.
So your String should be a description of the InputStream, not its contents.
For example: "InputStream for URL: http://google.com/ [google.com]" or whatever satisfies the co
Re: (Score:3)
Why would you expect toString() to work on a InputStream?
There is no general safe way to create a String from an InputStream, because mapping from a byte stream(Which is what a InputStream is) to a string is not 1:1.
That is: The same string can be encoded as different bytes, depending on the encoding such as UTF-8, UTF-16 iso-8859-1).
The funny thing is that Sun did not think about this when they first created Java, so there are a bunch of deprecated methods which create strings from bytes, trying to guess t
Re: (Score:3, Informative)
A Stream is not a String. A Stream is a pipe which can serve you bytes as soon as some of them available.
If the InputStream.toString() will give you the full content of the stream you will have some very nasty errors. Eg. A beginner wants to read a file using a stream and is doing a toString() suddenly all the file will be loaded into memory into a big String eating all the memory. Another beginner listens to a tcp port using a stream does a toString() and suddenly the thread hangs until the client closes
Readability is crucial for new languages (Score:2, Insightful)
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 opin
Re:Readability is crucial for new languages (Score:5, Interesting)
As an example of what I mean by 'toolable'. When I rename a variable in Java, every instance of that variable throughout the entire project are changed. This is not a dumb 'search and replace'. It is a precise change made by tools that use most of the Java compiler front end in order to make these changes. Similarly if I rename a method, the change is precisely made throughout the source code. It doesn't matter if there is a variable, or a class or even another method elsewhere with the same name, there can be no possible confusion. Just as the compiler has no confusion about what identifier 'foo' in some line of code refers to, the renaming and refactoring processes are equally precise. That is what is meant by toolable.
If it aint broke dont fix it (Score:2)
Just like IE 6 it is so engrained into our business processes that it won't ever leave. At least here in the office which greatly angers web developers greatly, but operations doesn't care.
Java is around for no technical reasons. It is here because it is already here. Why change for the sake of change and .NET wasn't worth the effort in 2005 as IIS was a steamy piece of poo back then. So now no one wants to take the risk and $$$$ for something that already works. Yes we stayed on XP too until 2014 but my em
Yeah right. Then explain COBOL. (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
Other solutions may look sexy. And for smaller projects, they probably are.
But long term maintainability is important. Does your project still need to work in ten years? Twenty?
Having a compiler is also probably a major factor to Java success. If I make
Re: (Score:2)
serendipity
serndipd/
noun
the occurrence and development of events by chance in a happy or beneficial way.
Re: (Score:3)
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.
It's not that great (Score:2)
I could sure do without the { }.
Re: (Score:2)
Would you rather have begin/nigeb or something dumb like that?
Re: (Score:2)
What exactly makes curly brackets inherently not dumb? They are non-indicative and typing them on many keyboard layouts that are not en-US is quite uncomfortable.
Easy to read? (Score:3, Informative)
Re:Easy to read? (Score:5, Insightful)
If you confuse easy to read with easy to understand, you aren't a skilled programmer.
You must be joking (Score:3, Insightful)
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 (Score:5, Insightful)
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: (Score:3)
int number = Integer.parseInt(System.in.readLine());
Libraries tools and 3rd party, oh my ! (Score:2, Insightful)
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 documentatio
Really? (Score:2)
Most of the cost of maintaining any body of code over time is in maintenance ...
obvious much? (Score:2)
No, really? The cost of maintaining is in maintenance? Well, now that's some earth shattering surprise.
Anyway, the intention was probably to say that maintaining is more costly than creating. However, since it says "any body of code" I'll just call it the deepest bullcrap. I've seen and heard lots of people talking out of their behinds over the years dismissing the effort going into creating some really nice algorithms and realizing t
Re: (Score:2)
No, really? The cost of maintaining is in maintenance? Well, now that's some earth shattering surprise.
I thought the same thing when I first read that, but then again we're talking about an architect for the language that brought us "Foo foo = new Foo();" so a bit of redundancy is to be expected ;)
Yes, and that's why lambdas are a bad idea (Score:3)
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.
Dumb Slashdotters (Score:4, Insightful)
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.
Laughable (Score:3)
Seen enterprise software? (Score:5, Interesting)
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.
Java vs. C# amuses me (Score:4, Interesting)
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.
Is this supposed to be a joke? (Score:3)
Re: (Score:2)
But a more convoluted, heavy weight Scheme? If we adopted Lisp 20 years ago the world would be a better place.
#1. Java is nothing like Scheme, it's a fundamentally different language.
#2. Scheme is a Lisp, so if Java were a heavy weight one, we would have a widely adopted Lisp.
#3. Why would having Lisp being a widely adopted "make the world a better place"? Does it donate to charity?
And frankly, I personally consider the Lisps to be heavily overrated to begin with.
Re:Sure, easy to read (Score:5, Informative)
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.
Re: (Score:3)
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