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

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