I recently started learning the haskell programming language. It has support for the likes of opengl and win32 and all the necessary basics for developing graphical applicaitons. I was wondering if anyone has used haskell for anything significant over here. How was the experience, what are some obvious advantages (or disadvantages) you realized as opposed to application development in c/c++ or c# or whatever?

I'm loving this language so far. It's so... different then what I'm used to. They should really add this kind of stuff to computer science courses.

I wrote a blog post here with a whole buch of links to how I got started and various tutorials and all if anyone is interested.

I had to use it for a course, probably to learn that there are more languages other than the imperative ones. We had to write a kind of Basic interpreter with it. Maybe I'm too conservative or maybe I have troubles to switch to things I'm not used with, but I never used it again. The programs you can create with it are sometimes beautiful though.

well functional programming was not a part of my curriculum at all. There was one class that gave us a few intro lessons to lisp (our AI course), but the way it was taught in those 3-4 periods made it seem insignificant and completely useless. And it wasn't actually "taught" as in how they tech OO/procedural concepts, it was just a "oh and by the way you can do this with this language". Actually, it was so horribly taught that I don't think those classes we had on it had anything to do with AI even though it was part of the AI course... And don't even get me started with my AI course, it was the course I was looking most forward to in my final semester and turned out to be the biggest dissapointment ... but that's quite OT so bleh...

Multi-threading does seem to be the biggest benefit of functional languages. The functions have no side-effects, so threads can be created be the compiler as it sees fit. So, it makes sense that they would be great for server code.

Sure it can be helpful to have some functional concepts in a programming language, but forcing everything in that paradigm makes some simple things needlessly complicated. If you're a mathematician and you're only writing small applications, it can be great, but for anything really serious it quickly becomes a pain. The claims about needing less code are true, but you need just as long or longer to write it down...

I love C++ because it's multi-paradigm. For nearly every problem there's an elegant solution. This freedom brings its own complexity but once that's mastered I see little reason to look at other languages except for very specific situations. Like my professor used to say: "I'm teaching you Haskell and Prolog to make you better C++ programmers".

If you're a mathematician and you're only writing small applications, it can be great, but for anything really serious it quickly becomes a pain.

Hmm, that's what I'm thinking so far. Though I can't really argue on this because of my lack of experience in the functional domain, but I'm looking into how true this actually is. I've heard a lot about erlang for server side development. There's an article here on devmaster actually: http://www.devmaster.net/articles/mmo-scalable-server

I love C++ because it's multi-paradigm. For nearly every problem there's an elegant solution. This freedom brings its own complexity but once that's mastered I see little reason to look at other languages except for very specific situations.

Indeed, c++ really is a beauty in that regard. Though that's also one of it's biggest "pitfalls" in my opinions - a "full of adventure and surprise" pitfiall

Just for kicks, when you've done some haskell go back and look at that nifty template facility C++ got.

You'll be asthonised when you realize that you got a complete functional compiletime language built into your C++ compiler Doing work in haskell will enhance your ability to create complex template meta programs a great deal.

yeah but using "raw" templates to get meta-programming functionality is not a walk in the park. But you are right, the light that is boost.lamda and boost.mpl do shine brighter after dabbeling in the functional world.

:blink: i have to say your comment is quite odd, this just sounds like an ill-informed and inexperienced opinion. Actually it's common for someone to say this who does not have much experience with recurision or just doesn't naturally think recursively. If you had any idea you would know it's quite the opposite.

if you're not familliar with the concepts of Accumulators, recursive operators (patterns of recursion such as Catamorphisms), and languages which foster writing recursive functions (in which with C++ this is not the case) then you do not really have a place to make such comments.

Sure it can be helpful to have some functional concepts in a programming language, but forcing everything in that paradigm makes some simple things needlessly complicated. If you're a mathematician and you're only writing small applications, it can be great, but for anything really serious it quickly becomes a pain. The claims about needing less code are true, but you need just as long or longer to write it down...

Exactly what are you basing your claims on? quite clearly this cannot be based on any comprehensive (personal) experience because of what you said above.

I can tell you for one thing there are many "serious" and significant applications which have and still are written in a number of functional programming languages so do not make assumptions and come out with rubbish like that.@Nick

I love C++ because it's multi-paradigm. For nearly every problem there's an elegant solution. This freedom brings its own complexity but once that's mastered I see little reason to look at other languages except for very specific situations. Like my professor used to say: "I'm teaching you Haskell and Prolog to make you better C++ programmers".

