But it's not making a good point. It's not even close. I wish people would stop voting it up.

- "In Java, you can forget about doing it in the cleanest or the best way, because that is impossible." -- cleanest in any language? Or cleanest for Java? Of course the "cleanest" way for Java is possible, and it does matter -- there is a huge difference between "clean" Java and unclean, and anyone who says otherwise is a Java pretender. And arguing about "cleanest for any language" is just a proxy for a language flamewar.

- "And nobody can glare at you and demand to know why you used 576 classes when you should have used 50, because in Java doing it with only 50 classes is probably impossible." -- The "Har-har-so-many-classes-and-don't-even-get-me-started-on-variable-names" argument. In Java, as in any language, you can over-design, or you can under-design, or you can design just what you need. The number of classes may end up higher than in other languages, but this argument is silly and tired, and yes, length is one of the tradeoffs of Java. An IDE (gasp!) should make that largely irrelevant.

- "The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands." -- This word "verbose" keeps being thrown around as an insult, but nobody brings up the tradeoffs. Verbosity has a purpose, just like brevity and terseness do. And of course it's never out of the programmers' hands. Once given a language, it's all relative.

There's more, but I'm arguing with a person who believes that a question about stdin and stdout is a proper gateway for measuring skill toward any programming problem ever.

There's actually something quite liberating about languages that deny you any clever solutions. Just write code that works and don't worry about whether you could have used <fashionable programming concept X> instead. I found Go to be quite refreshing for the same reason - the standard library is pretty small and the language lacks anything particularly magical, even some stuff that Java has like generics. The end result, however, is code that is very easy to read and write for anyone who learned imperative programming in the last 30 years.

That's a common anti-intellectual fallacy about why people code in higher level languages. High level languages are attractive because they let you write code faster and make your code easier to maintain, and not because they're "fashionable".

>There's actually something quite liberating about languages that deny you any clever solutions

To me, "deny[ing] clever solutions" translates to "this code is going to be a pain in the ass to write because I'm going to waste time fighting the language to get what I want." Programmers learn to avoid unnecessarily complicated code as they gain more experience. Mature programmers should have the freedom to exercise their judgement about what kind of code is appropriate.

Writing code faster is not my problem. The problem is building systems (that work) faster and this need sometimes requires using higher-level abstractions that maybe allow for more modularity, that maybe are more composable, or maybe are safer to use (and I'm specifically thinking here of concurrency, parallelism, asynchronous I/O, etc...). Higher-level abstractions is my goal when learning a new language (this or gaining access to another platform).

"clever solutions" is indeed an unwarranted euphemism that people use. But we are ending up having such discussions, precisely because we aren't defining well what we are talking about. Writing less code is a subjective problem. Not being able to build and/or work with a certain abstraction is an objective problem.

Maybe, maybe not. But at least 2 of the 3 points that you made are not true of JavaScript. Also, the whole "write code faster" has always been perplexing to me. The speed at which you write code is never significantly different between any two mainstream languages to really matter in the end, especially since the lifetime of a piece of software is dominated by maintenance.

And I don't know what you mean by "High level language". Java is a high level language.

>To me, "deny[ing] clever solutions" translates to "this code is going to be a pain in the ass to write because I'm going to waste time fighting the language to get what I want."

There's clever and then there's too clever.

One of the very few bits of relatively solid software engineering that we have is that line count for a given task does matter. Fewer lines written by the programmer to do the same thing strongly tends to yield higher productivity. (Note the "by the programmer" clause; lines autogenerated... well... correctly autogenerated tend not to count against the programmer, which is an important part of doing Java, or so I hear.)

And remember, if this were not true, we'd be programming entirely differently; why do anything but assembler if line count doesn't matter? You might be tempted to thing that's some sort of rhetorical exaggeration, since it sort of sounds like one, but it's not; it's a very serious point. If line counts are actually irrelevant, then we'd never be bothering with high-level languages, which up until fairly recently have the primary purpose of doing a whole bunch of things which, in the end, reduce line count.

(Slowly but surely we're starting to see the mainstream introduction and use of languages that also focus on helping you maintain invariants, but that has still historically speaking been a sideline task and niche products.)

Sorry, but unless you have an architect dissect the problem to exaustion and freeze the architecture after it, no piece of software creates the correct autogenerated code, and those lines still have to be changed by the programmer. Several times.

And if you have an architect dissect the problem to exaustion and freeze the architecture after it, that's already a bigger problem than dealing with all that autogenerated code. No win.

Because I'd totally buy that the number of expressions matters.

But I really doubt actual lines matters much.

Still, I do stick by my original point... if you think lines of code are irrelevent, it becomes very difficult to understand the current landscape of language popularity. A language in which simply reading a line from a file is a multi-dozen line travesty is harder to use than a language in which it's two or three, and that extends on through the rest of the language. I know when I go from a language where certain patterns are easy into a higher B&D language where the right thing is a lot more work, I have to fight the urge to not do the lot-more-work, and this higher level "how expensive is it to use the correct pattern?" is a far more important, if harder to describe, consideration across non-trivial code bases.

1) How do you count "expressions"? is (b+sqrt(b * b - 4 * a * c))/(2 * a) one expression or 14?

2) Assuming reasonable coding style and reasonable definition for what an "expression" is, the variance of the measurement "expressions per line" will be very small - thus, "number of expressions" and "number of lines" are statistically equivalent as far as descriptive power goes.

I don't have a citation, although I do remember this conclusion mentioned in PeopleWare - specifically, that "number of bugs per line" tends to be a low variance statistic per person, with the programming language playing a minor role. I might be wrong though.

But I can offer my personal related experience ("anecdata"?) - when you ask multiple people to estimate project complexity using a "time to complete" measure, you get widely varying results that are hard to reason about. However, when you ask them to estimate "lines of code", you get much more consistent results, and meaningful arguments when two people try to reach an agreement. YMMV.

Expressions are distinct from Compositions, and both influence LOC. I wouldn't suspect that Java software is of generally lower quality than Ruby code on average for example even though in Java you might see a Reader around a Buffer around a Stream instead of Ruby's `open`.

I guess what I'm getting at is what you might loosely call boiler-plate. Java has a lot more boiler plate. Which could easily result in 2X higher LOC. Having worked with more Ruby than the average bear I feel very confident being skeptical of the assertion that Ruby libraries are generally of higher quality/fewer bugs.

I think your last anecdote is more getting into Five Whys territory, and it's probably reasonable to expect a greater degree of consensus then.

Final note: Scala is typically less verbose than Ruby by a fair margin (at least if you leave off imports). Idiomatically usage is also Functional to a significant degree in a way that no Ruby library I've ever seen comes close to. So does that automatically mean that Scala is the superior language? (Well of course it is ;-D, but is that the reason?)

How do you count lines? On unix, "wc -l"; if you insist, sloccount, but "wc -l" is a good approximation.

