Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: How Haskell Fits Into an Operating System / API
Environment (Philippe Sismondi)
2. Re: How Haskell Fits Into an Operating System / API
Environment (Brandon Allbery)
3. Re: How Haskell Fits Into an Operating System / API
Environment (Heinrich Apfelmus)
----------------------------------------------------------------------
Message: 1
Date: Sat, 17 Aug 2013 17:10:26 -0400
From: Philippe Sismondi <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] How Haskell Fits Into an Operating
System / API Environment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
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 li
ke 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 -
------------------------------
Message: 2
Date: Sat, 17 Aug 2013 17:26:50 -0400
From: Brandon Allbery <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] How Haskell Fits Into an Operating
System / API Environment
Message-ID:
<CAKFCL4Vf=yhyowalre-urxxckgaolpimuutbpj-tufrsqrx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sat, Aug 17, 2013 at 5:10 PM, Philippe Sismondi <[email protected]>wrote:
> 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.
I have several security lists (and victims of the reported security issues)
and several rather large sectors of industry (financial and medical, to
name two) which are increasingly realizing that this attitude isn't viable
any more. It is becoming increasingly obvious that "productivity is more
important than error-free" leads to very expensive reparations down the
road.
--
brandon s allbery kf8nh sine nomine associates
[email protected] [email protected]
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130817/ba2387fa/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 18 Aug 2013 10:55:00 +0200
From: Heinrich Apfelmus <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] How Haskell Fits Into an Operating
System / API Environment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
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
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 62, Issue 18
*****************************************
