> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.
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.
>> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product.
> 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.
On the oyher hand, some people that argue for their use of strict typing on Haskell's level say that it is because they are not good enough programmers to not waste time on runtime type errors, another form of self-deprecation.
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.
My internal me was screeeaming just to put "citation needed" here (I've never done it before, this is not a good time to start). And while I agree with you on a certain level; I don't think "Java engineers" are the best software engineers per se. Neither that the best software engineers love Java 'without exception'.
I agree [with you] that Java invites you (nay, urges you) to use good engineering practices.
Agreed. His background is Perl after all, so the idea of 'one way to do something' and 'readable code' is extremely foreign to him. I'd take his advice on programming with a grain of salt.
(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.
I would look at Modern Perl before Perl Best Practices. While Perl::Critic bases much of its criticism on PBP, quite a bit of it turned out to be not so useful.
To me I think he's clearly qualified to make all sorts of judgements about Perl. For opinions on Java, I'll look to people who have written well reviewed 500+ page books on Java.
No - my statement is pretty clear. Someone who likes Perl is not going to be appreciative of 'one way to do something' and 'readable code'. Those properties are the basis for modern language design and they are properties that most people want in a language. Taking his opinion means also taking his assumption that the properties of Perl ('interesting code') is a good property for a language to have. Hence my advice to take any opinion from a Perl guy as coming from a Perl guy - don't disregard it, but make sure you don't inadvertently put Perl in your language design. Because Perl in your language design is going to give you unreadable code.
If you're going to argue that Perl is readable code then I'm going to have to disagree with you extremely after having been in a position to maintain some Perl code before.
I wrote a blog post which entirely disagrees with you that got around 11000 hits to date (many from here on HN).[1]
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 unreadable about that. It provides a package with declarative specifications for properties and accessors (all of which are read only) and methods which delegate to PostgreSQL stored procedures (more information of which is probably further clarified in the Baz interface.
There is nothing inherently unreadable about Perl.
Thanks for the reply - I haven't touched Perl in years and it's definitely much more readable now. It looks like a lot of work has gone into making Perl more readable, especially Moose.
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?
Part of the problem is that one-off scripts are different than applications. One off scripts don't need to be big or particularly maintainable, but the problem is people get in the habit of writing Perl that way.
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.
Just to clarify, re-reading this it looks a little confused. The rubbish I maintain is not stuff on CPAN but legacy code inherited from another non-CPAN project. The legacy modules are sometimes annoying in some ways but they are serviceable.
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.
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 statement is pretty clear, which is useful as far as it goes. But it's also wrong, and that's pretty significant too.
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?)
You do realize you're making this in defense of someone starting a language war, right? You may be in the wrong thread. Or its only bashing a modern language when you're bashing Perl?
I don't feel that users of Java are "relieved of the responsibility from doing 'the right thing'" for the following reasons:
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.
When writing Python you're constantly making a lot of choices that you simply don't get in Java. e.g. "do I use a tuple/dictionary for this thing or make a class" - in Java there are no tuples and no dictionary literals, so you always make a class. "Do I group this bunch of functions into a class or leave them freestanding?" - in Java you don't have freestanding functions, so you always put them in a class. "Loop, map, or list comprehension?" - Java only has one option (at least until recently). "Several functions or one function with a lot of keyword arguments?" Even the tools seem a lot more wide open - with Java these days maven is pretty much standard, your only real choice is eclipse vs intellij. In Python I still couldn't tell you what's the right tool to package with (though pip/virtualenv is more-or-less becoming the standard for dependencies), and there seem to be dozens of IDE/editor options.
"When writing Python you're constantly making a lot of choices that you simply don't get in Java. e.g. "do I use a tuple/dictionary for this thing or make a class""
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.
> 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
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.
> I've never seen a case where that choice was important; you can just use ArrayList and LinkedHashSet everywhere
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.
Read that article, as it's not talking about the same thing. A lot of thought and design went into both C and Unix. "The right thing" is relative to the tradeoffs you find acceptable or not.
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.
To be honest, reading the article, he sounds like he is depressed. He seems very bitter about a programming language that he doesn't even have to use every day.
Now Mark Jason Dominus is often wrong when it comes to his political opinions, but he's rarely wrong about programming, and your tone is just way too negative for seemingly no reason. Of course he's missing selection bias. That kind of goes with being MJD. So?
How does this have 91 points and get to the front page of HN? I suspect that you know the answer to this already. Hacker News is home to a bunch of elitist language bigots who think that if you don't code in their own coolest-language-ever you are some kind of second class citizen.
There's no surprise that this is the culture here. Need I mention the term "blub programmer"? Could anything be more elitist and offensive?
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.