How do you count expressions? The fact it will take you a few paragraphs to answer (you haven't, btw) indicates that it's a poor thing to measure and try to reason about.

I've done some IO code in C# (mostly WCF, bot not just), and I still think you are playing with semantics as far as statistics is concerned.

Figure out an objective, automatable way to count your "expressions" or "compositions" or "code points" or "functional points" or whatever you want to call it. Run it on a code base, and compute the Pearson r coefficient of correlation. It's likely to be >95%, which means one is an excellent approximation of the other.

And I have no idea what you were trying to say about Scala. I wasn't saying "terser is automatically better". I was saying, (and I'm quoting myself here: "number of bugs per line" tends to be a low variance statistic per person, with the programming language playing a minor role"). Note "per person"?

I guess "expression" seems semi-obvious to me since it's a standard rule in SBT. Variable assignments, return values and function bodies might get close.

  val a = 1 + 1

An if/else with a simple switch for the return value would be an expression for example. A more complex else case might have nested expressions though.

It takes some charity I suppose; one of those "I know it when I see it" things. I don't do a lot of Math based programming though. It's all business rules, DTOs, serialization, etc. So maybe not something that could be formalized too easily.

I guess where I'd intuitively disagree (and would be interested in further reading) is that LOC as a measure just doesn't feel like it works for me.

Considering only LOC to implement a task it's likely: Java, Ruby and Scala in that order (from most to fewest). But in my personal experience bugs are probably more like: Ruby, Java, Scala from most to fewest.

Hopefully that helps clarify and not just muddy what I'm trying to express further.

What confuses me is that you appear to be claiming that fewer LOC should correlate strongly with fewer bugs, but then go on to say that terser is not automatically better (in this context (sic?)). Maybe I'm reading more into it than you intend, but I'm left a bit confused.

Which is a confusing use of the term "expression", since it is very well defined when talking about languages - in fact, most formal grammars have a nonterminal called "expr" or "expression" when describing the language.

Your description, though, more closely correlates with what most languages consider a statement.

Regardless, it's just pure statistics - if you calculate it, you'll notice that you have e.g. 1.3 expressions per line, with a standard deviation of 1 expressions per line - which means that over 1000 lines, you'll have, with 95% confidence, 1200-1400 expressions -- it wouldn't matter if you measure LOC or "expressions".

> What confuses me is that you appear to be claiming that fewer LOC should correlate strongly with fewer bugs, but then go on to say that terser is not automatically better (in this context (sic?)). Maybe I'm reading more into it than you intend, but I'm left a bit confused.

What I'm claiming is that, when people actually measured this, they found out that a given programmer tends to have a nearly constant number of bugs per line, regardless of language - that is, person X tends to have (on average) one bug per 100 lines, whether those lines are C, Fortran or Basic - the variance per programmer is way larger than the variance of that programmer per language.

Now, PeopleWare which references those studies (where I read about that) was written 20 years ago or so - so the Java or C++ considered wasn't today's Java/C++, things like Scala and Ruby were not considered. However, I'd be surprised if they significantly change the results - because those studies DID include Lisp, which -- even 20 years ago -- had everything to offer that you can get from Scala today.

So, in a sense - yes, you should write terse programs, regardless of which language you do that in. If you wrote assembly code using Scala syntax, and compiled with a Scala compiler - Scala is not helping you one bit.

My problem is that the solution in a slightly more expressive language is equally obvious, so I have to fight my own rage at java for its stuttering and clumsy excuse for closures. Fighting the language, on the other hand, is when I try to write a conditional or loop in sh.

This isn't a bad tradeoff though. Elegance means generally gains in maintainability, possibly with lesser costs in the actual development. And thinking about elegance in code is the first step to writing better, more maintainable code.

> For example... should I use map or reduce here, or maybe an iterator, or... oh fuck it, I'll use a for loop. It turns out that the old-school for loop works just as well despite earning you precisely zero style points.

I usually stick with for loops because they are clear. Remember:

elegance is about simplicity and clarity. If you sacrifice either of these, you are reducing the elegance of your code.

And a lot of thought went into Unix, as evidenced by its longetivity and long lasting tradition of its phylosophy. To date it's the oldest family of operating systems and at the same time, the most popular. Anybody that thinks the "worse" in the "worse is better" argument is about not carrying, is in for a surprise: http://en.wikipedia.org/wiki/Unix_philosophy

Even in the original comparisson to CLOS/Lisp Machines outlined by Richard Gabriel, he mentions this important difference (versus the MIT/Stanford style): It is slightly better to be simple than correct.

But again, simplicity is not about not carrying about design or the implementation and in fact the "worse is better" approach strongly emphasises on readable/understandable implementations. And simplicity is actually freaking hard to achieve, because simplicity doesn't refer to "easy", being the opposite of entanglement/interwiving: http://www.infoq.com/presentations/Simple-Made-Easy

"Worse is better" is, ultimately, an argument against perfectionism. Many of the features of Unix could have been implemented in a "better" way, and these ways were known to people working at the time. But it turns out that those "better" options are much more difficult to implement, harder to get right and are ultimately counter-productive to the goal of delivering software that works. We can set up clear, logical arguments as to why doing things the Unix way is worse than doing things another way (e.g. how Lisp Machines would do it), but it turns out that the Unix approach is just more effective. Basically, although we can invent aesthetic or philosophical standards of correctness for programs, actually trying to follow these in the real world is dangerous (beyond a certain point, anyway).

I think that's pretty similar to the OP's argument that, whilst Haskell is clearly a superior language to Java in many respects, writing code properly in Haskell is much harder than doing so in Java because, probably for entirely cultural reasons, a programmer working with Haskell feels a greater need to write the "correct" program rather than the one that just works. Java gives the programmer an excuse to abandon perfectionism, producing code that is "worse" but an outcome that is "better".

I think I know what you're getting at, which is that a comparison between Unix and the monstrous IDE-generated Java bloatware described in the OP is insulting to Unix. On this you are correct. But for "worse is better" to be meaningful, there still has to be some recognition that, yes, Unix really is worse than the ideal. Unix isn't the best thing that could ever possibly exist, it's just the best thing that the people at the time could build, and nobody has ever come up with a better alternative.

> Haskell is clearly a superior language to Java in many respects, writing code properly in Haskell is much harder than doing so in Java

I do not agree on your assessment. Haskell is harder to write because ALL the concepts involved are extremely unfamiliar to everybody. Java is learned in school. Java is everywhere. Developers are exposed to Java or Java-like languages.

OOP and class-based design, including all the design patterns in the gang of four, seem easy to you or to most people, because we've been exposed to them ever since we started to learn programming.

Haskell is also great, but it is not clearly superior to Java. That's another point I disagree on, the jury is still out on that one - as language choice is important, but it's less important than everything else combined (libraries, tools, ecosystem and so on).

However, on the "Better" side, ie. the LISP/Haskell side, the moral of WIB is that time-to-market is hugely important. It's not that the "Better" side was bogged-down in philosophical nuance and was chasing an unattainable perfectionism; it's that their solutions took a bit longer to implement. For example, according to Wikipedia C came out in '72 and Scheme came out in '75. Scheme is clearly influenced by philosophy and perfectionism, but it's also a solid language with clear goals.

The problem is that Scheme and C were both trying to solve the 'decent high-level language' problem, but since C came out first, fewer people cared about Scheme when it eventually came out. In the mean time they'd moved on to tackling the 'null pointer dereference in C problem', the 'buffer overflow in C' problem, the 'unterminated strings in C' problem, and so on. Even though Scheme doesn't have these problems, it also doesn't solve them "in C", so it was too difficult to switch to.

Of course, this is a massive simplification and there have been many other high level languages before and since, but it illustrates the other side of the argument: if your system solves a problem, people will work around far more crappiness than you might think.

More modern examples are Web apps (especially in the early days), Flash, Silverlight, etc. and possibly the Web itself.

C is quite odd in that the programmer is expected to pay dearly for their mistakes, rather than be protected from them. BTW it wouldn't be as much fun if they were protected.

Regarding Scheme, it has withstood the test of nearly forty years very well.

The more I learn about assembler, the more I appreciate how C deals with dirty work like calling conventions, register allocation, and computing struct member offsets, while still giving you control of the machine.

On the other hand, some processor primitives like carry bits are annoyingly absent from the C language.

Use the least powerful tool that solves the problem. A map is less powerful than a fold (reduce), so use that if you can. A fold is probably less powerful than a for-loop, so use that if you can. An iterator is probably less powerful than a for-loop, so use that if you need the more streamlined accessing of elements rather than a fine-grained, indexed loop.

Goto has a problem, it breaks the structure of the code. For does not have this problem. Thus, you should avoid goto, and there is no reason to avoid for. The fact that you knows how to write both changes what?

In basic you can use your labels and goto statements to create a hierarchy of dispatching routines. And if you're very disciplined about which global variables you use as flags to control the execution flow, i.e. which goto statement gets selected next, and which variables to hold return values, you could write a decent program.

The danger lies in that it allows the programmer too much range to produce low-quality code. The negative effect includes too much attention to the implementation of abstractions, instead of its usage. The existence of the goto statements can undermine other abstractions offered by the programming language.

Goto doesn't break structure of the code, programmers do. (I guess that's the whole reason we stopped using it: reducing the risk of making crappy software)

In my comment structured programming refers to using structured syntax to generate goto statements, so you don't have to see them or implement them yourself. It should free the programmer of considering those alternative ways of controlling program flow. Presence of goto statement points to a flaw in the language design.

To answer your question: Because the basic language I'm referring to, was on my TI84-plus calculator, and it only had an if-statement (no if-else!).

There is a very simple isomorphism between each of the typical control structures (sequencing, choice, and iteration) and its implementation with gotos. It's an easy mechanical translation, in either direction. I don't think Dijkstra was making any claim that spelling these control structures with goto radically increased the difficulty of programming. The important thing was using reasonable control structures (and only reasonable control structures) in the design of your program. Obviously, having the language do it for you is preferred much like any other mechanical translation - but that's not the key point.

