Slashdot Mirror

I doubt that the original designer of Haskell had an SCM tool, e.g. darcs, in mind when creating the language.

I disagree; keeping track of multiple revisions of data is an important AI topic and would be exactly the sort of thing the committee had in mind. Show me something utterly divorced from academic interests - an FPS game perhaps - and I'll be impressed.

Academics... You keep using that word. I do not think it means what you think it means.

in the end, procedural programming is simply more intuitive

Maybe that's the reason why you can do procedural programming in functional languages. And monads are the way to do it; they are so important because they provide the bridge between the imperative and functional worlds, keeping the best of both.

If you really appreciate imperative programming, you should learn how monads work, because monads are a mathematical (declarative) description of procedural computations. Monads are used by building a sequence of operations, much like a Unix pipe, carrying state from one operation to the next. (Why defining a monad then, instead of using an imperative language? Because with the monad, you have the definition visible in your program, instead of hidden in your execution engine/virtual machine).

As for the *why* of monads: they are a Design Pattern in functional languages, just like "Observer" or "Strategy" are design patterns in Object-Oriented Programming. If you structure your code according to the predefined pattern, you'll likely get some benefits in terms of flexibility and mantainability.

The benefits provided by monads are close to those provided by Dependency Injection and Inversion of Control in OOP: you can delegate some complex processing into a supporting framework. Then you can build your application in terms of small blocks whose control flow is handled by the framework in the right order, thus helping reusability and simplifying the bookkeeping a lot.

For the *how* this is done, I recommend reading about the assembly line and space station metaphors (in that order), as well as any explanation intended "for imperative programmers". As I said, the structure of a monad is similar to a Unix pipe, but with user-defined types instead of just plain text. The "lift" and "bind" functions are methods defining an interface to comply with the pattern definition (they are a constructor and a sequencer, respectively).

When I look into a language, the first thing I check is "How do I do random IO to fixed size blocks on a disk file?" Most functional languages don't document any answer to that at all.

http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#21

"How do I draw pictures on the screen, and get user responses?" Gtk is an acceptable answer. So is SDL.

http://haskell.org/gtk2hs/
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL

When I look into a language, the first thing I check is "How do I do random IO to fixed size blocks on a disk file?" Most functional languages don't document any answer to that at all.

http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#21

"How do I draw pictures on the screen, and get user responses?" Gtk is an acceptable answer. So is SDL.

http://haskell.org/gtk2hs/
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL

When I look into a language, the first thing I check is "How do I do random IO to fixed size blocks on a disk file?" Most functional languages don't document any answer to that at all.

http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#21

"How do I draw pictures on the screen, and get user responses?" Gtk is an acceptable answer. So is SDL.

http://haskell.org/gtk2hs/
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL

As this gives some problems with IO, Haskell, taking purity to the extreme, had to wait for the invention of Monads to be able to do IO. Yes, Haskell was not capable of IO (reading/writing) for years.

How wrong can you be? Really.

If you would actually take some time to read the Haskell standards (which are all freely available,) you would see that Haskell 1.3 introduced Monads as the way to encapsulate I/O and side effects (the IO Monad.) Before that, i.e. Haskell 1.0 to Haskell 1.2, streams and continuations were the foundations for doing input and output with the real world.

Next time think before you speak utter nonsense. Wait, I forgot, this is Slashdot. My bad.

I've never heard of Hackage until I read this post, even though I've been reading about Haskell and other functional languages on and off for several years now.

Hackage is well known to haskell programmers. It is linked to directly from the front page of haskell.org, it is mentioned frequently on the haskell-cafe mailing list, and that's where hundreds of haskell projects are hosted. If you're an average passer-by and not an active haskell developer, it's not necessarily going to jump out and say "boo!", but it isn't hiding under a rock, either.

Note: hackage is not the standard libraries. Those are documented elsewhere.

I've never heard of Hackage until I read this post, even though I've been reading about Haskell and other functional languages on and off for several years now.

Hackage is well known to haskell programmers. It is linked to directly from the front page of haskell.org, it is mentioned frequently on the haskell-cafe mailing list, and that's where hundreds of haskell projects are hosted. If you're an average passer-by and not an active haskell developer, it's not necessarily going to jump out and say "boo!", but it isn't hiding under a rock, either.

