Speaking as someone who's done a good bit of Haskell, the type system only provides a syntax which catches certain classes of errors -- it doesn't catch them al

Speaking as someone who's done a good bit of Haskell, the type system only provides a syntax which catches certain classes of errors -- it doesn't catch them all, and I've only a couple of times been surprised to see "oh, hey, it worked!" the first run through. (Actually it's probably one-for-one between Haskell and JS for me, though I guess I've done several times as much work in JS as in Haskell.) The type system, for example, does not help you when you have five Ints and you use the wrong one for an index and the output of the procedure is thereby completely messed up at runtime. It helps to report a lot of other syntactic errors, and can be thought of as automatically providing the first half of a good test suite. To me the real win of the type system is how it gets you breaking down real-world problems into actual code. Programming has inertia. You can choose to either start writing garbage code until something smells right and then build organically around that smell. Totally valid. Or, you can sit and philosophize for a while about what approach you're going to take, build up some lower-level primitives that you're pretty sure you want, write some high-level overview with stub functions of what the algorithm does, connect the low-level with the high-level, and then grow organically around that. Also totally valid. For the second one, it's really nice to have type signatures. For the first, they get in the way. Both approaches for me involve about the same amount of "wasted" time -- this is what I mean by the problem's "inertia". With the first approach, I do throw away dead code at a prodigious rate; and I often find out that I've reimplemented some popular library function which does it faster and better. With the second approach, I find that I either have to waste time redrawing my diagrams in Visio to show to a boss (so that they don't think I'm goofing off just 'cause I'm not typing). But I do like the tradeoff of repetitive-strain-injury for lots of drawings. I think most of the mystique of Haskell comes from hackers well-versed in the first kind running into the type system as a mental roadblock which had to be overcome, forcing them to learn to plan a bit more, "here is where I/O will happen, here are the state variables I need to thread through this walk of the graph", etc. You can get that anywhere. I really like the syntax for Haskell function-calls, `a f (g 3 + 4)` rather than `a(f)(g(3) + 4)`. I just want to figure out a way to do tensor indices alongside it, so that I could write tutorials in mathematical physics with the same syntax -- something a bit like the Structure and Interpretation of Classical Mechanics did in Lisp.