"It should free the programmer of considering those alternative ways of controlling program flow. Presence of goto statement points to a flaw in the language design."

I don't disagree with any of that.

"Because the basic language I'm referring to, was on my TI84-plus calculator, and it only had an if-statement (no if-else!)."

That's still an example of using goto to implement missing control structures, not using goto when the control structure you want is present.

The most obvious symptom would be with libraries; even though GOTOs, loops, recursion and morphisms are equivalent, if most libraries expose APIs in a different style than your code, you'll have to sprinkle translation code all over the place.

It also makes a difference for static analysis, eg. in IDEs and linters. For example, Iterators might give you more precise type hints or unhandled-exception warnings, which makes that style safer (all else being equal).

Of course, the other point is that there are no such 'lowest common denominators'. GOTO certainly isn't, since Python, Java, etc. don't support them. For loops aren't, since languages like Prolog, Haskell, Erlang and Maude don't support them. Recursion isn't supported in COBOL or OpenCL, and took several decades to appear in FORTRAN. Morphisms require first-order functions, which rules out FORTRAN and C, and until very recently C++ and Java. It may or may not be possible to build such features from the other ones, but even so that's clearly working against the language and causing massive incompatibility with everyone else.

Clinging to particular features like this will only blinker us to the possibilities which are out there. In this case, clinging to for loops implies avoidance of at least Erlang, Haskell and Prolog. These languages have a lot to offer, and are/look-to-become the go-to solutions* in the domains of concurrent, high-confidence and logical/deductive code respectively. Clinging to inappropriate concepts dooms us to 'reinventing the square wheel'.

* No pun intended ;)

PS: I actually think recursion and morphisms are safer, more structured and conceptually simpler than for-loops. See http://lambda-the-ultimate.org/node/4683#comment-74319

For loops have the advantage, particularly in languages like Perl, of being quite clear.

One important thing to note with any language is that the culture matters - a lot. For instance, Tcl and Tk let people easily create GUI's, but there was no UI culture. Most of the main books didn't dedicate even a page to how to make a good looking, functional GUI. You can produce some godawful messy code in Ruby if you put your mind to it, but there's a culture of not trying to be too clever, and also of writing stuff that's easy(ish) to read later.

Since I'm not really a Java guy at all, I don't know enough to comment in an authoritative way, but I sneak a glance from time to time, and my guess is that there may be a bit of a culture of over-designing things.

I think overall these cultures don't indicate too much of an underlying problem and aren't too harmful, except when assimilating developers from other language. But to your point, these barriers to entry likely exist for nearly every language (and if not, other barriers do), so on balance, it's largely a wash.

I think that the Java ecosystem being so massive and Java being so popular, it also attracted a lot of mediocrity, since the usual bell curve applies. That said, I know Java developers that definitely don't like verbosity and that don't follow the usual "best practices" as some kind of dogma. In the end, it all depends on the work environment you end up in.

(I assume that you are not being sarcastic - my sarcasm detector did not go off. In case I missed the sarcasm, apologies).

It is not at all a mystery, if you had been there in the late '90s / early 2000s : Java was actively marketed to management as a language that's usable by mediocre programmers to produce usable results ; "See, unlike C/C++, there are no buffer overflows, no dangling pointers, no undefined behavior, no platform dependencies, no memory leaks - your projects now are in bad shape because of these, but when you switch to Java, all of these problems will be a thing of the past". And those same people who bought the marketing hype, were also mostly believers in the "programmer is a replaceable cog" religion, which is still prevalent today in many places (not just Java), and during the .com days was actually somewhat truthy in the sense that people switched jobs so fast that you had to build your culture in such a way that people are replaceable, because programmer turnover at many companies was exceeding 20%/year.

Today's Java culture is rooted in those days, and it has an underlying "make it painful to not be stupid-simple" directive, and "make it easy to replace the programmer" requirement. Though these are often satisfied, my impression is that overall, it does not make projects more likely to deliver (on time or at all), or higher quality. But it is what it is.

But i think there's another significant factor. Java came as a successor, of sorts, to C++. Early Java programmers were former C++ programmers, and its designers had C++ experience (as well Smalltalk, Lisp, etc experience). As a result, many features of Java are responses to pain felt in C++. Feeling the pain of memory leaks and use-after frees? Garbage collection. Feeling the pain of segfaults and incomprehensible pointer chains? No pointer arithmetic (the party line for years was that Java had no pointers, only references). Feeling the pain of baffling symbol use in APIs? No operator overloading. Feeling the pain of aeons-long build times? Compilation to bytecode, with linking left to runtime.

I believe this pain response carried over into the culture. The pain in C++ didn't just come from the language, but from the fact that people did clever things with it (template metaprogramming had been invented - discovered? summoned? - in 1994). There was a strong association between cleverness and pain. Cleverness was therefore taboo in the brave new pain-free world of Java.

There was another point in the grandparent, and in the original post, about Java culture's tradition of verbosity. I think this is also a post-C++ thing. In C++, it takes a lot of writing to get anything done. In Java, it takes a bit less. You feel like you're moving faster when you write Java. So, as an ex-C++ programmer who has the endurance to write a lod of code, and is feeling the exhilaration of moving fast, what do you do? Write as much code as possible?

There has certainly been a huge shift back towards concision in Java, but it's not something that's completely permeated the community. There are people today still learning Java from books written by people who learned in the '90s and who internalised that logorrheic style. We'll probably never move entirely beyond it.

Maybe the language didn't have powerful tools in its core? What if getters/setters weren't mandatory, like in Scala, wouldn't we write more tiny expressive classes to hold intermediate values?

Think about this example of Dependency Injection: Why did we have to use DI? Because using statics as a dependency injector (like in Play) prevents from unit testing. How could we have solved it? By allowing inheritance override on statics. We don't have it, therefore we have Spring.

Even the Servlet API is criticized for being inexpressive [1]. They've done it so wrong that every single framework reimplements url routing (Struts, Spring MVC...) resulting in those horrible /myserviceaction.do patterns. In turn, those patterns deny RESTful apis, prompting for yet-another-framework for REST resources. We just became Enterprise [2].

I personally have no wonder why we became verbose. But it's understandable, since Java was built using community processes.

[1] http://blog.lunatech.com/2011/12/08/wrong-with-servlet-api [2] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Abstraction has a huge mental cost (I ignore the execution speed cost, because it is mostly irrelevant these days for most projects).

You need more than one case to abstract over. Abstracting "just in case" is, much more often than not, very leaky - that is, requiring you to keep in mind the details of both the abstraction and the abstracted - and requires revision when you actually need it.

Abstraction is not magic, not cost free, although Java culture is to assume that it is both. (Same criticism for C++, BTW; C culture tends to err the other way -- which, in my experience, is the better error to make)

I've been programming in Java (gulp) all my professional life of about a decade. I can totally attest to this.

Just couple of days ago in one of the code reviews I gave a lengthy explanation for using StringUtils.equals("foo", someVariable) over "foo".equals(someVariable). I could have instead just said what you've stated; prefer verbosity over cleverness :)

If code review ends with lengthy explanation over why not use "foo".equals(someVariable) or some other maintenance/readability/effectivity/other important consideration non-affecting issue, I see something wrong with code review.

http://steve-yegge.blogspot.hk/2006/03/execution-in-kingdom-...

StringUtils.equals(a, b) on the other hand clearly states in its interface document that it is null safe and there's no NPE trap.

There, I said it :). That was my lengthy argument for using StringUtils.equals!

Code reviews should focus on more important things than this, IMO.

Making code that shouldn't need to be "null safe" masks errors, and ultimately makes them harder to track down.

I love Ruby dearly, but I can't agree with this. There's a lot of being "too clever" in Ruby land. Not in terms of writing fiendishly convoluted but brilliant code (though we do have a nice subset of "code as art", like _Why's Camping micro-framework), but in terms of caring too much about elegance over things like speed and memory usage, until it comes back to bite us.

My pet peeve at the moment is Bundler and Rubygems, which while they are fantastic productivity tools when you start out, has the serious issue that the way they grow the load path means that the time to require a file grows exponentially with the number of gems. 100k+ failed stat calls on startup just to try to be "too clever" about not making people specify more clearly exactly what they are loading is no fun.

Many of these "too clever" things then starts to dictate app design. E.g. if you want to make a command line app out of a large tool that depends on a long list of gems and Bundler, you better think long and hard about making sure you defer all loading as much as you possibly can, or alternatively start up the app in the background and make a small command line app that talks to it over a socket...

For my part, I have a longer list of other Ruby practices I've come to detest than most, probably, as I'm working on a "as static and ahead of time as possible" Ruby compiler, and there's a lot of Ruby idioms that massively complicates things because Ruby developers are used to the malleability of the language, and so will often alter fairly central parts of the language even when there may be conceptually simpler ways of achieving the same that just doesn't look quite as clean.

Again Rubygems is a great example: It replaces "require". That's one of the means it uses to munge load paths. On the surface it was a great thing: it let Rubygems let people pretend Rubygems wasn't there, and yank out gems in favour of manually installing the files if they wanted to. But it came at the cost of contributing to the load path/stat mess I mentioned above.

Some of these things are in fact great no matter what, and exactly why we love our languages. But some of them come with ugly warts that we grow blind to because we understand the underlying reasons for why things have been done the way they have.

I think all languages grow these kind of warts. To me, Java has more of them than most... Java from beginning seems to have grown a culture of ceremony and abstraction that due to the language easily (but not necessarily) ends up with very verbose code.

http://hop.perl.plover.com/ - seriously clever.

Yes, I know that he says that he is negative and his praise comes across badly (he gives an example of him damning his blogging software). I suggest, if he is being sincere, that the problem is his attitude. If he isn't being sincere, then I'd say that he's not as clever as he thinks he is, or he just never had any passion for Java and so he actually hates it as he never mastered it.

In terms of boilerplate code, I'd love to see his exact examples. With annotations, I've found that plenty of Java code is actually not verbose at all. If he churned out thousands of classes when actually he could have reduced the number of classes to 50, then that's an example of poor management and poor workmanship, certainly not a problem with the language.

Here's the real issue: the article conflates a corporate environment that likes to measure productivity in klocs (or from the number of classes you create) with the tool that is being used. He even admits that he could have actually produced better code, just that nobody cared to correct him when he produced crap quality code.

However, when it comes down to it, the real phrase that comes to mind is:

YHBT. YHL. HAND.

The guy is trolling you all.

(Different languages have different failure modes. With Perl, the project might fail because you designed and implemented a pile of shit, but there is a clever workaround for any problem, so you might be able to keep it going long enough to hand it off to someone else, and then when it fails it will be their fault, not yours. With Haskell someone probably should have been fired in the first month for choosing to do it in Haskell.)

The languages he praises so highly are now put down. Correction: in each case, he's dissing the programmers who wrote the crappy code and caused the project to fail, and he's damning the terrible management that didn't have good enough leadership and oversight to prevent the project failure.

Seriously, this is likely asking proof regarding the presence of sun during broad day light.

>>With annotations, I've found that plenty of Java code is actually not verbose at all.

Again. Are you really serious?

>>If he churned out thousands of classes when actually he could have reduced the number of classes to 50, then that's an example of poor management and poor workmanship, certainly not a problem with the language.

You certainly haven't ready his book 'Higher Order Perl'.

Indeed. And?

No disrespect to the guy though I'm sure he is and general respect for publishing a book like that.

I guess just limited exposure to Java

Why is the age of this book relevant? It's not an overview of the basics. it's a 500+ page exploration of Perl's functional programming features, a topic rarely (if ever) covered in this depth.

Time to re-read it, because when I first read it, I had to skim some parts. Probably applies to Python.

Even the best master carpenter wouldn't be able to build something as simple as an end table if he were given a pickle to use as a hammer, and an onion to use as a saw.

Also, have you heard the saying: A bad workman blames his tools

Well, it sure did a good job of identifying a lack of skill of folks on HN, so maybe it isn't quite so crazy after all.

Apparently you missed his second sentence:

> The first question on the quiz is a triviality, just to let the candidate get familiar with the submission and testing system.

Sure, you can overdesign in any language, but some inner language characteristics of Java lead to it more than other languages do. Copying input to output is a statement, if you think about it in in a logical, human way: "I want you, program, to perform the action of copying this to that". But Java, unlike some other languages forces you to say: "Make a class, make a main function because YOU need it, Java, and only after please do what I really want and copy that input to the outout".

In python, for instance, I'm in control of whether making a StreamCopier class, a copy_stream() function or just get to the core of what i want and write "print(input())".

Generally speaking, in most dynamic languages if I want to access the to_string() method of something passed to a function, I can pass a list, an int, a Duck object and till it has a to_string() function I'm good to go, or I can even monkey patch to_string() and call it a day.

In (too) many cases Java the language forces you to make instances over instances and implementation of interfaces and the like just to access the data you need in the way a framework or a method wants, not you, and often this is frustating because you see your data "just there" and the language fights against you preventing you to acccess it in an easy way. I need to call to_string() of SomeClass but I have an instance of SlightlyDifferentClassStream? Good luck with that, maybe the only possible way is to create a DifferentClassConverterProxy just to have a DifferentClassTranslator, extend TraslatorStream, feed it with my SlightlyDifferentClassStream and have something compatible with SomeClass.

This is not only true to Java, some of these "problems" arise from it being a statically typed pure OO language (a very good thing on my book when it is not implemented in a dumb way) that is put to shame by a cleaner implementation of the same principles like the one seen in C# that, on top of all, also offers a powerful dynamic programming, lambdas and so on.

Also, Java suffers from an enterprisey background. I consider a language environment to be a very relevant part of a language itself, and Java has promoted the proliferation of ridiculous bahamut frameworks with a freaking large number of classes and instances "just in the case someone needs to extend it".

These are facts, not "Har-har-so-many-classes".

Take a sane implementation of a web framework like Django. It is an opensource project born from the needs of a small group of developers. You don't have "so many classes" if you only write those that you really need to solve of your problems, and the project progresses from there to embrace the everyday, real world needs of a larger group of contributors. Most Java frameworks I've worked with really give me the tangible perception of a large group of monkey developers programming them following line by line a technical specification bible of thousands of pages written by a council of architects with business people yelling at them "mooooore, mooooore, we need more of all of this so that we can sell to ANYONE!"

Wow. What a pompous thing to say.

How does this have 91 points and is on the front page of HN?

Per the "most horrible answers were in Java", personally, I think he's missing selection bias, in that many newbie programmers who wouldn't know what they were doing in any language, think they "know" Java because they took a class on it.

I have no problem reading critiques of Java, not concise/etc., and like Scala/etc. as much as the next guy, but "relieved of the responsibility for producing a quality product"? Wow.

I suppose I'll add the disclaimer that if his 3 years of putting in time writing Java were doing J2EE, then I'll understand where he's coming from. But that's not the language.

> Wow. What a pompous thing to say.

I don't think it's pompous, I think it's actually self-deprecating. I think he's confessing to his perfectionism - to the fact that, if given a tool like Haskell he'll pursue some perfect, idealised program, because if you're not going to produce more beautiful code in Haskell then why are you using it? Java serves as the antidote here because nobody ever judges Java programs on their terseness, expressiveness or subjective 'elegance'.

When he says 'quality product' he's talking about the aesthetic qualities of the code, not the end result. When he says he's relieved of having to think about this, he means he can focus on shipping rather than perfection.

Because HN is full of Java hate, where all cool guys would never touch the JVM.

Meanwhile the world moves along and JVM based products get deployed every day.

i hate java. i hate java as much as i can. and i love hating java. java must be hated. java must be estranged. java must die. but definitely not the jvm. that's a beast i love. i use clojure and fantom on the jvm.

I agree [with you] that Java invites you (nay, urges you) to use good engineering practices.

At least exceptions ensure (...) - at least in Java - that errors are forced to be dealt with in a certain way.

bulte-rs - orkoden: 0 - 1; I love Java for it's exceptions (and "the IDE's" telling me to catch them all).

I learned more about you than about Dominus with that comment.

Here is a link to his well received book, by the way: http://hop.perl.plover.com/book/

(But the book you should probably look at to understand the world better, is "Perl best practices".)

Edit: fuzzix -- you are certainly right about most useful modern books, I was making a point to what I comment on. The idi.. cough.. Which insinuated that readable code is an unknown concept to typical Perl programmers.

It is true that one way to do something is foreign to Perl culture. It is also true that the best Perl code is pretty unreadable if you expect to read it as a C/C++/Java programmer. Perl is a very different language, and good Perl code reads very differently.

I am not going to get in a language war of Perl vs Java. Both languages have their places. I prefer Perl on the server. I prefer Java on clients I have no control over because at least I can hope it has a working JVM.

Readable Perl code is just different from Java. Let's take an example:

     package Foo;
     use Moose;
     use PGObject::Util::DBMethod;
     with 'PGObject::Simple::Role', 'Baz';
 
     has id => (is => 'ro', isa => 'Int');
     has name => (is => 'ro', isa => 'Str');
     has description => (is => 'ro', isa => 'Str');

     dbmethod int => (funcname => 'foo_to_int');
     dbmethod get => (funcname => 'get_foo');
     dbmethod save => (funcname => 'save_foo');

There is nothing inherently unreadable about Perl.

[1]http://ledgersmbdev.blogspot.com/2014/02/in-praise-of-perl-5...

The perl code I've seen in the wild generally doesn't look like that though. Is that more an issue of the age of most Perl code? Or are some people still writing 'old fashioned perl' even if it isn't the recommended way anymore?

So it's complicated.

Also keep in mind that a lot of CPAN modules out there began back in the 1990's and are still being developed today. I know. I am now a maintainer of several, and the code isn't often that pretty.

But this is the benefit of being encouraged to think about elegance of code: one improves.

But one can write amazingly beautiful, clear, and elegant Perl or one can write rubbish (after all good Perl doesn't take much work to maintain). Most of my work is either maintaining rubbish or (I hope) writing nice, maintainable code.

Some of the non-CPAN code I have (the rubbish) is sufficiently unmaintainable that the only way of dealing with it is to refactor with a chain saw and avoid touching it otherwise.

See e.g.

http://search.cpan.org/~mauke/Keyword-Simple-0.02/lib/Keywor...

http://search.cpan.org/~mauke/Function-Parameters-1.0401/lib...

What seems to happen the coming years in Perl 5 (unless the Python language trolls manages to discredit it enough to kill it :-) ) is probably gelling around language [syntax] extensions and Moose going to the Perl core.

But it will still keep backwards compatibility.

(And I write horrible Perl code most days myself, as one line liners. :-) Best damn shell functionality on this planet imho, along with Emacs command line editing.)

