How Haskell Fits Into an Operating System / API Environment

Philippe Sismondi

10 Aug 2013 10 Aug '13

10:22 a.m.

I am interested in tracking down discussions on how Haskell fits into an operating system environment. That is probably not a very clear question, so let me explain. One of the great obstacles I have faced in using two of my favourite languages (Common Lisp and Haskell) for anything practical is that I am constantly frustrated by their relationship with the host OS, or perhaps more accurately with the APIs provided by the OS. For example, I tend to program mostly on OS X. I have a reasonable knowledge of Cocoa, and can get quite a lot done with Objective-C. So, if I want to use Haskell on OS X, I can run off and learn about Haskell's FFI, or some hand-rolled widget package, etc. But here is the problem: Cocoa et al provide an entire ecosystem that includes data structures, error handling, and so on. So, when trying to use Haskell with a GUI, or perhaps to do some audio processing, or other things that are provided by the OS X APIs, I feel that I am layering two quite incompatible worlds together: Haskell and its host environment. I ran into the same dilemma with Common Lisp. Clozure Common Lisp provides an excellent Cocoa binding. But using it feels (to me) like communications between alien races. The OS APIs want to do things the Objective-C way, and that is (clearly) not the Haskell or Lisp way. One soon notices that books on Haskell pay virtually no attention to this issue. At least, the ones I have don't. Maybe what I am really experiencing is that OS X just "wants" to be programmed in its native language. I had something of a better feeling about using F# on Windows, because that architecture does leverage the native stuff much better. The upshot is that I remain skeptical that Haskell is actually a practical language for many kinds of development. Can anyone point me to discussions on this? I may be having a dimwitted interval here, but I don't know what to search to find this. - P -

Show replies by date

Magnus Therning

10 Aug 10 Aug

4:06 p.m.

New subject: How Haskell Fits Into an Operating System / API Environment

On Sat, Aug 10, 2013 at 10:22:06AM -0400, Philippe Sismondi wrote:

...

I am interested in tracking down discussions on how Haskell fits into an operating system environment. That is probably not a very clear question, so let me explain.

One of the great obstacles I have faced in using two of my favourite languages (Common Lisp and Haskell) for anything practical is that I am constantly frustrated by their relationship with the host OS, or perhaps more accurately with the APIs provided by the OS.

For example, I tend to program mostly on OS X. I have a reasonable knowledge of Cocoa, and can get quite a lot done with Objective-C. So, if I want to use Haskell on OS X, I can run off and learn about Haskell's FFI, or some hand-rolled widget package, etc. But here is the problem: Cocoa et al provide an entire ecosystem that includes data structures, error handling, and so on. So, when trying to use Haskell with a GUI, or perhaps to do some audio processing, or other things that are provided by the OS X APIs, I feel that I am layering two quite incompatible worlds together: Haskell and its host environment.

I ran into the same dilemma with Common Lisp. Clozure Common Lisp provides an excellent Cocoa binding. But using it feels (to me) like communications between alien races. The OS APIs want to do things the Objective-C way, and that is (clearly) not the Haskell or Lisp way.

I'm not sure there are a lot of discussions or texts on this issue, but maybe you can find some solace in me thinking that this problem pops up whenever one tries to combine components written in different languages. For instance C++ is able to call straight to C libraries, but that doesn't mean that C APIs fit well into "idiomatic C++" (or maybe I should say one of the many "idiomatic C++s"). The same goes for all other combinations I've tried out myself, Python+C, Python+C++, Java+C, Haskell+C... I'm fairly sure it is the case with *every* combination. I'm also fairly sure that the friction becomes higher the more different the languages are, i.e. combining two procedural (non-OO) languages is most likely easier than combining a procedural (non-OO) with an OO language, even if both are imperative. If the languages have different paradigms, e.g. imperative vs. functional, the friction becomes higher still.

...

One soon notices that books on Haskell pay virtually no attention to this issue. At least, the ones I have don't.

