Comment by silentbicycle | Hacker News Reader

Comment by silentbicycle | Hacker News Reader

I'm not surprised that he's finding Haskell's static typing to be a hurdle. I had the same experience when I started learning OCaml after years with Python and Scheme - it took me a couple days to think in, rather than fight with, its type system. Nowadays, I strongly recommend reading _The Little MLer_ before starting with Haskell or OCaml - it does for static typing what _The Little Schemer_ does for Lisp.

Its type checks can be incredibly useful for finding code needing updates during refactoring, automatically verifying things that would otherwise require writing reams of tedious tests, etc. It's a trade-off, though - you're deliberately structuring your code so that your assumptions can be mechanically checked. This is very much a matter of taste, and I understand having strong opinions either way. (I go back and forth on it.)

Stupid type systems suck hard, though - smart static typing (ML and Haskell) and full dynamic typing (possibly with optional static annotations) both work well, but in between lies pain and misery.

Also, look at the follow-up: (http://tourdelisp.blogspot.com/2008/03/farewell-haskell.html) I feel like he barely tried.

It should be noted that Haskell's type system supports a form of dynamic typing: Existential types http://www.haskell.org/haskellwiki/Existential_type (among other methods).

Also, static polymorphic types are a superior substitute for many uses of dynamic typing.

My type system experience mostly comes from OCaml, not Haskell, and I haven't done much with existential types.

While I feel vaguely anti-intellectual saying this: I grok the H-M type inference used by ML* , and the simplest mechanical application of it probably covers 95% of the things I'd use it for. It simplifies things immensely, yet it's easy to reason about. I'm not sure that more advanced types are useful enough to justify the added complexity, personally. (Though if I added one thing to ML, it would be typeclasses.)

However, I'm sure that, with sufficient experience, they probably also become second nature. I just prefer languages with relatively small semantics.

* If I had understood unification when I was learning OCaml (I learned Prolog/unification later), though, it would have seemed practically obvious. "It's trying to unify the types, based on actual usage...oh! And it infers when they're parametric!" (with a few special cases so that e.g. functions keep their more specific types in recursive calls.)

It's possible to do without Existential Types, in fact they are only a language extension supported by GHC, not part of any standard. I think the obvious way to "simulate" existential types is with records like

data MyRec = MkMyRec { op1 :: Int -> (MkMyRec, Int); op2 :: MkMyRec }

Existential types just give you direct access to all methods in an existing typeclass, which may or may not be helpful.

Btw., OCaml is on my list of "things to do" right below "create something with more than 200 lines in Haskell" (which is hard because Haskell is so dense). ;-)

"create something with more than 200 lines in Haskell" (which is hard because Haskell is so dense). ;-)

You might succeed by translating USSM http://www.loup-vaillant.fr/projects/ussm The system is written in about 300 lines of Ocaml, and should be easy to translate. Plus, you can rewrite it piece by piece, and still have a system that works.

My problem with raw H-M is that it introduces a lot of very tight binding between modules; this can be good when it comes time to detect things you missed in a refactoring, but it is often still a bit too much binding even in my own code base, and it is definitely too much binding in a library. And large code bases structured sanely should usually be built like libraries anyhow. Being able to use classes and a selected handful of other constructs goes a long ways towards making Haskell more practical, even if the inference engine sometimes needs a bit more help.

(And yes, I know you can hide symbols and such, but with raw H-M you still get these rigid concrete types. An XML parsing library that emits only XML datatypes defined in that one library and every function you write then has to know about these datatypes, and you can forget about changing that library ever again without entirely rewriting every line of code that touches it. Theoretically "every line that touches it" should be in some interface that converts it to your internal concepts, but in practice I am not completely wrapping every damn library I use so I still end up with some concrete types from libraries throughout. Mathematically this makes perfect sense, as a developer it makes my laugh derisively. Fortunately the situation isn't as bad as all that, though I'm still not 100% convinced that I'm not still at least chuckling derisively. I've been fiddling with Haskell for nearly a year now and I'm still completely undecided whether this is the future or an amusing but futile diversion from the ivory tower. I've never been this undecided about a language for so long. The awesome is so awesome, then I stumble into some unbelievably poky briar patch that I could have at least hacked around in any other language.... it's very odd.)

You're absolutely right about modules. I didn't mention them because I tend to think of the module system as being independent from the type system, but they're actually closely related.

I find that F#'s (close to OCaml) type system helps me think through problems and lets me get correct programs faster, that somehow just seem to work correctly the first time.

Usually when writing a program in F# I usually write out the types of the functions I need first, before worrying about how the functions work. Because the type system is so descriptive I can validate that a plan to solve a problem is going to work before I start writing code.

Because the type system is powerful, when I need to make a change, it is simple to determine where my assumptions are broken and make the correct fixes.

> Usually when writing a program in F# I usually write out the types of the functions I need first, before worrying about how the functions work.

And that kind of things can give rise to such wonderful tools as hoogle (a type-based Haskell search engine, specify the type you need and it'll find the matching functions, whose types are often quite good insight as to their purpose)

Reply on news.ycombinator.com