Your opinion is a complete generalisation and makes you sound profoundly ignorant. Language choice != coding ability.

1. I like Perl.

2. Imo, if someone doesn't see advantages to TSBOAPOOOWTDI then they don't understand it -- and the same is true of TIMTOWTDI, TIMTOWTDIBSCINABTE, and many other useful generalizations.

3. I love readable code.

I think the above three statements also apply to Larry Wall (the creator of Perl) and many others in the Perl community.

Imo "Someone who likes Perl is not going to be appreciative of 'one way to do something' and 'readable code'." is not a useful generalization.

If the universe applied different rules to me than everyone else I might advise folk to take any opinion from someone who generalizes without sufficient respect for the dangers of generalization as coming from someone who generalizes without sufficient respect for the dangers of generalization. But it doesn't, so I won't. :)

>>after having been in a position to maintain some Perl code before.

Sigh... You "supported some code" and know how modern Perl looks like?! :-)

Could you carefully explain e.g. the problems with Moose and the latest [syntax] extensions you find on CPAN?

To start with.

Making wild claims like that without support makes you seem like a language war troll or a complete asshat. To be taken seriously, show that you know what you make such big claims about.

Edit: And since you have nothing to say about the subject matter -- what is it in the Python culture that brews such fanatic language war trolls? (I assume you're a Python guy?)

No, I am questioning your specific claims about things you obviously have no clue about.

That was a pathetic attempt to change the subject. I stop waiting for a serious answer from you now. Bye.

Edit: And if you're a high schooler, sorry if I'm brusque. There is too much of this language war garbage on HN, I want to keep the quality up.

http://www.jwz.org/doc/worse-is-better.html

1) Java has the paradox of choice problem. Unlike say Python, there are so many ways of structuring code based on the extreme flexibility of available frameworks and so many different libraries that it gets complicated fast due to sheer number of choices, unless you're really experienced and you already know what you want ahead of time.

2) Java's verbosity necessitates heavy abstraction through many patterns. Which patterns will you choose for your given problems? It's still somewhat easy to write spaghetti unless you have both the experience and discipline to prevent it.

Python isn't perfect, but its one way to do something philosophy leads to "relieved of the responsibility from doing 'the right thing'" unlike Java. People who use Ruby kind of experience this as well if they use Rails.

In Java you're going make similar choices. which collection implementation am I going to use? Which hash implementation am I going to use? and so on, but that's not really the big problem.

Java's strong type system also comes into play. Yes it's easier to read, debug, and performance get's a boost, but you have a think more about designing it (abstract classes, interfaces) and refactoring is harder. Yes things like generics have made this a little easier.

The best comparison you can make about the languages comes down to IDEs. You don't really need an IDE for Python, while an IDE is pretty much a must for Java.

The hardest part about java isn't the language itself; it's the philosophy. In my 10 years of experience with java outside of academia in places like telecoms, banks or eccomerce sites, you're likely going to be using some dependency injection framework for Java. Do you use Spring or Guice? ( Most likely) If you use spring, do you use annotations or XML schema? If you use annotations how do you structure it? What's the scope of the bean classes? The list goes on and on.

Java's (meaning the ecosystem as a whole) biggest strength and weakness is its extreme flexibility and choice that it gives its users.

Conversely Python (meaning its ecosystem as a whole) doesn't give you much of a choice so there's less decisions that have to be made.

I've never seen a case where that choice was important; you can just use ArrayList and LinkedHashSet everywhere. Whereas the python examples are actual tradeoffs, and your code will be worse if you pick them wrong.

> you have a think more about designing it (abstract classes, interfaces) and refactoring is harder.

Disagree. Refactoring is easier in Java because your IDE can tell you what's broken (and even make a lot of changes for you); in Python you have to hope your test coverage is good enough.

> you're likely going to be using some dependency injection framework for Java. Do you use Spring or Guice? ( Most likely)

Choice of libraries is important in any language, and IME it's much more possible to get it wrong in Python. I have a perfectly good website backend from a few years ago, only it's built on TurboGears which is now defunct. PIL was about as big and popular a Python library as they come, but I understand it's now unmaintained. There are about 5 different XML parsers, in Python as it is in Java.

> If you use spring, do you use annotations or XML schema? If you use annotations how do you structure it? What's the scope of the bean classes? The list goes on and on.

Those are choices you make, but you make them once at the start of the project, and again it doesn't matter so much if you get them wrong because you can trust that all the options will be maintained for a while. In Python with no explicit IoC container you still have to solve the same problems, so you end up making the same kind of decision again and again.

You shouldn't. Sometimes you should be using CopyOnArrayList. that's one example.

> Refactoring is easier in Java because your IDE can tell you what's broken

It's harder because there's more code to sift through and it's easier to have bad design.

> Choice of libraries is important in any languag

It's not really the choices of libraries that's the big killer in Java. It's the freedom of usage of those libraries. Spring is a good example of this.

> Those are choices you make, but you make them once at the start of the project

This is easy to say for veterans. Not so much for newbies.

TFA is talking about simply not caring. Which I find an awful opinion. There's a really big difference between a well designed, well built Java product/library and a badly designed, poorly built one. The Java ecosystem being so massive, you can notice examples of both everywhere and the difference is night and day.

Java does in no way relive you from the responsability of producing quality. At times it makes it harder, as you need a lot of knowledge and extremely good taste to do the right thing, instead of sucumbing to "best practices" that are perpetuated as myths or instead of adopting poor libraries, just because they are popular.

Example: java.util.Date / java.util.Calendar versus Joda Time.

There's no surprise that this is the culture here. Need I mention the term "blub programmer"? Could anything be more elitist and offensive?

Off the top of my head, right now, in this text box, without google, I can't write the code to copy standard input to standard output.

System.out.println(System.in)? That's wrong. You need some kind of InputReader, or BufferedInputReader, or Buffered...something. I think System.in is an InputStream, so presumably I need to do new InputReader(System.in)? Or BufferedInputReader? Should I buffer the output?

Ok, let's do some API googling (ie, not StackOverflow).

So I was... pretty wrong. I think what you want is:

public class CopyInput { public static void main(String[] args) { while (true) System.out.write(System.in.read); } }

I haven't tried to run this though.

In my defence, I have never, in all my years of working, had to ever read standard input, let alone write it out again.

Don't tailor from-memory standard library questions to bits of code that almost nobody ever has to use.

For example:

