What advantage does Haskell have over a "typed" language like Java or C++

Submitted by metaperl on Fri, 09/02/2005 - 7:01am.

I was in a job interview for a Perl position and I volunteered some information about learning Haskell in my freetime since it has improved my Perl programming so much.

Then my boss asked me this: "what advantage does programming in Haskell have over Java or C++. They have strong typing don't they"

And my answer was: "they don't have type inferencing" --- but is not advantage, only something different it has. What would you say are the advantages of Haskell over Java or C++?

Submitted by gour on Fri, 09/02/2005 - 9:41am.

I was in a job interview for a Perl position and I volunteered some information about learning Haskell in my freetime since it has improved my Perl programming so much.
Then my boss asked me this: "what advantage does programming in Haskell have over Java or C++. They have strong typing don't they"

So, you've got a job?

What would you say are the advantages of Haskell over Java or C++?

Although I'm very green with Haskell, I'd say that Haskell is very elegant & clean language (if it makes some sense to anyone except my mind :-)

Sincerely,
Gour

Submitted by metaperl on Sat, 09/03/2005 - 9:27pm.

So, you've got a job?

No, not yet...

Submitted by jgoerzen on Fri, 09/02/2005 - 2:24pm.

The two-word summary: productivity & correctness.

The longer answer:

With Haskell, you can often model problems in a more "natural" way. Many of us are so used to using counters to iterate through lists, as opposed to a recursive solution, because we've been programming that way for so long. I find that I can just look at Haskell code, and intuitively understand exactly what it's doing, far easier than C++ or Java code.

It also requires a lot less code to accomplish the same task, compared to C++ or Java. Part of that is thanks to type inference, part thanks to polymorphic types, part thanks to type classes. Part is simply the functional approach to life.

Then there is the zero side-effects approach, sidelining side effects into the IO monad. This is a great way to minimize obscure bugs. It also makes it easier to read code and reason about it. In C, you can't really reason about a function without seeing its source. With Haskell, if you see a function outside the IO monad, the *only* question you have is what it returns. You know with certainty that nothing else is touched. Neither C++ nor Java offers that.

When I read through a Haskell program, it's more like reading a novel than solving a calculus problem. It is easier to see what's happening. That translates into higher-quality software and lower maintenance times.

Submitted by Paul Johnson on Sun, 09/04/2005 - 5:39pm.

C++ and Java like to pretend they have strong typing, but they don't really.

Strong typing means that the type system guarantees type correctness at compile time. In C++ you can of course cast anything to anything, and the fact that this is regular practice pretty much destroys any pretence the language might have. But even if you could ban all "unsafe" casts, you can still get a type error like this:


  1. A Car is-a Vehicle. So Array of Car is also an Array of Vehicle.

  2. Lorry is-a Vehicle. So if I have an array of Vehicles I can put a Lorry in it.

  3. So I create an array of Car, cast it to array of Vehicle, create a Lorry, and insert it into the Vehicle array. Now I have a variable of type "array of Car" pointing at an array that contains a Lorry. Boom.

Java suffers from this vice as well, although it does try to handle it at runtime with an exception. But run-time type checking is not strong typing.

All mainstream OO languages suffer from this vice (not sure about O'Caml).

Haskell does not suffer from this vice. The Haskell type system guarantees that if your program compiles then it will contain zero run-time type errors.

Paul.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.