Hacker News new | ask | show | jobs
by the-owlery 3959 days ago
I've avoided Haskell, primarily because:

* hearing how difficult it is to learn, and

* recalling C++ & Java, not crazy about the idea of going back to having to specify types for everything.

But Haskell is enticing to me:

* bindings to C-libraries in general (been meaning to try GTK, and wanted to use SQLite for a small project)

* apps start-up quickly

* compiled (good performance)

What's the Haskell community like?

Is Haskell a practical language/ecosystem, or more academic-focused?

5 comments

> * recalling C++ & Java, not crazy about the idea of going back to having to specify types for everything.

This is a big misconception. The type system in Haskell becomes much more of a tool than a hindrance. Although you will tend to write type signatures for all your top level functions, type inference is very good and it's not necessary most of the time.

The reason you should consider writing at least the top level signatures is that when you do the compiler will help you fill in the banks with type holes. See

* https://www.reddit.com/r/haskell/comments/19aj9t/holedriven_...

* https://wiki.haskell.org/GHC/Typed_holes

Once you learn these tricks, it can really feel like magic sometimes. :-)

> recalling C++ & Java, not crazy about the idea of going back to having to specify types for everything.

In the dynamically typed languages static types are substituted with tons of trivial (stupidly trivial) tests, which is a way much more lines of code than with just simple type annotations.

> * hearing how difficult it is to learn, and

I thought it was pretty straight forward coming from Erlang.

The biggest thing for me was practice thinking in recursion.

edit: Erlang and Haskell was just side hobby. I didn't do anything major with them. But I thought the languages were small enough, Haskell has such a clean looking syntax.

Oh, I think you're trying to say the threshold of being good with haskell is much higher? Cause I see that argument quite and bit.

> > * hearing how difficult it is to learn, and

> I thought it was pretty straight forward coming from Erlang.

> The biggest thing for me was practice thinking in recursion.

I use Clojure, generally like functional programming, and am fine using recursion.

> Haskell has such a clean looking syntax.

I have gotten fond of Clojure's Lisp-like syntax.

> Oh, I think you're trying to say the threshold of being good with haskell is much higher? Cause I see that argument quite and bit.

Not sure -- haven't spent any time with Haskell. Never tried Erlang either. Do you think it generally takes longer to become productive with Haskell than with other functional programming languages?

> recalling C++ & Java, not crazy about the idea of going back to having to specify types for everything.

I want to reiterate the other comments and clarify: C++ & Java have poor type systems compared to Haskell. Haskell's not only is much safer, but it also allows for much much better inference, so you rarely ever need to add type annotations. People do typically add top-level annotations, for documentation's sake, in most cases, but they are not required.

> * hearing how difficult it is to learn, and

I thought it was pretty straight forward coming from Erlang.

The biggest thing for me was practice thinking in recursion.

The person you are replying to, unawares of the difference between static typing and type inference, is not going to find Erlang any easier to learn.
My understanding is that type inferencing allows you to omit specifying types in many places (the compiler uses heuristics to figure out the types in those places out at compile-time), but that you still need to specify types when necessary. (Please correct me if I'm wrong.)

I think Rust does this, but looking at Rust code, there's still types specified all over the place, and it looks much more cluttered to me than dynamically typed languages I've used.

Here's a slightly longer example of Haskell's awesome type inference with some additional commentary to complement the example that elbenshira gave:

    >>> let showAdd x y = show (x + y)
    >>> :type showAdd
    showAdd :: (Num a, Show a) => a -> a -> String
The compiler infers:

* The two arguments, `x` and `y`, must be some type `a`

* They must be the same type `a`

* The type `a` must implement the `Num` interface (because we add them together using `(+)`

* The result of addition must also be the same type `a`

* The type `a` must also implement the `Show` interface (because we call `show` on the result of addition, which also has type `a`)

Notice how the compiler works backwards from the call to `show` on the result of addition to infer that the two original arguments must also implement the `Show` interface.

We didn't need to annotate any argument types or interfaces: the compiler did all the work for us. This is what people mean when they say that Haskell has "global" type inference.

A language like Rust has "local" type inference, meaning that you have to help a the compiler a little bit by providing the types and interfaces of function arguments, but then the compiler can infer the types of locally bound variables from that point forward.

Yes, read this part: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md#t... and https://github.com/Gabriel439/post-rfc/blob/master/sotu.md#r...

From my (short) time with Haskell, I've found the type system to be the best I've ever used. It really does feel like it's helping you, instead of getting in the way. And so it feels more like a dynamic language than other strongly typed languages I've used (e.g. Scala, Java).

Below is a simple example, but look, no types to type!

    >> let plus1 = (+1)
    >> plus1 10
    11
    >> :t plus1
    plus1 :: Num a => a -> a
You can ask for the type by `:t plus1`.

I've also used Clojure, and I do really like Lisps, but I don't think untyped languages give enough benefit for all the problems it causes. I'm excited, however, about Typed Clojure (and Typed Racket).

We made a choice with Rust to force you to write type annotations in function signatures, because it prevents errors at a distance. Even in languages with full type inference, writing out signatures is still considered good style for this reason.