Whenever I'm dealing with a data processing pipeline I tend to design things as if they would be used from a unix command line. I tell the team to make their classes etc as if they would be wrapped with a simple chunk of code to parse a text stream then serialize to it later. During the course of testing, I almost always will then write those tools to allow simple command line pipes to push test data around. It helps prevent reliance on certain toolsets and certainly helps stop us from conflating bugs in our code with bugs or operator error about a pipeline framework. Later we can go back and more closely integrate with the chosen operating environment, if performance demands it. On the other hand going from a situation where code is written to the environment and migrating to another environment can be very daunting, difficult and error prone.

So seriously? You almost never need to read & write to streams?

Again, most of us write real apps, not command line utilities.

Yeah, but you've probably done a read and write independently. This is just about joining the two together.

> There's a method in one of the apache commons libraries for that.

Yup, and that's great to use that, and you'll no doubt end up with more efficient code most of the time if you do. But... you still should be able to write correct code for reading bytes from one stream, writing to another, without losing data in between.

With access to Google and the library documentation sure, but I don't use those APIs often enough to be worth keeping in memory.

Why the heck would you need Google

> and the library documentation

It's an online quiz.

> sure, but I don't use those APIs often enough to be worth keeping in memory.

You don't worry about it, but it tends to accumulate in one's mind anyway.

Here's the thing though. People are posting solutions on HN... and getting it wrong.

I guess I've been stuck in webapps and NoSQL libraries for a while now.

Doesn't matter. For this problem it is just a conveniently available InputStream. How often do you read from an InputStream? I'd hope the answer to that isn't 0.

> I also programmed in Java for nearly a decade in the late nineties till about 2004 and have never used System.in for anything.

Okay, then change the problem to implementing this interface:

    public interface Copier {
        public void copy(java.io.InputStream in, java.io.PrintStream out);
    }

Your interface does not change the problem, but it does phrase the problem in a more familiar way and would have been much more easy for me to respond to (in my Java hey day that is).

It's an online quiz. You don't have to do it from memory.

Java didn't grow up in the world of unix where scripts that read from stdin and write to stdout get chained to produce pipelines. It grew up in the world of long-running stand-alone applications that communicate over sockets (like web applications). Java, because of the virtual machine, has a particularly slow start-up time and would be a poor choice for implementing mini pipeline components like this anyway.

import java.io.*;

public static void main(String[] args) {

  byte[] buf = new byte[4096];

  while (true) {
    int numRead = System.in.read(buf);
    if (numRead < 0) {
      // hit EOF, terminate
      System.out.flush();
      System.exit(0);
    }
    System.out.write(buf,0,numRead);
  }
}

    public class SimpleJavaTest 
    {
        public interface RunnableEx
        {
            // can't use Callable<Void> because that run method needs to return a value
            public abstract void run() throws Exception;
        }

        public static void main(String[] args) 
        {
            // write standard in to standard out:
            uncheck( () -> {
                int c;
                while( (c = System.in.read()) > -1)
                {
                    System.out.write(c);
                }
            } ).run();
        }

        public static Runnable uncheck(RunnableEx r)
        {
            return () -> {
                try
                {
                    r.run();
                }
                catch(Exception e)
                {
                    throw new RuntimeException(e.getMessage(), e);
                }
            };
        }
    }

... And here's a fine example of Java culture.

2 lines do stuff, everything else is fluff, and it is considered prettier.

BTW: I did not run this specific code, but dropping the buffer is likely to make this code take much, much more CPU (unless HotSpot is much better these days than it was in 2010 when I last used it). That's another pillar of Java culture - care not about performance.

Disclaimer: I didn't test this, and any mention of performance requires testing, rather than reasoning. I don't have a Java compiler handy anymore, or I would test it.

e.g. if the File implementation had an internal buffer (C stdio's "FILE " does), and the read from that* buffer was inlined (from my past experience up to date as of early 2011, HotSpot doesn't, but LuaJIT does), it might not make any difference.

Seriously, LuaJIT does things I've never thought I'd see a compiler (JIT or AOT) for any language (dynamic or statically typed) do. I used to reply to "sufficiently smart compiler" with "one hasn't appeared yet, despite at least 3 decades of waiting". But LuaJIT has appeared.

Yeah, but there is nothing different from this and having to copy data from an input stream to an output stream. If you can't remember how to do that, it kind of raises the question of what you were doing in Java.

Not knowing if you need to buffer is actually fine in my book. That's an optimization thing. Not knowing how to make the code correct though...

[1] http://en.wikipedia.org/wiki/Pipeline_%28Unix%29#Pipelines_i...

Ignoring that, what I like about java is that my programs are clear, and that once I compile my programs, they just work. I can refactor my code, and the compiler makes sure that I don forget anything. I don't love it they way I loved Perl or C. But when I write Java, I feel confident that my program is not going to break; and even if it breaks a stack exception is going to point me directly to the offending line.

Of course you don't have to use 25 Design Patterns at the same time. But lets not blame Gosling for that, that is the fault of the "Enterprise Architects", I still think you can write good tight java code.

I have no problems with Java. But I have routine fits of frustration during P1 issues when I have to dig piles and piles of code to analyze simple things. Often its like there are 9-10 hierarchy of classes each doing something very simple and passing the burden of implementation to things below and down there you see more and more verbosity, boiler plate, getters/setter and pages of exception handling.

In some way Java too is a write only language.

Totally agree.

Dijkstra wrote "a case against the goto statement" (which was renamed "Goto considered harmful" by the editor of the journal) when he saw these things happening to flow control because of GOTO.

These days Java (and C++, to a lesser but similar extent) has just as much "class spaghetti" as the "goto spaghetti" of the old days - and many programmers have no idea that it can actually be better.

The library is too verbose and over-architected. My idea of a good match would be the Java language with Python's libraries.

There's a balance. Neither is optimal. (I think C# comes very close to what I'd call "perfect", but it doesn't run anywhere I'd want to use it.)

Sure, it's a fine way to do math, and you get all the same answers, and it's not really much slower. But I didn't like doing it then and I wouldn't like doing it now.

Programming in Java feels like doing math with blocks. I have all this code that needs to be there, and I understand why it's there, but I still find its inclusion frustrating. Java is a fine tool, and can be used to build great stuff, but it's not to my taste.

[0] http://i.imgur.com/PSd5k7q.jpg

The most probable reason for the failure is because Java is not used in industry that much as a shell programming environment. The most common use case for Java is as a server-side, long-running server, with C++-like performance and without C++-like headaches. I work with algorithmic trading engines in my job. Though I trade personally these days and the orders are small, the engines I implemented for banks typically handle $250m worth orders per stock exchange. I have NEVER, not in a single instance in the last 5 years, have had to read from stdin in Java. Why : in my particular niche in my industry, input comes via a socket that is abstracted away by an engine that implements the FIX (Financial Information eXchange) protocol. For all practical purposes, in the finance industry, the FIX library / server IS stdin and stdout. This doesn't make a colleague of mine who forgot how to access stdin in Java a nincompoop. It's a failure to remember what is rarely used, not a failure to perform basic job duties. See the difference?

I believe the author is / was a Perl expert? That's why he thinks being able to read stdin is "so basic". I challenge the author to confront his prejudices : hire a few candidates who fail the stdin / stdout test. If they are allowed to do the damn work instead of jumping through your Perl-shaped hoops, they might have actually done quite well on the job.

Similarly, many Perl programmers would fail a test devised by someone who is used to Java.

If the test is open book, then "I can't manage to look up how to deal with stdin and stdout in Java" is decidedly more damning than "I can't remember".

