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.

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?

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

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.

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.

It works both way, there are many acceptable times to use a design pattern, and many non-acceptable times.

It always produces stuff like... that.

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

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

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?

This whole thread sounds like a lot of non-java-programmers complaining about Java.

(Note: incorrect * used above because HN's parser sucks.)

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?

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

In C it always feels like the pillars were speed of implementation and speed of execution on low cost hardware and without sophisticated compilation technology.

Ignoring syntactic issues there are only a few things I wish it had as part of the specification (when viewing it as a (if used in a certain manner) portable minimum viable language where assembly language meets high level languages):

1. A better implementation of Landin's J operator than setjmp 2. Compile, Link, and Load time reflection 3. Portable dynamic code generation (at runtime) operators (to allow late binding and JIT style optimization).

Java can be also viewed as a reworking of Algol but this time with design pillars centred on working in a VM, modularity for large code bases and simplification principles.

It always feels to me like the simplification was intended to reduce complexity (originally: signed ints, no function pointers, no lambda, no manually managed memory objects) but unfortunately this has just pushed huge complexity into code bases. Whilst I can accept this in C (minimum viable human readable and writable portable code), for some reason because Java sits on a huge stack of runtime code and tooling I dont like it. What Java did really bring to the mainstream is the whole VM thing (although some of us will remember BCPL or UCSD p-code), but I think the VM brings too much Java-ism into it and a smaller and better VM lies within.

Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay.

Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay.

That's true, but show me an IDE that lets someone write better code than someone without the IDE. The reality is that IDEs provide very superficial features that help beginners be more productive, but don't help experienced programmers much. (The most cited feature, symbol completion with docstrings, is available in pretty much every text editor. It's nice confirmation that your mental model matches the tags table, but hardly essential.)

All I can say is: Java got a lot easier for me when I stopped trying to make Eclipse useful. It turns out that Eclipse doesn't really do anything except sleep(5) after every keystroke.

Eclipse is not Visual Studio though I've heard good things about IntelliJ IDEA.

IntelliJ is on par with Eclipse. Period. Let us put a stop into that topic.

Also, if you're basing your IDE experience solely on Eclipse and Netbeans, give IntelliJ a try. Both Eclipse and Netbeans pretty much seem unusable after you use IntelliJ for a while.

Basically, my experience with IDEs at Google is that none of them can handle our repository. Even managing the transitive closure of a single project, Eclipse randomly freezes while typing. I don't know anyone that uses Eclipse anymore. Most of my team uses IntelliJ, but even then, the codebase is just too big for it. People type something like com.google.commons.collect.L and see no results (when the right answer is "Lists"). I haven't debugged this, since I don't have any interest in using IntelliJ, but the number of times a day I'm brought to someone's desk to "watch this", I don't think it would work for me. I'd rather have consistent limitations than random failures. Emacs won't iterate over every Java file in Google's repository to complete "Lists" as above, but if I've used it in another file, it will.

The good news is, we have an internal code indexing system that provides an RPC API for many of the IDE features, including completion and duplicate code detection. (But most of the Java chores that people love their IDEs for are handled in other ways at Google. I don't think I've ever written a getter or setter, for example, because every class I've written has been immutable with private internal state. When your objects aren't dumping grounds for other objects, you don't need to get or set anything! :)

Like I've said in other comments, I would never do Java outside of Google. But since I'm here, I have nice tools available to me and using Emacs for Java is no problem at all.

I stand by my original point though. I wouldn't want to write in any programming language without tooling and the availability of sophisticated tooling (of many different styles) for a given language is a strength not a weakness.

Except, we're using computers to help assist us with a terrible codebase that is unnecessary complex and verbose.

Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay.

Vim and emacs not "dumb text editors". They are very powerful tools in the hand of a skilled programmer.

The very best IDEs produce code at the skill level of dumbest programmers - generating getter-setter, or importing, or wrapping something in try-catch...From the top of my head, I can't think of a single instance where the code produced by IDE can be considered semi-intelligent, let alone at par with code produced by skilled programmer.

And code produced by a skilled programmer using a dumb text editor? A skilled programmer using notepad, eclipse and vim produces different code in all 3?

The smarter and more intelligent it gets, the harder it is for the less skilled programmer to edit it.

The skilled programmer can still improve the unintelligent code.

In my experience, fixing a crap piece of code (Usually called refactoring.) takes longer than just writing a correct implementation from scratch. In most cases.

But hey, at least you have a fancy, complicated IDE keeping track of all the "useless shit" for you, right?

  import com.gs.collections.impl.*;

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 boilerplate code for something most languages handle out of the box?

As an example, with Google's collection library (Guava), you might create a set like:

   import com.google.common.collect.ImmutableSet;
   ImmutableSet<Foo> foos = ImmutableSet.of(bar, baz, quux);

(Goldman also has a lot of mutable data structures. I don't think I've used or created a mutable data structure at Google ever :)

If so, how do they look like?