Note: hackage is not the standard libraries. Those are documented elsewhere.

When I look into a language, the first thing I check is "How do I do random IO to fixed size blocks on a disk file?" Most functional languages don't document any answer to that at all. (With Erlang it's "Use our custom database", so they've an answer, of sorts.)

For haskell, you might want to look at System.Posix.IO. I haven't had to do arbitrary seeking in haskell, but that's what I'd probably try first if I did. Of course, all this has to happen inside the IO monad, so you'll need to be prepared to deal with monads. You might find the IO chapter in real world haskell helpful.

The second thing I look for is "How do I draw pictures on the screen, and get user responses?" Gtk is an acceptable answer. So is SDL. Erlang has a custom approach that is decent for drawing buttons in boxes, etc., but not really sufficient for what I want. Most functional languages don't seem to even consider the matter. (Perhaps they do, but it doesn't seem to appear in the documentation.)

Both haskell and ocaml have pretty good OpenGL bindings, called Hopengl (tutorial) and LablGL respectively. Ocaml also has a simpler built-in graphics library, and haskell has an (I believe) windows-only graphics library that is used extensively for examples in the book "The Haskell School of Expression".

Thoughts on Haskell, from a Haskell programmer.

Haskell has a very nice software transactional memory library, which makes a lot of otherwise-difficult concurrency problems much easier. It's statically safe, too, unlike similar libraries for imperative/OO languages.

Certain other language features are very nice. Monads are also extremely powerful once you wrap your head around them, and the type-class system and standard libraries make a lot of math programming problems much easier.

The language also has downsides. The laziness makes it possible to build up an arbitrarily long chain of suspended computations, which amounts to a hidden memory leak. Laziness also complicates the semantics for "unchecked" exceptions, most notably division by zero. The combination of laziness and purity can make the language very difficult to debug and optimize. While the compiler has very powerful optimization capabilities, sometimes code needs to be just so to use them (like flagging things "const" or "restrict" in C), and this can make it hard to write clean code that runs fast.

The other problem is that most programs need some amount of imperative code somewhere to do the I/O. This code has a tendency to be verbose, nasty and slow in Haskell.

There are also some problems that would be relatively easy to solve in a very nice way within the semantics of the language (give or take), but are not solved well in the standard libraries. These include exception handling, global mutable state, strings and regular expressions, certain I/O operations, arrays and references. It would be very nice if the ST and IO monads were unified, and if references and arrays had nice syntax; this would reduce the ugliness needed to write those occasional bits of imperative code.

That underlying C code is what needs to be written carefully, because you use Haskell itself to write its own compiler.

There's a Haskell compiler written in Haskell already. Where does C fit in to that?

After the 'l' and before the 'o'.

Don't you mean "After the 'g' and 'h'"?

Now, if Haskell is smart enough to be able to cache the result of the 100th Fibonacci number and use it later (like as the starting point for the calculation of the 200th), that would be useful.

Well Haskell isn't "smart" in the sense that it goes out and arbitrarily caches things it thinks may be helpful (that way leads to madness).

It does cache computations it's made if you store them in a variable or part of a data structure, so if you plan things right, you can get the behaviour you want.

Basically, here's one advanced way of calculating fibs in Haskell:

fibs = 0 : 1 : [ a + b | (a, b) <- zip fibs (tail fibs)]

(From Haskell for C Programmers).

This takes a bit of thinking to work out, but basically it declares fibs as a list of ints, which is infinitely long, the first two elements are 0 and 1, and each subsequent element is the sum of the previous two.

But there's a catch - unlike C where declaring an infinite data structure would be absurd, Haskell stores it this way:

[0, 1, <some vague concept of the remaining computation>] - a finite data structure of in fact just three elements.

Now you request the 100th fibonacci number, like this: (fibs !! 99). Haskell doesn't know the value of elements 2 through 99, so it unrolls it, performing the computation as much as possible - that's the laziness. Now it stores:

[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, ... , 218922995834555169026, <some vague concept of the remaining computation>]