Further, if there is a requirement that you use the same language for all of the answers, choosing Java when you know Java best makes sense. If not, choosing for that problem Java (when you don't firmly remember how to do normal IO!) is itself a bad decision, when you likely would have got full marks for

    #!/bin/sh

    cat

Want to show off to the web CRUD hipsters, you can go Groovy, Grails and Play framework.

Want to show off to the Enterprise architect astronauts, you can go Hibernate, Spring, ElasticSearch and JBoss.

Want to show off to the Big Data ivory tower academics, you can go Weka, Lucene, Hadoop and Scala.

Want to show off to the esoteric language hipsters, you can go Clojure, JRuby, Jython, JScheme and Rhino.

Sun Microsystems and applets on IE6 live on in my big heart warmed up by hot cup of cappuccino beans.

It reminds me of a great post by Coda Hale a couple of years back where he was explaining why he switched back to Java from Scala (which was hot shit on HN at the time):

http://codahale.com/the-rest-of-the-story/

"The world has yet to take me aside and ask me for my opinion of it, and in the past few years I’ve found that it’s far more profitable to build things rather than tilt at windmills."

It's an environment that needs an IDE because of the large number of libraries and the large number of features delegated to libraries rather than the core language (which is an architectural decision that I approve of, BTW)

As for the java-hate - in my 10 years of java-programming it has always been there. They used to complain about it not being portable enough, not performant enough, GC-pauses, start-up times, and lately that it's to verbose and non-functional. But java has persisted, and only improved over the years. I'm happy I've been able to (mainly) program in the same language for so many years. It makes me realize just how long it takes to truly master a programming language (or perhaps programming in general). I guess that's why they say "..it takes 2 weeks to learn a programming language, and 10 years to master it". It's an art, and the language is your tool.

I was complaining that Java was verbose in 1999.

The codahale post is old news referencing issues which have already been fixed.

... it's not on HN. It's among the users to languages that aren't Java or C#.

Some people obsess over the tool itself. My tool has these 10 features, and it was hand crafted and it can solve 8 Queen problem in 2 lines and it has monads or a cute puppy for a mascot and so on. People who use tools obsess about them, and it kind of becomes the end not just a means to an end. They would read about the new features in the language, they would run over tutorials in their free time and so on. There is a good amount of pleasure derived from fawning over the tool itself.

Others don't care about the language or the framework, they just want to job to be done and get paid. It turns out that some part of code they are working on is written in FORTRAN, COBOL, or (oh the horror!) MUMPS, that won't bother them much. They'll just figure it out and fix the issue. The pleasure comes from getting paid and solving the business problem at hand.

Both are extremes and there is a continuum between the two on which most people fall. Neither extreme I think is healthy and at the same time there are good parts about each one --

Someone who cares about the tools they are using will probably also use the tool better and more effectively. Someone who is picky about the type of hammers and their design and knows the history is also probably pretty good at hammering nails in. They might spend $1000 for a titanium hammer but hey they will be good at it.

Also someone who cares to get the job done and derives pleasure from solving a business problem, might just be the one keeping the product/company/startup afloat. Making money and delivering products is the top goal of most companies. This often means what seem to be boring, old, broken, unfashionable frameworks or tools. But so what, look we are still getting a paycheck!

There is a validity in both.

Yes, in the broadest sense of the word, Spanish is a tool. So is a programming language, but the analogy is stretched and stale. The image it puts in people's minds is not super helpful. And if we must use such a broad word as tool - let's acknowledge that it's really a collection of tools (every API, bit of syntax, and language feature is a tool).

I still say it is a tool, just a tool with many buttons and settings. English is a natural language that I learnt (it was my 3rd natural language) primary to read and understand computer related materials (books, keywords, instructions). It was absolutely a tool just like a hammer is a tool to drive a nail in. It turns out to be a very beneficial tool but a tool nevertheless. I would never bother spending time learning the etymology of words or finding all the tenses or declensions (but some do and derive great pleasure from that).

Most of the time, there’s a balance to be struck in the tool you choose—if we did it in Haskell or OCaml or Scala, it’d probably be more correct and easier to maintain in the long run; but we are a startup that is likely going to run out of funding in a month or two, and if we hack it together in Ruby or Python or Node then no one will fault us and we can rewrite it in a good language later if we have the budget of time and money.

So while Haskell might be my primary language at work and play—and I see the tremendous value it holds for experienced developers—when beginners ask me what language they should learn, I invariably say: “Java”. At this point, it’s the essence of mediocrity, the dead middle of the bell curve; you can go better or worse from there.

While I don't have actual proof of anything (and I doubt parent has either), removing classes of issues is a big win. Not to say that any of the three languages you list is a silver bullet, they all come with a long list of drawbacks. You just have to pick which drawbacks you dislike the least.

> For Haskell in particular, if you change assumptions in your type system you are going to have a lot of work cut out for you which seems to go against 'easier to maintain'.

What do you mean by this? If your types are fine-grained enough (which you can absolutely do in Java, at the cost of a lot more code), and you change your specification, you will need to change your types. But if you did not have fine-grained types (in any language), you're going to be fixing errors at runtime instead. If you're not going to leverage the type system, you may as well work with Python, you'll get the same effect with a lot less code.

Now maybe Haskell really would be easier to maintain - but it's something that needs proof and hard evidence. To use a car analogy for the GP's post, "I could buy a Ford because it is safer and easier to repair, but sometimes I'd just buy a Chrysler because it's cheaper and easier to purchase". There's nothing wrong with this statement if you have real numbers on the two different cars - but making the statement based on some kind of assumptions on what you think the two languages will or won't do is pure folly.

If I start a project tomorrow in Haskell or Python, the GP's post is saying my Python project will be completed quicker but be less correct. He is also saying that the amount of time I spend maintaining my Python project over the next few years will be higher than time spent maintain a same-feature Haskell project. There is absolutely zero evidence I have seen anywhere that this is correct and from experience it depends far more on the project itself and where the strengths of the language (and libraries!) lie than the language itself.

It depends on what you do. If you (say) add a new field to an existing type, this will screw up pattern matching. It's a bit inconvenient, but typically not a big deal. On the other hand, if your previously non-nullable String field becomes a Maybe String, you're going to have to update every location where you access it... and that's exactly what a reasonable programmer wants to do. Unfortunately, you can't encode this in Javascript, so you're going to resort to 'grep' (good luck if you have the same field name for several objects), or forget about it and get runtime errors. Sure, in theory you can rely on your Javascript unit tests to detect the error, and you may be right in practice, or you may be out of luck.

Generally speaking, Haskell has its fair share of problems, but it's not one of them.

> If I start a project tomorrow in Haskell or Python, the GP's post is saying my Python project will be completed quicker but be less correct.

It definitely matches my own experience (it obviously depends on your proficiency in both languages, and Haskell will have only marginal advantages if you use String everywhere because types are hard).

> He is also saying that the amount of time I spend maintaining my Python project over the next few years will be higher than time spent maintain a same-feature Haskell project. There is absolutely zero evidence I have seen anywhere that this is correct and from experience it depends far more on the project itself and where the strengths of the language (and libraries!) lie than the language itself.

It's the kind of thing for which it is extremely hard to get any evidence for (and not only in Haskell vs Javascript debates), for obvious reasons. The best you can say is that the stronger guarantees of correctness offered by a strongly-typed program ensure that it makes it much easier to detect regressions. On the other hand, if, say, there are no third-party libraries for the problem domain at hand, strong typing will not magically fix that.

(reason for liking Java)

Well, here are some other reason for liking Java: https://medium.com/i-m-h-o/da3b2c180e9c

But I really believe the future of software is affected more by having better programmers rather than having better languages.

Yes, it helps to have cool languages like Julia, Nimrod, Rust, even Scala (which I think is the best statically typed JVM language out there). But I tend to think that a good developer will be good in any language, Haskell, C, Java or LOLCODE.

I think that a good developer "forced" to use Java will find tools that bring out the good parts of the language: Dropwizard, Play framework / Akka, even latest versions of Spring and Java EE are much more convention over configuration and lightweight than before. They will use Guava and Apache commons to streamline common Java verbosity and bloat. They'll use Java 8 which allows much more robust and concise syntax to common problems.

But I don't think that the language is the problem. I think that a great developer will be able to tackle any problem with the language itself easily, because the real problem is not how to implement X, but more what is X. Designing the software correctly is the main problem at hand, not how to move input to output. This is what stackoverflow is for.

One last point about this all "I hate/like Java" type of post

1) If you write Java for your day job and hate it, either try to introduce something else (Clojure / Scala / Java 8 / Kotlin) If you can't introduce any of these then either accept your fate or just quit and find another job. If you can't find another job, then perhaps you deserve to stay and write Java so stop whining, it's not that bad (and one day you'll get to use Java 8).

2) If you don't write java for your day job but as a freelancer - start getting other non-java gigs. Not so many non Java jobs? well, continue to write Java bashing blog posts until people will stop using it I guess...

3) If you don't write Java for your day job or as a freelancer, then just stop complaining about it. There are million of other things (not just programming languages) out there worth complaining about. They can use your writing talent for a better cause.

On average, I believe the quality of programmers will decline, simply because as they demand rises more and more people will come to the field that don't do it out of interest/passion but because it a profitable profession. Not that this is already the case today - I think it's a trend that's already begun and will probably continue this way.