hey, same snk_kid from gamedev.net? I actually got started with haskell through the links in your sig on gdnet (if you're the same)... :huh:

i have to say your comment is quite odd, this just sounds like an ill-informed and inexperienced opinion. Actually it's common for someone to say this who does not have much experience with recurision or just doesn't naturally think recursively. If you had any idea you would know it's quite the opposite.

I have to agree with snk_kid on this, i've been "learning" haskell for about a week now (spend more or less my entire day on it), and recursion is getting much more natural. At the beginning I was weirded out by the fact that there were no loops as well, but it turns out that it makes more sense without them. You'll have to spend a bit more time in a heskell like environment before things start to click.

I learned Haskell in university and used it on and off from there on. It sure is a beatiful language allthough I generally am more in favor of lisp, since it is a multi paradigm language. Well... lisp by definition will be able to support close to any language feature you can think of. Sort of a local optimum in computer languages i guess.

We use Haskell in university for an automated theorem proover tool, that we produce. For that kind of work functional is the only way to go. I think for things that are less heavy on the algorithmic side and involve more "library calling" I wouldn't want to use Haskell though.

As for the loops... One great thing about functional programming is that you can look at functions as idioms. So if you miss loops, just write a function that imitates a while loop and everything is fine. Of course Lisp with macros is even better that respect.

Comparing fucntional to oop I pondered about what concept is the more general for a while and which could be expressed better in the terms of the other. I think objects could be easily expressed in functional languages. In essence an objekt is a functional closure over the objects members, that can be passed a method name. Of course that wouldn't include inheritance but that's beside the point here.

A book I can reccomond on the topic is The Art Of The Meta Object Protocol, by Kiczales, Gregor, Jim des Rivieres, and Daniel G. Bobrow.

bladder :

from your blog :

Haskell is a programming language, just like c++ or c\# is... however, it is based on completely different concepts that are simply just different then what the average computer science student is used to.

Well... C# is moving into a direction where they integrate functional concepts pretty extensively. C# now has functional closeures and anonymous methods i.e. lambda expressions, which is half the way. C3.0 is going to add type inference and real lambda expressions to that which is really nice. I tend to like this approach, because it's good to make many programming paradigms available.

:blink: i have to say your comment is quite odd, this just sounds like an ill-informed and inexperienced opinion. Actually it's common for someone to say this who does not have much experience with recurision or just doesn't naturally think recursively. If you had any idea you would know it's quite the opposite.

Could you add some arguments? Now you're just offensive.

Seriously, being limited to recursion is silly. For some really simple things in an imperative language it takes mind bending complexity to do it in a purely functional language. Don't forget that computers are imperative. When I'm writing C++, I already see the assembly code before me. With a functional language, there's absolutely no guarantee that what I see is what will be executed. Writing high performance functional applications, like games, is a nightmare.

if you're not familliar with the concepts of Accumulators, recursive operators (patterns of recursion such as Catamorphisms), and languages which foster writing recursive functions (in which with C++ this is not the case) then you do not really have a place to make such comments.

Exactly what are you basing your claims on? quite clearly this cannot be based on any comprehensive (personal) experience because of what you said above.

Again.

I can tell you for one thing there are many "serious" and significant applications which have and still are written in a number of functional programming languages so do not make assumptions and come out with rubbish like that.

Again you're getting personal. Name some high performance applications for me please.

:blink: Well now that just says it all doesn't it...

Actually the professor has decades of experience with functional languages. Claiming that teaching us functional languages will make us better C++ programmers is based on that experience. He went beyond functional languages and realized that it's not important to teach a language like Haskell, but to teach a new paradigm. I can now use both functional and logical paradigms, together with imperative and object-oriented paradigms, in multi-paradigm languages like C++ and C#. It has taught me to use the right tool for the right job. I'm tackling problems which a couple years ago would have taken me more code for a less elegant solution.

Realizing the intrinsic limitations of functional languages is fundamental. They did not make a breakthrough on their own, nor will they ever. Multi-paradigm languages are far more popular, for good reason.

In the end, programming languages (and their compilers) are nothing more than tools to write assembly code. A 'perfect' language is worthless if it's not practical. Remember that.

Lisp: Yahoo's Online Shopping Cart (in the late 90's, although I cannot speak to their current state on any given domain)

It's unlikely that these are the only examples, but these are the ones that I have seen the sourcecode for. You can hear of the woes of trying to explain how NASA's software is almost all FP from JPL and NASA engineers, but NASA doesn't want sourcecode released...ever. There are some scattered Erlang voice/data programs from NASA on the web. In the 80's, the British metropolitan phone systems were controlled by Ericsson (Erlang) phone routing software (some still is). I'm afraid I've long since forgotten the obscure names to the Traffic Control Software in Erlang that I've played with or the phone control software.

