Skip to content

Programming Niches

March 14, 2011

On his Sententia blog, Chris Smith argues that Haskell’s niche is “hard problems”. While I agree with many of things he finds are great about Haskell, I don’t really agree with the premise that “different programming languages are good at different things”, at least universally.

There are certainly domain specific languages, languages that have made syntactic and semantic trade-offs to support one particular domain very well. awk comes to mind as a good example. Sure, it’s Turing complete, but it is really only well suited to line-oriented text processing.

But a large class of languages are general purpose, and as such, I don’t think make them particularly good at one thing over another. For example, I think any distinction between what Python is good at vs. Java vs. Ruby vs. PHP vs. C++ vs. Haskell is just bound to be forced, and 99% a matter of taste.

Now, it is certainly true that the set of libraries available, and the execution environments often are highly skewed to one domain or another. For example, I still find myself coding in PHP for small dynamic web sites. Not because the language is particularly suited to it (in fact I find it downright painful), nor the libraries particularly good, but because it is right there integrated into Apache and “just works” out of the box.

Once you are over the hump of getting a language workable in a particular environment, then I think for most “full-featured” programming systems (languages and their commonly available libraries), I think one would find that none of them is more or less particularly suited to any given domain.

All that being said, I find Chris Smith’s main points about Haskell spot on, and I love his slogan: “Haskell is for solving hard problems.” But, I’d go further, assuming I can get it running in whatever execution environment I need, “Haskell is for solving most problems.”


From → Software

One Comment
  1. Padhrig McCarthy permalink


    What about the use of strongly-typed languages in situations where you want to get compile-time errors vs. runtime errors? I think these sorts of structural-level distinctions may form practical branches for where you might choose to apply different languages.


Comments are closed.

%d bloggers like this: