java vs haskell: not so dumb after all?

Despite massive popularity, java is often criticized. some of these criticisms are fair: the language is verbose, fetishizes OOP, abuses exception syntax, and most of the APIs require an IDE to navigate successfully. Yet java manifests some positive qualities missing from tools like haskell that are apparently more elegant.

Consider types. haskell has a fantastic mechanism for creating types, surely the most elegant and capable of any popular programming language. Yet the type hierarchy that has emerged from this mechanism manifests repetition and promotes boilerplate resulting in brittleness. Consider the "readFile" function. how many times is it redeclared in both the standard prelude and popular recommended libraries? seven times!. And why? Because haskell coders have not built a standard library that distinguishes interfaces from implementations, even though the language provides for this via typeclasses.

Java on the other hand has a near-universal discipline of creating interface definitions for both the standard library and many prominent third-party libraries. It is common practice for java coders to swap out implementations for common interfaces as the application demands. Regardless of java's other warts, this is a huge benefit.

Haskell on the other hand gets by with an incomplete application of typeclasses to its libraries, and hacks like "OverloadedStrings", a compiler directive that essentially imposes a "String-like" phantom-interface-thingie on your entire program so that string types can be interchanged without fuss.

Now that java8 is introducing functional programming features to the core language, it seems to be in a better place:

OOP for defining interfaces, functional for application implementation.

While I am a lifelong opponent of the state-drive approach of OOP in common applications, it is clear that it is a valuable design methodology for creating an interface hierarchy. Introducing functional idioms for handling the implementations of these interfaces seems to be the best of both worlds.

Its not hopeless for haskell though. the community has spent the last few years pushing haskell towards becoming a more strict and pragmatic tool. Fixing the twin issues of missing typeclasses and fractured APIs may require a more fundamental rebooting of the language.

last update 2013-10-09