And it returns you the value 218922995834555169026 which is the last *known* element of the list. Note however that the computed list so far remains.

Now you request the 200th fibonacci number, like this: (fibs !! 199). And Haskell figures it has to do some more computation, but it already knows the first 100. So it just unrolls the next 100 elements, and gives you the 200th fib. You could subsequently request (fibs !! 37) and it would look it up without recomputing.

Note that this is a bit of a bad example, as Haskell uses linked lists, the lookup itself is linear, which is the same as the computation time. But other more expensive computations could be done using this technique.

Also note that my definition is a lot smaller and closer to the mathematical definition of Fibonacci sequence than your C code. Functional programming is (or at least tries to be) about defining what you want to compute, not how you want to compute it. Having said that, it does often mess with my head and I tend to use imperative languages for this reason ;)

That underlying C code is what needs to be written carefully, because you use Haskell itself to write its own compiler.

There's a Haskell compiler written in Haskell already. Where does C fit in to that?

After the 'l' and before the 'o'.

There's a Haskell compiler written in Haskell already. Where does C fit in to that?

Absolutely, and this is why there's one of freenode's biggest IRC channels, a pair of mailing lists with thousands of subscribers, and the Hackage library/tool repository just waiting to help you solve your real world problem. Be it Compiler building, version control, writing interpretters for popular imperrative languages, Writing 3D shooters, or a whole host of other tasks.

Absolutely, and this is why there's one of freenode's biggest IRC channels, a pair of mailing lists with thousands of subscribers, and the Hackage library/tool repository just waiting to help you solve your real world problem. Be it Compiler building, version control, writing interpretters for popular imperrative languages, Writing 3D shooters, or a whole host of other tasks.

Absolutely, and this is why there's one of freenode's biggest IRC channels, a pair of mailing lists with thousands of subscribers, and the Hackage library/tool repository just waiting to help you solve your real world problem. Be it Compiler building, version control, writing interpretters for popular imperrative languages, Writing 3D shooters, or a whole host of other tasks.

This is nonsense. There are hundreds of bindings and other great libraries.

A separate, but related problem is that the community doesn't seem interested in practical use of it
Really? That's why there's a new book called Real World Haskell. The IRC channel on freenode is one of the largest on the entire network, and full of people doing real world things with haskell.

there aren't lots of bindings to libraries to make easy things easy.

I call FUD. The Hackage databasehas literally hundreds of libraries sat there ready for you to use. And if you really need something that isn't there, the FFI is mature, and very easy to use.

Haskell for everyone's favorite lazy functional language.

Data structures, compiler design, operating system design - all of these require vastly different languages than purely functional ones.

Then why is the Glasgow Haskell Compiler written in Haskell? You can do absolutely anything that you can do in an imperative language in a functional language, oftentimes with far less code and sometimes running faster (YMMV). If you need definitive proof of this, such proof does exist.

Computer Science departments must teach concepts, and those require languages flexible enough to express different paradigms.

But functional languages use those very same concepts! Also, you can learn the nuts and bolts of programming without having to worry about segmentation faults and bus errors and java.lang.NullPointerExceptions. Newbies should be taught to program in a type-safe environment!

Seriously just check out the "Who's Using Haskell?" bit of the Haskell Wiki. You can't just disregard an entire style of programming just because it doesn't look like the languages you're used to.

C#/.NET - http://msdn.microsoft.com/
Haskell - http://haskell.org/
Nemerle - http://nemerle.org/
OCaml - http://caml.inria.fr/
PHP - http://php.net/
Python - http://python.org/
Ruby - http://ruby-doc.org/ (API docs), http://ruby-lang.org/ (for more links and info)
SML - http://smlnj.org/ (the most popular implementation), http://standardml.org/Basis/ (standard library)

(X)HTML/CSS/DOM/XSL/etc. - http://w3.org/

Hm. Now that I've written it down, I see most of these are obvious, but then it makes sense, that the "official" sites tend to be the best reference.

SNOBOL - http://www.snobol4.org/

Logo - http://el.media.mit.edu/Logo-foundation/logo/programming.html

