That’s not to say strictly typed languages are better, just that if you’re dealing with strict typing you may as well get the benefits, saving a few characters and giving up that kind of guarantee is kind of silly.

As for language vs library, certainly the language has an impact on the library, but not to the extend necessarily expect. You can generally find ways to make an API highly productive in any language, Java’s big problem is that it typically doesn’t try to make things concise. It’s simple to have all the power of the Java IO APIs but still provide a simple method that reads from standard in or a file. Similarly even though Java doesn’t have regex built into the language, it’s trivial to provide simple utility methods like String.replaceAll() which is just as good as the // syntax used by many languages that have native support.

I’ll agree that the Java IO library is a bit cumbersome – basic file IO shouldn’t have so many ways to do it wrong. For such simple operations, the syntax (language and library) should be elegant. I mean – cumbersome file IO code is one reason why people prefer databases to filesystems.

The flipside is that Java IO gives you lots of flexibility and extensibility.

To many it doesn’t make sense to instantiate and wrap and wrap. However, once you learn the Decorator pattern, it makes a bit more sense. Serial access to a file may be used if I want to write a replacement for BufferedReader.

Without the declared type, programming to an interface, or Decorator become less elegant.

> Why not just call it a Map? Well let’s say you later want the map to be sorted, then it simply becomes….

Yep. A key benefit of programming to an interface, in a strongly-typed language. Let’s look at how this works in other language types:

In a typeless or dynamically-typed language, you can still change the implementation without changing the declared type, so long as the code still meets the new interface – this is more dangerous, though, as the errors aren’t found compile-time.

In a statically-typed language which supports implicit types in variable declaration (eg F#), you can change the implementation type without changing the declared type… however, issues will be picked up by the compiler, as types are still static. This might be a candidate for a “best of both worlds”.

My preference is definitely with statically-typed language, for this type of issue.

I’ll agree that the libraries have a bigger impact on the ease of use of a language… but the impact of the language itself shouldn’t be underestimated. Same goes for ide/tool support. To me, they would have to be the 3 big factors in a language’s ease-of-use.

Another thing to consider is that the distinction between language and library is blurred. For a given feature, one language may implement it in library and another may make it native syntax. Also, for a given task, you use a mix of language and library. The syntax of the language impacts how elegant the library usage is. The language’s syntactic strengths drive library development, and, as such, the combination of both impacts the usability, as does each separately.