sometimes Haskell isn't what you want

Sadly, I've decided Haskell is not the right language for my current project. Python is better. I need to hack together data, and strict typing is getting in the way. Most of my algorithms are better served with imperative/mutable-data. I learned a lot about Haskell trying to do it, but my knowledge of the language is not quiet good enough and I feel like I'm fighting the language. Python is better. For now.

If one programming language suited every computable problem there
would only be one programming language.
You don't seem to have a point worth making without more description
of your problem.
On Sun, Sep 9, 2012 at 1:10 AM, Dennis Raddle
Sadly, I've decided Haskell is not the right language for my current project. Python is better. I need to hack together data, and strict typing is getting in the way. Most of my algorithms are better served with imperative/mutable-data. I learned a lot about Haskell trying to do it, but my knowledge of the language is not quiet good enough and I feel like I'm fighting the language. Python is better. For now.
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
-- -- Regards, KC

... strict typing is getting in the way....
When Haskell's strict typing seems to get in your way, chances are more
that you are heading for a big and nasty problem (aka, bug) sometime down
the line, unless you are extremely careful of what you do.
Strict typing is a boon to software designers in that it helps point out
even major design flaws and that too rather earlier.
But, apart from this, if one is trying to deal with a computational problem
involving lots and lot of state-change (and things like memoization etc),
then there is no "easy" way out for a beginner in Haskell. IMHO, that's
because, Haskell isn't modelled after the so called state-change model of
computation.
But I am sure, Haskell Gurus out there may help you out if you give more
inputs about your problem.
-Damodar
On Sun, Sep 9, 2012 at 1:45 PM, KC
If one programming language suited every computable problem there would only be one programming language.
You don't seem to have a point worth making without more description of your problem.
On Sun, Sep 9, 2012 at 1:10 AM, Dennis Raddle
wrote: Sadly, I've decided Haskell is not the right language for my current project. Python is better. I need to hack together data, and strict typing is getting in the way. Most of my algorithms are better served with imperative/mutable-data. I learned a lot about Haskell trying to do it, but my knowledge of the language is not quiet good enough and I feel like I'm fighting the language. Python is better. For now.
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
-- -- Regards, KC
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

I agree with this. Often it seems that Haskell takes longer to write, but I think this is because it makes you work harder than other languages before it compiles successfully. The tradeoff here is that you wind up with fewer runtime errors, which are more frustrating than compiler errors. A Haskell program is a proof of its own type. Writing proofs is a challenging task. Whether you want to incur this overhead is, of course, up to you as a programmer. Nick On Monday, September 10, 2012 03:28:45 PM damodar kulkarni wrote:
... strict typing is getting in the way....
When Haskell's strict typing seems to get in your way, chances are more that you are heading for a big and nasty problem (aka, bug) sometime down the line, unless you are extremely careful of what you do.
Strict typing is a boon to software designers in that it helps point out even major design flaws and that too rather earlier.
But, apart from this, if one is trying to deal with a computational problem involving lots and lot of state-change (and things like memoization etc), then there is no "easy" way out for a beginner in Haskell. IMHO, that's because, Haskell isn't modelled after the so called state-change model of computation.
But I am sure, Haskell Gurus out there may help you out if you give more inputs about your problem.
-Damodar
On Sun, Sep 9, 2012 at 1:45 PM, KC
wrote: If one programming language suited every computable problem there would only be one programming language.
You don't seem to have a point worth making without more description of your problem.
On Sun, Sep 9, 2012 at 1:10 AM, Dennis Raddle
wrote:
Sadly, I've decided Haskell is not the right language for my current project. Python is better. I need to hack together data, and strict
typing
is getting in the way. Most of my algorithms are better served with imperative/mutable-data. I learned a lot about Haskell trying to do it,
but
my knowledge of the language is not quiet good enough and I feel like I'm fighting the language. Python is better. For now.
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
-- -- Regards, KC
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Well, at least you now know that the language exists and you have some idea of where its associated resources (libraries, tutorials...) are located, so that you can take it up again if the need arises in the future... Angelos Date: Sun, 9 Sep 2012 01:10:14 -0700 From: dennis.raddle@gmail.com To: beginners@haskell.org Subject: [Haskell-beginners] sometimes Haskell isn't what you want Sadly, I've decided Haskell is not the right language for my current project. Python is better. I need to hack together data, and strict typing is getting in the way. Most of my algorithms are better served with imperative/mutable-data. I learned a lot about Haskell trying to do it, but my knowledge of the language is not quiet good enough and I feel like I'm fighting the language. Python is better. For now. _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

