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

[David Thomas]

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 <kdamodar2000 at gmail.com>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 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>
>>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130813/54c6c85a/attachment.htm>