I believe the FFI is touched upon, but providing an idiomatic Haskell API for a C library is most likely an art (maybe a black one ;) at this point. So in short, you are right. (I'd love to be proven wrong here and be pointed to some recipe book for how to wrap C in Haskell, or C in Python, and do it well.) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay

Heinrich Apfelmus

11 Aug 11 Aug

4:58 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

Philippe Sismondi wrote:

...

I am interested in tracking down discussions on how Haskell fits into an operating system environment. That is probably not a very clear question, so let me explain.

One of the great obstacles I have faced in using two of my favourite languages (Common Lisp and Haskell) for anything practical is that I am constantly frustrated by their relationship with the host OS, or perhaps more accurately with the APIs provided by the OS.

For example, I tend to program mostly on OS X. I have a reasonable knowledge of Cocoa, and can get quite a lot done with Objective-C. So, if I want to use Haskell on OS X, I can run off and learn about Haskell's FFI, or some hand-rolled widget package, etc. But here is the problem: Cocoa et al provide an entire ecosystem that includes data structures, error handling, and so on. So, when trying to use Haskell with a GUI, or perhaps to do some audio processing, or other things that are provided by the OS X APIs, I feel that I am layering two quite incompatible worlds together: Haskell and its host environment.

I ran into the same dilemma with Common Lisp. Clozure Common Lisp provides an excellent Cocoa binding. But using it feels (to me) like communications between alien races. The OS APIs want to do things the Objective-C way, and that is (clearly) not the Haskell or Lisp way.

One soon notices that books on Haskell pay virtually no attention to this issue. At least, the ones I have don't.

Maybe what I am really experiencing is that OS X just "wants" to be programmed in its native language. I had something of a better feeling about using F# on Windows, because that architecture does leverage the native stuff much better.

The upshot is that I remain skeptical that Haskell is actually a practical language for many kinds of development.

Can anyone point me to discussions on this? I may be having a dimwitted interval here, but I don't know what to search to find this.

I'm not entirely sure I understand your question. The fact that, say, Objective-C uses quite a different way of speech than Haskell is not surprising, these are two different languages after all. You would have similar problems in an imaginary world where Haskell were the norm and Objective-C the exception. If you want to use both at once, you have to invest work in building a bridge. For instance, you can present Haskell in a more Objective-C-y fashion, or the other way round, or some middle ground. That's just how it is and it applies to all languages. Concerning Objective-C specifically, there was a very nice project implementing a slick FFI for Cocoa in Haskell. Unfortunately, it has been dead for years now. http://hoc.sourceforge.net/ Somewhat related, there is actually an (experimental) OS written in Haskell, see http://stackoverflow.com/a/6638207/403805 In case you're not that interested in integrating with the entire OS, but are just looking for a GUI library in Haskell anyway, I would like to toot my own horn and point to threepenny-gui, which uses the web browser as a display. https://github.com/HeinrichApfelmus/threepenny-gui Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

Philippe Sismondi

11:10 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

On 2013-08-11, at 4:58 AM, Heinrich Apfelmus wrote:

...

Philippe Sismondi wrote:

...
I am interested in tracking down discussions on how Haskell fits into <snip> I'm not entirely sure I understand your question.

Well, I admit that I am having trouble formulating my question clearly. It was probably not even clear in my own mind. However, posting and clarifying here have served a purpose for me; read on. Upon reflection, probably my real concern is not about mixing dissimilar programming languages, but about the frequently discussed issue of finding production-quality libraries for a language. This issue is a serious one for Common Lisp, Scheme, ML and OCaml, and other languages I like. It is perhaps less of a problem for languages built on a substrate such as the JVM or .NET. For most of the software that I am interested in working on, there is a vast collection of "native" stuff available in both OS X and Windows. This includes, just as an example, Core Audio in OS X. As a result of posting my (vague) question, and thinking about this, I have decided that it makes more sense to just stick to Objective-C or C when the vendor of the OS has provided a good library in their language of choice. I like Haskell and Lisp better than I like flavours of C. But for now I am going to abandon the forlorn hope of doing everything in my favourite languages when the OS ecosystem favours something else. Moreover, I am dissatisfied with the quality of Haskell libraries even for those things that are not already supplied by OS vendors. In my opinion (and I may be wrong), hackage is littered with half-baked stuff, poorly documented projects started by extremely bright grad students and then abandoned after a year or two. (Of course, there is some great stuff on there too.) As a result of this little thread I have come to another conclusion, and this is just my subjective view. Most of the software that I am interested in seems to live most comfortably with a stateful conception of the world. (The native libraries I find most useful certainly are stateful.) I am reasonably competent with monads and monad transformers in Haskell. But, to be honest, after three years of pluggin away at Haskell, I am not the least convinced that the problem of handling a changing external world in a pure functional language has been successfully solved by those techniques. I always feel as though I am using the robot arm on a space shuttle when a screwdriver would do. (Again, no need to rebut this - I may be wrong or just to stupid to use Haskell effectively - so be it.) Perhaps in the end I do not really believe that functional programming is the panacea that its devotees claim it to be. I think this post may mark the beginning of my abandonment of Haskell for many purposes. So long…. - P -

Stephen Tetley

11:45 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

I tend to see OO subtyping and heterogeneous collections as more an impediment to (pure) functional integration with the "rest-of-the-world" than state. There are a lot of quality wrappers to stateful C libraries from Haskell, but few to object oriented C++ or Objective C libraries. On 11 August 2013 16:10, Philippe Sismondi wrote:

...

As a result of this little thread I have come to another conclusion, and this is just my subjective view. Most of the software that I am interested in seems to live most comfortably with a stateful conception of the world. (The native libraries I find most useful certainly are stateful.) I am reasonably competent with monads and monad transformers in Haskell. But, to be honest, after three years of pluggin away at Haskell, I am not the least convinced that the problem of handling a changing external world in a pure functional language has been successfully solved by those techniques. I always feel as though I am using the robot arm on a space shuttle when a screwdriver would do. (Again, no need to rebut this - I may be wrong or just to stupid to use Haskell effectively - so be it.)

Perhaps in the end I do not really believe that functional programming is the panacea that its devotees claim it to be.

Philippe Sismondi

12:42 p.m.

New subject: How Haskell Fits Into an Operating System / API Environment

On 2013-08-11, at 11:45 AM, Stephen Tetley wrote:

...

I tend to see OO subtyping and heterogeneous collections as more an impediment to (pure) functional integration with the "rest-of-the-world" than state. There are a lot of quality wrappers to stateful C libraries from Haskell, but few to object oriented C++ or Objective C libraries.

That may be true. And, state and OO types are different issues. I guess I conflated the two because the stateful OS X libraries I use are largely implemented using Cocoa or sometimes C data structures. So, do I make my own Haskell list or record or type representing something in the API, or just access the Cocoa one? etc. etc. Also, in truth I introduced a totally separate gripe, which is that I find monads and monad transformers to be a hell of a messy and difficult way to deal with state. Sometimes I get sick of all the layering in monad transformers and hand-roll my own monad with all the stuff. But it just seems baroquely difficult. Perhaps I was just to set in my ways when I came to FP, and cannot really "get it". There are things I have never looked into such as FRP, but maybe my poor old brain is just not up to it. Maybe I should have been a janitor or a car salesman. - P -

...

On 11 August 2013 16:10, Philippe Sismondi wrote:

As a result of this little thread I have come to another conclusion, and this is just my subjective view. Most of the software that I am interested in seems to live most comfortably with a stateful conception of the world. (The native libraries I find most useful certainly are stateful.) I am reasonably competent with monads and monad transformers in Haskell. But, to be honest, after three years of pluggin away at Haskell, I am not the least convinced that the problem of handling a changing external world in a pure functional language has been successfully solved by those techniques. I always feel as though I am using the robot arm on a space shuttle when a screwdriver would do. (Again, no need to rebut this - I may be wrong or just to stupid to use Haskell effectively - so be it.)

Perhaps in the end I do not really believe that functional programming is the panacea that its devotees claim it to be.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Kelleher, Kevin

14 Aug 14 Aug

3:04 p.m.

New subject: How Haskell Fits Into an Operating System / API Environment

I have had the same frustration. It feels like you're learning a foreign language that doesn't have any vocabulary for walking directions, prices, or ordering food. So, while you could discuss philosophy, say, you wouldn't be able to ask for a drink of water, or how to find the bathroom. I do believe there is a payoff to studying Haskell, and I do keep plugging away, rather inconstantly. It's difficult, because I don't really have the time now, but hopefully I can devote some of an upcoming vacation to make what I know of Haskell finally touch the ground. Kevin From: Beginners [mailto:beginners-bounces@haskell.org] On Behalf Of Stephen Tetley Sent: Sunday, August 11, 2013 11:45 AM To: The Haskell-Beginners Mailing List - Discussion of primarily beginner-level topics related to Haskell Subject: Re: [Haskell-beginners] How Haskell Fits Into an Operating System / API Environment I tend to see OO subtyping and heterogeneous collections as more an impediment to (pure) functional integration with the "rest-of-the-world" than state. There are a lot of quality wrappers to stateful C libraries from Haskell, but few to object oriented C++ or Objective C libraries. On 11 August 2013 16:10, Philippe Sismondi mailto:psismondi@arqux.com> wrote: As a result of this little thread I have come to another conclusion, and this is just my subjective view. Most of the software that I am interested in seems to live most comfortably with a stateful conception of the world. (The native libraries I find most useful certainly are stateful.) I am reasonably competent with monads and monad transformers in Haskell. But, to be honest, after three years of pluggin away at Haskell, I am not the least convinced that the problem of handling a changing external world in a pure functional language has been successfully solved by those techniques. I always feel as though I am using the robot arm on a space shuttle when a screwdriver would do. (Again, no need to rebut this - I may be wrong or just to stupid to use Haskell effectively - so be it.) Perhaps in the end I do not really believe that functional programming is the panacea that its devotees claim it to be. This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you.

Heinrich Apfelmus

12 Aug 12 Aug

5:23 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

Philippe Sismondi wrote:

...

Upon reflection, probably my real concern is not about mixing dissimilar programming languages, but about the frequently discussed issue of finding production-quality libraries for a language. [..]

For most of the software that I am interested in working on, there is a vast collection of "native" stuff available in both OS X and Windows. This includes, just as an example, Core Audio in OS X. [..]

Moreover, I am dissatisfied with the quality of Haskell libraries even for those things that are not already supplied by OS vendors. In my opinion (and I may be wrong), hackage is littered with half-baked stuff, poorly documented projects started by extremely bright grad students and then abandoned after a year or two. (Of course, there is some great stuff on there too.)

Well, there are a lot of magazines at the news kiosk, too, while only a few are of outstanding quality. That is just how a news kiosk works. Speaking of quality, what I like most about Haskell libraries, even the half-baked ones, is that they have very few bugs. I've been programming functionally for a decade now, and whenever I venture into the world of imperative languages, I always trip up bugs that just shouldn't be there. Here two recent examples: * HTML 5 drag and drop. Apart from the fact that the specification is overcomplicated, Chrome doesn't even implement the spec correctly. When the mouse enters a child element of a "dropzone'd" element, the latter receives a "dragleave" event, but will not receive a "dragenter" event again when the mouse moves away from the child element. Argh! * HTML 5 WebSockets. Chrome or Safari. After a certain amount of inactivity on the server side, the browser will close the WebSocket. However, it will only close the client side, so the client cannot send messages anymore. The connection to the server is still *open*, though, and the server can happily send data. What? Also, if you connect with a WebSocket and then reload the page and connect again, the old connection will be reused. WTF? These are just examples, this happens to me all the time. Curiously, whenever I use state, my programs start to become similarly brittle. There is no reason why state should be a fundamental element of a programming language, and as a design pattern, state is best avoided at all cost.

...

As a result of this little thread I have come to another conclusion, and this is just my subjective view. Most of the software that I am interested in seems to live most comfortably with a stateful conception of the world. (The native libraries I find most useful certainly are stateful.) I am reasonably competent with monads and monad transformers in Haskell. But, to be honest, after three years of pluggin away at Haskell, I am not the least convinced that the problem of handling a changing external world in a pure functional language has been successfully solved by those techniques. I always feel as though I am using the robot arm on a space shuttle when a screwdriver would do. (Again, no need to rebut this - I may be wrong or just to stupid to use Haskell effectively - so be it.)

Perhaps in the end I do not really believe that functional programming is the panacea that its devotees claim it to be.

I think this post may mark the beginning of my abandonment of Haskell for many purposes.

Haskell may not be easy to learn, but it's definitely worth the effort. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

damodar kulkarni

13 Aug 13 Aug

12:45 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

...

Curiously, whenever I use state, my programs start to become similarly brittle. There is no reason why state should be a fundamental element of a programming language, and as a design pattern, state is best avoided at all cost.

Just as a curiosity, how would one avoid state in cases like protocol design? e.g. protocols specifications (like TCP/IP) do have a large element of state dependent behavior that "seems essential" to the problem. How would one deal with such cases? @Philippe Sismondi: I always feel as though I am using the robot arm on a space shuttle when a

...

screwdriver would do.

+1 for this remark. Thanks and regards, -Damodar Kulkarni On Mon, Aug 12, 2013 at 2:53 PM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote:

...

Philippe Sismondi wrote:

...
Upon reflection, probably my real concern is not about mixing dissimilar programming languages, but about the frequently discussed issue of finding production-quality libraries for a language. [..]

For most of the software that I am interested in working on, there is a vast collection of "native" stuff available in both OS X and Windows. This includes, just as an example, Core Audio in OS X. [..]

Moreover, I am dissatisfied with the quality of Haskell libraries even for those things that are not already supplied by OS vendors. In my opinion (and I may be wrong), hackage is littered with half-baked stuff, poorly documented projects started by extremely bright grad students and then abandoned after a year or two. (Of course, there is some great stuff on there too.)

Well, there are a lot of magazines at the news kiosk, too, while only a few are of outstanding quality. That is just how a news kiosk works.

Speaking of quality, what I like most about Haskell libraries, even the half-baked ones, is that they have very few bugs. I've been programming functionally for a decade now, and whenever I venture into the world of imperative languages, I always trip up bugs that just shouldn't be there. Here two recent examples:

* HTML 5 drag and drop. Apart from the fact that the specification is overcomplicated, Chrome doesn't even implement the spec correctly. When the mouse enters a child element of a "dropzone'd" element, the latter receives a "dragleave" event, but will not receive a "dragenter" event again when the mouse moves away from the child element. Argh!

* HTML 5 WebSockets. Chrome or Safari. After a certain amount of inactivity on the server side, the browser will close the WebSocket. However, it will only close the client side, so the client cannot send messages anymore. The connection to the server is still *open*, though, and the server can happily send data. What? Also, if you connect with a WebSocket and then reload the page and connect again, the old connection will be reused. WTF?

These are just examples, this happens to me all the time. Curiously, whenever I use state, my programs start to become similarly brittle. There is no reason why state should be a fundamental element of a programming language, and as a design pattern, state is best avoided at all cost.

As a result of this little thread I have come to another conclusion,

...
and this is just my subjective view. Most of the software that I am interested in seems to live most comfortably with a stateful conception of the world. (The native libraries I find most useful certainly are stateful.) I am reasonably competent with monads and monad transformers in Haskell. But, to be honest, after three years of pluggin away at Haskell, I am not the least convinced that the problem of handling a changing external world in a pure functional language has been successfully solved by those techniques. I always feel as though I am using the robot arm on a space shuttle when a screwdriver would do. (Again, no need to rebut this - I may be wrong or just to stupid to use Haskell effectively - so be it.)

Perhaps in the end I do not really believe that functional programming is the panacea that its devotees claim it to be.

I think this post may mark the beginning of my abandonment of Haskell for many purposes.

Haskell may not be easy to learn, but it's definitely worth the effort.

Best regards, Heinrich Apfelmus

-- http://apfelmus.nfshost.com

______________________________**_________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/**mailman/listinfo/beginners http://www.haskell.org/mailman/listinfo/beginners

Darren Grant

1:30 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

On Mon, Aug 12, 2013 at 9:45 PM, damodar kulkarni wrote:

...

Curiously, whenever I use state, my programs start to become similarly

...
brittle. There is no reason why state should be a fundamental element of a programming language, and as a design pattern, state is best avoided at all cost.

Just as a curiosity, how would one avoid state in cases like protocol design? e.g. protocols specifications (like TCP/IP) do have a large element of state dependent behavior that "seems essential" to the problem. How would one deal with such cases?

State can be achieved in pure functional languages. The difference is that the state management is not directly accessible to the programmer as it is hidden behind a highly declarative set of abstractions. This provides the benefits of consistency, and sometimes frustration when the resulting machine code doesn't perform as expected. Cheers, Darren

Heinrich Apfelmus

5:33 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

damodar kulkarni wrote:

...

...
Curiously, whenever I use state, my programs start to become similarly brittle. There is no reason why state should be a fundamental element of a programming language, and as a design pattern, state is best avoided at all cost.

Just as a curiosity, how would one avoid state in cases like protocol design? e.g. protocols specifications (like TCP/IP) do have a large element of state dependent behavior that "seems essential" to the problem. How would one deal with such cases?

Well, in a protocol like TCP/IP, the response of a participant does depend on the history of the communication, and that history can neatly be summarized in a small amount of state. I don't think it's possible to avoid state in this case. But I meant something else, actually, and should have been more precise. Namely, it is best to avoid *mutable* state as a *design pattern*, i.e. the use of IORef and thelike. Pure functions State -> State are fine, but anything were the meaning of an expression depends heavily on the context (the program state) is prone to bugs. The problem is more about source code than it is about state. To avoid bugs, each piece of source code should be understandable in isolation, i.e. it should give the same results in all contexts ("code paths"). This way, it is a lot easier to determine its correctness. Of course, "source code" has different scales, and can include protocol design. After all, protocols are made by humans, and clever design can prevent headaches later. For instance, HTTP GET requests were designed to be stateless, and that makes the protocol a lot more robust. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

David Thomas

11:21 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

It seems like it would be roughly as easy to encode TCP with continuations as with the usual imperative approaches, though I'll certainly admit I haven't tried. On Mon, Aug 12, 2013 at 9:45 PM, damodar kulkarni wrote:

...

Curiously, whenever I use state, my programs start to become similarly

...
brittle. There is no reason why state should be a fundamental element of a programming language, and as a design pattern, state is best avoided at all cost.

Just as a curiosity, how would one avoid state in cases like protocol design? e.g. protocols specifications (like TCP/IP) do have a large element of state dependent behavior that "seems essential" to the problem. How would one deal with such cases?

@Philippe Sismondi:

I always feel as though I am using the robot arm on a space shuttle when a

...
screwdriver would do.

+1 for this remark.

Thanks and regards, -Damodar Kulkarni

On Mon, Aug 12, 2013 at 2:53 PM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote:

...
Philippe Sismondi wrote:

...
Upon reflection, probably my real concern is not about mixing dissimilar programming languages, but about the frequently discussed issue of finding production-quality libraries for a language. [..]

For most of the software that I am interested in working on, there is a vast collection of "native" stuff available in both OS X and Windows. This includes, just as an example, Core Audio in OS X. [..]

Moreover, I am dissatisfied with the quality of Haskell libraries even for those things that are not already supplied by OS vendors. In my opinion (and I may be wrong), hackage is littered with half-baked stuff, poorly documented projects started by extremely bright grad students and then abandoned after a year or two. (Of course, there is some great stuff on there too.)

Well, there are a lot of magazines at the news kiosk, too, while only a few are of outstanding quality. That is just how a news kiosk works.

Speaking of quality, what I like most about Haskell libraries, even the half-baked ones, is that they have very few bugs. I've been programming functionally for a decade now, and whenever I venture into the world of imperative languages, I always trip up bugs that just shouldn't be there. Here two recent examples:

* HTML 5 drag and drop. Apart from the fact that the specification is overcomplicated, Chrome doesn't even implement the spec correctly. When the mouse enters a child element of a "dropzone'd" element, the latter receives a "dragleave" event, but will not receive a "dragenter" event again when the mouse moves away from the child element. Argh!

* HTML 5 WebSockets. Chrome or Safari. After a certain amount of inactivity on the server side, the browser will close the WebSocket. However, it will only close the client side, so the client cannot send messages anymore. The connection to the server is still *open*, though, and the server can happily send data. What? Also, if you connect with a WebSocket and then reload the page and connect again, the old connection will be reused. WTF?

These are just examples, this happens to me all the time. Curiously, whenever I use state, my programs start to become similarly brittle. There is no reason why state should be a fundamental element of a programming language, and as a design pattern, state is best avoided at all cost.

As a result of this little thread I have come to another conclusion,

...
and this is just my subjective view. Most of the software that I am interested in seems to live most comfortably with a stateful conception of the world. (The native libraries I find most useful certainly are stateful.) I am reasonably competent with monads and monad transformers in Haskell. But, to be honest, after three years of pluggin away at Haskell, I am not the least convinced that the problem of handling a changing external world in a pure functional language has been successfully solved by those techniques. I always feel as though I am using the robot arm on a space shuttle when a screwdriver would do. (Again, no need to rebut this - I may be wrong or just to stupid to use Haskell effectively - so be it.)

Perhaps in the end I do not really believe that functional programming is the panacea that its devotees claim it to be.

I think this post may mark the beginning of my abandonment of Haskell for many purposes.

Haskell may not be easy to learn, but it's definitely worth the effort.

Best regards, Heinrich Apfelmus

-- http://apfelmus.nfshost.com

______________________________**_________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/**mailman/listinfo/beginners http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Philippe Sismondi

17 Aug 17 Aug

5:10 p.m.

New subject: How Haskell Fits Into an Operating System / API Environment

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 -

Brandon Allbery

5:26 p.m.

New subject: How Haskell Fits Into an Operating System / API Environment

On Sat, Aug 17, 2013 at 5:10 PM, Philippe Sismondi 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 allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Heinrich Apfelmus

18 Aug 18 Aug

4:55 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

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

Magnus Therning

19 Aug 19 Aug

4:18 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

On Sun, Aug 18, 2013 at 10:55:00AM +0200, Heinrich Apfelmus wrote:

...

Philippe Sismondi wrote:

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

There are also a few articles on Erlang, and I believe there's good reason to believe the results with that language can be transferred to other "languages without assignment". - Productivity gains with Erlarng http://dl.acm.org/citation.cfm?id=1362710 slides: http://is.gd/BgGZyh (behind a paywall, I haven't found a freely available copy) - Breakthrough in software design productivity through the use of declarative programming http://www.sciencedirect.com/science/article/pii/S0925527397807669 (behind a paywall, I haven't found a freely available copy) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay

Henk-Jan van Tuyl

6:52 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

On Mon, 19 Aug 2013 10:18:11 +0200, Magnus Therning wrote:

...

There are also a few articles on Erlang, and I believe there's good reason to believe the results with that language can be transferred to other "languages without assignment".

- Productivity gains with Erlarng http://dl.acm.org/citation.cfm?id=1362710 slides: http://is.gd/BgGZyh (behind a paywall, I haven't found a freely available copy)

For free: "Four-fold Increase in Productivity and Quality" Ulf Wiger, FemSYS 2001, Munich http://www.erlang.se/publications/Ulf_Wiger.pdf Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

Magnus Therning

20 Aug 20 Aug

4:11 a.m.

New subject: How Haskell Fits Into an Operating System / API Environment

On Mon, Aug 19, 2013 at 12:52:20PM +0200, Henk-Jan van Tuyl wrote:

...

On Mon, 19 Aug 2013 10:18:11 +0200, Magnus Therning wrote:

...
There are also a few articles on Erlang, and I believe there's good reason to believe the results with that language can be transferred to other "languages without assignment".

- Productivity gains with Erlarng http://dl.acm.org/citation.cfm?id=1362710 slides: http://is.gd/BgGZyh (behind a paywall, I haven't found a freely available copy)

For free: "Four-fold Increase in Productivity and Quality" Ulf Wiger, FemSYS 2001, Munich http://www.erlang.se/publications/Ulf_Wiger.pdf

Thanks! I was trying to find that paper yesterday, but apparently my google-fu isn't as strong as yours ;) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

4290

Age (days ago)

4300

Last active (days ago)

List overview

Download

17 comments

10 participants

participants (10)

Brandon Allbery
damodar kulkarni
Darren Grant
David Thomas
Heinrich Apfelmus
Henk-Jan van Tuyl
Kelleher, Kevin
Magnus Therning
Philippe Sismondi
Stephen Tetley