There's a gravitational pull towards popular languages because popular languages have more books, more (idiomatic) libraries and tools, copy-pasteble examples all over the web and a big pool of developers that can be productive from day 1 on simple problems.
In order to adopt a language that isn't in the top 6 or so, you've got to have good reasons for it. And depending on the problems you're trying to solve, sometimes it's worth it, sometimes it isn't. For a startup, with a small but capable team that's trying to outrun its competition to market, then using the most productive tools possible is a good choice. In other contexts though, like in a big company where long-term maintainability might be more important than speed to market, well, Java might be the better choice, and not because of the language per se (I think Java code is often unreadable), but more because the cost of maintainability is low due to its popularity and its slow pace of change.
I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Only now with the most recent features is it really likely that you'll run into some one-liners and magic functions. Now, if you were talking about frameworks/app servers and not being able to figure out which levers and knobs to push to get them to behave, I would agree wholeheartedly.
I'm not saying Java is good looking by any means, but I've never found it to be heard to read in the "I can't completely grasp exactly what everything is supposed to do" kind of way. I often find Python and JS to have enough shortcuts, callbacks, and anonymous functions to find other people's code much harder to grok than other people's Java.
> I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose.
Not bad_user, obviously, but excessive verbosity can be antithetical to readability. (As can excessive conciseness.)
It can make the overall structure and meaning of the code hard to discern, even though can clearly tell where what gets assigned to what variables, etc.
The thing that always kills me on new Java projects is wading through these enormous hierarchies of folders full of interface classes just to find one actual line of implementation code. Of course, right after that one line of implementation code there's an invocation of some other interface class that then leads me on the next goose chase to find line 2. I think it's not so much a problem of verbosity as it is this sort of "Enterprise FizzBuzz" mentality that crept into Java over the years. Some of this IOC stuff gets so far out of hand that I feel like I'm in the House of Mirrors at the local carnival when I first start trying to walk through a new code base.
Yeah, I don't know. Java developers need IDEs like Rob Ford needs crack cocaine, but it's more a comment on the deficiencies of the language than the purported benefits of an IDE.
Would be curious to find out what that means, since I see it repeated many times in favor of mainstream and verbose languages, such as Java. I get it to mean somehow that Java is more readable, however in my experience that doesn't make sense, as the IDE can deal with generating the boilerplate, but the IDE cannot help with readability. Not even if you include quick navigation by click, since that has been the purpose of ctags in plain editors.
The mathematical language is a "pile of hieroglyphics", yet mathematicians can speak it just fine. And in fact without their domain specific language mathematics would be much, much harder to deal with. We know this because the mathematical language in use today is newer than the discipline of mathematics and we can make a before and after comparison.
Personally I don't understand why some programmers insist on communicating only in english words. First of all because english words suffer from the problems of natural language, which is that natural language is imprecise, with the words having multiple meanings depending on surrounding context. For example when adding two numbers, should you use "add" or should you use "plus"? As it may be, "add" is actually incorrect according to its precise English definition, because the operation doesn't necessarily lead to increasing the size or amount. Yet this does not stop people from using it. Fortunately classes like BigDecimal are using "plus", yet I don't get why in the world would anybody think that "x.plus(y.multiply(z))" is more readable than "x + y * z".
You might thing picking on BigDecimal is a cheap shot. Well, how about the well known "ListUtils.union(a, b)" and why would that be better than "a ++ b". Speaking of "ListUtils.union", joining 2 lists is not a union, as union is in the context of sets or maps. Joining 2 lists is a concatenation and that matters, because concatenation is not commutative, whereas a union (of 2 sets or maps) is commutative. Basically the Apache Commons folks have got the naming wrong and if such mistakes happen in libraries that are so public, guess what happens inside corporate projects.
But much more problematic in languages like Java is not the wording as much as the way the logic is often expressed. In a functional programming language you usually get pure expressions that operate on immutable data-structures, pure as in true mathematical functions (for the same input you always get the same output). Such functions are much easier to reason about and much easier to test, because the output does not depend on some object's history (or in other words, an object's identity).
The worst and most unreadable code I've ever seen was written in Java, a language in which people often pass around mutable data-structures, like arrays, modifying them on the spot, for no good reason other than not knowing any better, in a dance of mutation that can only be considered an abomination of nature, with code so obtuse that it would make grown men cry. It's not uncommon for pieces of code to be commented with "here be dragons" with people no longer understanding what it does. Couple that with "enterprise design patterns" based primarily on IoC containers and best practices spawned from hell, with deep layers of inheritance that don't make sense and with chronic multi-threading issues and you've got a recipe for disaster. And you don't even have to search for proof for too long. Take any reasonably sized open-source project and you'll see this fact in all its glory. The last Java open-source project I interacted with is SpyMemcached and is a fine example of a Java project that works, that does its job well, that is reasonably well maintained, but that has internals that expose all the problems that I just mentioned. And sometimes I wonder why anything written in Java works at all, my guess being simply that people hit that code with the hammer until it quacks, in a process that resembles more natural evolution and mutation rather than engineering.
Therefore I'm personally dumbfounded by claims of readability. And in regards to the capabilities of an IDE, I do use IntelliJ IDEA, but I am wondering what the other 99% of its capabilities are, preferably that help with readability. Syntax highlighting?
The verbosity not just directly affects readability by simply being longer and more to read. It also affects writeability which in combination with lazy developers (as we all are) leads to bad, unreadable, code. This is true for any language and can most often be seen on sloppy error handling, if you have to write 2x the amount of code to handle errors will you do it? 10x?
Oh, it is very much relevant for Go, except that those of us interested in expressivity simply gave up on Go a long time ago.
You see, Go is not popular enough to have users that don't like it. The people that end up trying out Go simply move to something else if they don't like it. Go's community is also strongly opinionated and has rejected any dialog for meaningful improvements. In other words the Go community is filtering out people that want something different. Whether this is good or bad, you be the judge, but if there's one thing that's definitely bad is the echo chamber. Case in point you're under the impression that Go is tolerable, even though many of us consider it to be worse than Java.
You misunderstand me. I find Go painfully verbose, mostly because of the elaborate if/else constructs around every single method call to handle errors. Even Java's ill-conceived checked exceptions (which can be suppressed with lombok's @SneakyThrows) are a massive improvement.
Completely agree. This is really the best time for comments in Java. Have 5 lines of stuff that's essentially working towards a single goal? Comment it! You should end up with the comments reading out the narrative properly, even if the code is way too wordy.
Java's verbosity (and misuse of OOP, but to be fair, that's not the fault of the language) can get in the way of understanding. Why use multiple words to say something when a single word will do? "Unreadable" is obviously hyperbole; "harder to read" is probably more accurate.
On the contrary, I think the recent additions from Java 8 are a step in the right direction.
Except almost all the tools work with the pre-java-8 way of doing things (and often even pre-java-7). Thus, you end up with layers of different idioms, all of which are not quite compatible with each other.
In order to adopt a language that isn't in the top 6 or so, you've got to have good reasons for it. And depending on the problems you're trying to solve, sometimes it's worth it, sometimes it isn't. For a startup, with a small but capable team that's trying to outrun its competition to market, then using the most productive tools possible is a good choice. In other contexts though, like in a big company where long-term maintainability might be more important than speed to market, well, Java might be the better choice, and not because of the language per se (I think Java code is often unreadable), but more because the cost of maintainability is low due to its popularity and its slow pace of change.