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

[Heinrich Apfelmus]

Philippe Sismondi wrote:
> I am the original poster on this. [..]
> 
> 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.

Note that there is a principled argument for (a) that does not rely on 
empirical evidence. It goes as follows: avoiding mutable state means 
that a piece of source code, say a function definition, can be reasoned 
about *without* needing to know about the possible contexts (code paths) 
in which it can appear. In other words, the correctness of a pure 
function can be checked by looking only at the function definition, the 
rest of the program code has no bearing on it. In contrast, mutable 
state usually means a "spooky action at a distance" between separate 
code sections.

> 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.)

You know well that (1) such studies are hard to design for any language 
and (2) nobody asks for studies that quantify the benefits of imperative 
languages, simply because they happen to be the status quo.

Still, there are some interesting case studies, for instance

   P Hudak and M P Jones
   "Haskell vs. Ada vs. C++ vs. Awk vs. ...
    An Experiment in Software Prototyping Productivity"
   http://haskell.cs.yale.edu/?post_type=publication&p=366


> 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. [..]

I always dread the prospect of dealing with non-Haskell libraries, 
because I often lose several days of development time investigating how 
a library really behaves as opposed to how it should behave according to 
the specification. I have mentioned two recent examples in a previous 
email (HTML 5 drag & drop, WebSockets), but it has also happened to me 
when doing development with Cocoa.

> 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.

Note that source code is a *model* and we are free to choose any model 
we like. The "true nature" of the world being "stateful" has no bearing 
on this. For instance, physicists actually model the world in a 
stateless fashion (a particle is modeled by a function from time to 
position in space).

> 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).

Huh? How is dealing with IO not a solved problem in Haskell?

Note that there may be smarter ways to deal with "IO" (e.g. FRP), but I 
don't see how experiments with new models invalidate an existing model.

Also note that software transactional memory (STM) is a solved problem 
in Haskell, something that cannot be said of any other imperative language.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com