This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance.
> The more bugs in the system, the shorter you can think ahead.
Very true. Too many bugs prevent me from thinking ahead, forcing me to program very slowly by trial-and-error.
> If you have to work with some buggy system over which you have little or no control, which is often the case, you are limited in how much you can think ahead.
There are many buggy systems over which I have little or no control. I often, however, can decide not to work with such systems in the first place. Since such buggy systems have so much effect on my productivity, it is worth putting a lot of effort into avoiding them.
> This may be why so many Haskell examples are math-centric: it allows you to look the farthest into the distance.
It may also explain why Haskell has so much built-in error checking, why Haskell programmers have been pioneers with respect to new testing strategies (Quickcheck), and why Haskell programmers try to separate `pure` and `impure` code so that as much of their program as possible can be math-centric. They are trying to spend as little time as possible with buggy code that slows them down.
> That's no doubt true, but that can only get you so far
Thinking ahead is great only under ideal conditions, as you pointed out. If you accept whatever conditions are there, thinking ahead can only get you so far. Taking responsibility for such conditions, and trying to change them, can get you much farther.
--------------
I actually don't use Haskell very much, but Clojure has a lot of similarities. Like Haskell, Clojure has a lot of support for abstraction and allows you to do a lot with very little code. Perhaps even more importantly, Clojure libraries tend to be simpler, easier to understand, and less buggy than their Java counterparts.
I'm curious as to what you have in mind as a credible example in Haskell of a "buggy system over which you have little or no control." Haskell is such a marginal little language right now that it hasn't attracted the same level of programmer mediocrity as, say, Java has.
Also, the typing system tends to all but eliminate common errors in other languages -- your segfaults and NPEs and buffer overflows. Haskell tends to front-load the pain of development. If your code compiles, you can reasonably expect that any bugs in the code are due faults in your own reasoning rather than failing to accommodate some unplanned-for side-effect (like the uninitialized pointer in C). And unless you've made the mistake of locking up all your logic within the IO monad, finding and correcting these faults tends to be more straightforward, thanks to the math-like syntax.
My experience with Haskell is that, as hard a language as it is to learn, it is remarkably easy, once learned, to think in.
I never see those in Smalltalk. I'd be surprised if that's an issue in Python, Ruby, or Lisp.
(But the number of DoesNotUnderstand errors in Smalltalk is quite impressive. This is why XUnit unit testing was first developed in Smalltalk. Unit testing with good code coverage is the only way to reliably prevent those.)
I'd be very surprised if there weren't similar issues in these languages, since these are all duck-typed and the topic at hand is "bugs prevented by rigorous up-front type checking." I don't have extensive experience in any of the above, so I couldn't include any examples of errors they are prone to.
Duck typing means that I can run an incomplete program, that is, one that will misbehave for certain inputs.
It turns out that running incomplete programs is incredibly useful.
Yes, I can spend time up front to fake a complete program and remove the fakeness as I provide additional completeness, but ....
Those are no doubt buggy to some degree.
The headaches you run into have more to do with getting Haskell to recognize where the relevant dev and runtime libraries are, especially on non-Unix systems where library locations are not standardized. It's possible, but you end up having to hack the Cabal package, a process that is not particularly well documented at the moment.
Another issue is simple bitrot. Many libraries in Hackage were developed by students who have no interest in maintaining their thesis work post-graduation.
Doing iPhone development in XCode, I find it's best to try out code with lots of NSLog statements and a breakpoint in the new routine, so I can explore what's happening at runtime. (The NSLog statements are mainly to get around annoying quirks in the inspectors when you have really long Strings.) This is probably just my taking my Smalltalk habits and trying to do analogous things in XCode/Objective-C.