On Sun, 9 Sep 2012, Dennis Raddle
Sadly, I've decided Haskell is not the right language for my current project. Python is better. I need to hack together data, and strict typing is getting in the way. Most of my algorithms are better served with imperative/mutable-data. I learned a lot about Haskell trying to do it, but my knowledge of the language is not quiet good enough and I feel like I'm fighting the language. Python is better. For now.
I always recommend Scheme. It is like Haskell in one respect: The Scheme Tribes keep the Ritual and the Law of Lambda. Scheme is different from Haskell in two respects: We Lispers do all our coding under the Great Functor, the Great Functor from Code to Objects in the Lisp World. For most Scheme systems, the Type Sub-System calculates less at compile time. Robert Harper has a new textbook available at http://www.cs.cmu.edu/~rwh/plbook/book.pdf and here is a useful notice of the book http://blog.ezyang.com/2012/08/practical-foundations-for-programming-languag... ad missing the Great Functor: See remarks on "symbols" in the section 32.3 on page 321, and the discussion of observational equivalence in section 47.1 on page 498. A Lisper reading these sections might say "Ah, the Great Functor is worthy of study by New Type Theorists too. We Lispers consider a symbol to be a symbol first, and nothing else until you pass across one or more functors, and then the symbol might become many different things.". ad "dynamic typing" vs "static typing": Professor Harper's blog post http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static... deals with this. I think the claim made, that "dynamic typing" is a special case of "static typing", is, when sympathetically read, right. oo--JS.

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. I used to program in Python. 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. Maybe Haskell will make me think harder but at least the whole
language and supporting documentation and the whole community has "got my
back." Haskell is a gift and I'm not throwing it away.
Yay!
On Mon, Sep 10, 2012 at 2:23 PM, Jay Sulzberger
On Sun, 9 Sep 2012, Dennis Raddle
wrote: Sadly, I've decided Haskell is not the right language for my current
project. Python is better. I need to hack together data, and strict typing is getting in the way. Most of my algorithms are better served with imperative/mutable-data. I learned a lot about Haskell trying to do it, but my knowledge of the language is not quiet good enough and I feel like I'm fighting the language. Python is better. For now.
I always recommend Scheme.
It is like Haskell in one respect:
The Scheme Tribes keep the Ritual and the Law of Lambda.
Scheme is different from Haskell in two respects:
We Lispers do all our coding under the Great Functor, the Great Functor from Code to Objects in the Lisp World.
For most Scheme systems, the Type Sub-System calculates less at compile time.
Robert Harper has a new textbook available at
http://www.cs.cmu.edu/~rwh/**plbook/book.pdfhttp://www.cs.cmu.edu/~rwh/plbook/book.pdf
and here is a useful notice of the book
http://blog.ezyang.com/2012/**08/practical-foundations-for-** programming-languages/http://blog.ezyang.com/2012/08/practical-foundations-for-programming-languag...
ad missing the Great Functor: See remarks on "symbols" in the section 32.3 on page 321, and the discussion of observational equivalence in section 47.1 on page 498. A Lisper reading these sections might say "Ah, the Great Functor is worthy of study by New Type Theorists too. We Lispers consider a symbol to be a symbol first, and nothing else until you pass across one or more functors, and then the symbol might become many different things.".
ad "dynamic typing" vs "static typing": Professor Harper's blog post
http://existentialtype.**wordpress.com/2011/03/19/** dynamic-languages-are-static-**languages/http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static...
deals with this. I think the claim made, that "dynamic typing" is a special case of "static typing", is, when sympathetically read, right.
oo--JS.
______________________________**_________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/**mailman/listinfo/beginnershttp://www.haskell.org/mailman/listinfo/beginners

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.
Haskell is a gift and I'm not throwing it away.
Luckily this is a small list, otherwise a flame war would have started by now. Personally, I learnt the basics of Haskell in the year 2000 in college. I am re-learning it again, and it's an absolute delight. I am not a programmer by profession - and this is the only language which *makes* me want to learn it as I am generally interested in math and bit of CS theory. It's also interesting to note that Haskell is being used in finance, and maybe I will get to use it professionally one day. Regards, Anindya

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.
Cheers,
Darren
On Tue, Sep 11, 2012 at 6:34 AM, Anindya Mozumdar
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.
Haskell is a gift and I'm not throwing it away.
Luckily this is a small list, otherwise a flame war would have started by now.
Personally, I learnt the basics of Haskell in the year 2000 in college. I am re-learning it again, and it's an absolute delight. I am not a programmer by profession - and this is the only language which *makes* me want to learn it as I am generally interested in math and bit of CS theory. It's also interesting to note that Haskell is being used in finance, and maybe I will get to use it professionally one day.
Regards, Anindya
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

On Tue, Sep 11, 2012 at 3:21 PM, Darren Grant
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
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.

On Tue, Sep 11, 2012 at 1:53 PM, Mike Meyer
On Tue, Sep 11, 2012 at 3: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.
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.
Yea, and when the rules for the game change frequently, it is vital to maintain composition. Cheers, Darren

On Tue, 11 Sep 2012, Darren Grant
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.
Cheers, Darren
I know of no decent taxonomy of programs. For example the Linux kernel runs, at least on my machines, for the great majority of my loads, for literally years without trouble. Most of the time, my standard stack of Emacs, quack, and Aubrey Jaffer's SCM, works just fine, though occasionally the repl-Emacs connection fails to behave properly. Usually one of a small standard set of repair tricks works to restore the repl. The famous "Unix pipeline of filters" is an example of part of the stuff that Functional Programming advocates advertise. And spreadsheets are an example of another one of the advertised advantages. Now these four things, the Linux kernel, the Emacs-SCM short stack, a Unix one liner, and a spreadsheet system, are all programs. They differ in presentation and in use and in implementation. Here is a missing book (I am aware of the just attack that this is too easy.): A Taxonomy of Computer Programs which would have at least one chapter for each of the the four kinds of programs. oo--JS.
On Tue, Sep 11, 2012 at 6:34 AM, Anindya Mozumdar
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.
Haskell is a gift and I'm not throwing it away.
Luckily this is a small list, otherwise a flame war would have started by now.
Personally, I learnt the basics of Haskell in the year 2000 in college. I am re-learning it again, and it's an absolute delight. I am not a programmer by profession - and this is the only language which *makes* me want to learn it as I am generally interested in math and bit of CS theory. It's also interesting to note that Haskell is being used in finance, and maybe I will get to use it professionally one day.
Regards, Anindya
_______________________________________________ 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

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.
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
On 09/11/2012 04:21 PM, Darren Grant wrote: 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

On Tue, Sep 11, 2012 at 6:03 PM, Michael Carpenter
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.
The parallel relationships point is interesting. I think sequential cases could still be helped by FP as well. I look at things like OpenGL wrappers for Haskell, which successfully solve immediate interop problems, but then wonder about revisiting whole approaches by applying new techniques. For instance, what if you cut out the existing OpenGL API and feed an infinite list into the device command buffer? It seems like there should be this potential for cutting latency and improving bandwidth through system comprehension tools, but that this sophistication has not become accessible to application programmers. I know there are plenty of experts hard at work on these problems, but they are interesting.
- Michael
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
participants (10)
-
Angelos Sphyris
-
Anindya Mozumdar
-
damodar kulkarni
-
Darren Grant
-
Dennis Raddle
-
Jay Sulzberger
-
KC
-
Michael Carpenter
-
Mike Meyer
-
Nick Vanderweit