[Haskell-beginners] How Haskell Fits Into an Operating System / API Environment

[Philippe Sismondi]

I am the original poster on this. I have not checked the thread for some time - I had decided to sign off on it because seemed to be veering off in the direction of a religious dispute. (That is probably my fault; my observations were perhaps too caustic.) But I seem unable to resist. Sorry if this post makes you go "TLDR". 

We seem to be revisiting the whole "state/mutability is evil" thing for the umpteenth time. There is an obvious dichotomy between algorithms that are stateful (but entirely internal to the program) and those that require state + IO. (There is probably some proper terminology for this difference, but I don't know what it is.) Anyway, my main frustration with pure FP is in respect of interacting with the "outside world", i.e. IO. I suppose that in part is what what drove my question of operating systems and their native libraries, all of which (in the case of OS X) rely on mutability and state.

One of the commonest claims made about pure functional languages, and Haskell in particular, is that programs written in pure functional languages contain fewer bugs than…"other stuff". The claim seems largely to be about (a) avoiding mutability, and (b) type safety and static type checking. (I have no quibble with the typing part of the claim; I love this in Haskell.)  In the same spirit, Haskell programmers are wont to assert that they are confident that a program that compiles is a correct program. However, these claims (as made in books on Haskell, and on mailing lists such as this) are no more than anecdotal. At the risk of pouring fuel on the fire, I would ask: Can anyone point me to scientific studies quantifying the benefits of pure functional languages? I expect they exist, but I am interested not just in lack of errors, but in overall productivity. (It's easy to avoid program bugs: just write programs that don't do anything, or don't write any software at all.)

The value of being able to produce correct programs is, no doubt enormous. But that is hardly the end of the matter.

My sense is that most of us who produce software are less interested in error-free software than in overall productivity. There is an enormous amount of highly useful software out there that contains all kinds of both known and as yet undiscovered bugs. In other words, I propose that the perfect is the enemy of the good here. We are all most likely exchanging our thoughts on the topic on this mailing list using buggy operating systems, buggy email software, buggy hardware, and buggy human brains. But somehow we soldier bravely on ;-) Somebody may be writing an experimental OS in Haskell, but I ain't using it at the moment, and neither are you (probably). Moreover, whenever a list appears of Haskell systems in production, it is woefully tiny. I am reminded of the same kind of lists of Lisp software: They invariably include AutoCAD scripting, emacs, Viaweb, and…and…and a few other niche thingies, and the list peters out. Because people are mostly writing software in shitty languages like Java and Objective-C and C++ and so on.

The world outside your program is stateful, I think (I agree with Heraclitus on this). Any software that must deal with the "world" outside itself over time must deal with state. So even devotees of of pure FP agree that the trick is to somehow hive off or isolate state and IO, or maybe to mimic it with pure techniques in order to ensure correctness.

But the problem of dealing with IO in Haskell is hardly a solved problem. Reading the history of Haskell one discovers that the use of monads was not the first attempt at dealing with IO in the language. Moreover, research papers continue to appear on other ways to handle state and IO in FPL. So it can hardly be said that, "well, we've got this problem licked, so just suck it up and learn it." It can hardly be questioned that people find monads tough to understand; some never do, and some (like me) can use them but find them a pain in the ass (so are arrows). Thus in that sense, Haskell has saved legions of programmers from writing buggy software - because it has prevented them from writing any software at all, at least in Haskell.

My guess is that FP research has and will continue to provide real benefits to software development. But making that observation that other approaches are a "bad idea" is not terribly helpful (to me, anyway). I'll continue to tinker with Haskell, and when I want to write audio software or a game or something I'll use Objective-C and the massive bug-riddled but vendor-supported, documented libraries that come with OS X.

- P -