9 ms·

This is one of those criticisms that sounds right if you know a little bit about the topic, and is certainly clever enough in and of itself to make the reader t

by chavesn 13y ago

This is one of those criticisms that sounds right if you know a little bit about the topic, and is certainly clever enough in and of itself to make the reader think that it's making a good point. 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.

rjknight 13y ago
I took his post as a fairly standard "worse is better" argument. Many newer or more fashionable languages enable some very elegant programming styles, but this comes with a concern about the elegance of one's code, which can easily result in the programmer spending more time thinking about elegance than about functionality. 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. 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.
- bad_user 13y ago
  The "worse is better" argument is in the context of Unix and C and cannot be separated from that context, otherwise it is meaningless. 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 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 http://www.infoq.com/presentations/Simple-Made-Easy
  - rjknight 13y ago
    "Worse is better" can easily be separated from that context, though I would admit that most people do it incorrectly. "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.
davidw 13y ago
> In Java, as in any language, you can over-design, or you can under-design, or you can design just what you need 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.
- chavesn 13y ago
  I almost made a similar point but didn't want to be too long-winded. But you're exactly right on. Certain idioms develop in every language. In Java there's a culture of favoring verbosity over cleverness. In fact, I think you'll find some Java programmers who hate the cleverness that is often common in other more terse languages. And they'll throw "clever" around as an insult much the way "verbose" is used against Java. 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.
  - vishnugupta 13y ago
    >In Java there's a culture of favoring verbosity over cleverness. 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 :)
    - cowls 13y ago
      Wow, sounds like a productive code review.
cowls 13y ago
Guy works on Java projects for 3 years. In this time wasnt able to produce a high quality project, blames language.
- fuzzix 13y ago
  Well, the Guy is pretty clever. I think, given the tools, he could produce high quality work. http://hop.perl.plover.com/ http://hop.perl.plover.com/ - seriously clever.
  - cowls 13y ago
    Seriously Clever for A 10 year old book on perl basics is probably pushing it. 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
    - fuzzix 13y ago
      > Seriously Clever for A 10 year old book on perl basics is probably pushing it. 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.
    - swah 13y ago
      The other day I surprinsingly found more praise for HOP from a coder I admire: http://books.google.com.br/books?id=2kMIqdfyT8kC&pg=PT89&lpg=PT89&dq=%22higher+order+perl%22+coders+at+work&source=bl&ots=MkbsubIIDC&sig=3SWQT7uJeF5QWMeA1Tl0k7xeIl8&hl=en&sa=X&ei=iFwxU_ChFaeA2gWug4DQCQ&redir_esc=y#v=onepage&q=%22higher%20order%20perl%22%20coders%20at%20work&f=false http://books.google.com.br/books?id=2kMIqdfyT8kC&pg=PT89&lpg... Time to re-read it, because when I first read it, I had to skim some parts. Probably applies to Python.
    - chromatic 13y ago
      That's like calling SICP a book on Scheme basics.
  - 13y ago
valevk 13y ago
I think the writer of the article is clearly suffering Ahmdal's Condition. Many of the problems he states are clearly personal experiences, and could not be applied to a more broader environment. Just like saying: a whole sport is bad, becuase one team is not performing well.
cbsmith 13y ago
> 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. 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.
tod222 13y ago
> 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. 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.
pistacchioso 13y ago
The "Har-har-so-many-classes-and-don't-even-get-me-started-on-variable-names" argument is true. 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!"

by chavesn 13y ago

rjknight 13y ago

I took his post as a fairly standard "worse is better" argument. Many newer or more fashionable languages enable some very elegant programming styles, but this comes with a concern about the elegance of one's code, which can easily result in the programmer spending more time thinking about elegance than about functionality. 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. 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.

bad_user 13y ago
The "worse is better" argument is in the context of Unix and C and cannot be separated from that context, otherwise it is meaningless. 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 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 http://www.infoq.com/presentations/Simple-Made-Easy
- rjknight 13y ago
  "Worse is better" can easily be separated from that context, though I would admit that most people do it incorrectly. "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.

davidw 13y ago

> In Java, as in any language, you can over-design, or you can under-design, or you can design just what you need 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.

chavesn 13y ago
I almost made a similar point but didn't want to be too long-winded. But you're exactly right on. Certain idioms develop in every language. In Java there's a culture of favoring verbosity over cleverness. In fact, I think you'll find some Java programmers who hate the cleverness that is often common in other more terse languages. And they'll throw "clever" around as an insult much the way "verbose" is used against Java. 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.
- vishnugupta 13y ago
  >In Java there's a culture of favoring verbosity over cleverness. 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 :)
  - cowls 13y ago
    Wow, sounds like a productive code review.

cowls 13y ago

Guy works on Java projects for 3 years. In this time wasnt able to produce a high quality project, blames language.

fuzzix 13y ago
Well, the Guy is pretty clever. I think, given the tools, he could produce high quality work. http://hop.perl.plover.com/ http://hop.perl.plover.com/ - seriously clever.
- cowls 13y ago
  Seriously Clever for A 10 year old book on perl basics is probably pushing it. 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
  - fuzzix 13y ago
    > Seriously Clever for A 10 year old book on perl basics is probably pushing it. 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.
  - swah 13y ago
    The other day I surprinsingly found more praise for HOP from a coder I admire: http://books.google.com.br/books?id=2kMIqdfyT8kC&pg=PT89&lpg=PT89&dq=%22higher+order+perl%22+coders+at+work&source=bl&ots=MkbsubIIDC&sig=3SWQT7uJeF5QWMeA1Tl0k7xeIl8&hl=en&sa=X&ei=iFwxU_ChFaeA2gWug4DQCQ&redir_esc=y#v=onepage&q=%22higher%20order%20perl%22%20coders%20at%20work&f=false http://books.google.com.br/books?id=2kMIqdfyT8kC&pg=PT89&lpg... Time to re-read it, because when I first read it, I had to skim some parts. Probably applies to Python.
  - chromatic 13y ago
    That's like calling SICP a book on Scheme basics.
- 13y ago

valevk 13y ago

I think the writer of the article is clearly suffering Ahmdal's Condition. Many of the problems he states are clearly personal experiences, and could not be applied to a more broader environment. Just like saying: a whole sport is bad, becuase one team is not performing well.

cbsmith 13y ago

> 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. 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.

tod222 13y ago

> 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. 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.

pistacchioso 13y ago

The "Har-har-so-many-classes-and-don't-even-get-me-started-on-variable-names" argument is true. 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!"