[jrockway]

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]

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]

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]

Do you think that 100 years from now, anyone other than programming language researchers will have heard of any programming language used today?

[DanBC]

Do you think 40 years ago people would have thought that people would still be using C (and derivatives)?

[hermanhermitage]

Yes a very interesting point. You could even replace C in that sentence with Algol and it rings fairly true.

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.