6 ms·

Why? Because Java has good, built-in, worldwide namespacing that always works? Or because Java has IDEs that pull in imports automatically so developers don't h

Why? Because Java has good, built-in, worldwide namespacing that always works? Or because Java has IDEs that pull in imports automatically so developers don't have to think useless shit? Or is it because you're fanboi who dislikes Java merely because it's Java and choose any opportunity, not matter how inappropriate, to disparege it. Java is by no means perfect, but let's at least pick on it for the things it actually does poorly rather then just picking on it because it's no longer considered cool.

runn1ng 14y ago
I hate auto-generated code by IDEs. It always produces stuff like... that.
- eropple 14y ago
  And then hides it. Which I'll agree is a little stupid, but you never really see it in practice.
- arcdrag 14y ago
  You realize that any modern language is nothing more than an abstraction layer to automatically generate code in a lower level language right? The only difference here is that if you view the .java file in a plain text editor, you'll actually see that block. You won't see it in modern IDE's though. It gets automatically collapsed, as it is an aid to the compiler more than the developer.
  - hermanhermitage 14y ago
    One viewpoint is such noise doesn't scale - both for tooling or human consumption. Java and C# are both heading into a territory where it is getting less reasonable for a human to write them without tooling support - is this what people really want? If we have such sophisticated tooling why bother dropping to low level text? Wouldn't it make more sense to manipulate and compose more expressive objects than text? The end game is you obsolete the languages and they become targets of more expressive languages. It highlights a potential design flaw in the composition model of the language and/or the libraries. Should for example C/C++ include the generated assembler in pragmas to guide compilation? Always? Visible to the programmer?
    - jrockway 14y ago
      I disagree. It's the concise model that can't scale without tool support. Imagine you import foo.∗, bar.∗, and baz.∗. How does someone reading the code know where the Quux class comes from? They can't, without checking all of the namespaces that were imported. But if you just "import foo.bar.baz.Quux", then you know exactly where Quux comes from. This whole thread sounds like a lot of non-java-programmers complaining about Java. (Note: incorrect * used above because HN's parser sucks.)
      - hermanhermitage 14y ago
        I'm not too fussed with the namespaces - I dont think you will find anyone arguing against that. What is at issue is the over specialization of class or framework components because of language limitations. A language that leads to degenerate boilerplate or mounds of endless repetition (but in user land code and libraries/frameworks) can be viewed as having a serious abstraction problem. Do you really think java will be looked at in 100 years as the pinacle of language evolution or some horrible dead end? Like cobol or basic?
        jrockway 14y ago
        This library looks bad because it is bad. (I just wrote a long rant about this, but on my internal blog, so I'll summarize here. They have 12 classes implementing immutable lists. A class for an empty list. A class for a list with one element. A class for a list with two elements. That continues to 10 (!!!!) elements. Then there's a class for lists greater than size 10. This pattern is repeated for all the other types. That's going to be messy in any language. Google seems to survive with 0-, 1-, and n-element classes.)
        arcdrag 14y ago
        Do you think that 100 years from now, anyone other than programming language researchers will have heard of any programming language used today?
        14y ago
- jrockway 14y ago
  I never use an IDE to edit Java, and that's pretty much what it looks like. To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name. It's basically like that in every other programming language, though others are less opaque. In Perl, you get a variable called %:: that holds the symbol table, and you can directly manipulate it. That lets you write something like "use all" and use every CPAN module at once. In C, you can include arbitrary source files at arbitrary places, making it possible to import every library with one statement. But in both languages this is considered terrible practice, with most style guides wanting one use or include statement for each library. Exactly the same as Java. If you were going to complain about the API, you might complain about the "impl" in every import. That's a silly convention that wastes typing. (Also, Google puts their collection classes in the "collect" namespace, saving a few letters over calling it "collections" like Goldman.)
  - jordyhoyt 14y ago
    But, if you're using a modern IDE, removing impl or going from "collections" to "collect" isn't saving anyone any time. Or, at least, it shouldn't be.
    - jrockway 14y ago
      Sure, but it's always nice when imports fit on a single line without wrapping. Essential, no, but nice.
  - irahul 14y ago
    > I never use an IDE to edit Java, What do you use? I find it extremely painful to write Java in Vim, even though I have been using Vim for quite some time and am very comfortable using it. Text based completions and re-factoring doesn't cut it for Java/C#, so I use eclim to use what eclipse is good at which comprises of smart auto-complete, auto-imports, generating getters and setters, implementing interface, auto-correct code for trivial cases etc. > To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name. That's similar in Python. I think the parent post wasn't complaining about namespacing but the way project is structured and named(impl, factory).
- sevenstar 14y ago
  Does Eclipse do that?
jlarocco 14y ago
If it's "useless shit", why have it there at all? But hey, at least you have a fancy, complicated IDE keeping track of all the "useless shit" for you, right?
- ntkachov 14y ago
  I think you missed the "computer" part in "computer programming language". It's there because it needs to be for the JVM. It resolves naming conflicts so that having two "component.java" files in the same project don't end up blowing the whole thing apart.
jabr 14y ago
I can't speak for jlarocco, but my concern is not directly the import statements, but rather, what those import statements imply. That repo has 1,290 files. Excluding file pathnames containing 'test', there are 601 files. Of those, 430 are .java files. Java is complicit in that crime, but Enterprise Java is the bigger culprit. The library makes doing a map on an array cleaner for me, but behind the scenes it is using a dozen "factories", a bunch of "builders", several "strategies", and a handful of "visitors", "bridges", and "proxies". And guilt by association is valid here. We bleed over whether semicolons are needed in some languages, but Java is off limits for needing 10-fold more (auto-generated?) boilerplate code for something most languages handle out of the box?
- mkramlich 14y ago
  Yep. Don't forget Aspects! "But, but... a good IDE can make all this boilerplate be less painful!" Of course, you could just not have the boilerplate, abstraction and over-complexity to begin with, use a simpler language & ecosystem like Python, and just code in vi.
  - arcdrag 14y ago
    "I don't want to learn how to use an IDE" is the same argument as "I don't want to learn how to use vi". There are a lot of reasons to hate Java...I don't want to use a bloated IDE is a pretty weak one in an age of 8 core processors and 32 GB of ram. Also, many Java shops do so because few other languages are an option when you need 200+ trained developers, as few cities even have 200 experienced Python devs. Then there's performance, as Java performs an order of magnitude faster than Python for many operations.
    - mkramlich 14y ago
      The vast majority of dev workstations in the real world have far less than 8 cores and 32 GB of memory. Also it's not about "bloat" in some abstrance sense, I've found, but rather about the noticeably slower interactivity, the mysterious delays, the mysterious crashes, and the overwhelming surplus of unnecessary visual/cognitive vomit occupying the screen real estate at any time. Oh and Byzantine IDE configuration option panels. And the always-harder-to-automate nature of GUI interfaces. And the local drive bias. And every other "feature" they add that you're supposed to appreciate as some new gift from the gods turns out to be something you could already do, for free, on the command-line or with a vi/emacs-style terminal-friendly UI. I have a lot of experience working in both paradigms and I know which one I've found to be better. I think the last fast/simple/non-crashy/non-visual-vomit IDE I experienced was TurboC in the early 90's. It's been mostly downhill ever since. I think a lot of shops that think they need 200 developers, and thus it's easier to get Java than Python developers and thus should use Java, etc., may have made a base assumption after which all following deductions are dependent. If instead of starting with assumption you need 200 developers you instead think we only want a few smart/elite developers, then you can have a smaller total headcount, a less enterprisey tech stack, and less mindless process and makework. I've seen and heard of small teams that run circles around large bloated enterprise shops for just these kinds of factors. Also I guarantee you that in the vast majority of real world programming situations needed by large companies the software is mostly not CPU-bound but rather IO-bound, and any greenfield or maintenance development is mostly bug-bound or developer-hour-and-quality-availability-bound and bureaucracy-bound. CPU time is cheap and lots of ways to parallelize, defer and cache. Software developers are not cheap. Well, worse software developers can be "cheaper" superficially but end up being more expensive due to being slower, dumber or less knowledgable of implementation options, and needing much more of them. CEO salaries and their royal court are extremely NOT cheap.
crumblan 14y ago
Actually, it looks like he was picking on it for something he thinks it does poorly.

runn1ng 14y ago

I hate auto-generated code by IDEs. It always produces stuff like... that.

eropple 14y ago
And then hides it. Which I'll agree is a little stupid, but you never really see it in practice.
arcdrag 14y ago
You realize that any modern language is nothing more than an abstraction layer to automatically generate code in a lower level language right? The only difference here is that if you view the .java file in a plain text editor, you'll actually see that block. You won't see it in modern IDE's though. It gets automatically collapsed, as it is an aid to the compiler more than the developer.
- hermanhermitage 14y ago
  One viewpoint is such noise doesn't scale - both for tooling or human consumption. Java and C# are both heading into a territory where it is getting less reasonable for a human to write them without tooling support - is this what people really want? If we have such sophisticated tooling why bother dropping to low level text? Wouldn't it make more sense to manipulate and compose more expressive objects than text? The end game is you obsolete the languages and they become targets of more expressive languages. It highlights a potential design flaw in the composition model of the language and/or the libraries. Should for example C/C++ include the generated assembler in pragmas to guide compilation? Always? Visible to the programmer?
  - jrockway 14y ago
    I disagree. It's the concise model that can't scale without tool support. Imagine you import foo.∗, bar.∗, and baz.∗. How does someone reading the code know where the Quux class comes from? They can't, without checking all of the namespaces that were imported. But if you just "import foo.bar.baz.Quux", then you know exactly where Quux comes from. This whole thread sounds like a lot of non-java-programmers complaining about Java. (Note: incorrect * used above because HN's parser sucks.)
    - hermanhermitage 14y ago
      I'm not too fussed with the namespaces - I dont think you will find anyone arguing against that. What is at issue is the over specialization of class or framework components because of language limitations. A language that leads to degenerate boilerplate or mounds of endless repetition (but in user land code and libraries/frameworks) can be viewed as having a serious abstraction problem. Do you really think java will be looked at in 100 years as the pinacle of language evolution or some horrible dead end? Like cobol or basic?
      - jrockway 14y ago
        This library looks bad because it is bad. (I just wrote a long rant about this, but on my internal blog, so I'll summarize here. They have 12 classes implementing immutable lists. A class for an empty list. A class for a list with one element. A class for a list with two elements. That continues to 10 (!!!!) elements. Then there's a class for lists greater than size 10. This pattern is repeated for all the other types. That's going to be messy in any language. Google seems to survive with 0-, 1-, and n-element classes.)
      - arcdrag 14y ago
        Do you think that 100 years from now, anyone other than programming language researchers will have heard of any programming language used today?
        14y ago
jrockway 14y ago
I never use an IDE to edit Java, and that's pretty much what it looks like. To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name. It's basically like that in every other programming language, though others are less opaque. In Perl, you get a variable called %:: that holds the symbol table, and you can directly manipulate it. That lets you write something like "use all" and use every CPAN module at once. In C, you can include arbitrary source files at arbitrary places, making it possible to import every library with one statement. But in both languages this is considered terrible practice, with most style guides wanting one use or include statement for each library. Exactly the same as Java. If you were going to complain about the API, you might complain about the "impl" in every import. That's a silly convention that wastes typing. (Also, Google puts their collection classes in the "collect" namespace, saving a few letters over calling it "collections" like Goldman.)
- jordyhoyt 14y ago
  But, if you're using a modern IDE, removing impl or going from "collections" to "collect" isn't saving anyone any time. Or, at least, it shouldn't be.
  - jrockway 14y ago
    Sure, but it's always nice when imports fit on a single line without wrapping. Essential, no, but nice.
- irahul 14y ago
  > I never use an IDE to edit Java, What do you use? I find it extremely painful to write Java in Vim, even though I have been using Vim for quite some time and am very comfortable using it. Text based completions and re-factoring doesn't cut it for Java/C#, so I use eclim to use what eclipse is good at which comprises of smart auto-complete, auto-imports, generating getters and setters, implementing interface, auto-correct code for trivial cases etc. > To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name. That's similar in Python. I think the parent post wasn't complaining about namespacing but the way project is structured and named(impl, factory).
sevenstar 14y ago
Does Eclipse do that?

jlarocco 14y ago

If it's "useless shit", why have it there at all? But hey, at least you have a fancy, complicated IDE keeping track of all the "useless shit" for you, right?

ntkachov 14y ago
I think you missed the "computer" part in "computer programming language". It's there because it needs to be for the JVM. It resolves naming conflicts so that having two "component.java" files in the same project don't end up blowing the whole thing apart.

jabr 14y ago

I can't speak for jlarocco, but my concern is not directly the import statements, but rather, what those import statements imply. That repo has 1,290 files. Excluding file pathnames containing 'test', there are 601 files. Of those, 430 are .java files. Java is complicit in that crime, but Enterprise Java is the bigger culprit. The library makes doing a map on an array cleaner for me, but behind the scenes it is using a dozen "factories", a bunch of "builders", several "strategies", and a handful of "visitors", "bridges", and "proxies". And guilt by association is valid here. We bleed over whether semicolons are needed in some languages, but Java is off limits for needing 10-fold more (auto-generated?) boilerplate code for something most languages handle out of the box?

mkramlich 14y ago
Yep. Don't forget Aspects! "But, but... a good IDE can make all this boilerplate be less painful!" Of course, you could just not have the boilerplate, abstraction and over-complexity to begin with, use a simpler language & ecosystem like Python, and just code in vi.
- arcdrag 14y ago
  "I don't want to learn how to use an IDE" is the same argument as "I don't want to learn how to use vi". There are a lot of reasons to hate Java...I don't want to use a bloated IDE is a pretty weak one in an age of 8 core processors and 32 GB of ram. Also, many Java shops do so because few other languages are an option when you need 200+ trained developers, as few cities even have 200 experienced Python devs. Then there's performance, as Java performs an order of magnitude faster than Python for many operations.
  - mkramlich 14y ago
    The vast majority of dev workstations in the real world have far less than 8 cores and 32 GB of memory. Also it's not about "bloat" in some abstrance sense, I've found, but rather about the noticeably slower interactivity, the mysterious delays, the mysterious crashes, and the overwhelming surplus of unnecessary visual/cognitive vomit occupying the screen real estate at any time. Oh and Byzantine IDE configuration option panels. And the always-harder-to-automate nature of GUI interfaces. And the local drive bias. And every other "feature" they add that you're supposed to appreciate as some new gift from the gods turns out to be something you could already do, for free, on the command-line or with a vi/emacs-style terminal-friendly UI. I have a lot of experience working in both paradigms and I know which one I've found to be better. I think the last fast/simple/non-crashy/non-visual-vomit IDE I experienced was TurboC in the early 90's. It's been mostly downhill ever since. I think a lot of shops that think they need 200 developers, and thus it's easier to get Java than Python developers and thus should use Java, etc., may have made a base assumption after which all following deductions are dependent. If instead of starting with assumption you need 200 developers you instead think we only want a few smart/elite developers, then you can have a smaller total headcount, a less enterprisey tech stack, and less mindless process and makework. I've seen and heard of small teams that run circles around large bloated enterprise shops for just these kinds of factors. Also I guarantee you that in the vast majority of real world programming situations needed by large companies the software is mostly not CPU-bound but rather IO-bound, and any greenfield or maintenance development is mostly bug-bound or developer-hour-and-quality-availability-bound and bureaucracy-bound. CPU time is cheap and lots of ways to parallelize, defer and cache. Software developers are not cheap. Well, worse software developers can be "cheaper" superficially but end up being more expensive due to being slower, dumber or less knowledgable of implementation options, and needing much more of them. CEO salaries and their royal court are extremely NOT cheap.

crumblan 14y ago

Actually, it looks like he was picking on it for something he thinks it does poorly.