Seriously, being limited to recursion is silly.

Please do not argue your professor's views by proxy, as he is not here to correct your memory or reasoning. As it stands, this statement is false on it's face. You provide no reason it is silly, other than you don't accept it for some esoteric personal reasons. When you can actually write something in an FP again (since you've clearly drawn upon your vague memories of languages you had been told were impractical), you might learn some of your biases are unfounded, while others may be justified.

Actually the professor has decades of experience with functional languages.

After a couple years in the trenches, it has become very clear to me that I cannot trust everything I have been taught. When I go back to school to learn a new language there is an Ivory tower. A common problem among academia, wherein an instructor spends enough time teaching the basics, that they believe they are an expert in what's practical. Again, while I have no reason to doubt you have been told certain things about FP, when my experience contradicts your claims, reality wins. This means you continue to believe what you like until you take the time to find out for yourself, based on differing opinions from programmers like yourself.

Ex: I've tried it, and AJAX is silly. AJAX is XMLHttpRequest Object and what you can do with it...but it's not clever enough for PHBs, so they called it AJAX.

He went beyond functional languages

This is a cute catchphrase. Going beyond FP would be to program at a lower level, as FPs are commoditized wrappers for common imperative objects and actions. A lot of people really hate the syntax. I personally like Erlang and Lisp, hate Haskell (sorry OP )

functional and logical paradigms

Functional and Imperative. Both of them are logical.

Hope you try out some FPL again and come back with some real problems that FP can't solve. It's been a long time since I've seen a serious FP challenge. Pwning CODERS with actual examples is a lot more fun than posturing, since you get taken more seriously. More importantly, try a more appropriate forum (like comp.lang.functional) for stating that FP is useless when people use it every day. It's obvious that very few people use it here and a great many don't even use C yet.

By the way, with high-performance I actually meant performance critical. I'd love to see an AAA game or something like a video codec in a functional language...

It's unlikely that these are the only examples, but these are the ones that I have seen the sourcecode for. You can hear of the woes of trying to explain how NASA's software is almost all FP from JPL and NASA engineers, but NASA doesn't want sourcecode released...ever. There are some scattered Erlang voice/data programs from NASA on the web. In the 80's, the British metropolitan phone systems were controlled by Ericsson (Erlang) phone routing software (some still is). I'm afraid I've long since forgotten the obscure names to the Traffic Control Software in Erlang that I've played with or the phone control software.

As far as I know the primary goal of such software is correctness. I'm sure NASA doesn't care if it's a few time slower than an optimized imperative program, as long as it keeps the Space Shuttle from crashing into the earth. For these applications I'm convinced that purely functional languages have great benefits. It's excellent for control.

I tried a couple times to write a high-performance application in Haskell, but I just didn't get what I expected. It's just far less suited for number crunching. I'm aware that the compiler has a lot to do with it, but that's a worthless excuse in practice. It's also likely that I could have gotten higher performance if I rewrote some things differently, but if it requires a PhD in math to get a language to do exactly what I want then I don't want to bother with it. Sometimes it's even easier to just write the assembly code. At that point using these languages is not worth it.

This is a site about game development, and I just don't think functional languages are very useful there. But don't get me wrong, I still find them very interesting and I know they are useful for certain classes of applications. They just have their limitations. In a multi-paradigm language I get the best of both worlds and I'm not limited.

Please do not argue your professor's views by proxy, as he is not here to correct your memory or reasoning. As it stands, this statement is false on it's face. You provide no reason it is silly, other than you don't accept it for some esoteric personal reasons. When you can actually write something in an FP again (since you've clearly drawn upon your vague memories of languages you had been told were impractical), you might learn some of your biases are unfounded, while others may be justified.

If I want a loop, I want a loop. In my opinion, recursion is more complicated than a loop. That's my reason why I think it's silly. These languages are so mathematically sound, that they are harder to use in practice. Loops are still simple, but there are other things that are almost a no-brainer in an imperative language but needlessly complicated in a functional language.

After a couple years in the trenches, it has become very clear to me that I cannot trust everything I have been taught. When I go back to school to learn a new language there is an Ivory tower. A common problem among academia, wherein an instructor spends enough time teaching the basics, that they believe they are an expert in what's practical. Again, while I have no reason to doubt you have been told certain things about FP, when my experience contradicts your claims, reality wins. This means you continue to believe what you like until you take the time to find out for yourself, based on differing opinions from programmers like yourself.

