3 ms·
an impressive number of programs work correctly the first time they [compile]. Everybody says this about Haskell, and it's probably true. But really, isn't it
by mnemonicsloth 17y ago
an impressive number of programs work correctly the first time they [compile].
Everybody says this about Haskell, and it's probably true.
But really, isn't it about as true of Lisp, Scheme, or Clojure? Once you can call your program in a repl, it's probably mostly right. Maybe it's just my inexperience with Haskell showing, but ISTM that the square-peg-round-hole errors catchable by type checking are pretty rare.
Am I missing something?
- Zak 17y agoI've found my Haskell code much more likely to do what I want the first time it is accepted by the compiler than Clojure, CL or Scheme. On the other hand, I find it easier to play around with things in a Lisp REPL than GHCi. Maybe that's because I have more experience with Lisp than Haskell, but I suspect there's something inherent. I don't think one approach is better than the other, but each has strengths that help with certain kinds of development.
- skew 17y agoFor one, GHCi doesn't even provide the whole language. You can't define new types, classes, or instances, and as a matter of syntax you have to use explicit braces or semicolons for multi-line things. I haven't used it much, but O'Caml's REPL is better on these counts. As far as semantics, GHCi doesn't let you redefine a function and continue working, largely, I suspect, because Haskell doesn't describe how that should work. Conversely, if you keep your source open in an editor and reload, then you can change classes, macros, etc, but you lose your state across reloading (declaring top-level values to set up your testing state can help, but it's less fluid).
- silentbicycle 17y agoDue to type checking, the compiler verifies that it still works as you refactor. People don't usually re-test everything exhaustively in a REPL after changes. Type checking is still in effect during long-term maintenance.