FORTH - http://www.phact.org/e/forth.htm

Prolog - http://www.logic.at/prolog/faq/faq.html

Algol - http://www.algol68.org/

Lucid - http://www.haskell.org/haskellwiki/Lucid

PL/I - http://www.users.bigpond.com/robin_v/resource.htm

Aside from the obvious, there are some interesting papers, essential reading, a mailing list, a tutorial, and even a (reasonably complete) wikibook.

Aside from the obvious, there are some interesting papers, essential reading, a mailing list, a tutorial, and even a (reasonably complete) wikibook.

Aside from the obvious, there are some interesting papers, essential reading, a mailing list, a tutorial, and even a (reasonably complete) wikibook.

Sorry I didn't think we were confined to the same company. I was arguing against the idea that the research "dies".

A public example is the Glasgow Haskell Compiler. True, it's not actually Microsoft branded as "MS Visual Haskell" or anything like that, but it is developed largely by Microsoftians (most prominently Simon Peyton Jones at Microsoft Cambridge). We all get a pretty decent and very usable compiler out of it; does it matter so much that it isn't branded as a Microsoft product?

I've got three words for you:

Glasgow Haskell Compiler.

More info

Basic parallelism hinting

More sophisticated tools

I've got three words for you:

Glasgow Haskell Compiler.

More info

Basic parallelism hinting

More sophisticated tools

I've got three words for you:

Glasgow Haskell Compiler.

More info

Basic parallelism hinting

More sophisticated tools

I've got three words for you:

Glasgow Haskell Compiler.

More info

Basic parallelism hinting

More sophisticated tools

Haskell programs can use whitespace to define blocks. However, anything that can be done with the layout rule (whitespace) can also be done with braces and semicolons, so you can have it either way.

Now that I'm working in academia researching functional programming languages I read feeds like Lambda the Ultimate, comp.lang.functional, PLNews, Topix Programming Languages, Planet Python and Planet Haskell.

Get a better programming language.

module Timer where
import System.Environment
import Control.Concurrent
import Control.Concurrent.Chan

main = do {
putStrLn "Command Line Parameters";
sync <- newChan;
args <- getArgs;
forkIO $ timer sync $ length args;
sequence_ $ zipWith (zipf sync) [1..] args;
} where zipf sync n s = (readChan sync) >> (putStrLn $ (show n) ++ ": " ++ s)

timer :: Chan Int -> Int -> IO ()
timer sync n = mapM_ (\n -> (threadDelay $ 1000000) >> (writeChan sync n)) [1..n]

http://www.haskell.org/haskellwiki/Haskell_in_web_browser

Data Parallel Haskell.

Cheers.

Haskell has parMap for that sort of situation. I've been using parMap to speed up a raytracer I'm writing. I'm getting less than linear speedups for some unknown reason, but it does help and it's easy to use. (I switched from ocaml to haskell partly because I wanted the parallelism, and partly because I wanted to learn haskell.)

Comments on the Cox paper from the Haskell regex implementer. Another response, from the Perl side.

Ruby and Erlang are the two I've spent the most time with so far. I like Ruby enough so far, that I've decided to write the initial
batch of install scripts for OpenQabal in Ruby.

Outside of that wish-list, I also harbor some vague hope of one day finding time to dabble with Forth, Fortran, Perl, and maybe Dylan.

• Lambda calculus-ish
  • Scheme
  • Haskell
• Combinator/Forth-ish
  • Joy
  • Interesting but not practical: unlamdba iota and jot
• Logic
  • Prolog
  • Mercury - compiled and pure
  • Lygon - prolog like linear logic programming.
• Pi calculus-ish
  • Join calculus
  • Nomadic Pict

I think I want to master logic programming next, though it may be better for me to do some haskell programming first so I have a better foundation. Monads/Arrows give me a headache, but with enough time, I'm sure I could get used to them. s-expressions a-la lisp/scheme are very similar to xml, except better, but logic programming seems more likely to make the hardest parts of internet programming easier.

Unfortuately, I have nowhere near enough time to get proficient in all these languages.

