What is Haskell?

[zachogden]

I have been wondering for a while what Haskell is for. Does it have any specific uses, or is it an all around language?

[Whiteknight]

as an addendum, what makes a language a "functional language?"

[Strike]

http://www.hprog.org/fhp/HaskellLanguage

[zachogden]

The website says that Functional programs are like mathematical expressions that are "executed" by simplifying them as much as possible. Functional languages are also tied together by featuring function values that are as easy to manipulate as more common data types, allowing them to be combined in interesting ways..

I still don't know what Haskell acoomplishes. Does it simplify any sort of problems?

[sicarius]

It depends on what you mean by simplifiy. A big draw for functional languages is that you can say a lot with a little bit of code. You can also use lazy evaluation (which basically allows you to mess with infinite data structures).

I took a course in Haskell when I was in school, but I've pretty much forgot everything because I have yet to encounter it in the wild. I do remember that one thing I hated about functional languages was performing I/O. It is so easy to implement algorithms, but doing something so basic as printing some text to the console is very convoluted.

[slidewinder]

Originally posted by sicarius
II do remember that one thing I hated about functional languages was performing I/O. It is so easy to implement algorithms, but doing something so basic as printing some text to the console is very convoluted.

Not really.

module Main where
main = putStrLn "Hello, world."


is a complete "hello world" program in Haskell, for example.

For less trivial IO, you just need to learn the "do" syntax , which is very simple, and serves the purpose of permitting sequencing in a "pure" language where expressions can otherwise be evaluated in any order whatsoever.


module Main where
main = do input <- getContents
putStr $ reverse input


You could just as well use the monadic "bind" operators ">>=", and ">>" for simple actions like the above[1], which could be rewritten


module Main where
main = getContents >>= putStr . reverse


Either of which is a complete program that reverses and prints the text from stdin. That doesn't seem particularly convoluted to me. Different from what most are used to, yes, and a little more verbose than most scripting languages, but not really that bad.

The advantage of this "imperative sublanguage" is that the compiler can let you know when you mistakenly or improperly mix pure ("mathematical") and impure functions. The reason that's nice is that you can often formally prove things about the pure aspects of (any) program that you can't about the impure aspects. When you can mix the two with impunity, this becomes harder. These guys (http://www.galoisconnections.com/), for example, use Haskell for that reason.

1. The "do" syntax is just sugar for the ">>=" and ">>" bind operators, in fact, and the compiler rewrites it into that form.

[sicarius]

For such a simple example yes, but more complicated I/O requires more use of the do statement, which becomes crappy very fast. Functions need to start evaluating to I/O types, etc, etc.

There may be some advantages to functional languages, but I don't think they are mature enough for me to develop commercial apps in.

Yes, yes. You may be able to provide 10 or even 100 examples of people that use it. I don't think you'd find, however, full win32 GUI apps (where the GUI is coded in Haskell). Also, if I wanted to hook Haskell into some of the more advanced windows APIs I'd probably have to do a lot tinkering. Since most gui toolkits are signal or event based, you run into a lot of people grafting GUIs onto functional programs. That is so 1980s.

[slidewinder]

Originally posted by sicarius
For such a simple example yes, but more complicated I/O requires more use of the do statement, which becomes crappy very fast.

But you said
doing something so basic as printing some text to the console is very convoluted.


So you'll concede that it's not complicated in the "simple" case, then? Because I don't see how it becomes any more complicated, compared to other languages, when you start doing more realistic things, either. That "do" syntax doesn't suddenly turn into a big scary monster. There are just more pseudo-assignments, and more statements inside your "do" block. Exactly the same as there would be more statements in any other language.

Originally posted by sicarius
There may be some advantages to functional languages, but I don't think they are mature enough for me to develop commercial apps in.


The languages themselves (well, I'll just talk about Haskell here) are plenty mature as far as design goes. I think you would have a hard time arguing, for example, that Haskell is not at least as well designed as, say Java, C#, or C++.

If you have a beef, it's got to be with the implementations and infrastructure. There are many fewer Haskell libraries and frameworks than Java or C# ones. That is certainly a very big drawback, and probably a deal killer for the vast majority.


Yes, yes. You may be able to provide 10 or even 100 examples of people that use it. I don't think you'd find, however, full win32 GUI apps (where the GUI is coded in Haskell). Also, if I wanted to hook Haskell into some of the more advanced windows APIs I'd probably have to do a lot tinkering. Since most gui toolkits are signal or event based, you run into a lot of people grafting GUIs onto functional programs. That is so 1980s.

Huh? Of course Haskell has bindings to GUI toolkits. Here's one (http://wxhaskell.sourceforge.net/) to wxWidgets, for example, which is cross-platform but uses the native widgets on each platform. Programming with it is really no different than programming in an imperative language:


module Main where
import Graphics.UI.WX

main :: IO ()
main
= start hello

hello :: IO ()
hello
= do f <- frame [text := "Hello!"]
quit <- button f [text := "Quit", on command := close f]
set f [layout := widget quit]


( http://wxhaskell.sourceforge.net/quickstart.html )
There's our familiar imperative "do" syntax, and we have the equally familiar GUI event-driven programming.

I guess with your "so 1980s" comment you were talking about writing a stdin/stdout Haskell program and then using a GUI written in another language to wrap that. There's no more reason to do that in Haskell than in any other language.

I'm not going to claim that Haskell is a great choice for the usual code monkey "enterprise Java/.NET app" work. It'd be a terrible choice for that kind of stuff, not least because of the huge lack of 3rd party libs and frameworks which I already mentioned, and even more because there simply aren't that many Haskell coders out there.

I'm also not trying to be jerk by disagreeing with you, so I hope that neither my original post nor this one comes off that way. I think most peoples' problems with functional languages boils down to "it's different!", and they never get past that. That's fine, I guess, but it'd be nice if that were recognized. Personally, I like that Haskell is different, but I admittedly do not find any of the real bread-winning languages particularly satisfying. Programming in Java or C# is better than digging ditches, but it could be a lot better still.

[zachogden]

Holy crap man. How long did that take you to write?

[sicarius]

No, I don't care if you have your own opinion.


Programming with it is really no different than programming in an imperative language:


Exactly, so why switch?


I guess with your "so 1980s" comment you were talking about writing a stdin/stdout Haskell program and then using a GUI written in another language to wrap that. There's no more reason to do that in Haskell than in any other language.


That is exactly what I was talking about. I don't count bindings because really any language could do that. My issue is more that I haven't seen a GUI toolkit that was native to Haskell (or any other functional language), but I imagine it is theoretically possible to make one.

I agree with your point about some people liking functional programming just because it is different. I thought it was nifty for a while, then I got a big "so what?" feeling. For me to really get into using another language it has to provide me with something that is really great and it has to be able to natively handle all the things I want it to do.

[Strike]

Originally posted by sicarius
Exactly, so why switch?
One of the more compelling (albeit not really all that interesting in practical use, IMO) arguments from the Haskell camps is that since it is purely functional, you can more or less calculate that your functions will always do the same thing given the same input. There's no real "state" to worry about affecting.

For the long version of "why haskell?" check out this bit on haskell.org (http://www.haskell.org/complex/why_does_haskell_matter.html)