I am very well aware that professors do now always know how to put their theory into practice. But this professor actually realized that functional languages are too academic to ever become really popular.

Hope you try out some FPL again and come back with some real problems that FP can't solve. It's been a long time since I've seen a serious FP challenge. Pwning CODERS with actual examples is a lot more fun than posturing, since you get taken more seriously. More importantly, try a more appropriate forum (like comp.lang.functional) for stating that FP is useless when people use it every day. It's obvious that very few people use it here and a great many don't even use C yet.

Where did I claim that functional programming can't solve certain problems? Where did I claim that functional programming is useless?

All I'm saying is that they can be limiting in practice for certain applications.

In a multi-paradigm language I get the best of both worlds and I'm not limited.

I'd just like to point out that multi-paradigm languages often don't let you use functions as first-class values, like passing a function as parameter to another one, declaring a local function and returning it, and so on. This is one of the main features of functional languages and it can be very handy. In C++ you can emulate some of this with function pointers but it's nasty; as far as I know Java has no support for this sort of thing at all. However, the next version of C# is supposed to have lambda expressions, so we'll see how that goes.

If I want a loop, I want a loop. In my opinion, recursion is more complicated than a loop. That's my reason why I think it's silly. These languages are so mathematically sound, that they are harder to use in practice.

I find certain algorithms easier to think about in recursive terms. For instance, binary tree operations like searching and inserting, quicksort, recursive descent parsing of grammars, and so forth are easier to think about and more elegant in a recursive framework. Sure, in C++ we can write these recursively if we want to. But we don't want to, because recursion is inefficient, so we rewrite them iteratively and they become harder to understand. In a functional language we can write them recursively, and if we make them tail-recursive they are almost as efficient as an imperative, iterative implementation. (As far as I know, no C++ or Java compiler optimizes tail recursion, but correct me if I'm wrong.)

Additionally, I find recursive reasoning generally easier to follow than iterative reasoning. Both are essentially equivalent, but I find the idea of a base case and then a recursive case that reduces the problem to a simpler one easier to think about than a loop invariant with initialization, maintenance, and termination arguments. If I'm trying to convince myself that something I've written is correct, it's better if it's recursive. This wasn't always the case. When I first encountered functional languages as a first year university student, I would have agreed with you that recursion was more complicated than a loop. It took some time before I learned how to think about recursion, but now it seems just as natural as a loop to me.

Of course, everything I'm saying here just applies to me and not necessarily to anyone else. If you don't like recursion, that's fine; but I hope you can see how people can have different perspectives on the matter.

...there are other things that are almost a no-brainer in an imperative language but needlessly complicated in a functional language.

Could you give an example? I think it would help the discussion if we had something concrete to point to rather than speaking in generalities all the time.

This is a site about game development, and I just don't think functional languages are very useful there.

Realistically, I'm inclined to agree. But that doesn't mean we can't discuss them.

Just remember that "math" definitions and symbols are not the BEST. That is, recursion (math-oriented) is not necessarily the BEST. I know some of you might consider me a loop-lover, but please think about math first -- it's not the super-ultra-universal easiest-to-read and perfect language. I find intuitive examples much easier to follow

Next, functional programs depend mainly on compiler. Compilers do most of the job. However they STILL rely on us, else we wouldn't have programmers This means, he has to "guess" what we wanted to accomplish, thus never really knowing the task at hand. On the other hand, if we use imperative languages, we can easily translate it with our minds directly in an "execution" oriented thing, i.e we know almost anything about the result -- thus we can write better code in this respect.

Math-lovers (this does not mean math-logic, but rather math-language): use functional languages

Logic-lovers (sorry if "logic" is not the correct term, I'm not native english): use imperative languages

ps: by "logic" I mean.. well example:

1) Aha, it computes 5+1 2) then is sees if it's > 5 3) then it jumps somewhere 4) then, based on that new variable, adds 1 5) then....

again sorry if logic is not an appropiate term.

In my opinion (just my opinion, please don't offense), math-language (not logic, just language) sucks! A good example that requires a "special" symbol in math is "Sigma" (for sums, you know).. it represents a loop.. it needs that, because it doesn't want to process it as loops. Math-language sucks. It's too :wacko:

Other funny things in math: if and only if, instead of plain if, etc..

math-logic is same for both imperative and functional languages, however imperative extend this (logic operators, weird tricks, etc). Math is abstract, I know, but the language in my opinion is :wacko:.. too confusing