This attracted a lot of people who weren't really passionated about programming.

Now years later I was hiring during the bank crisis and I interviewed CS students who got their degree but couldn't find a job. I couldn't understand that if you have your degree and are out of job in 2 years you haven't written a single line of code on a hobby project. But these people exist.

These people will be always there in any field.

Only new Java projects would actually use the Java 8 features anytime soon. Existing Java codebases will stick to their Java 6 installation for a long while. It could be years before lambdas are used to any significant degree. Look at how long it took for many Java 1.4 shops to actually upgrade to Java 5, let alone encourage developers to use its features. Even today a lot of places still allow and even encourage use of collections classes without the generics specified.

As long as you aren't writing Java code on Android, in which case you're still stuck at Java 6 (with a very small subset of Java 7 features that were added 3 years after Java 7 came out).

Not the fault of the Java language, really, but it is incredibly annoying how unclear Google has been on the future of their dialect of Java post the Oracle lawsuit.

https://code.google.com/p/googleappengine/issues/detail?id=3...

The funny thing is that google's own GWT requires it now.

Of course, if this is any indication it'll be several years before its safe to use even JDK7 features considering Android's update trends, let alone JDK8 ...

The NDK has all the support I need, when coupled with something like Qt/SDL/openFramerworks and C++11 feels better than Google's Java fork.

One worth noting: If existing code is using Proxy.getProxyClass and the Constructor.newInstance method to create a proxy instance, it will fail with IllegalAccessException. RFE 4487672

> If existing code is using Proxy.getProxyClass and the Constructor.newInstance method to create a proxy instance, it will fail with IllegalAccessException if the caller is not in the same runtime package as the non-public proxy interface. For such code, it requires a source change to either (1) call Constructor.setAccessible to set the accessible flag to true, or (2) use the Proxy.newProxyInstance convenience method.

To end up in that specific condition is fairly difficult and usually means something is wrong with the code to begin with. It's still a very easy fix in any event (adding in 1 extra line of code before the call).

(yeah, shouldn't happen in the best of all possible worlds, but may still happen anyway)

Recompile away, stuff just works. Add lambdas to your code, compile. Still works. This isn't like 1.2 where you were adding collections classes (arguably for the first time) or 1.5 where you encounter generics.

He sounds like someone who never learn Java in the first place. Neither he learned what it is good for, what it is bad for. I think that if you interview in some language, you should understand what kind of problems are easy to solve in that language and which are hard or never done.

If I have to write libraries less input output example in interview, my code will be ugly and long. I'm not saying that interview should not ask these questions, it tests whether the candidates ability to find his way around api he uses rarely. It is needed skill, so no problem there.

If I have to design complicated system, adjust it to changing requirements and maintain it for years, I feel most comfortable in Java. Type safety, tools and language itself allow me to focus on the system itself and how systems parts cooperate with each other.

He also sounds like somebody who is biased against whoever uses java, because he worked once in bad java shop. It sounds that it really does not matter what those people would do, they used java, so they are incapable in his eyes.

"In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated."

Guess I was right about learning Java.

Better programmers will likely make better languages. Undoubtedly a good programmer can learn to program in any language, because its the same process, but languages do certainly have their limitations.

Sorry, no. That's just too far. Imagine being handed a codebase of LOLCODE.

I hope to God no one ever was or will be handed a codebase of LOLCODE for a "real" commercial system.

But if anyone ever does, it will sure be fun to hear about it in a blog post.

I consider myself a fairly competent programmer, and I have a little knowledge of Java, including building GUIs and so on. Here's the Hello World program off the top of my head:

    public class HelloWorld {
      public static void main(String[] args) {
        System.out.println("Hello World.");
      }
    }

Bingo! I've found System.in, and it says it's an InputStream. So now I just need to find ... ah ... there are three of them. Is System.in a java.io.InputStream, org.omg.CORBA_2_3.portable.InputStream, or org.omg.CORBA.portable.InputStream? The documentation doesn't say.

Well, I have a vague idea of what CORBA is, and I don't think I'm using CORBA here, so it must be java.io. Good first problem solved. Now, what methods can I use?

    abstract int System.in.read()
    int System.in.read(byte [] b)
    int System.in.read(byte [] b, int off, int len)
 

I figured it out in the end, but only through pure luck: I need to wrap System.in in a java.io.InputStreamReader.

? In most runtimes stdin is opened before you start. Certainly is true in the case of Java.

> So to answer the interview question, all I need to do is open stdin.

No, you also need to "open" stdout. More importantly, you have to figure out how to read and write to streams without losing data (which you'd think would be easy but evidence indicates otherwise).

The fact that I/O management is cumbersome in Java doesn't relate to the ability of Java programmers to provide value.

Doing it through, say, docs.oracle.com to check what's the stdin interface - that is quite easy, but writing it on a whiteboard from scratch would fail many Java developers.

People keep thinking that there are special functions involved in this solution for interacting with the console (which by itself is telling). Let's pretend it was just copying from an InputStream to a PrintStream. Those are both interfaces that most Java developers should be quite familiar with.

The unix approach of treating most things as streams of bytes or lines tends to be abstracted - if I'm writing socket-based communications, then an InputStream exists there; but if I'm making web requests, then it's through a library where no streams are exposed. If I'm writing a logging library, then a PrintStream exists there; but if I'm doing proper logging, then again, it uses a library that doesn't expose any streams to a public interface, just the appropriate methods. Custom file formats would involve handling streams directly, but general practice in line-of-business apps nowadays is to never do that - you just [de]serialize to json/xml/something else standartized; and again that's done by a library that uses streams but doesn't expose them.

These things are trivial to do in java, but what I'm saying is that java is very often used in large codebases that don't touch raw streams at all. Students in java lessons use InputStream&PrintStream, but after starting work, promptly forget what the methods are called as they're used rarely.

No you wouldn't, unless you're working on some tiny project where using raw servlets might be justified (though I'd be highly suspicious of anyone doing raw servlets). Most any other framework will provide higher level abstractions such as Play's Iteratees or variations of sendfile to handle the streaming for you. You're job is usually just to configure the proper marshaling setup so that your higher level object(s) delivered by your controller methods are properly serialized by the lower levels of the framework.

Occasionally you may need to actually write marshalling code but you should definitely be wary that you're doing it wrong if so.

3 years is about the amount of time it took me to get a false sense of security in my understanding of a language, imo. After 3 years i thought I knew Java. After 3 years I thought I knew Ruby. I was wrong.

BTW- if I were to receive a question on my application asking how to read stdin and write stdout, that would be a bad sign.

> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.

Many quality products I use have been written in Java.

> It was pleasant to not have to worry about whether I was doing a good job, or whether I might be writing something hard to understand or to maintain.

Though, I understand the intended meaning of "Java is too verbose", You can write code in Java that is easier to maintain. Java is not an excuse for poorly written code.

> The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands.

You get paid to write maintainable code that does what is intended. It was never "out of your hands".

I no longer like Java as much, but I don't think Java ever was a reason to sit back and let bad code happen.

It occupies a weird middle ground where you give up the capability to code to bare metal or easily interface with C functions in exchange for nearly being able to quickly and succinctly create powerful abstractions.

There's not a whole lot wrong with it, but I don't think I've ever been using any other language and missed something from Java. But when using Java that experience is common and I find the amount of effort you have to put in to not write repetitive code is annoying and results in overly complex architectures.

I'd say this ground is well and truly occupied by Common Lisp. Java occupies some other ground which is neither quick nor succinct.

At MIT, in 2003, there was a class called 6.171 Software Engineering for Web Applications. The final project was, in fact, to design and make a web application. It was very open-ended and it could be in any language you wanted.

This particular course soon stopped being taught, because a large number of people failed the final project. They could not make an application that functioned in any way by the time the course was over. (Keep in mind: 2003. There weren't really any easy answers to web applications.)

Many people had chosen to do their project in Java, because that's what they had learned and used in the prerequisite course. And in particular, over half of the people who chose Java failed.

(By the way, the course on web applications is now the main project-based course on software engineering at MIT, and it is now taught in Ruby.)

Which one is that? As far as I can tell, the "new" 6.170 (6.S197) uses Python (or at least used it in the fall of 2011).

(I gather by its new subject number that it is no longer a part of the core requirements, being largely supplanted by 6.005, which ironically appears to use Java. Of course, when I took 6.170, we used CLU. Boy, am I old.)

I guess it would be true that 6.005 is the "main" software engineering course now, not 6.170.