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

[damodar kulkarni]

> 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 at 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 at haskell.org
> http://www.haskell.org/**mailman/listinfo/beginners<http://www.haskell.org/mailman/listinfo/beginners>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130813/a75b7b40/attachment.htm>