They love complexity

The only sane thing I read in those comments (many were noise, personal insults ... not really constructive) was along the lines of "designing an API is hard, otherwise it would be easy".

Whether Java the language traps itself into bad APIs or Sun's API designers just plain suck is an argument I'll leave to other people.

But how does Smalltalk counteract this, James? A simple language, but a huge library right? Is that ideal or should the language do more to "simplify" the API? Maybe that's the kind of backwards thinking that kills an API (maybe Perl, where you can do anything three different ways, is a counterexample). Smalltalk seems to follow the "here's a whole bunch of useful stuff, change it if you want" line of thinking. Doesn't seem too consistent, so software engineering types are hesistant and go for Java's rigidness.

I guess it would depend on how you define complexity: are the methods themselves complex or are there just too many of them, making the "whole API" complex? hmmm ... how much is complexity language syntax dependent? Compare languages with and without exceptions, for example, and how that changes APIs (return codes, etc) and if that makes API easier to use.

Are new languages making APIs better or worse? Are they just cornering APIs into a proper/prescribed format because of syntax? Is this good or bad?

Yeah, that's so true. A while ago, to learn C#, I wrote a small HTTP password cracking utility. Here's how you send a username and a password to a URL:

NetworkCredential nc = new NetworkCredential("foo", "bar");
Uri uri = new Uri("http://localhost/pr0n");
HttpWebRequest wr = (HttpWebRequest)WebRequest.Create(uri);
wr.Credentials = nc;
wr.GetResponse();

That's a lot of code, right? A friend of mine is making his own language called L, a Lisp dialect. He wants to compete with Perl, Sh, Python and Ruby, he wants people to use it as a scripting tool. So he's trying to keep things brief and simple. So for this particular problem, the solution would probably be like:

(get (url "http://foo:bar@localhost/pr0n"))
; or using URL literals (if we decide to go with those):
(get http://foo:bar@localhost/pr0n)

See? It doesn't need to be complex, just keep everything simple. And people who use web browsers (which is basically everyone) has see this syntax once, so it appeals because it's familiar.

Don't do the complex thing, do the right thing.

Comment on They love complexity by cdegroot

Sun's burying itself in badly designed API's - it is possible to design good API's in Java, I give the collection of API's that comprise Jini as a proof. What's lacking in most of the API's is minimalism - they try to solve all the cases to everyone; Java's rigidness encourages that behavior, but certainly does not stand forcefully in the way of minimalism (in contrary, the Java concept of Interfaces helps a lot - if you know where to make the cut between 'your' code inside the API and 'their' code using the API).

The java API is complex because it's not very object oriented. It doesn't take advantage of polymorphism - for example size() vs length() - and it doesn't do a very good job of encapsulating state (Stream hierarchy for example). The Smalltalk API is generally better because it more failfully applies the object-oriented principles of encapsulation, inheritance and polymorphism.