[Haskell-beginners] sometimes Haskell isn't what you want

[Mike Meyer]

On Tue, Sep 11, 2012 at 3:21 PM, Darren Grant <therealkludgy at gmail.com> wrote:
> Just adding another perspective: I developed the AI for a complex
> turn-based strategy game in C++. By the end of the process I found
> that I was not only continually repeating myself due to the language
> syntax because I needed a *lot* of specialized list manipulations, but
> I was also effectively composing pure functions.
>
> This made me think that it could be much more effective to develop AI
> in a functional language. There's no way I could do this with Haskell
> presently as I am still struggling to approach all problems from the
> FP perspective first, but I do think there is the potential.

This reminds me of a paper on one of the early Go-playing programs -
or more exactly, lessons learned from it. One of those was
(paraphrased): "Don't maintain state. It's easier to recompute values
from the board than correctly update the state information after a
move." Every time I see a program going through grotesque gyrations to
try and keep track of state I'm reminded of this.


> On Tue, Sep 11, 2012 at 6:34 AM, Anindya Mozumdar
> <anindya.lugbang at gmail.com> wrote:
>>> I went back to it
>>> for one day (yesterday) and that was enough to make me realize how
>>> unpleasant its inconsistencies, inconsistent documentation, awkwardnesses,
>>> etc.
>> Luckily this is a small list, otherwise a flame war would have started by now.

Yup. My experience with Python is almost the exact opposite of his. I
suspect that's because 1) I work with the libraries that ship with the
language unless I need something they just don't have, in part
*because* the documentation is almost always pretty good, whereas you
never know what you'll get going to third party libraries. And 2)
realizing that the goal of the languages are different: Python is
designed to make it easy to write clear, readable code using whatever
style is best for the problem at hand. So whether some bit of
functionality winds up being expressed in functional, OO or imperative
styles will depend on which is likely to be more readable in actual
use. Trying to write Python in a single fixed style is going to be as
painful as trying to write functional style code in Java, or OO style
code in Haskell.

     <mike