Most functionnal programming languages are a good step in this direction. Either Erlang with a message base approach or the pure way of (most interesting in my opinion) Haskell are very easy to run concurrently. Pure languages avoids mutable elements (think variables) so only the sequencing issue remains. That can be done with special instructions (seq) or by the language itseft (there is many Haskell variants going this way).

The "vaunted" MS Research team

I just skimmed it, so tell me if I'm missing something, but did they just not know about functional languages?

A purely functional language can, indeed, thread as much as you care to. A function without side effects can't really have any contention issues with any other functions, right?

In fact, I think that is the main distinction -- ever play with make? Did you notice that it's a declarative language? Check out the "-j" option -- unless you've done something clever, your Makefile will already scale to as many cores as you have, and if you wrap gcc (with distcc and such), it will scale to quite a few machines, too.

Or just take any purely functional language like Haskell, and you find similar features, where it's basically a matter of tuning performance settings -- much like tweaking the cache values on a MySQL database.

Now, they are correct in that it's very unlikely that you'll find an auto-parallelizing C compiler anytime soon. Or C#, or Java, or any imperative language, which is a shame -- I know I think and program much more quickly in an imperative language than in a functional one.

And they are also correct in that language constructs can make the job a lot easier, even in imperative languages. Erlang is mostly functional, but not quite purely functional -- functions can have side effects (though they generally don't), and functions are guaranteed to be executed in order. But Erlang also has lightweight green threads (it calls them "processes"), and extremely powerful language constructs, to the point where I've heard it called "Concurrency-Oriented Programming" -- your entire program is already built around message passing. And while multicore isn't automatic, it does become trivial to modify your code to run on multiple cores or computers (it has its own built-in RPC), and the sockets library is good enough that you can do it the old-fashioned way, too.

And, of course, there's Python's continuations and other neat toys.

Check out Haskell, specifically GHC's parallel library, which has an occam-like 'par' and 'pseq' commands. There's also Erlang, which has recently had a very good book entitled "Programming Erlang" released by the Pragmatic Programmers.

You say ick to something, and then go on to code C? Jesus man, you need more exposure. For the love of god, learn haskell, and see just how much you're missing.

I suppose I should be glad that you didn't say C++ or Java... that, at least, is something.

Use Haskell. It's a purely functional language, so no variables, no garbage, nothing to worry about :)

No, your assertion is not correct. The programs are not the same, because they do not perform the same computation. Though the "add" relation that they define is the same, the functions that you can ask the language to evaluate are not the same. If I'm writing a program, I'm not just concerned about the fact that it contains a definition of a particular mathematical object—I need to know what it will tell me about that object, that is, what function of it will be evaluated. The fact that two programs calculate different functions and give different answers is not a trivial one :)

By repeated beta reduction?

No, it isn't. It's relevant because it produces different results!

Nice try, but no! Finite domains? The domain of a function in a functional program can be infinite. Take the identity function: that should be pretty clear. Or a function that adds one to each element of a list of integers. There are an infinite number of such lists (take the list that contains n instances of the number 7, for any natural number n). So your proof falls down.

Haskell allows you to define new binary operators trivially, and set/override the precedence and associativity of operators (/w "fixity" declarations). Haskell assumes that a function name consisting entirely of symbols is meant to be used as an operator. You can even apply a function infix style using backquotes, e.g. "3 `func` 4" (yes, you can define precedence and associativity for those too).

OTOH, Haskell is very different from most languages (in a good way, IMO), being pure functional, lazy and statically typed. It's definitely not a drop-in replacement for C++ or Java.

If MS ever goes to a POSIX based UNIX type OS with a Windows GUI, just like Apple did, they would do the same thing but they wouldn't be nice enough to maintain an open source version like Apple has done with Darwin.

I don' see the ol' em-dollarsign pullin' that kinda shit veritably soon. They got a lot invested inta vista architectrally, and honestly now, deep down it ain't any worse than unix... it's mostly a matter of dev process suckage, which'd soon enough infect any other code base. But heyo ya know what? Them microfuckers do contribute to at least one total bona fide community open source project: GHC!! No kiddin, check out the site maint's email addr.

If you love type safety, you should check out Haskell.