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

[Michael Carpenter]

On 09/11/2012 08:16 AM, Dennis Raddle wrote:
> I went briefly to Python but guess what? I I U-turned right back to 
> Haskell. Because there is nothing like the consistent documentation 
> and well-thought-out libraries of Haskell. There is nothing else like 
> the help from #haskell or this list.
^This, right here, is one of the strongest things Haskell has going for 
it. I'm learning Haskell too and I love how active the community is, how 
helpful the documentation is, and how robust the technologies coming out 
of it generally are. I don't know why I haven't experienced this with 
another language before, but you search "haskell" in the search engine, 
immediately click on the Haskell Wiki, and enter a pretty website filled 
with everything Haskell related. The two books that you can learn 
Haskell from are free online, the #haskell channel chats long into the 
night long after all my other channels have dissipated, the subreddit 
and stackexchange get used, and the mailing lists are very informative 
and helpful. Not to mention the language itself is amazingly versatile, 
expressive, and robust. Then there is the fact that GHC manages to 
compile this awesomeness into something that's actually fast AND there 
is GHCi in case you want it. I'm sure there are things that Haskell 
simply isn't made to do, but that's like criticizing duct tape because 
it's not a duck.

On 09/11/2012 04:21 PM, Darren Grant wrote:
> 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.
There is a lot of potential here in my opinion. The two language 
families that have built their reputations through their use in AI 
research, Lisp and Prolog, share a lot in common with Haskell. AI, along 
with a lot of the big problems out there, seem to always boil down to 
parallel relationships between sets of data in a model rather than 
sequential object-oriented recipes. I would not be surprised if 
functional languages like Haskell supersede many of the imperative 
languages because of these problem sets. Sometimes I think I'm stupid to 
say that, but then I remember what SQL and RDBMS's did for the database 
world.

- Michael