Why Lazy Functional Programming Languages Rule

Da Massive writes "Techworld has an in-depth chat with Simon Peyton-Jones about the development of Haskell and his philosophy of do one thing, and do it well. Peyton-Jones describes his interest in lazy functional programming languages, and chats about their increasing relevance in a world with rapidly increasing multi-core CPUs and clusters. 'I think Haskell is increasingly well placed for this multi-core stuff, as I think people are increasingly going to look to languages like Haskell and say 'oh, that's where we can get some good ideas at least', whether or not it's the actual language or concrete syntax that they adopt.'"

Comments

I would have RTFA

[Anonymous Coward]

But I was too lazy to click on 13 pageviews.

Mmmm, Kay.

[jellomizer]

Hascal, and other functional languages may be good for multi-core development. However not to many programmers program in them... Plus I find they do not scale well for larger application. Its good for true computing problem solving. But today most developopment is for larger application which doesn't necessarly solve problems per-say but create a tool that people can use.

Re:Mmmm, Kay.

[thermian]

I spent a whole term at uni learning Miranda, which is similar to Haskell, I really liked it. I have *never* seen it being used since. To my mind they both belong in the category 'interesting, but pointless'.

Its not just because they're old. If age was what killed languages, C and Lisp would be long dead. There just isn't anything I could do with either that I wouldn't be able to do more easily with another more 'mainstream' language.

Re:Mmmm, Kay.

[beelsebob]

I call FUD. There's a lot of things that Lazy functional languages make easy, that mainstream languages don't. Here's just a few examples:
Infinite data structures can be handled naturally. Here's a function that generates the infinite list of fibbonacci numbers:
fibs x y = x : (fibs y (x + y))
Here's a list that does a complex calculation on every one of the fibbonacci numbers:
map complexCalculation (fibs 1 1)
While we're at it, Haskell programs are very easily parallelisable. Here's the same list, but computed on multiple cores:
(parMap rnf) complexCalculation (fibs 1 1)
Haskell only evaluates what it has to -- this program for example which looks up the 3000th element of the sequence will not compute the complexCalculation on the 2999 fibbonaccis before hand like a traditional program would:
(parMap rnf) complexCalculation (fibs 1 1) !! 3000

There's only a small sample of what's so powerful about these languages. If you'd bothered to RTFA, you'd know there are a lot more. But then, I guess this is slashdot.

Re:Mmmm, Kay.

[Anonymous Coward]

Sure, the language might be powerful. However, if it's difficult to read, like that is, it makes real-world projects a nightmare. Imagine having a project with millions of lines of code in that obscure speak.

This seems like something those people who write in obfuscated "efficient" C would drool over, but project managers wouldn't touch with a 20-foot pole.

Re:Mmmm, Kay.

[Anonymous Coward]

"Plus I find they do not scale well for larger application"

You find this from your vast experience not using it? Quit making up FUD because you don't want to learn new concepts and are happy in imperative land. Nobody is forcing you to learn a good language, and there will always be plenty of jobs for mindless java monkies like you, relax.

Re:Mmmm, Kay.

[beelsebob]

It's only difficult to read if you don't know it. I personally (being experienced in both Haskell and a wide variety of imperative languages) find it much easier to read than any of the imperative languages I've looked at.

Re:Mmmm, Kay.

[Dragonslicer]

I call FUD. There's a lot of things that Lazy functional languages make easy, that mainstream languages don't. Here's just a few examples: Infinite data structures can be handled naturally.

Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

Re:Mmmm, Kay.

[Bill, Shooter of Bul]

I agree 100% Haskell is awesome. However, not everyone who is designing rails like sites is going to be working with fibbonacci numbers. We, the doers of awesome, must come up with real world solutions to real world problems that make use of the awesomeness. And then we must document the awesome for all to see and appreciate.

Re:Mmmm, Kay.

[thermian]

It's only difficult to read if you don't know it.

That is true of almost any language. The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages. Elegance cannot beat convenience in the workplace, or in most at any rate.

All that aside, how many Haskell programing jobs have you seen advertised lately? Like it or not, that's what decides which languages people use.

That's why I have to deal with languages I'd prefer to never use, because that's what pays the rent. In my own time I use C.

Re:Mmmm, Kay.

[mean pun]

Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

Might that be because mainstream programming languages don't support infinite data structures?

Re:Mmmm, Kay.

[beelsebob]

I've seen quite a few Haskell jobs advertised recently actually, I even got one of them :).

Re:Mmmm, Kay.

[Dhalka226]

I call FUD.

I call meme misuse.

Re:Mmmm, Kay.

[Abcd1234]

Mmmm... yes, I see you picked a few practical, real world examples, and didn't try to stack the deck with tasks that Haskell (or a similar language) would be particularly well-suited for.

Or not.

Re:Mmmm, Kay.

[NoNeeeed]

Here's a function that generates the infinite list of fibbonacci numbers: fibs x y = x : (fibs y (x + y))

You have just demonstrated thermian's point.

How often do you actually need to generate infinite sequences? I have never needed to do that outside of a functional programming class.

I'm a big fan of alternative programming languages, I've used some 20 or so since I started 20 years ago. I did a fair amount of commercial Prolog development after I left university, I really like Prolog. It makes certain things really easy and it's a joy to code certain types of solutions in, but I'm never going to write a web-app, or a word-processor in Prolog.

Many of these languages are very clever when it comes to doing certain things, but how often do you actually need to do those things?

The truth is that the vast majority of the software out there does pretty dull, mostly procedural jobs. That's why the main languages in use are just dull variations on the procedural, C/Java/Perl style. No matter how much maths geeks go on about functional programming, procedural systems will always be more suited and easier to use for most of the problems out there.

That isn't to say there is no place for these alternative languages, but it's a smaller one which you probably won't see very often.

Paul

Re:Mmmm, Kay.

[beelsebob]

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.

Re:Mmmm, Kay.

[Rob Riggs]

Functors and generators will do the same thing for you in a more mainstream languages like C++ and Python. And they'll be a hell of a lot more understandable to your average still-wet-behind-the-ears programmer. And you can certainly write code in those languages to do lazy evaluation.

Now, I will grant you that, in general, one can do it more concisely in Haskell than one could in C++ and even Python. But these languages are more well rounded, IMO, than Haskell.

Re:Mmmm, Kay.

[beelsebob]

How often do you actually need to generate infinite sequences?
Actually, when you're able to do it naturally in your language, it becomes a very useful thing to do. For example, when you want fresh variables in a compiler, it's very useful to have the infinite list of variable names you haven't used yet hanging about.

Re:Mmmm, Kay.

[afabbro]

I call FUD.

I call meme misuse.

Thank you. There is no fear, uncertainty, or doubt here.

Re:Mmmm, Kay.

[localman]

That is very cool, but does anyone need to do any of those things in the programs that are being created and used today? I'm talking websites, media players, and video games? Haskell may be the coolest thing in the world but maybe not many people need or want the coolest thing in the world. This is always the problem with arguing "but it's better!": things generally only need to be good enough.

If you don't believe me, look at the human race. Do you think that high intelligence or great beauty are driving evolution forward? Or is it "good enough" people who reproduce a lot?

I'm not saying the general tendency towards "good enough" is a good thing, or that anyone should stop doing cool stuff with Haskell, but I'm not terribly surprised it hasn't caught on.

Cheers.

Re:Mmmm, Kay.

[Anonymous Coward]

I call FUD.

I call meme misuse.

Thank you. There is no fear, uncertainty, or doubt here.

All your FUD belong to us.

Re:Mmmm, Kay.

[jbolden]

That is true of almost any language. The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages. Elegance cannot beat convenience in the workplace, or in most at any rate.

That was the point of the examples he gave there are lots and lots of things that are easier to do in lazy languages than in mainstream languages. Huge blocks of code simply aren't written because they aren't needed.

Re:Mmmm, Kay.

[jbolden]

Sure they do. How many lines in the next web page? How many variables? How many on the whole site? How many simultaneous users? How many files do they need access to?

Not having to worry about these constraints saves tons of time.

Re:Mmmm, Kay.

[Anonymous Brave Guy]

Plus I find they do not scale well for larger application.

And you discovered that through your own experience with functional programming languages, did you? It's remarkable that you could have gained such insight, yet not know how to spell the name of one of the best-known FPLs in town.

I rather suspect that, like many critics of FPLs, you have never actually tried to use them for a big project, and just assume that they won't scale because you read it somewhere.

But today most developopment is for larger application which doesn't necessarly solve problems per-say but create a tool that people can use.

I'll gloss over whether your unverified assertion about "most development" is actually true. Even assuming it is, producing good tools requires things like defining abstractions and building modular libraries to contain them, and these are areas where several of the relatively popular FPLs excel compared to the drek most of us have to use at work.

There are many valid technical and social reasons that the current generation of FPLs have not taken off — Peyton-Jones himself has talked about them insightfully on several occasions — but I can't agree that the reasons you suggested are among them.

Re:Mmmm, Kay.

[Vexorian]

I call FUD

Did you know that FUD does not really mean 'disagrees with what I think'? He never said lazy languages are useless, he mentioned LISP as a language that's still being used. In my opinion lazyness is useful, so let's just wait for an imperative language to steal that feature so people can actually use it, just like what happened with the rest of functional languages' features... (I know people are gonna mod me troll for this, don't worry)

Re:Mmmm, Kay.

[david.given]

Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

Sure they do. On my computer, there's an infinite stream of ethernet frames arriving, an infinite stream of video frames leaving, an infinite stream of keyboard events arriving, etc.

The thing about functional languages, and strict lazy functional languages like Haskell, is that the underlying principles are quite different from procedural languages like C. In C, you tell the computer to do things. In Haskell, you tell the computer the relationships between things, and it figures out what to do all on its own.

Personally, I suck at Haskell --- I'm too much of a procedural programmer. My mind's stuck in the rails of doing thing procedurally. But I'd very much like to learn it more, *because* it will teach me different ways of thinking about problems. If I can think of an ethernet router as a mapping between an input and output stream of packets rather than as a sequence of discrete events that get processed sequentially, then it may well encourage me to solve the problem in a some better way.

Re:Mmmm, Kay.

[jbolden]

Video games is a good example of where Haskell would be excellent. The AI for most of these games is terrible. And it is terrible because making reasonable choices in a game is a very complex analysis. So complex that most programmers can't handle it.

Another example is taking advantage of the hardware. Right now because of eager evaluation it is very difficult to take full advantage of hardware. Use lazy evaluation and the system can allocate tasks based on hardware availability (like a mainframe does).

Re:Mmmm, Kay.

[Tetsujin]

Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

Might that be because mainstream programming languages don't support infinite data structures?

Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

(OK, now everybody imagine that this is in fact an infinite thread of responses and counter-responses which aren't actually evaluated or stored until you ask to see them...)

Joking aside, though - lazily-evaluated, conceptually-infinite data structures are a useful way to express things sometimes... I figure most programmers don't have a deep enough understanding of how that style of expression can be useful - in part because so much software development these days is dominated by the procedural model...

Re:Mmmm, Kay.

[mrops]

Real world comprises of transactions, security, fault-tolerance, uptime and databases to name a few. Those excellent examples have no real world quality, except maybe demonstrate a bit of distributed programming.....

Re:Mmmm, Kay.

[Tetsujin]

I call FUD.

I call meme misuse.

I call no tagbacks!

Re:Mmmm, Kay.

[Ngarrang]

That was the point of the examples he gave there are lots and lots of things that are easier to do in lazy languages than in mainstream languages. Huge blocks of code simply aren't written because they aren't needed.

...because the underlying code was already written and is being used by the above layer. The lower layer was probably written in C. And that underlying execution engine needs to be programmed, profiled and optimized for the very multi-core operation that adherents of lazy func's claim. That underlying C code is what needs to be written carefully, because you use Haskell itself to write its own compiler. So, lazy functional languages are another variation of 4GL stuff.

Re:Mmmm, Kay.

[Anonymous Coward]

Got it.

Fibbonaccis calculator => Functionnal Language
Any other application => {pick a real language} :-p

Seriously, say again why nobody write real world application in haskell ?

Re:Mmmm, Kay.

[the_greywolf]

Infinite data structures can be handled naturally. Here's a function that generates the infinite list of fibbonacci numbers:
fibs x y = x : (fibs y (x + y))

Which doesn't help me understand how to apply infinite recursion of a lambda to my immediate problem, which may be as trivial as asynchronously handling arbitrary messages which may or may not be related in a direct sequence.

I'm sick of seeing the Fibonacci example. It doesn't help me understand the language at all. It just tells me, "O HAI I HAS TAIL RECURSION." Good for you. Now show me how to do other things.

Re:Mmmm, Kay.

[arevos]

The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages.

At University, I studied SML, and came out with a opinion similar to yours concerning functional languages. But when I started to learn Haskell on my own, really learn it, I found that all the concepts in my CompSci courses that seemed so pointlessly complex before, just fell neatly into place.

I'll give you an example of a case where my solution in Haskell to a problem was rather better than any solution I came up with in C#. A while ago I was designing a program to export some hierarchical data held in a database to XML. Because SQL resultsets are 2D grids, I needed a way of converting a 2D grid into a list of fixed-depth tree structures.

In Haskell, the solution is two lines of code, and assuming you know Haskell pretty well, it's fairly clear as well:

listToForest :: Eq a => [[a]] -> Forest a
listToForest = map toBranch . groupBy ((==) `on` head) . filter (/= [])
              where toBranch = Node . (head . head) <*> (listToForest . map tail)

I'd be interested to see if you could mirror the functionality in one of the 'popular' languages you mentioned. Perhaps something in Java?

Re:Mmmm, Kay.

[Dragonslicer]

On my computer, there's an infinite stream of ethernet frames arriving, an infinite stream of video frames leaving, an infinite stream of keyboard events arriving, etc.

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

Re:Mmmm, Kay.

[tedu_again]

newvariable = "variable" + numvariables++

Re:Mmmm, Kay.

[grumbel]

Depends on how you determine "easy to read". The main difference between Haskel and say C is that Haskel is very dense while C is not so much, so one line of Haskel holds a lot more information then C, which of course makes look like its Haskel harder to read, since understanding a line of code requires effort, while its trivial in C. However that line of Haskel might contain the same information as a whole function in C and reading that whole function in C might turn out harder then comprehending that single line of Haskel.

All that said, I don't consider the syntax of Haskel very good, lack of parenthesis around function arguments certainly doesn't help readability and the error messages can be rather obscure as well.

Re:Mmmm, Kay.

[0xABADC0DA]

Haskell only evaluates what it has to -- this program for example which looks up the 3000th element of the sequence will not compute the complexCalculation on the 2999 fibbonaccis before hand like a traditional program would

And then when you actually do use the other values you program is ridiculously slow because the generator function is recalculating the fibonacci number over and over again.

Except you hope that Haskell automatically memoizes the results, but that destroys your smp performance as the CPUs contend over the result cache. So maybe you have separate caches per thread. Then you program grows larger and all the memoization takes too much memory and the system start dropping out results (3000th fib is what 520? bytes). Then you have to go back and tell it to keep the results longer for that function.

In the end maybe you just make it a list that's precomputed.

But that's really beside the point, because you can do the exact same thing in Smalltalk, Ruby, JavaScript, etc, with most of the same costs and benefits. So really the question is, what makes it better than Smalltalk? It's faster at maths, but that's about it. But it has a harder/alien paradigm, the syntax is foreign, etc. Maybe that's why afaik mainly Haskell is only being used by people that crunch numbers ?

Re:Mmmm, Kay.

[ozmanjusri]

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?

Re:Mmmm, Kay.

[Hurricane78]

No. It's not because of a huge lib. It's because code can be so much more generic than in other languages. And that's the biggest point/plus in Haskell. You don't have to write a new for loop for everything. Even the for loop is abstracted (map, fold, zipWith, ...). And this works with everything. I have yet to find something that's not generalizable in Haskell,

Your 4GL claim turns out to either be true for all languages with a compiler or
the Haskell compiler is just an abstraction you do *once* instead of reinventing it every time and using it in a crude and ugly way, like in C or similar languages,

Your real problem with Haskell is that it is more complex per written token, and so you have to think more per token. Most people seem to generate some inner fear for things they don't understand as good as they expect. And that's the base of all your motivation to find reasons why you dislike Haskell.
Of course you could simplify it, and get something like Python. But this is a bad idea on the long run, because then nature will only create bigger idiots. It's better to wise up a bit, because what you get then, is really really nice!

P.S.: I once tried to design the "perfect language". I stopped as soon as I learned Haskell, because it was not only extremely similar to what I had created myself, but even much better.

Re:Mmmm, Kay.

[thermian]

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'.

Re:Mmmm, Kay.

[DragonWriter]

Hascal, and other functional languages may be good for multi-core development. However not to many programmers program in them... Plus I find they do not scale well for larger application.

What particular problems have you identified in scaling functional (lazy or otherwise) programs to larger applications? Usually, I've seen that touted as a strength of functional languages, not a weakness.

Re:Mmmm, Kay.

[selfdiscipline]

you lucky bastard.

Re:Mmmm, Kay.

[Anonymous Coward]

The whole lazy sequence things is easy to do with any language with subtyping (preferably static), you just need an abstraction of iterable sequence.
Just make an seuqnece adaptor that applies a function whenever it gets dereferenced.

One could write
transform(fibonnaci_numbers, complexCalculation); to return a new iterable type, that will iterate and return transformed fibonnaci numbers as it is iterated.

And to parallelize it, I just have to traverse it with parallel_for.
But if the calculation is really something that needs to be optimized, it really ought to be made eager, I'd think, so you can really locate where it takes place.

Generating an infinite sequence just requires an adapter that will calculate the next element depending the the previous ones.
infinite2(make_sequence(1, 1), lambda(x, y)(x + y));
Could thus generate fibonnaci numbers, and that's arguably clearer IMO.

I personally find it better with infix notation, for example | as in shell programming. That's easy to do if you've got operator overloading.

Re:Mmmm, Kay.

[Anonymous Coward]

Infinite data structures are not that useful in practice. The most useful infinite structures are things like I/O streams, but these require handling with monads in Haskell.

Mapping a function over a list is trivial in almost any language I can think of.

The parallel call you make above is much subtler than you think, since it changes the semantics of Haskell in subtle ways. Think about -- lazyness is by definition sequential (there is only one redux to reduce, if you reduce another redux you may have done computation that isn't necessary for the computation).

Also space usage in Haskell programs is extremely hard to estimate. For me this is almost always a killer. I get all this nice lazyness at the cost of much higher space consumption.

Re:Mmmm, Kay.

[Mr2cents]

However, if it's difficult to read, [...]

IMO, code readability is more a question of discipline at the programmers end than it is of the language. You can write perfectly readable code in almost every language if you really want to. Good documentation, good naming and small functions (not 200 line monsters full with if/thens, each containing multiple conditions and'ed and or'ed together, e.g.) already takes you quite far.

Pose yourself the question "if someone reads this for the first time, what should he need to know?" and write it down in a comment. Also document your data structures, and how they are used (often forgotten).

Last but not least, good abstractions will make it possible to think on a higher level, will keep code small and easier to read too. Within the abstraction, you tacle a small problem so that's easy to follow, and outside the abstraction you don't waste attention on micro-management.

BTW, with good documentation I mean documentation that adds value, not something like "count++; // increment counter" (I can read that myself, thanks). Something like "count++; // found another target" is much more useful, as it tells you in 3 words what is happening at the application level.

Re:Mmmm, Kay.

[glassware]

A well designed class library will get the job done for you in any language. There's nothing you wrote there that couldn't be done in C# or Java or C++.

However, no, none of the languages I use have a keyword reserved for "(parMap rnf)" nor does it have a wacky double-exclamation mark that means something silly like "use only the Xth element". Frankly, I would prefer my language to use human readable words rather than chicken scratches. We're not trying to optimize the file size of your source code here. Bytes on disk are virtually free. What we are trying to optimize is the amount of programmer time to build, maintain, test, document, and understand these software programs.

Re:Mmmm, Kay.

[moreati]

Be it Compiler building [haskell.org], version control [darcs.net], writing interpretters for popular imperrative languages [perlfoundation.org], Writing 3D shooters [haskell.org], or a whole host of other tasks.

I'm sure there are other prgrams written in haskell, but >95% of programmers won't tackle those problems in the real world.

Alex

Re:Mmmm, Kay.

[PitaBred]

That'd actually be an interesting project... write an AI as a separate process for a game in Haskell... wonder how well that'd work out.

Re:Mmmm, Kay.

[Anonymous Coward]

"In C, you tell the computer to do things. In Haskell, you tell the computer the relationships between things, and it figures out what to do all on its own" ...

If you have ever written any serious functional programs you know this is simply false. As soon as you become interested in the performance and space usage of your program this kind of nonsense about "it figures it all out on it's own" becomes clearly bs.

It is the same with Prolog. When you are interested in performance you learn about cut and clause ordering.

Re:Mmmm, Kay.

[Anonymous Coward]

lulz@Frag

You should have mentioned xmonad, since it has greater than zero interest (though not as much interest so as to warrant the endless proggit spam Dons provides every time #haskell farts).

Re:Mmmm, Kay.

[DancesWithBlowTorch]

Functional programming languages are still new, and they do take some getting used to. However, once you have wrapped your head around them, you will not want to go back to imperative style coding.

There are jobs where having functional language experience is an asset. Most of them also require a PhD in CS, and in most of them the knowledge gained by designing the software is more valuable than the software itself.
automated trading algorithms, for example, or search. Pretty much every elaborate Machine Learning application can gain massively from functional implementations.
Scientific computing is just starting to realise the power of functional programming. It allows very rapid development (switching to F# from Matlab and C# has easily doubled my productivity), and is great for applications where design-time is often longer than use-time.

The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages.

There is also nothing that can be done in C that cannot be done in Assembler.

Re:Mmmm, Kay.

[cdfh]

fibs x y = x : (fibs y (x + y))

And also:
fibs = 0 : 1 : (zipWith (+) fibs $ tail fibs)
Which has the advantage of not needing to specify the leading terms in the list, although you could also claim that is a disadvantage (if you prefer fibs 1 1, for example).

Re:Mmmm, Kay.

[bberens]

Simple. In Java I'd use JPA to get the objects I want and use maybe XStream to convert the class to XML. I'm not going to take the time to look up the appropriate API calls at the moment, but I believe it's somewhere in the range of 2-3 lines of code to accomplish this feat.

Re:Mmmm, Kay.

[Anonymous Coward]

That is true of almost any language. The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages. Elegance cannot beat convenience in the workplace, or in most at any rate.

Haskell is extremely easy to read if you have any familiarity with modern mathematical notation. List comprehensions are set-builder notation, computerized. Guards are used analogously to "the big brace" in function definition notation. There are too many examples to list. This doesn't make it just elegant, but amazingly useful.

Mathematical reasoning about your programs isn't constrained by the disanalogies introduced by the object system or "convenient" quirks. (I'm not saying syntactic sugar is bad, mind you. It just has the potential to introduce complexity). This is why Haskell is seeing use in high security applications, written by the sorts of companies with DOD grants.

Functional languages in general will see more use as parallelization of code becomes more important. Potential parallelization is nearly automatic through the use of a few simple techniques (though tail-recursion kills). The relatively stateless nature can allow functions to automatically work in parallel, since their effects cannot influence other computations. They are somwhat similar to processes, as opposed to threads. They do not share state unless explicitly directed (IPC, in this analogy), whereas object/threading models potentially can.

It's also kind of fun to work with Haskell.

But realistically, designing an object system drawing on the strengths of functional programming is not difficult, and has been done, to varying degrees, many times. JavaScript is a fine example. Ruby and many other scripting languages implement functional programming constructs as method calls (perhaps with special syntax -- Ruby's .each is followed by a block, for example) Erlang's functions are literally services in a pool of services (the neat thing about that is that you can add new function instances to the pool at run time, as needed. Instant cloud computing, 10 years ago)

I don't much care what I work with as long as it is functional enough.

Re:Mmmm, Kay.

[IamTheRealMike]

Yes exactly. Real world performance is often where these sort of very academic languages fall down. The other big problem with lazyness (which is what gives you these infinite data structures) is that it can result in very unintuitive space complexity for common algorithms, because the calculations are suspended until needed. The result is enormous RAM blowup that unless you happen to be a quite advanced programmer is very difficult to predict or understand.

Re:Mmmm, Kay.

[Anonymous Coward]

And how does a "manager" i.e. PHB measure the productivity of a team of Haskell programmers?

Re:Mmmm, Kay.

[Nevyn]

Actually, when you're able to do it naturally in your language, it becomes a very useful thing to do. For example, when you want fresh variables in a compiler

How is that better than doing (or basically the same in Java/C/perl/ruby/etc.):

__compiler_var_num = 0
def next_fresh_variable():
global __compiler_var_num
__compiler_var_num += 1
return "_id_%d" % __compiler_var_num

Re:Mmmm, Kay.

[ClosedSource]

When the last argument given is "look it up", I suspect there's no counter-argument.

In what way is there an "infinite stream of ethernet frames ariving" on your computer with its finite lifetime?

If you have an explanation, why not give it?

Re:Mmmm, Kay.

[arevos]

I'm not going to take the time to look up the appropriate API calls at the moment, but I believe it's somewhere in the range of 2-3 lines of code to accomplish this feat.

If you're not going to take the time to actually produce any code to back up your point, why bother replying?

The biggest problem with talking about the advantages and disadvantages of programming languages is that people tend to make vague claims without producing any evidence for their case. Can JPA produce lazily produce a hierarchical tree of objects from a single database query? I don't know; it's not an answer you're likely to find in an FAQ or a tutorial. And how much work is it to actually set JPA and XStream up? Does it really only take 2-3 lines of code?

Without providing working code, who knows whether your assertion has any merit or not.

Re:Mmmm, Kay.

[Nevyn]

Sure they do. How many lines in the next web page?

And these are all terrible things to create infinite lists for, those aren't notational convenience ... you actually need to inspect them. To be fair firefox often do that well on this, as if you give it a 100MB xml file it'll happily try and use it without warning. But that doesn't mean "eat all the resources on the machine and die" is a best practise.

Re:Mmmm, Kay.

[jbolden]

I see below people missed the point you are making. You are correct but because mathematical concepts work so broadly and Haskell allows you to work so abstractly a very small collection of optimizations need to be done to get the compiler to work well. In terms of the code itself you just need to avoid certain well known pitfalls to get good performance.

Nothing beats C.

Re:Mmmm, Kay.

[adrianwn]

Functional programming languages are still new

Ever heard of "Lisp"? It is now 50 years old, which is ancient in programming language terms.

Re:Mmmm, Kay.

[Anonymous Coward]

Easily predictable space complexity.

Re:Mmmm, Kay.

[david.given]

If you have an explanation, why not give it?

Why should I? I spent time and effort composing a response to Dragonslicer's original query. Dragonslicer then responded by being an ass. Why should I waste any further time? I've got better things to do.

Re:Mmmm, Kay.

[ottothecow]

The first class in my college's intro sequence is done in scheme (taught by the fantastic Robby Findler). Coming in with some knowledge of "normal" procedural languages, the functional paradigm was sometimes frustrating to the point where a friend in the class with no prior coding experiance was initially able to figure out how to do things much faster (though the methods would be much more brute force than elegant functions someone familiar with efficiency in other languages might write).

I first started to appreciate it when we were shown how to generate a sierpinsky triangle. The triangle was the first program I ever wrote (copied out of the manual of a TI calculator) and in the version of basic, was an absolute mess compared to the simple recusive functional code. I've lost a lot of my memory on how to write programs in scheme but I'd like to find reason to write something in a functional language again...I took computer systems this spring with the same professor and a lot of his examples were done in scheme (as opposed to C)...quite interesting

Re:Mmmm, Kay.

[adrianwn]

Another example is taking advantage of the hardware. Right now because of eager evaluation it is very difficult to take full advantage of hardware. Use lazy evaluation and the system can allocate tasks based on hardware availability (like a mainframe does).

There is a huge difference between an interesting, promising idea and its actual feasibility in practice. Others had the same idea before, and when they implemented it, the results were disappointing; for example dataflow-processors ("use the resources of the system as efficiently as possible") or demand-based evaluation of dataflow-graphs ("only evaluate what is really needed"). Those concepts were very popular in the academic world of the 80s, but they never caught on.

Regarding AIs in games: the problem here does not lie in implementing good algorithms, but in thinking of them. Give me a description of an algorithm, and I will implement it for you in an imperative language.

Re:Mmmm, Kay.

[Dragonslicer]

I'm well aware (as well as I can be, at least, having been out of school for a few years now) of the benefits of all of the theoretical work with concepts like Turing machines. I'm certainly not saying that such concepts are useless or unimportant. Here on the outside of academia, though, we don't usually have wires with infinite bandwidth, disks capable of storing infinite frames of video, or users that can press infinite keys.

As for being an ass, I have to say that it's a bit deserved. Participating in a discussion that's arguably about computer science theory and grossly misusing the word "infinite" doesn't make you very credible.

Re:Mmmm, Kay.

[Anonymous Coward]

Have you tried it in C# with LINQ? It should map almost exactly to LINQ, just with different syntax.

dom

Re:Mmmm, Kay.

[snoyberg]

Well, in this case the "infinite stream" is really a stream of indefinite size. However, you can treat it as being infinite.

Re:Mmmm, Kay.

[Medievalist]

Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

Sure they do. On my computer, there's an infinite stream of ethernet frames arriving, an infinite stream of video frames leaving, an infinite stream of keyboard events arriving, etc.

I don't understand why you'd think of a stream as an infinite data structure. I'd think of it as a stream, optimally processed as a stream.

But I don't know Haskell, so perhaps I'm just confused by my own ignorance.

Re:Mmmm, Kay.

[Grishnakh]

If you don't believe me, look at the human race. Do you think that high intelligence or great beauty are driving evolution forward? Or is it "good enough" people who reproduce a lot?

I'd say it's the opposite: highly intelligent people usually don't reproduce much, if at all, whereas utterly stupid people reproduce at an astonishing rate. The solution? I have no idea. The obvious solutions (which usually have something to do with eugenics, forced sterilization, etc.) aren't really palatable, and since average people are in the majority anyway, they're not going to accept them in a democratic society. Of course, we could abandon democracy, but the alternatives are usually worse. When they do work, they usually only do so for a while (while the good leaders are still around), but eventually become corrupted and end up much worse than the democratic alternative.

Besides, it's been shown that a lot of a person's intelligence is based on nurture, not nature; raising kids in a good environment probably helps them a lot more than simply having good genes. Intelligent people, knowing their time is valuable and limited, don't usually have many children because they know there's not enough time for them to accomplish much and also raise 13 kids, whereas stupid people happily have 13 kids because they know the government will give them a big welfare check for it, and time isn't a problem since they can just ignore the kids and go drinking instead of putting any effort into raising them.

Re:Mmmm, Kay.

[pla]

Might that be because mainstream programming languages don't support infinite data structures?

Mainstream programming languages run on mainstream hardware - Which does not support infinite data structures natively. Thus, any code (C or Haskell, doesn't matter) must necessarily reduce to simple imperative/procedural code at (or before) runtime.

Re:Mmmm, Kay.

[david.given]

As for being an ass, I have to say that it's a bit deserved. Participating in a discussion that's arguably about computer science theory and grossly misusing the word "infinite" doesn't make you very credible.

And yet, a number of people, not just me, were using the term as if it meant something... which should have been your clue that your understanding was flawed.

Here's the clue: Haskell is a *lazy* language. This means it only evaluates things as it needs to. This allows it to operate on representations of infinite amounts of data, by only actually needing to do the operations on the data required right now. So, you can construct a list that contains all the members of the fibonacci sequence, and while summing all the members will take an infinite amount of time, summing a finite subset of the members will take a finite amount of time.

This applies to I/O: your program is a function which takes, as a parameter, a infinite list of keyboard events. It returns a list of characters (which may be infinite if your program never halts). Your entire program logic then becomes a mapping between input events and output events. Something like:

main i = map i (1 +)

(very dodgy syntax, this was all years ago) returns an infinite list which is a copy of the input infinite list with all the elements incremented by one. Press an A, and it'll print a B. Of course, you're probably going to ^C it before very long, but it doesn't escape the fact that the program is quite happily operating on lists that it considers to be infinitely long --- one element at a time.

(In fact, that's a huge simplification; the real thing is significantly more complex and uses things call monads for dealing with all this that are infamously nasty. I don't pretend to understand them.)

Re:Mmmm, Kay.

[makapuf]

Yup, lazy, functionnal, imperative, object : for each problem there is a better solution. However maybe there would be at then end a language where :

1) syntax could be made a little less strange so that people knowing C (like python by example and then adding its own concepts) could make simple things, simply
2) different paradigms should be coexisting peacefully - fast, simple inner loops in C, structured, object in ($dynamic language), algorithms needing such kind of concurrency or metaprogramming, possible also.

3) a pony

Re:Mmmm, Kay.

[Anonymous Coward]

I call BS. Perl 6 is not popular :)

Re:Mmmm, Kay.

[skulgnome]

Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

Might that be because mainstream programming languages don't support infinite data structures?

Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

Re:Mmmm, Kay.

[Anonymous Coward]

I remember HATING Haskell in college, cause I already knew OO languages, and it was so counter intuitive. I also figured out that one could make an OO language that could compile to haskell, so there was nothing innate about OO languages that haskell was lacking, including their problems. My teacher described it as a kung fu mind training tool, and he may have been right, but I don't think it will ever hit main stream use. Human minds are object oriented, at least mine is.

Re:Mmmm, Kay.

[Soul-Burn666]

Except usually the compiler/interpreter/whatever takes that into account and when there's a "time/space leak" (iirc that's the term they use), they collapse the laziness somewhat to reduce it.
Don't forget these people are usually quite smart and have thought of solutions to many of these problems :)

Re:Mmmm, Kay.

[jbolden]

You are thinking in terms of eager evaluation. You don't have to do that in a lazy language since it uses things as needed. You manipulate infinite lists containing large but finite data sets safely because everything ends up being buffered but without any code or effort on your part.

Re:Mmmm, Kay.

[Anonymous Coward]

I call FUD.

I call meme misuse.

I call Ghostbusters.

Re:Mmmm, Kay.

[91degrees]

Perhaps a better example would be stream processing. Replacing CR+LF with LF is about the simplest useful application I've ever written, but does actually use a common required technique. Perhaps that would be a better test.

Re:Mmmm, Kay.

[jbolden]

Haskell is a programming language. It makes it easy to work through algorithms that are complicated by giving you tools that are very powerful. So I think it does make it easier to think of algorithms because in practice you put them together piece meal.

Take an example of 8 queens problem. You say well I want solve the n-1 queens problem and then add queens:

queens number_of_queens = qu number_of_queens where
        qu 0 = [[]]
        qu (m+1) = [ p++[n] | p

Simple. I don't have to work through how to detect conflicts yet.

Then I work out the conflicts code:
safe p n = all not [ check (i,j) (m,n) | (i,j) - zip [1..] p ]
                                        where m = 1 + length p

check (i,j) (m,n) = j==n || (i+j==m+n) || (i-j==m-n)

and that's it. Much easier than in an imperative language.

safe p n = all not [ check (i,j) (m,n) | (i,j) - zip [1..] p ]
                                        where m = 1 + length p

check (i,j) (m,n) = j==n || (i+j==m+n) || (i-j==m-n)

As for your point about demand evaluation (lazy evaluation) is one of the key concepts in Haskell. If you don't agree with the advantages of lazy over eager .... I can say from experience I love it and use it all the time. What do you think didn't work about it?

Re:Mmmm, Kay.

[Tetsujin]

Yup, lazy, functionnal, imperative, object : for each problem there is a better solution. However maybe there would be at then end a language where :

1) syntax could be made a little less strange so that people knowing C (like python by example and then adding its own concepts) could make simple things, simply
2) different paradigms should be coexisting peacefully - fast, simple inner loops in C, structured, object in ($dynamic language), algorithms needing such kind of concurrency or metaprogramming, possible also.

3) a pony

Can't help you with #3. I've been thinking about solutions to #2 (Integration between languages is still a real weak point... I hope this will change over time - part of that will be increased cooperation between the tools themselves. Seems like Microsoft has taken a decent stab at this with .NET...)

I don't really agree with #1. I don't believe any language yet (especially not C++) has "the perfect syntax", so when it comes to defining new languages I don't believe emulation (of syntax) is necessarily the right approach. The damage done to the language as a result (syntax not matched to concepts, possible syntax innovation stifled) outweighs the benefits of familiarity. Anyway syntax has to serve the design of the language, not the other way around. Designing a language you choose priorities - what should be convenient, what should be conceptually emphasized, and try to optimize the syntax for that - and the rest winds up an inevitable compromise.

Personally I think Haskell syntax is great. I love the foundation in format math notation, and I think the syntax fits the language. The support for extensible infix is great, and I like how this scales down to the colon operator, which is like the fundamental infix operator version of "cons"... Haskell notions of constructors (particularly them being things that can be applied or pattern-matched and stripped from data) and pattern-matching function arguments in general are a bit alien to C++ anyway, even if you wanted to try to fit Haskell into a C++-ish syntax.

Re:Mmmm, Kay.

[HiThere]

OK, but either they don't have any reasonable way to do I/O, or they don't have any decent documentation of it.

For that matter, most basic algorithms aren't findable in any of the functional languages, much less the ones that are both functional and lazy.

If I were to pick ONE of that set that was reasonable, I'd pick Erlang, which can definitely handle the parallelism. But Erlang is **S*L*O*W**. It's great for certain things, but in general....

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.) 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.)

So, not considering style, but merely easy capabilities, I don't think functional languages are likely to find much use from me.

OTOH, Ruby, Python, D, and probably lots of other more traditional languages have many of the capabilities of functional languages...if you can ever convince anyone to use them. LISP started off as a purely functional language...but it sure knew better than to remain one. Etc.

THAT said, some sort of handle on multiprocessor solutions is truly needed. I just don't think that functional languages are where the answer lies. Dataflow seems more reasonable, but I don't know of a decent dataflow language in existence. Prograf for the Mac used to be such a language, though it had many problems (such as not being able to create a text representation of a program). Unfortunately it died during the transition from the Mac to MSWind95. (As did a very interesting dialect of Forth...Kyria, as I remember. It was object oriented Forth was quite different from vanilla Forth. Enough different to actually be a decent language. And it DID have lazy evaluation. And, as Forth, it was "sort of" functional, but without divorcing itself from screen or disk interactions. But neither of these was designed with the concept of multi-processors in mind, so perhaps they couldn't have made a successful transition even had they survived.

Also, I have the suspicion that these functional lazy languages emit parallelism at the wrong level. If you create too much interprocess communication, then you dissipate most of your increased efficiency in interprocess communication. Of course the trade-off differs as machine architecture changes...but ...

Re:Mmmm, Kay.

[grumbel]

we don't usually have wires with infinite bandwidth, disks capable of storing infinite frames of video, or users that can press infinite keys.

You completly missed the point. An infinite data structure in a lazy language isn't something that you write down to disk or something you store in memory, its a concept with which you structure your code. For example instead of having a while-loop to poll an event from an event queue like you would do in C, you could have an infinite list of all the events that you system would ever create, but it isn't a list/array in the C sense, its much more like a generator in Python in that the elements are only generated once requested, except that you can handle it like any other list in Haskel. Having a recursive function that walks over an infinite list in a lazy language really isn't much different then having an endless loop in C.

Re:Mmmm, Kay.

[Bill, Shooter of Bul]

Your mind works the way it was trained to. People still argue that OO languages are a failed experiment, because they are "too complex" for ordinary minds to grasp. Its sort of like doing algebra for the first time and manipulating unknown variables in an equation. Sort of crazy unless you've done it before. Or calculus with its limits and infinitesimals. Or zero, which was a concept too difficult for the Romans to grasp.

Re:Mmmm, Kay.

[Nevyn]

No, I'm thinking in terms of the real world. Yes, you can probably think of data coming from the network as "an infiite list of bytes" ... but that is a terrible model with which to represent that data. Yes, it might make your life easier ... just as doing open(filename).readlines() is "easy" in python, but they don't not treat the machine resources as what they are (limited).

As a concrete example, think of a HTTP "message". Now you could represent this as an infinite list of bytes, that get transformed into an infinite list of lines (ignoring uploaded data for now) ... however you still need to handle someone connecting and sending a continuous stream of NIL bytes.

Re:Mmmm, Kay.

[DragonWriter]

The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages.

Well, part of the reason for that is that the "current crop of popular languages" are mostly multiparadigm languages with substantial influence from functional languages as well as OO and procedural languages, and whenever something that functional (or any other paradigm) languages do better becomes important in the marketplace, more and more features get moved over into popular languages, or newer languages become more popular.

Re:Mmmm, Kay.

[daemonburrito]

Functor (in CS): A functional object or function symbol.

Generators are being bolted onto Java, as well, IIRC.

Functors and generators in the languages you mention are emulations of native constructs in the languages we are talking about here (the lazy functional languages). The mainstream languages wouldn't have these emulations if the languages we're talking about (and smalltalk, I guess) didn't introduce them.

One strength of mainstream languages is that they are mainstream, I suppose. I see your point about wet-behind-the-ears programmers wading into Haskell. But it doesn't follow that things have to be this way (I wish schools still taught some lisp in intro CS). And it doesn't mean that functional languages aren't very very cool, or that C++ and Python (with today's idioms) will be with us forever.

Re:Mmmm, Kay.

[osgeek]

paraphrase comment #1: Haskell is too academic to be useful.

paraphrase comment #2: No it isn't, here's how to do something with a fibbonacci sequence.

Uh, you failed at "fibbonacci" to make your point. :)

Re:Mmmm, Kay.

[mdmkolbe]

Except you hope that Haskell automatically memoizes the results

Please don't take this the wrong way, but please stop spreading your misinformation. One doesn't hope Haskell memoizes because it doesn't memoize functions. One requires that Haskell implement call-by-need. Overlapping but very different concepts. I'll assume it was an honest mistake but the difference makes the rest of your post nonsense.

Haskell is only being used by people that crunch numbers

Another point of dissagrement. If anything number crunchers (e.g. scientific computing in which I've done a fair bit of work) avoid Haskell (along with anything that is not Fortran, Matlab or C). Haskell finds favor more among "programing language" types who are interesting in writing their own language (Haskell is a phenominal language to wrong another language in) or in "elegant" ways to write compact solutions to traditionally verbose problems (e.g. merge sort in two "statements").

Re:Mmmm, Kay.

[Anonymous Coward]

Ah ah, very funny.
I didn't get it.

Re:Mmmm, Kay.

[speedtux]

You can build all these things in Haskell. You can also build all these things in Perl, Fortran, or Brainf*ck. What are you trying to say?

Re:Mmmm, Kay.

[extrasolar]

In what way is there an "infinite stream of ethernet frames ariving" on your computer with its finite lifetime?

I think the point is that an infinite data structure is a good structure for dealing with indefinite data. There's no definite last ethernet frame, so an infinite data structure is a good way of expressing that.

Re:Mmmm, Kay.

[extrasolar]

Shh. The meme is mutating.

Re:Mmmm, Kay.

[speedtux]

It's only difficult to read if you don't know it.

In my experience, Haskell syntax is much more prone to typos that don't get caught by the compiler or, at best, get reported as bizarre type errors.

So, you claim Haskell syntax is just like anything else, I claim it's worse. Do you have any studies on Haskell syntax to convince me otherwise?

Re:Mmmm, Kay.

[KDR_11k]

There's nothing you wrote there that couldn't be done in C# or Java or C++.

Well duh, Church-Turing Thesis.

Re:Mmmm, Kay.

[The End Of Days]

No, it must all be stupid because I don't understand it. Stop defending Haskell and accept that C is the one true way to write anything.

Re:Mmmm, Kay.

[Anonymous Coward]

Might that be because mainstream programming languages don't support infinite data structures?

Might that be because infinite data structures aren't very practical?

If it doesn't have a formula that can separately calculate each element, it gets typed into a look up table once.

Re:Mmmm, Kay.

[FLAGGR]

This is the idea: let x=the list of all incoming messages. Let f be a function that takes a message and the last result, and produces a result, that is some actions and a state. Now, the code for a client is foldr1 f x. Of course, the fun is in programming the function f, but that is why an infinite lazy list is awesome. You don't have to manually make the code for waiting for the next message etc, all that boring stuff no useful person wants to write anyway.

This example is extremely simplified of course, but it's the general idea. I have an IRC bot that operates basically on that principle. It is an infinite loop of taking the next message and using it. Since it is lazy, it doesn't keep looping super fast, it only evaluates the next message as soon as it exists (i.e. when the bot gets a message from the server)

Re:Mmmm, Kay.

[daveime]

And how would Haskel determine the length of that stream, without first processing the entire thing to determine how "indefinate" it is ?

Infinite = known to have no end, ever.
Indefinate = end is not known at this time.

There's a huge bloody difference, especially if you have to code a decision whether to store that stream on your /tmp drive based on it's size. By definition Haskel would store the entire thing until it runs out of drive space, and then presumably crash with some sort of "application error" ???

Re:Mmmm, Kay.

[xorbe]

Except nobody can read that. The line noise up there with perl!

Re:Mmmm, Kay.

[j1m 5n0w]

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".

Re:Mmmm, Kay.

[Anonymous Coward]

Yes, and that's why real programmers program in assembly only. *rolls eyes*

Re:Mmmm, Kay.

[snoyberg]

Well, in a case when you need to know the length, you have to use strict evaluation (sort of- I'm simplifying), in which case Haskell is reducing to what "normal languages" do. In the case where you do not need the length, you get the benefits of laziness.

Re:Mmmm, Kay.

[arevos]

Have you tried it in C# with LINQ? It should map almost exactly to LINQ, just with different syntax.

Yes, you're probably right. LINQ is a specialised form of monad comprehension, and I suspect that some of the Haskell programmers that Microsoft employs might have contributed to the initial idea. For a 'popular' language like C#, LINQ is a pretty advanced feature to have. I guess Microsoft was able to get away with it by dressing it up in SQL-like syntax.

That said, I'd be interested in seeing someone actually produce the code. I suspect LINQ would allow for a pretty concise implementation, but there may be gotchas in the Haskell code that LINQ wouldn't be able to deal with.

Re:Mmmm, Kay.

[arevos]

Except nobody can read that. The line noise up there with perl!

Nonsense. You need to be familiar with Haskell's syntax, but once you are, it's as clear as it can be for what it does.

Reading the Haskell in evaluation order:

filter (/= [])

Filters out blank lists.

groupBy ((==) `on` head)

Groups rows whose first column is identical.

toBranch = Node . (head . head) <*> (listToForest . map tail)

This uses a function from Control.Applicative, but once you know that:

(f . g <*> h) x = f (g x) (h x)

It's not so scary. It takes the first cell from the first column of the group (head . head) to use as the value of the branch node, and then passes all the remaining columns (map tail) back into the listToForest function, and uses this as the subtree.

Not trivial, but pretty clear when you think about it.

Re:Mmmm, Kay.

[beelsebob]

Not true. A quick look at the Debian lanugage shootout will reveal that Haskell's performance is only barely slower than C's, and that's even with a ban on setting up the garbage collector to work well with the program that's being run, and an out of data compiler that isn't as efficient as the most recent.

Re:Mmmm, Kay.

[beelsebob]

Frankly, I would like my language to allow me to define whatever operators I like to mean whatever I like. The double exclamation mark is only so, because that's what someone named the function. They could equally well have named it "listIndex" or "yourAuntJane" or "^>.*.*>*.^.". This is of course not to say that I'd suggest any of these names.

Re:Mmmm, Kay.

[TuringTest]

Actually, the gurus at Microsoft Research are doing a really good work in 1) and 2) with F#. Its syntax is C-like, and it has monads wrapped up in "computation expressions", edible by imperative programmers! And it runs on the .Net platform, so it interacts nicely with the CLR engine and .Net libraries.

For 3), though, I suppose you'll have to ask Bill himself. ;-)

Re:Mmmm, Kay.

[TuringTest]

Actually, imperative code is executed by a IO monad at the CPU level. So it's functional lambda-calculus all way down.

Re:Mmmm, Kay.

[TuringTest]

Might that be because infinite data structures aren't very practical?

So, you've never used an event queue?

Re:Mmmm, Kay.

[glassware]

Sure it sounds nice to be able to say "define whatever operators I like!". But in practical use, in the real world, maintaining a program is much more important than being able to name some rarely used operator an indecipherable set of words. This is partly why day to day business is done in Java and .NET; because the language provides clear, legible names for everything. It takes longer to type ".ToString()", but it is readable and predictable.

I would have a much easier time trying out wacky new languages if they would stop trying to compress their keywords down to the smallest number of keystrokes and instead concentrated on making the code more readable. Perl and Haskell exist because people think playing with syntax is fun, when it isn't.

Re:Mmmm, Kay.

[beelsebob]

Interestingly, lack of parenthesis is the one feature that makes Haskell much easier to read than for example LISP (lots of irritating superfluous parenthesis). I'd argue strongly that your wish to have arguments parenthesized is purely bread from the fact that you're used to seeing them that way, and not to do with that actually being clearer.

Here's why no parenthesis works better in Haskell: Function application can be partial. Suppose we have a binary function: (<) is a good example. In haskell, this is not a binary function, but instead a unary function that returns a function as it's result. Thus (< 5) is the function which checks if things are less than 5. Similarly (+ 10) is the function that adds things to 10, and (elem 5) is the function that checks if 5 is an element of the list you pass it. We may then apply these functions to their single argument, thus making ((elem 5) [1,2,3,4,5]) the function that checks if 5 is in the list [1,2,3,4,5]. Finally, function application is left associative, so we can clean up this syntax to elem 5 [1,2,3,4,5].

I expect you're wondering why this is useful. Well, the answer is that it's extremely powerful when considering higher order functions. We may find all the elements of a list greater than 5:
filter (>5) [2,4,6,8,10]
We may add 10 to all elements in a list:
map (+10) [1,2,3,4,5]
we may even find out which elements in a dictionary have a value greater than 5:
filter ((>5) `on` snd) [(1,20), (2,3), (3,29)]

Re:Mmmm, Kay.

[TuringTest]

Space complexity should be predicted in functional languages the same as it's done in C++ : by using data structures that you'll know how will use memory under different conditions. If you use collections from the STL to create complex algorithms, you'll also have to learn how to avoid calling the copy constructor if you want predictable space.

Re:Mmmm, Kay.

[beelsebob]

This is partly why day to day business is done in Java and .NET; because the language provides clear, legible names for everything. It takes longer to type ".ToString()", but it is readable and predictable.
The language doesn't provide these things though. The library does. The most the language can hope to do is allow the library designers a decent amount of freedom in naming these things in the hope that they might chose a sensible name.

In haskell, my position as a programmer though is somewhat better, in that if I decide that I don't like "!! 5" as a syntax for indexing things (or "[5]" as the case may be), I can redefine it. Simply adding elementAtIndex = (!!) to my code somewhere allows me to now use myList `elementAtIndex` 5 to index into the list.

Re:Mmmm, Kay.

[HiThere]

OK. OpenGL wasn't included in my "good GUI packages", because when I've looked at it it looked too heavy and clumsy for what I wanted to do. And nothing that's "Windows only" is going to meet my needs.

I did look at using the POSIX package for Haskell, but that looked quite clumsy. (Well, I'm clearly not a Haskell programmer, so I could be wrong about that.)

I just now went to the Haskell code site mentioned elsewhere in this thread looking for I/O methods and found Couch. When I looked it up, it turns out it's a version 0.8 and has a known memory leak. There didn't seem to be anything else relevant. (Yeah, I know, POSIX exists, but it wasn't mentioned at that site.) I haven't looked at OCAML seriously in a couple of years, but I don't recall any graphics package catching my notice.

I'll grant that I'm not giving Haskell the kind of fair shake that I'd give to, say, Ada, but Haskell looks stranger, has less documentation, and is more difficult to translate the standard algorithms into. So it needs to offer something that's clearly superior enough to compensate for the deficiencies. I just couldn't find anything that looked even close to that. (Alice from Stanford came much closer, as did Mozart...but they weren't good enough either...though I can't remember in detail why I decided that. [Stanford's Alice compiles to ML, so it could be an efficiency thing.])

OK. Now I've looked at "Real World Haskell". It seems to answer many of my questions, the ones that were sufficient to cause me to stop looking back when I was choosing what language to study next. I've still got concerns about how one would deal with large programs, persistence, etc., but those were secondary, and I never got as far as checking them out the last time I looked at Haskell. I still don't see a place to find translations of the various standard algorithms, and that's a pretty big hurdle. I did notice that Gtk access is provided...at least via Glade, so most things of that nature that need to be done should be doable.

If you want to get programmers to use Haskell, you should make sure that they are exposed to that book. (I've only glanced through it, of course, but it does deal with many of the concerns that other sources of information left unanswered.)

Re:Mmmm, Kay.

[Anonymous Coward]

Please don't take this the wrong way, but please stop spreading your misinformation. One doesn't hope Haskell memoizes because it doesn't memoize functions. One requires that Haskell implement call-by-need.

``Call-by-need is a memoized version of call-by-name where, if the function argument is evaluated, that value is stored for subsequent uses.''

In other words, the function is 'called' when used not when passed, and the result is cached. Which is pretty much what I said, no?

Re:Mmmm, Kay.

[jbolden]

The way this would work is that there is a that there would be an array of input. Once a function needed more input then was available the input would "compute" additional information which would be reading a buffer and/or waiting for input. The same way you would in an imperative language. The difference is that all the messy loops happen automagically since in terms of every other function the input has already happened. There is no waiting except in the one I/O routine.

Re:Mmmm, Kay.

[Samah]

"per se", not "per say".

Re:Mmmm, Kay.

[Anonymous Coward]

listToForest :: Eq a => [[a]] -> Forest a
listToForest = map toBranch . groupBy ((==) `on` head) . filter (/= [])

              where toBranch = Node . (head . head) <*> (listToForest . map tail)

Can you translate that code in English? I think it can be translated to Python too.

Re:Mmmm, Kay.

[cdfh]

I believe you mean:

Prelude Data.Function> filter ((>5) . snd) [(1,20), (2,3), (3,29)]
[(1,20),(3,29)]

Rather than:

Prelude Data.Function> filter ((>5) `on` snd) [(1,20), (2,3), (3,29)]
:1:8: Couldn't match expected type `b -> c' against inferred type `Bool' ... (snipped)

Re:Mmmm, Kay.

[arevos]

1. Start with a grid of data
2. Filter out empty rows
3. Group rows together that have identical values for the first column.
4. Make a tree branch from each route, using the value of the first column as the head of the branch, and use recursion to find the child branches from the remaining columns (i.e. every column but the first) of the grid.

So:

A B D
A B E
A C F
A C G

Becomes:

......A
..../...\
...B.....C
../.\.../.\
.D...E.F...G

Re:Mmmm, Kay.

[simplerThanPossible]

Infinite data structures have been available for a long time in Haskell - what practical applications has they been used for?

There's a long history of pure mathematics being considered useless... until a use is found. Has it happened yet?

Re:Mmmm, Kay.

[mdmkolbe]

Yes and no.

Yes in the sense that in Haskell "let x = foo 3" will not evaluate "foo 3" until the actual value of "x" is needed and any further reads of "x" will use the "cached" value. (In the lingo "x" contains the thunk "foo 3" that is forced the first time the value of "x" is needed. Further forcing of "x" just looks up the value stored in "x" and doesn't execute anything.)

No in the sense that with Haskell further calls to "foo 3" will not use the value from previous calls to "foo 3". (Which is what the GGP was implying.) This usually included under the broad term memoization, but not call-by-need.

The reason this is important is that with full function memoization you have to make a trade off of how many argument values (which might themselves be large data structures) to store for each function. This leads to the issue you mention, but as I said, Haskell doesn't do that. On the other hand, with call-by-need, the values to store are very well defined (there is no "cache" only forced and unforced thunks) and standard garbage collection techniques apply (*).

(*) There are ways to get space leaks in a call-by-need language, but those are not what the GGP was describing. (For example, "(let a = (let x = 3 in if x > 3 then z else 4) in ...". As long as "a" doesn't get forced, the thunk for "a" will keep "z" alive even though "z" could never actually be needed. This is a problem but has nothing to do with the SMP or caches the GGP mentions.)

Re:Mmmm, Kay.

[grumbel]

Looks nice on a simple example, the problem is that it can quickly get quite complicated, for example take this:

func1 x y = x * y
func2 fn x = fn x
> func2 func1 2 5
10

It is completly non obvious what the code will actually do, since it could be func2(func1(2,5)) func2(func, 2, 5), func2(func1(2), 5), func2(func1)(2,5) or whatever, with mandatory parenthesis you would never have such a problem. This might not be much an issue when one is very experienced with the language, but then that is kind of the point, languages like Python are popular because you can understand them even without having a very deep knowledge of the language internals, Haskel on the other side can easily confuse even an experienced (non-Haskel) programmer.

Re:Mmmm, Kay.

[Peaker]

Funny you should mention .readlines(), because if you use .xreadlines(), or the newer __iter__(), then you can just as easily treat the file as a potentially infinite list of lines, without worrying about resources, and yet get limited resources used:

for line in file:

This uses lazy-lists, or generators/iterators as they are called in Python. Python supports lazy lists, but Haskell supports lazy data structures in general (such as lazy trees, lazy tuples, etc).

Re:Mmmm, Kay.

[Peaker]

How exactly can you write the code to "do lazy evaluation" in these languages?

Lets look at a practical example (taken from the old and famous Why Functional Programming Matters article).

Lets say you're implementing the alphabeta algorithm. In a lazy language, you can say something like:

solution = alphabeta . cutTree 5 . fmap gameValue . generateGameTree initialState

Where "cutTree 5" will cut the tree's branches to depth 5. In Python, or various other languages, you'd end up passing some "depth" variable to the recursion itself (in this case, generateGameTree), which would have to be decreased at each call. In a lazy language, the solution remains modular. You can re-use existing components like "cutTree" without having to write them yourself!

Modularity is the basis of programmer productivity, and laziness allows exciting new ways to actually achieve modularity.

Re:Mmmm, Kay.

[Peaker]

Python generators are extremely popular. They are basically "lazy lists" or "infinite streams" for Python.

If you look for uses of generators in Python, you'll find them quite popular, and thus, probably pretty useful.

Re:Mmmm, Kay.

[acheron12]

Since almost all Haskell functions are curried, wouldn't requiring parentheses around function arguments lead to code like this?

fn(arg1)(arg2)(arg3)

Re:Mmmm, Kay.

[Pseudonym]

I have yet to find something that's not generalizable in Haskell,

I have. Data structures which are both pure/persistent and state-monad-based can't be expressed with the same interface cleanly. For example, you can't use the same interface for both Array and STArray.

Not that this is a show-stopper; you tend to use arrays far less in most languages (even C++) than you do in C.

Re:Mmmm, Kay.

[Pseudonym]

Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?

Sure they do. They're just usually called "file descriptors", "iterators", "streams", "FIFO buffers" or something like that.

Re:Mmmm, Kay.

[Pseudonym]

Let me put it this way. If someone was to look at your code and say "your algorithm doesn't terminate", ask yourself if it would be a correct reply to say "But all programs terminate!" "Unbounded" is an entirely correct sense of the word "infinite".

Re:Mmmm, Kay.

[Pseudonym]

There are several correct meanings of the word "infite". The one being used here is "unbounded".

Re:Mmmm, Kay.

[piojo]

Haskell only evaluates what it has to -- this program for example which looks up the 3000th element of the sequence will not compute the complexCalculation on the 2999 fibbonaccis before hand like a traditional program would:
(parMap rnf) complexCalculation (fibs 1 1) !! 3000

Actually, I think you're confusing two concepts. parMap is strict--it does not return until it evaluates the entire list. So in fact, even the following simple line of code will never return:

(parMap rnf id [0..]) !! 1

If you think about it, it makes sense--if you aren't going to need all the values, why bother parallelizing their calculation? Why not just not calculate them? There is a lazier alternative--parBuffer works like parMap (and will still evaluate the list from start to finish), but will evaluate n elements at a time, so the following doesn't run forever:

(parBuffer 8 rnf id [0..]) !! 1

This will map the function "id" (or any function you choose) over a list, evaluating 8 elements at a time (and it will only evaluate as far as it needs to). But if you really don't need to evaluate all the elements, it's much more efficient (and lazy) to just use "map" instead of "parBuffer ".

Re:Mmmm, Kay.

[piojo]

Sorry, I got the syntax wrong. The working line of code is syntactically a little strange:
(parBuffer 4 rwhnf $ map id [0..]) !! 1

Re:Mmmm, Kay.

[johanatan]

Why should we dumb code down? If I'm writing my own code at home, then I take pride and enjoyment in writing stuff that only hackers can read.

And, if I am running my own business, I do not want to hire or work with 'still wet-behind-the-ears' programmers.

Granted, in the existing business world where mediocrity reigns, it would be hard to justify using such esoteric languages. But, why should we cater to the lowest common denominator because it is entrenched? Great minds think alike--if you really want to be doing Haskell (or other functional langs), I'm sure you can find some like-minded people to start a business with (and you'll blow away the competition because your code will be 10x shorter and take 1/3 the time to write).

Re:Mmmm, Kay.

[johanatan]

You're missing the points. Comment #1 was:

There just isn't anything I could do with either that I wouldn't be able to do more easily with another more 'mainstream' language.

He said nothing about academic--the statement was quite general ('there isn't anything...'). And, the poster is simply flat-out wrong. Everything that you can do easily in Python or Ruby (like list processing, map/reduce, lambdas, etc.) can be done *more* easily in Haskell. And, then there's the other more esoteric/academic stuff that poster #2 cited--lazy evalution, infinite lists, etc. But, Haskell is also much faster than the scripting languages. All the productivity of the scripting languages and speed rivaling C++. How could you not like that?

And if you think that list processing and lambdas are academic, go talk to some scripters (Python, Ruby, Perl).

Re:Mmmm, Kay.

[Workaphobia]

I don't have mod points, but I award you a theoretical (+1, Awesome incarnation of tired old gag), and (+1, Said gag actually relevant to topic of discussion). Unfortunately I undid both mods by replying to your post.

Re:Mmmm, Kay.

[Workaphobia]

You're getting side-tracked by the word infinite and missing the underlying point of stream programming and recursive definitions. Replace the word "infinite" with "unbounded" if it satisfies you.

Re:Mmmm, Kay.

[johanatan]

Also, the code you provided has much higher specified complexity than a couple of Java API calls. Anyone could wrap some logic in a function and call it from any other language, but what matters is the actual logic inside (which would be completed encapsulated in the Java version).

[This is essentially the same problem as SLOC count comparisons between languages]. There's no question Java is way more verbose, and I suppose even the most complicated program could be expressed in two lines if we allow arbitrary library usage:

#import UberLib

class Main{
public static void main(){ UberLib.doSomethingFabulouslyComplex(); } }

Re:Mmmm, Kay.

[johanatan]

The specified complexity of the Haskell code is much higher than that of the Java suggestion. Anyone could wrap some logic in a function and call it from any other language, but what matters is the actual logic inside (which would be completed encapsulated in the Java version).

[This is essentially the same problem as SLOC count comparisons between languages]. There's no question Java is way more verbose, and I suppose even the most complicated program could be expressed in two lines if we allow arbitrary library usage:

#import UberLib

class Main{
public static void main(){ UberLib.doSomethingFabulouslyComplex(); } }

Re:Mmmm, Kay.

[johanatan]

Mod parent up!

Re:Mmmm, Kay.

[johanatan]

Well said (on all points)!!

Re:Mmmm, Kay.

[Hurricane78]

He does go out of business. Thereby making the world a better place. :D

Re:Mmmm, Kay.

[Hurricane78]

Hmm... lol. You seem to be right. But you really make me think. There must be a way... There must... ;))

Re:Mmmm, Kay.

[Hurricane78]

How about pushing every non-monad trough a "monadizer" and then generalizing on handling monads only? ;)

But you are right. It's realistic, that you can't handle something unpredictable and timing-dependent in the same way than the completely deterministic rest of the program. If you assume non-deterministic behavior, of course you can generalize it.

Aahh... I love Haskell... :D

Re:Mmmm, Kay.

[Anonymous Coward]

oh hi, i'm joe user/programmer!

i was wondering, will haskell give me a faster or more maintainable h.264 video encoder or decoder? oh, no one's been able to write one? oh, that sucks.

are there any web browsers written in haskell? no? oh darn.

surely, an email reader? word processor? image browser? nintendo emulator? irc client? vector art program? compressor/archiver? mp3 encoder?

huh. sounds pretty useful so far, i wonder why it hasn't caught on for scratching itches. ohhh that's right, it takes far more time and effort to write the 'trivial' programs that most people actually USE or NEED, and when actually done, are slower than C. awesome. keep me posted.

Re:Mmmm, Kay.

[j1m 5n0w]

I've still got concerns about how one would deal with large programs, persistence, etc., but those were secondary, and I never got as far as checking them out the last time I looked at Haskell.

I don't know about very large programs, but I've written a ~3500 line ray tracer and the code hasn't become unwieldy. It's broken up into a lot of small modules. The compiler is definitely very slow; that might be an issue if you had a project that was tens or hundreds of thousands of lines.

There's an easy way to do persistence. Whenever you create a new data type, just add "deriving Show" to the end of the definition, and then you can convert it to a string with the "show" function. There's a corresponding "reads" function that turns a string back into the object. (I'm not sure if you have to do a "deriving Reads" as well or what; in my ray tracer, I manually overrode the standard read routines so I could parse a particular common graphics format instead.) Once the object is in string form, you can dump it to disk and retrieve it later. (A binary format may be more space efficient, but I'm less familiar with manipulating binary files in haskell.)

If you want to get programmers to use Haskell, you should make sure that they are exposed to that book.

It actually hasn't been published yet; it's scheduled to come out in November. It's being published by O'reilly, which is (in my mind, at least) a big deal since O'reilly traditionally doesn't do books about functional programming languages. I hope the language will be taken more seriously as a result.

Re:Mmmm, Kay.

[Pseudonym]

Well, there's the Identity monad, if that's what you meant.

Re:Mmmm, Kay.

[JonSimons]

All that said, I don't consider the syntax of Haskel very good, lack of parenthesis around function arguments certainly doesn't help readability and the error messages can be rather obscure as well.

Syntax is absolutely irrelevant.

As for parentheses and function application, there is a reason for that. Read about Currying.

Re:Mmmm, Kay.

[Anonymous Coward]

We, the doers of awesome, must come up with real world solutions to real world problems

You, the doers of awesome, have chosen an imperative programming language. That's why I prefer xmonad to solve a real world problem.

Re:Mmmm, Kay.

[Anonymous Coward]

It's kind of sad that people can go through college without learning that training can change the way you think and that easiness depends on what kind of understanding you already possess.

Re:Mmmm, Kay.

[GargamelSpaceman]

I think the lazy/eager divide is not so important. You can make a lazy language perform an eager calculation or an eager language compute something lazily. It's merely a question of what is the default behavior.

If I had to bet on a weird new language taking the world by storm it would have to be OZ.

Re:Mmmm, Kay.

[Anonymous Coward]

It's infinite from the perspective of a computer program. Just like there's an infinite number of clock cycles coming in, or whatever. It may not be from the perspective of an outside observer, but from the perspective of a program infinite streams of things is very convenient.

Also, infinite things are useful for producing more generic APIs. E.g. if you write a library for producing these Fibonacci numbers, it's much nicer to only export a single value, "fibs", than to have to produce lots of different functions (fibsLessThan, fibAt, fibsGreaterThan, etc. etc.). Laziness means you write a generic version of the algorithm once, rather than having to write one version for every usage case you can think of. If you need fibonacci numbers less than n, the client just does "takeWhile (n) fibs" and laziness ensures only what needs to be computed is.

Laziness enables a very powerful way of modularizing code. You can separate the bit that generates data, from the bit that selects what specific parts of the data you need. In strict languages you usually resort to trying to predict up front what kind of data you may need, and then re-implement the same algorithm multiple times with various different "selections" built-in (e.g. "stop after n numbers").

Re:Mmmm, Kay.

[Yenshee]

It's quite appropriate to view a stream of ethernet frames as infinite, in the sense of being of indeterminate size (infinite = without end). If you don't have infinite data-structures (which really just means that the language is taking care of all the bounds checking for you), your code will be cluttered with all kinds of termination checks.

When you have a process that produces a boundless amount of information (and the IO examples given are such processes), and you don't know how much of it you might need to consume, an infinite data structure might be an appropriate abstraction. It's a little pedantic to point out that in reality, any actual stream will be finite in length, and it completely misses the point. The point is that Haskell makes it possible to model these indeterminately long streams with compact and logical syntax. The only penalty is that the programmer needs to be comfortable using and understanding more abstract programming concepts.

Re:Mmmm, Kay.

[Bill, Shooter of Bul]

Yeah, I think it might be more than not have being taught that. I think, that many people may just have a hard time thinking about how other people different than them might think. It would surely explain politics in the USA.

Re:Mmmm, Kay.

[tkinnun0]

Java version might look something like this:

import java.util.*;

class Node {
  Map<String, Node> map = new HashMap<String, Node>();

  static Node asNodes(List<List<String>> input) {
    Node nodes = new Node();
    for(List<String> row : input) {
      Node node = nodes;
      for(String column : row) {
        if(node.map.containsKey(column) == false) {
          node.map.put(column, new Node());
        }
        node = node.map.get(column);
      }
    }
    return nodes;
  }
}

Re:Mmmm, Kay.

[poopdeville]

I don't think you know what is meant by an "infinite data structure". Hint: They are finite at every stage. Mainstream languages have supported infinite data structures since the linked list was invented. What Haskell brings to the table is not needing to know the values at "up front", since the data structure can compute them on the fly, as needed.

Think of them as unbounded (not tied to a finite collection) iterators of "objects" of the desired type.

Re:Mmmm, Kay.

[Anonymous Coward]

Ok, not infinite, try unbounded. It's an unbounded stream of ethernet frames arriving.

Re:Mmmm, Kay.

[Anonymous Coward]

If you want to convert SQL results to XML, you can't do better than VB9. Here's some actual code:

Dim foo = _
    <site>
      <%= From p In dc.PostItems _
          Order By p.PublicationDate Descending _
          Select <item>
                  <title><%= p.Title %></title>
                  <link>http://ThinqLinq.com/Default.aspx?Postid=<%= p.Id %></link>
                  <pubDate><%= p.PublicationDate %></pubDate>
                  <guid isPermaLink="false"><%= p.Id %></guid>
                  <description><%= p.Description %></description>
                </item> %>
    </site>

Note the XML literals with ASP-like insertions.

dom

Re:Mmmm, Kay.

[arevos]

Java version might look something like this

A neat approach to the problem, though your code loads the entire result tree into memory, which could be rather large if you're trying to export information from a large database. Conversely, the Haskell code builds up the tree lazily, so it can handle a result set of arbitrary size with relatively little memory overhead.

Re:Mmmm, Kay.

[badkarmadayaccount]

I dare you to write a 3D shooter in Brainfuck, or, better yet, Apollo. *ducks*

Re:Mmmm, Kay.

[arevos]

If you want to convert SQL results to XML, you can't do better than VB9.

That's just a linear list of items tags. The Haskell code was creating a tree of depth N from a result set of N columns.

Re:Mmmm, Kay.

[CableModemSniper]

Yes, it might make your life easier ... just as doing open(filename).readlines() is "easy" in python, but they don't not treat the machine resources as what they are (limited).

The Haskell equivalent to "open(filename).readlines()" does treat the machine resources as limited. When you do let s = lines $ readFile filename in Haskell, it doesn't slurp the whole file into memory. Rather, as you manipulate s, it reads the file in discrete chunks on as needed basis. I think you underestimate the sophistication of the implementation of this sort of functionality.

As for the continuous stream of NIL (what's a NIL byte? 0?) bytes scenario, you'd always have to handle that. I can't think of any language feature of any language that lets you get away with poor programming.

Re:Mmmm, Kay.

[CableModemSniper]

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

Re:Mmmm, Kay.

[Anonymous Coward]

The original post said:

A while ago I was designing a program to export some hierarchical data held in a database to XML. Because SQL resultsets are 2D grids, I needed a way of converting a 2D grid into a list of fixed-depth tree structures.

The VB does almost exactly that -- it performs a query against a SQL database and returns a fixed-depth tree structure (in XML already). Of course the tree structure is pretty short in that example, but it could be arbitrarily tall.

Here's a slightly taller version:

Dim foo = _
    <site>
      <%= From p In dc.PostItems _
          Order By p.PublicationDate Descending _
          Select <item>
                  <title><%= p.Title %></title>
                  <description><%= p.Description %></description>
                  <reviews>
                      <%= From r in p.Reviews _
                          Where r.stars >= 3
                          Select
                          <review>
                              <%= r.ReviewText %>
                              <%= From a in r.Reviewers _
                                  Order By a.Name _
                                  Select <reviewer cred=<%= a.Credentials %>>
                                            <%= a.Name %> </> %>
                          </review> %>
                  </reviews>
                  <keywords><%= From k in p.Keywords Select <kw><%= k %></> %></>
                </item> %>
    </site>

Note how clearly it states exactly what it does and how obvious it is what the resultant tree structure looks like.

dom

Re:Mmmm, Kay.

[arevos]

Note how clearly it states exactly what it does and how obvious it is what the resultant tree structure looks like.

The original problem called for a tree of depth 8, which from your VB example would result in a large amount of nested code.

I'm also interested whether the inner loop generates a new SQL query for each item. Is LINQ clever enough to optimise that inner query into a join? I'd be impressed if it did.

If not, then you're performing N queries as opposed to just one. Applying this technique to a tree of depth 8 would result in even more distinct queries. This would start to get very slow, as I've had experience maintaining code that use nested SQL statements to pull out hierarchical data. It takes about a day to do something that should have taken under a minute.

So the VB code is considerably longer than the Haskell code, and possibly much, much slower, depending on how clever LINQ is.

Re:Mmmm, Kay.

[thelawal]

Both you and the post you qouted are incorrect. The quoted post is incorrect because any application that excepts input from the keyboard has an infinite data structure in it. Streams, stacks and queues are infinite data structures. A lot of games rely on linked list which is another infinite data structure. If you look at most if not all the "mainstream" languages they do support infinite data structures. Let me give you a list. The C++ STL contains definitions for vectors, stacks, queues, and deques. The BCL of the .Net Library supports stacks, list, and sequences, and streams. Now the real pitfall of Haskell is that it shoves functional programming down your throat when you use it. I know what you're thinking,"So does Java,and C#." But OOP is funny in that it allows a lot to go on under the hood. You can program functionally, or imperatively. That is why such laguages as Scala, F#, and OCaml are able to exist along side Java, C#, and C++.

Re:Mmmm, Kay.

[idfubar]

...but I'm never going to write a web-app, or a word-processor in Prolog.

Many of these languages are very clever when it comes to doing certain things, but how often do you actually need to do those things?

Yeah, but how often are you going to need to write a web-app or a word-processor? Thanks to the open-source movement there's an abundance of applications & packages which are freely accessible to you as a developer; if you're writing code to do common things then perhaps you're not making use of what is available to you. BTW, freeing yourself up to think beyond the confines of a common paradigm, tool, etc. is what learning is all about; you can do most things you want to do with a UNIX shell using Scheme/LISP but most people don't because they don't realize they can. Given your experience you probably understand my point but I think that if you state that there's no place for alternative languages (or that their place is limited and/or small) you're essentially laying the groundwork for the logic which precludes those other languanges a priori.

Re:Mmmm, Kay.

[idfubar]

Elegance cannot beat convenience in the workplace, or in most at any rate.

I would argue that any workplace which demands a choice in tradeoffs between elegance and convenience is probably not somewhere you want to work (especially if you know a language like Haskell)...

Re:Mmmm, Kay.

[Anonymous Coward]

The final software formula (forever) will be the Universal Programming Language of the Informational Space based on the Informational Individual!

Re:Mmmm, Kay.

[QuestionsNotAnswers]

OP is using (one, two, infinity) rather than the more classical (one, two, many) number system.

You don't need to use obtusive language.

Re:Mmmm, Kay.

[Requiem18th]

Care to translate? Or at least x-plain plz?

I'm fluent in Python, Javascript, PHP, SQL, C/C++/C#/Java. Could accept a sample of scheme, lisp or ruby if necessary. Thanks.

Re:Mmmm, Kay.

[Thed77]

In my opinion lazyness is useful, so let's just wait for an imperative language to steal that feature so people can actually use it, just like what happened with the rest of functional languages' features... (I know people are gonna mod me troll for this, don't worry)

Actually laziness is implemented in many OO imperative languages as the iterator pattern. So it's already been stolen, and is used so much its in the base library of the .Net framework.

Re:Mmmm, Kay.

[IpalindromeI]

I don't see anywhere in the Haskell version where the tree is serialized as it's being built, so the entire result set will be read in eventually there, too.

Re:Mmmm, Kay.

[arevos]

See here. Hope that's clear enough!

Re:Mmmm, Kay.

[Hognoxious]

But today most developopment is for larger application which doesn't necessarly solve problems per-say but create a tool that people can use.

I'm not at all sure what you mean by that. My understanding was that most development, as in what most developers spend most of their time doing, involves things like maintaining stock control systems written in PHP or accounting systems written in perl. Are those problem solving or not?

While I'm here, is "hascal" a joke, a typo, or some obscure hybrid language?

Re:Mmmm, Kay.

[Eli Gottlieb]

Really. Please explain how a mainstream CPU (give an example) really processes lambda-calculus with an I/O monad.

Re:Mmmm, Kay.

[Eli Gottlieb]

WARNING: Possible infinite mutual recursion. ...

ERROR: STACK OVERFLOW. Attempting to exit gracefully.

slashdot:~ cowboyneil$

Re:Mmmm, Kay.

[Anonymous Coward]

First, even if all streams are finite, can you give me an upper bound? If you say '4.7 GB is enough for everyone', duck the BluRay disc that I'll throw at you. And so forth...

Second, which benefit do you seriously expect to derive from the knowledge that the stream is finite? So maybe you'll know that the number of bytes will fit into a 64-bit counter, and the number of packets will fit into a 32-bit counter, but other than that?? Maybe that leaking one byte of memory per kilobyte received is acceptable because that'll add up to no more than the available virtual memory???

Regarding the stream as infinite and treating its end as a special case should be easier.

Too constrained and academic

[m50d]

The problem with Haskell is that it's a superb language for solving the sort of problems its designers foresaw. Unfortunately it makes it almost impossible to do things they didn't expect; you're too trapped in the rigours of the Haskell way of doing things.

A separate, but related problem is that the community doesn't seem interested in practical use of it - there aren't lots of bindings to libraries to make easy things easy. Heck, even doing i/o at all isn't really supported very well. Functional programming is very good for the pure computer science part of programming, but unfortunately that's going to make up less than half of any given program. You also need to be able to interface.

So I think the quote in the summary is right: people won't be adopting Haskell or similar pure-functional languages any time soon. What will happen is the next generation of dynamic languages will adopt the best features from functional programming; we've seen that happen already in python and ruby, and it'll happen again. And people will start using them there.

Re:Too constrained and academic

[beelsebob]

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.

Re:Too constrained and academic

[sribe]

You also need to be able to interface.

Which is exactly why I find Scala to be interesting. Note: I haven't had time to learn or use it yet, but the design concept there is very interesting.

Re:Too constrained and academic

[Unending]

Very true, I did a large project in Haskell for a CS class once the three of us working on it hated the language after we were done.
Before that we were pretty happy with Haskell, because the programming assignments leading up to the final project were all fitted to the language, but the instant we had to do something that wasn't, we realized what a mess it is.

Re:Too constrained and academic

[Anonymous Coward]

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

Re:Too constrained and academic

[Anonymous Coward]

Let me guess, you've never actually used haskell right?

Re:Too constrained and academic

[Dan East]

Right in the middle of reading your comment I realized they must have changed something in the Matrix again.

Re:Too constrained and academic

[cameleon]

This is completely false. IO is well supported, with an almost imperative syntax. And as others have mentioned, there are hundreds of libraries available. As an aside, functional isn't the coolest aspect of Haskell. I think its type system is much cooler (although not as cool as Agda's).

Re:Too constrained and academic

[AKAImBatman]

people won't be adopting Haskell or similar pure-functional languages any time soon.

Correct-a-mundo. On the Haskell part at least. Javascript is a functional language that has managed to go mainstream. Whether you would call it "pure" or not is open for debate.

Re:Too constrained and academic

[Anonymous Coward]

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

http://hackage.haskell.org/packages/archive/pkg-list.html

> even doing i/o at all isn't really supported very well

I've never had a problem with it (but, i may be a better programmer :P )

> you also need to be able to interface

How so? You mean talk to other languages? The Haskell Foreign Function Interface is probably the easiest FFI I've ever worked with (not that it's the best, but it's good).

Re:Too constrained and academic

[cylence]

JavaScript is decidedly not a functional language. It's a language that "functions", maybe that's what you meant. "Functional programming language" means something else entirely, though.

Re:Too constrained and academic

[sergstesh]

And why not OCaml ? Nicely separated into both functional and imperative parts.

Has a lot of lazy evaluation stuff in libraries.

Has modifiable syntax/grammar.

Very efficient - number 2 after "C".

Re:Too constrained and academic

[Anonymous Coward]

Perhaps you are fairly new to computer science in general, but functional programming provides a lot more advantages than even OO does in the real world. I would encourage you to look at mutiple dispatch in Lisp as compared to Java.

The problem in today's world is that most people think that one paradigm is the right tool for every job! The right tool for the job does not just apply to the language my friend, but also the paradigm.

I would be willing to wager that most applications designed and built with OO are ill-conceived. Only a fraction of those built should have used OO in the first place. There still exists the logical, functional and procedural programming paradigms and are used quite often.

There is pleanty of reasons why functional programming is used extensively in a mathematics-heavy field; and logical and procedural programming is used extensively in a scientifically-extensive heavy field. OO has its place in business applications and rightfully so!

I hope this was enlightening...

Re:Too constrained and academic

[clang_jangle]

And people will start using them there.

Them there what ?

Re:Too constrained and academic

[burris]

I've been using Scala and it's the only way to do anything with Java, imho. Sure, it's no Haskell but it's pretty darn nice. A lot nicer than Java without the performance penalty of other languages that target the JVM, such as Groovy or Python.

Even if you don't have to use Java, the popularity of the language combined with the pervasive NIH syndrome of the community means there is a very rich library of software components to use.

Re:Too constrained and academic

[AKAImBatman]

No, I mean it is a true, honest to God, functional language. If you check Wikipedia, for example, you will see it listed as "Multi-paradigm: prototype-based, functional, imperative, scripting".

See, most people look at the C-style syntax and think it means that Javascript is a C-style language. Then they get frustrated when the C-stlye code they write looks like crap. Instead, they should be coding with closures and lambda, much like they would with a LISP program. The result is a far more sophisticated program that performs more work with greater elegance than a C-style equivalent.

I highly recommend Douglas Crockford's "The JavaScript Programming Language" introduction to the language if you're not familiar with Javascript's functional aspect.

Re:Too constrained and academic

[m50d]

I call FUD. The Hackage databasehas literally hundreds of libraries sat there ready for you to use.

Sure, but how many of them actually work? How many have a big enough userbase that you can be confident? And even if I give you that, it's still an order of magnitude fewer than you'd get with more popular languages. Last time I looked I couldn't find one that would let me *send an email*; ended up doing it myself with raw sockets. That particular case may have been fixed now, but the point remains: there are many common, easy tasks that should be one call into a library, but aren't, because the haskell users are mostly academics who have no need to do that.

And if you really need something that isn't there, the FFI is mature, and very easy to use.

Please. No such automatic interface is reliable enough to depend on - they always break on the one function you particularly need. The FFI is not a real solution.

Re:Too constrained and academic

[Anonymous Coward]

Lisp isn't a functional language. Functional languages are referentially transparent. Lisp is an imperative, object-oriented language with first-class functions. Multimethods are an OO concept, so citing them as an argument against OO demonstrates that you have no idea what you are talking about.

Re:Too constrained and academic

[cylence]

I wonder what you mean by "automatic", considering you have to explicitly define the type of the imported/exported interface.

Re:Too constrained and academic

[AKAImBatman]

There's a more in-depth article on Javascript's functional capabilities here:

http://www.hunlock.com/blogs/Functional_Javascript

Other stuff I pulled out of Google for your perusing:

http://dankogai.typepad.com/blog/2006/03/lambda_calculus.html
http://math.ucr.edu/~mike/lc2js.html
http://www.joelonsoftware.com/items/2006/08/01.html
http://www.ibm.com/developerworks/java/library/wa-javascript.html

What this all means is that Javascript is the most widely deployed functional language in existence! And that's a fact you can take to the bank.

Re:Too constrained and academic

[beelsebob]

And even if I give you that, it's still an order of magnitude fewer than you'd get with more popular languages.
Really? Ruby forge has a fairly similar number of projects available. PyPi has only a small amount more. Last time I checked with the guys who manage hackage, they're getting 100 submissions of new projects/versions every *day*.

Please. No such automatic interface is reliable enough to depend on - they always break on the one function you particularly need. The FFI is not a real solution.
Automatic? You sir have no idea what you're talking about. There is nothing "automatic" about the Foreign Function Interface. If you look on Hackage though you will find a couple of mature tools for generating FFI code automatically.

Re:Too constrained and academic

[cylence]

This is only true for specific implementations. The Haskell 98 report only specifies library support for textual input/output, and is completely useless for portably handling Binary IO. That everyone just uses GHC anyway, which has great support for Binary IO, doesn't negate the point that Haskell itself sucks when it comes to IO.

Other serious shortcomings would have to include lack of proper locale/encoding support (characters are read in as Unicode values; but what is the original encoding assumed to be, then? Current implementations do byte-for-byte, which also isn't great), and lack of serious exception-handling (though that is probably mitigated considerably by the Maybe monad in combination with "do").

Haskell is a gorgeous language, but it does have some serious shortcomings, at least when it comes to the official specification as opposed to popular implementations. GHC has done much in making it a truly useful language, and so most people mean GHC when they say "Haskell". Which is plenty portable enough, I guess, considering that it is capable of using GCC as the compiler backend.

Re:Too constrained and academic

[Anonymous Coward]

"Please. No such automatic interface is reliable enough to depend on - they always break on the one function you particularly need. The FFI is not a real solution."

The more you say, the more clear it becomes that you have never tried haskell and you have absolutely no idea what you are talking about. FFI is not an automatic anything, its how you interface with C. It makes it trivially easy to use a C library (there's quite a few of those I hear) from haskell. Its not magic, it doesn't automatically do whatever you think it does.

Re:Too constrained and academic

[raddan]

I think the real problem with Haskell is that you're required to use your brain to make any use of it. I.e., you have to be one of those people who, upon opening a Knuth book, goes "Wow!" If you were a mediocre CS student, or you have no formal CS or mathematics training, Haskell is going to be very hard for you to wrap your head around.

Re:Too constrained and academic

[cylence]

That a language has "functional aspects" doesn't make the language itself "functional". By the same reasoning you use, Python is a "functional language" too. Hell, even Perl has closures and lambda. And Python has list comprehensions and such. Pretty much every high-level language has these things; that doesn't make them functional.

Re:Too constrained and academic

[beelsebob]

I think the real problem with Haskell is that you're required to use your brain to make any use of it.
What, you mean you can't just bash your head against a keyboard repeatedly and expect your program to compile (but not necessarily work? Call me irrational, but hey, I see that as a good thing! Making programmers think before they write something, and then having it work first time is great!

Re:Too constrained and academic

[Anonymous Coward]

Can you do anything besides call FUD?!?!?
Seriously, every opinion the differs from yours is not FUD. Give the zealotry a rest, and try to have a conversation or dialogue.

Re:Too constrained and academic

[AKAImBatman]

What would you describe as "Functional" then? i.e. What is the key difference between a Functional language and a language that has "Functional Aspects"? Show me the difference you believe is there and I'll show you the Javascript goods.

Oh, and BTW? Academia agrees with me that Javascript is a functional language.

Javascript is a functional language [...] The world's most-widely deployed functional language
--Professor of Theoretical Computer Science Philip Wadler, University of Edinburgh

Re:Too constrained and academic

[BotnetZombie]

If you don't know of it already, you might also wanna take a look at Clojure, a Lisp dialect that can either be interpreted or precompiled to .class files.

Re:Too constrained and academic

[Just Some Guy]

Which is exactly why I find Scala to be interesting.

I just wish they hadn't re-used the name of an Amiga multimedia language. I'd been assuming there was a resurgence of Hypercard-style programming for the first year or so before I realized that this was something new.

Maybe Sun can come out with their own version named ARexx.

Re:Too constrained and academic

[burris]

yeah, Clojure looks promising but not nearly as mature as Scala right now. Also I'm afraid that I have allergic reactions to lispy syntax, no matter how much I like the languages from that family.

Re:Too constrained and academic

[Anonymous Coward]

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. In contrast, I know the similar "standard libraries" available for Java, Python, .NET and Ruby very well. Now if I were a project manager, this would be a great reason not to use Haskell. The fact that the library is not well-known could mean that it is immature, but even if it isn't, it definitely means that the Haskell community has poor marketing and as a result not many other people are using Hackage. If other people aren't using it, and it's unsupported open-source code, I sure as heck am not going to risk my project with it just to save a few lines of code.

This is the problem functional language fans will have to deal with - convince industry people that your language is not just a tech demo and that they can actually build large, scalable, reliable applications on it.

Re:Too constrained and academic

[Nevyn]

Really? Ruby forge has a fairly similar number of projects available. PyPi has only a small amount more. Last time I checked with the guys who manage hackage, they're getting 100 submissions of new projects/versions every *day*.

Are you still compiling your entire OS from source? Following every project on your system for updates? No you use a package management system (or at least sane people do). Ok, now goto a Fedora box and type "yum search haskell" and "yum search python" ... "fairly similar" is so off the mark it isn't even funny.

Also I'm not sure what "100 submissions a day" is supposed to be measuring, but it sure better not be "new packages" and anything else doesn't seem relevant to the discussion.

Re:Too constrained and academic

[raddan]

Oh, I totally agree with you. But if my peers (programmers) are any indication of the state of the average programmer, well, it ain't happening anytime soon. Not that I'm a fabulous programmer myself, but I do consider myself _interested_ in programming, and I try to learn from my mistakes. I can't say the same for some other people around here.

Re:Too constrained and academic

[nuttycom]

I'm currently using Scala and the Lift web framework on a fairly significant internal project at my company, and I have to say that I'm very impressed with both the quality of the language and how easy it has been to integrate existing Java code, including the whole JEE5 stack.

The only thing I've found with Scala that takes a bit of time to get one's head around is the type system; if you're one of those developers who found Java generics to be difficult, the intricacies of the type system in Scala will probably give you the fits. For an example of why, check out this set of exercises

Re:Too constrained and academic

[Anonymous Coward]

Let me guess. You can't fucking read and had your brother type that stupidity for you?

Re:Too constrained and academic

[NoOneInParticular]

A pure functional language would be a language where there are no side effects. I.e., you can't change the state of anything, you can only construct new things out of existing things. 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. Functional languages follow this pattern: side-effects are only permitted if there is no other way. Examples are Lisp and Scheme, but also Matlab, Mathematica and Scala. Other languages allow side-effects by default, and have functional aspects in other respects. Examples of these are Javascript, Ruby, Python, Java, C++, C and even assembler (programming without any functional aspects is going to be hard). Quite likely Javascript programming can be done almost purely functionally. But so can C.

So, if you can show me that you can't have mutable variables in Javascript, we can call it functional.

Re:Too constrained and academic

[AKAImBatman]

An excellent post, sir. Much more on target than cylence's attempts.

A pure functional language would be a language where there are no side effects.

This is correct. However, I did not claim that Javascript is a *pure* functional language, only that it is a functional language. If we go by the definition of a pure functional language, then we must discount a long list of functional languages as well. That includes the poster-child for functional programming: LISP

Javascript allows for pure functional programming just like any other functional language. However, it does not enforce the purity of functional code. Something that is a very difficult goal to reach. This combined with the C-Style of the language has the negative effect of encouraging imperative programming. With suitably predictable results. (How many times have we heard, "Javascript sucks!")

This is why I often refer to Javascript as a "LISP-style functional language". The two don't line up exactly, but the foundations of Functional List Processing are present in both.

An interesting aspect of the language's real-world use is that the designers of Javascript's web APIs could have created APIs that force imperative thinking. Yet they didn't. Even for traditionally imperative operations (e.g. networking), the designers of Javascript's web APIs have seen fit to ensure its functional nature through the use of an event system. e.g. I do not read values from XMLHttpRequest, I wait for a functional call.

I personally think it's fascinating that the functional underpinnings of the language have been so well preserved despite the lack of general knowledge about the language. The efforts they are putting into the language will pave the way for more mainstream functional languages in the future.

Re:Too constrained and academic

[Anonymous Coward]

No, I mean it is a true, honest to God, functional language. If you check Wikipedia, for example, you will see it listed as "Multi-paradigm: prototype-based, functional, imperative, scripting".

See, most people look at the C-style syntax and think it means that Javascript is a C-style language. Then they get frustrated when the C-stlye code they write looks like crap. Instead, they should be coding with closures and lambda, much like they would with a LISP program. The result is a far more sophisticated program that performs more work with greater elegance than a C-style equivalent.

I highly recommend Douglas Crockford's "The JavaScript Programming Language" introduction to the language if you're not familiar with Javascript's functional aspect.

Problem is that javascript even if you work heavily with closures and lambda like constructs still is a mess. The pure functional approach of everything is a function does not work in huge software systems where you need higher levels of abstraction.
The problems of javascript can be nailed down to a few words:
lack of namespaces which makes bigger software systems an inherent problem in this language
the lack of real oo enforces different incompatible implementation of those mechanisms on top of the prototype functions
the browser incompatibilities on various levels (this is the only level where javascript is not at fault)

After all, javascript is like most other functional languages, great for small systems because in a defined domain they really are compact. The fall heavily apart once you have to apply them to bigger systems!

Re:Too constrained and academic

[Tetsujin]

What this all means is that Javascript is the most widely deployed functional language in existence! And that's a fact you can take to the bank.

I did that, but the teller just kind of looked at me funny and asked if I'd like to deposit money to my account...

Turns out I didn't even have an account there. Go figure.

Re:Too constrained and academic

[Sancho]

I clicked on that link expecting text, but I got a video instead. Do you have anything along similar lines, but in a readable format?

Re:Too constrained and academic

[HiThere]

Scala is one of the languages that looks interesting... but what implications does using the JVM have for using multiple processors?

My understand was the Java threads, like the Python GIL (global interpreter lock) imply that the program is running in only one processor. If this is incorrect, then that would be very interesting.

Re:Too constrained and academic

[AKAImBatman]

lack of namespaces which makes bigger software systems an inherent problem in this language

Namespaces is an imperative problem. Javascript is a functional language. Think Functional.

It's easy to encapsulate Javascript objects into Java-style Packages with only a slight amount of work. However, I do not recommend that you do this. Most code should be kept out of the namespaces entirely. If you do project code into the browser's default object/scope/namespace (they're all the same thing in Javascript; "var x = 'blah'" will work with "alert(window.x)"), make sure you project only what is necessary to initialize the functional objects.

Re:Too constrained and academic

[wirelessbuzzers]

What would you describe as "Functional" then? i.e. What is the key difference between a Functional language and a language that has "Functional Aspects"? Show me the difference you believe is there and I'll show you the Javascript goods.

I'm not a dictionary, but I would say that "functional" is usually a synonym for "declarative". That is, a functional language is one in which work is done primarily by computing values, rather than by manipulating state. Javascript is designed primarily to manipulate the state of the browser, and internally most of its work is done by manipulating the state of objects, arrays and local variables. Therefore it is not a functional language.

In the limit, you have "pure functional" languages like Haskell, in which you can't manipulate state at all (at least, not without monads or uniqueness types or something like that).

However, Javascript has "functional aspects" in the form of closures, anonymous functions and higher-order functions, which are features common to (nearly?) all functional languages.

Re:Too constrained and academic

[mstahl]

Saying Haskell is useless just because you don't know how to write in that style is just like saying Perl is useless because you don't know how to use regular expressions. List comprehensions and functional mapping and folding are concepts that you might not learn in school without a theoretical background but learning how to use them and use them well will make you a better programmer.

It's the key difference between a "programmer" and a "computer scientist" and it really does make a difference in writing clean, elegant code. After you've been working in functional languages, suddenly for and while loops look ugly, global variables look like a joke from a previous century, and you start to see the simplicity of your code rather than being daunted by its complexity.

I love how people like to portray functional languages as academic exercises or feeble playthings—and maybe that's just from how you've been exposed to them—but they are real languages capable of real things, oftentimes performing better than imperative languages.

Re:Too constrained and academic

[wirelessbuzzers]

What this all means is that Javascript is the most widely deployed functional language in existence!

Javascript is probably the most widely-deployed programming language in existence. Nearly every PC, nettop and smartphone has at least one complete Javascript implementation on it, and many of them have more than one. The same is not true for any other programming language I can think of, unless you count i386 (or ARM) machine code. Java is probably less popular. (And Java, by the way, is nearly as functional as Javascript.)

Re:Too constrained and academic

[DragonWriter]

Functional languages follow this pattern: side-effects are only permitted if there is no other way. Examples are Lisp and Scheme, but also Matlab, Mathematica and Scala.

Lisp, per se, is pretty clearly not an example of this, though Scheme is an example of a Lisp-family language that, while not purely functional, at least leans more strongly than many Lisps toward avoiding side effects.

So, if you can show me that you can't have mutable variables in Javascript, we can call it functional.

You can have mutable variables in Lisp, which is usually described as functional. You seem to be saying that functional languages include only pure functional languages, which is pretty clearly not the way the term has traditionally been used (which is why we have the widely used term "purely functional" to refer to purely functional languages.)

JavaScript and Lisp are functional languages. They are not, like Erlang and Haskell, pure functional languages. Similar Java and C++ are OO languages, but are not, like Smalltalk or Ruby, pure OO languages.

Re:Too constrained and academic

[AKAImBatman]

And Java, by the way, is nearly as functional as Javascript.

Java isn't even close to functional. I love the language dearly, but it is incredibly imperative in nature. If you want to create something that looks even remotely functional, you need to dive into reflection (NOT recommended) or start creating single-method classes that implement a specific interface. Both options suck and are nowhere near the power of a true functional language.

Re:Too constrained and academic

[mstahl]

That's why he said the purity of it is debatable. Were it a "pure" functional language there would be no first-class objects but functions. Obviously that's not the case in Javascript, but it is a functional language in that it can be used in that style. Also, neither Python nor Perl count because you cannot define anonymous functions in either one.

This is an important distinction. In Python you can say "lambda x: 2 * x" and what you've got there is a lambda, but it is not a function; it's just an expression. In Javascript you can define actual, for real, bona fide functions and pass them as arguments inline, like so:

foo.prototype.bar = function (baz) {
do_something(baz);
do_something_else(baz);
return something(baz);
}

In Python you'd be restricted to kludging that all into one function (yes I know you can use boolean operators to trick it into doing multiple statements in the same lambda expression, but that's cheating and won't work all the time because the boolean operators short-circuit on a false return value).

Check out jQuery to see what it looks like when Javascript is written the right way.

Re:Too constrained and academic

[RAMMS EIN]

The bottom line here is that the paradigm isn't a property of the language, but of the program. You can do functional programming in Java, and you can do imperative programming in Haskell. At the end of the day, different paradigms are best for different tasks, and the best languages are those that don't get in your way, but give you the tools to build what you need.

Re:Too constrained and academic

[Anonymous Coward]

My understand was the Java threads, like the Python GIL (global interpreter lock) imply that the program is running in only one processor. If this is incorrect, then that would be very interesting.

That is incorrect.

Re:Too constrained and academic

[sribe]

I just wish they hadn't re-used the name of an Amiga multimedia language.

AH! I thought the name sounded familiar, then when I looked into it and saw how new and shiny it was, I assumed that my middle-aged memory was playing tricks on me. But yes, I remember there was a Scala for Amiga...

Re:Too constrained and academic

[sribe]

...I have to say that I'm very impressed...

Thanks for the info; I'll try to make time to look into it--I have the perfect little project for it.

Re:Too constrained and academic

[SrgntJack]

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.

Re:Too constrained and academic

[m50d]

Oh, I "get" it all right. Don't get me wrong, Haskell is a very good language - possibly the best one around currently - for doing new computer science in. It's just that less than 1% of any given program will be new computer science. Most of the code you write isn't doing actual computation, it's interfacing - with the OS, with libraries, with other programs, or with the user - and Haskell isn't very good at it. Consider a problem I'm currently grappling with - converting "hard", "burned-in" video subtitles to "soft" programmed ones. If I was doing this from scratch, in a world where nothing of the sort had been done before, Haskell might well be the best language to do it in. But I'm not - decoding video is a solved problem. Detecting where things have been superposed on a video is a mostly-solved problem. OCR is a mostly-solved problem. Putting a nice GUI and a web frontend on this are definitely solved problems. Very little of the program I eventually come out with will be dealing with the actual gruntwork, mostly it's a question of connecting the solutions to already-solved problems together to form a solution to a problem which hasn't (as far as I know) yet been solved. And Haskell is worse for that 90%, and this vastly outweighs being any better on the perhaps 10% that is the core of the problem.

Re:Too constrained and academic

[m50d]

I've been doing functional programming for years; I'm not arguing against functional programming, but against Haskell and similar languages. Yes, no one paradigm is perfect - which is why a multi-paradigm language with support for both OO and functional programming, along with the ability to do without either of them when you don't need it, is better. Take a closer look at modern languages like Python or Ruby - there's a lot of support for functional programming there, if you need it, but it's not thrust in your face if you don't want to use it.

Re:Too constrained and academic

[HiThere]

Any suggestions as to a good book to learn it from?

Re:Too constrained and academic

[Pseudonym]

Sure, but how many of them actually work?

They all typecheck, so they must all work!

Re:Too constrained and academic

[Pseudonym]

I still have to wonder how much of the "mess" was simply due to inexperience.

My first large undergrad project in C++ was a mess. I thought the language was bloated and useless. Then I came back a couple of years later and wrote another large project, this time after reading a few books and understanding what "good C++" was supposed to look like. The difference was remarkable, and I'm now sold on it.

Re:Too constrained and academic

[ModMeFlamebait]

Also, neither Python nor Perl count because you cannot define anonymous functions in either one.

ORLY?

#!/usr/bin/perl
my $foo = sub {
my $anothersub = shift;
print "arg: $_\n" for @_;
$anothersub->();
};

$foo->(sub { print "all done!\n" }, qw( 1 2 3 4 ));

Closures work out of the box, too. Oh, and the new /. interface sucks balls.

Re:Too constrained and academic

[axxackall]

you're too trapped in the rigours of the Haskell way of doing things.

That's why I use Python. It is a very multiparadigm language. When some task is solved better with OOP - I use classes and inheritance. When another task is better solved with FP - I use lambdas, maps and comprehensive lists. Sometimes I use regexps for parsing and filtering of texts. Or just a simple scripting when I need just a glue to combine things together.

But with all the mix of paradigms I can read such code after months and I can read the code of other programmers.

Even more - I can quickly (in a day!) introduce Python to sysadmins or DBAs in a level enough for practical programming. Later I can teach them paradigms one by one, again - in a day each paradigm.

Can you do the same with Haskell? Not a chance! So, Haskel IS too constrained and academic.

Re:Too constrained and academic

[goban19]

Haskell has mutable variables. State monad.

Re:Too constrained and academic

[dkixk]

A pure functional language would be a language where there are no side effects. I.e., you can't change the state of anything, you can only construct new things out of existing things. 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. Functional languages follow this pattern: side-effects are only permitted if there is no other way. Examples are Lisp and Scheme, ...

Lisp does not require tail-call elimination and, therefore, one finds a large number of iteration forms: do, do*, do-all-symbols, do-external-symbols, do-symbols, dolist, dotimes, and loop. Scheme does require tail-call elimination and, therefore, Scheme programmers tend to use recursion, without assignment, quite extensively. Lisp programmers use loop and functions which modify values all the time. For example, McCLIM, a rather large lisp package:
$ find . -type f -name \*.lisp -print | wc -l
397
$ find . -type f -name \*.lisp -exec grep -l loop {} \; | wc -l
210
(Why in the world does the pre tag not work?) And this is quite typical of Lisp code in general. Lisp is not a functional programming language, though it can support a functional style. Scheme is nearer to be a functional language.

Re:Too constrained and academic

[dkixk]

The problem with Haskell is that it's a superb language for solving the sort of problems its designers foresaw. Unfortunately it makes it almost impossible to do things they didn't expect; you're too trapped in the rigours of the Haskell way of doing things.

I doubt that the original designer of Haskell had an SCM tool, e.g. darcs, in mind when creating the language. I am personally not a big fan of Haskell, but neither am I a hater, and even I have used darcs.

Re:Too constrained and academic

[m50d]

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.

Re:Too constrained and academic

[cylence]

The State monad is absolutely not "mutable variables". It's a mechanism for successive transformations of a state value, which is pure functional programming defined.

Re:Too constrained and academic

[dkixk]

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.

Re:Too constrained and academic

[Anonymous Coward]

Well, using this logic.. neither Haskell, Lisp, Scheme, SML, or anything other than pure lambda calculus under plate glass in a vacuum could ever be functional, if even that. Functional is different than purely functional. And purely functional, even in the absence of monads, can have effects on stateful information. It just tracks and abstracts the statefulness, keeping it out of its stateless portions.

Haskell didn't 'decide' on any single method for dealing with state before monads, but there was still stateful code, it just wasn't of a canonical nature.

I think the argument you are having is one of semantics. When is something 'primarily' in one group, and not 'primarily' in another group, when it has features from both? Well C has overt features for state gymnastics and reference juggling, javascript doesn't. They are distinctly different in that reguard. Does this make javascript functional? Partially. Does it mean javascript is a functional language? Uh, who gives a crap.

As for Haskell not scaling up... hornswable. I remember back in my ruby programming days when I had to give a left testicle to administrators to get them to install ruby on their servers so I could run my software. Its really just a matter of exposure and adoption.

Why would the average indo-european want to learn mandarin? To talk to chinese people. Does it matter if the language is hard, and not like your native tongue? I mean, hell, there are all of these romantic languages we can use, why would I learn Hangul when USA Today isn't printed in Korea?

Because it will make you more intelligent and give you the opportunity to expose yourself to concepts barely, if at all present, in the languages you have been speaking your entire life.

Isn't variety a good thing? Since when did technically inclined people turn into industrialists?

Why they don't rule:

[Kingrames]

The picture in the linked article is missing a beard.

Re:Why they don't rule:

[Bob-taro]

The picture in the linked article is missing a beard.

I was going to mod you funny, then I thought maybe a lot of people wouldn't get the beard reference, so I decided to post instead. Anyone else want to mod parent funny?

Re:Why they don't rule:

[solraith]

Way to take one for the team!

Re:Why they don't rule:

[moderatorrater]

Anyone else want to mod parent funny?

Yes, I will!

Oh crap.

Re:Why they don't rule:

[Anonymous Coward]

Now, you, I would have modded funny, but I have no modpoints.

Re:Why they don't rule:

[cdfh]

The picture in the linked article is missing a beard.

There is a beard, but you have not evaluated it yet.

Re:Why they don't rule:

[RAMMS EIN]

That reminds me of something I thought of a couple of months ago (or is it years by now?). It seems to me that a lot of people who had a great impact on the world have had beards. Does anyone have any theories as to why that might be?

By the way, I have a beard, too. And I'm working on a programming language.

Re:Why they don't rule:

[TwistedSymmetry]

Oh crap.

...he types before clicking preview, and clicking submit. ;-)

Re:Why they don't rule:

[TwistedSymmetry]

A lot of geniuses in history had really messy hair. I need a haircut.

It's not for dumb people

[OrangeTide]

I haven't really been able to figure out how to do anything significant in Haskell. But I suspect that one day a language more like haskell and less like C will end up being the most popular. Monads and all that kind of confuses me.

I think it helps if you have a strong math background and are comfortable with Lambda calculus. I'm just an old C hacker and haven't used any real math in like 10 years, so I'm not that effective in Haskell :(

Re:It's not for dumb people

[Nursie]

Personally I'm pretty happpy with pthreads and C anyway... I've yet to be sold on any of these new languages.

Re:It's not for dumb people

[Valtor]

People will get more intelligent just by using functional languages. Even .Net has it now, it's called F# FSharp

Re:It's not for dumb people

[LWATCDR]

Don't worry.
In a few years you will see c++++ which will be c++ with functional programing tacked on. Of course you will also see Functional Object C but only Apple will use that.

Re:It's not for dumb people

[OrangeTide]

I can get things done in C, and it pays the bills. So I'm not complaining. But I think that letting the compiler figure out the threading for you will be the way of the future when something as simple as a cellphone consists of 300+ minimalistic processing cores working together.

It seems unnecessary today to thread out for more than a dozen cores, but maybe some future technology will require a fair amount of processing power to operate. Perhaps holographic projection need it to encode/decode a data stream useful enough for a portable 3D video communication device (fancy cellphone).

Re:It's not for dumb people

[Shados]

Well, that C++0x thing or however its called has lambdas and functions closer to being a first class construct...so thats pretty much exactly whats happening already, give or take :)

Re:It's not for dumb people

[Abcd1234]

Monads and all that kind of confuses me.

And that's exactly the problem. What are Monads? I'm not really sure (I sort of have a vague intuition of what they are, but that's it). But I do know that you need them in order to do anything that involves side-effects in the world outside of Haskell. And that includes I/O. Yes, that's right, you need to understand a rigorous mathematical construct in order to write a "Hello World" program. There's simply *no way in hell* a language like that will become popular in the mainstream.

The fact is, side-effects are simply a reality in computing. Should they be avoided where possible? Yup. But forcing the programmer through incredibly confusing hoops just to write data out to a file is plain and simply unreasonable.

Re:It's not for dumb people

[Abcd1234]

People will get more intelligent just by using functional languages.

Don't be ridiculous. Functional vs procedural isn't a matter of intelligence. It's simply a way of thinking. And the reality is that procedural languages better match the way the human mind works.

IMHO, learning to program in a functional style is like a right-handed person learning to write with their left. Yeah, they can do it, but it requires a ton of work for dubious real-world benefit, and in the end, it's never really natural, simply because that's not the way the brain is wired (except for the odd freakish exception ;).

Re:It's not for dumb people

[Jack9]

Schools teach functional languages to this purpose. There is no evidence that this is true, but it fills a couple hours of lecture time every semester.

Re:It's not for dumb people

[LWATCDR]

I should have learned this a long time ago.
Don't try and make stuff up to be funny. The truth is silly enough without my help.
All I can say is ewwwww..

Re:It's not for dumb people

[rockmuelle]

C++'s template system is actually a Turing-complete functional programming language.

-Chris

Re:It's not for dumb people

[fedtmule]

Yes, that's right, you need to understand a rigorous mathematical construct in order to write a "Hello World" program.

That is just wrong. You do not need to understand the math behind monads to use them. The part of your program that needs side-effects can be programmed like it was an imperative language. Will it help you, if you learn all the details about monads? Sure, but you do not _have to_ learn all the details.

If you still think you have to learn a bundle of math to do IO in Haskell, then look at a Haskell tutorial. You will see that they can teach you plenty of IO, without explaining the math behind monads.

And I am sure this hello world program do not need much explaining:

module Main where

main = putStrLn "Hello World"

Re:It's not for dumb people

[cylence]

you need to understand a rigorous mathematical construct in order to write a "Hello World" program.

Um... main = putStrLn "Hello World". And you don't have to understand the gory details of how Monads work in order to use them in a do-expression. It's a useful thing for a mature Haskell programmer to know (or, like me, a new but thorough learner), but hardly required.

Re:It's not for dumb people

[Prof.Phreak]

...one day a language more like haskell and less like C will end up being the most popular.

Welcome Perl. Read Higher-Order Perl ( http://hop.perl.plover.com/ ) if you don't believe me.

Best of all, it's always installed on all unix boxes (including macs!)

The only thing that's lacking is automatic palatalization across many cores for map{} operations, but I'm sure I can write a custom iterator to bucket things into N-threads on N-core CPUs if such a need arises.

Re:It's not for dumb people

[Abcd1234]

That's like saying you don't *have* to understand how I/O works to write data out to a file. Yeah, it's true, but any developer worth his title must.

Besides, basic I/O is just one case of side-effects, and Monads are ridiculously hard to understand and work with relative to procedural solutions to the same problems.

Re:It's not for dumb people

[gbjbaanb]

then you want OpenMP bindings. Its simple (though, obviously, not as flexible and all-encompassing as writing everything yourself). eg, if you want to run a for loop using multiple threads you do:

#pragma omp parallel for
for (i=0;i < 10;i++)
{
//do something
}
return 0;

pretty easy. There are limitations - no sleep constructs for example, but that's because its designed to process stuff in parallel, not be a theading library.

Its even available by default in MS VC2005 (you do need to enable it with the /omp compiler flag) even if MS doesn't bother advertising it.

Re:It's not for dumb people

[Anonymous Brave Guy]

Whitespace is Turing complete, too, but I still wouldn't write my next paid job in it. :-)

Re:It's not for dumb people

[jbolden]

You don't need to understand Monads to use monadic routines, the same way that in mainstream languages you don't need to understands stacks to use subroutines.

And monads are no more complicated than pointers.

Re:It's not for dumb people

[the_greywolf]

Well, that C++0x thing or however its called has lambdas and functions closer to being a first class construct...so thats pretty much exactly whats happening already, give or take :)

Have you looked at the syntax? You're basically just binding functions together in template parameters, then invoking them. Normally, I'd be pleased as punch that it's being included but... DAMN is it ugly syntax.

Re:It's not for dumb people

[OrangeTide]

I'm familiar with OpenMP, but have yet to meet anyone who takes it serious enough to use it anywhere. Interesting that it's in MSVC2k5, that is something I didn't know (I'm not a Windows programmer).

It does reminds me of another poster's comment about "c++++", where we hack the features we want onto c/c++ instead of implementing it properly.

Re:It's not for dumb people

[Abcd1234]

the same way that in mainstream languages you don't need to understands stacks to use subroutines.

What? You *do* need to understand stacks to use subroutines. How else do you explain why this code doesn't work:

int *func()
{
    int j = 3;

    return
}

And monads are no more complicated than pointers.

Care to explain that comment? No, seriously, I *really* can't understand monads, so if you can explain them as an analogy to pointers, I'd love to hear it. Because, last I checked, they were a rigorous mathematical construct that somehow encapsulates state, but no one could explain them without resorting to opaque mathematical notation.

Re:It's not for dumb people

[Abcd1234]

Stupid HTML. That example should've returned a pointer to j, in case it wasn't clear. :)

Re:It's not for dumb people

[Nursie]

True, for massively parallel processing against a single task a different model is needed.

My experience is of scalable parallelism on todays hardware in the server arena, when's it's as useful to do a lot of serial tasks in parallel as it is to break them down for faster individual processing.

Re:It's not for dumb people

[0xABADC0DA]

Don't worry. In a few years you will see c++++ which will be c++ with functional programing tacked on.

In order to be true to the spirit of c++ it should be called (*c)++.

You might be saying why not (*c)()++? Well, you see, in functional c++ those two are equivalent.

Re:It's not for dumb people

[0xABADC0DA]

I think it helps if you have a strong math background and are comfortable with Lambda calculus. I'm just an old C hacker and haven't used any real math in like 10 years, so I'm not that effective in Haskell :(

You realize that 'lambda calculus' doesn't have anything to do with integrals, integration, ln/2, etc? In this context it's just a name that means 'anonymous object' to people that reject object-oriented names as 'too hippie'.

Re:It's not for dumb people

[Eli Gottlieb]

'Allo. I'm an odd freakish exception. I can haz tenured research position? I gotz beards, too.

Re:It's not for dumb people

[beelsebob]

And the reality is that procedural languages better match the way the human mind works.
To quote you -- don't be ridiculous. From my personal experience of teaching people functional programming, it's nothing to do with imperative programming matching the brain better. Instead, it's to do with people learning to write imperative programs first, and then having a very steep unlearning curve to deal with at the same time as the learning curve for functional programming.

Re:It's not for dumb people

[gbjbaanb]

I don't think its that anyone takes it seriously, but no-one knows it exists.

The features hacked on to C++ are good, its the design of the language - keep it small and simple, and surprisingly well-designed enough for everything to be added later. Nowadays you have to think of C++ as te core + libraries anyway, C++ would be nothing without the SRL, Boost and others.

(its the same with other languages, C# would be nothing without the .NET class library)

Re:It's not for dumb people

[VoidEngineer]

Agreed! 'Imperative vs functional' programming styles have roots in the argument of 'stasis vs change' and 'being vs doing' that goes back 2000 years to the arguments of Parmenides and Heraclitus. The argument over a state-based vs. flux-based worldview is one of the oldest philosophical arguments in history. This is merely a 21st century adaptation, where procedural programming incorporates a state-based world view, and functional programming incorporates a flux-based worldview. Kudos to Turing and Church for formalizing the argument into machine compilable logic.

Re:It's not for dumb people

[VoidEngineer]

Didn't you know that the # in C# is suppose to be four pluses:

++
++

And C# does have functional programming tacked on in version 3.5 with lambda expressions! Seems like your prediction has already come true. :)

Re:It's not for dumb people

[Shados]

I'm a C# guy. To me, -everything- C++ short of the curly braces is damn ugly syntax. I can't tell whats "super ugly" and what is normal :)

Re:It's not for dumb people

[Anonymous Coward]

On the other hand, going around left-handed for a day teaches you the advantages and shortfalls of your right-handed world, and and the end of the day you can use that understanding to work better right-handed. (And, if you are good enough and the situation permits it, do the things left-handed that are best done that way.)

Which is why I want to learn functional programming: Not because I think I'll use it, but because I think it'll help me program better in the programming languages I do use.

Re:It's not for dumb people

[Abcd1234]

Oh, totally agreed. I've gone out of my way to play with all manner of programming languages, specifically because it's intriguing to work with their different programming models and features. For example, Smalltalk teaches you the incredible power of blocks and closures. Haskell is all about lazy evaluation and an innovative type system. Then there's Lisp's view of code and data interchangeability. All are interesting, and they can provide insights that are applicable across multiple application domains (for example, I enjoy using higher-order functional programming in languages like Perl, Python, and C#, which support such things, thanks to my exposure to Smalltalk and Lisp).

But no sane person would believe that pure functional programming languages will every really leave their niches. I repeat, they just don't match the normal person's mental model of computation.

Re:It's not for dumb people

[ppierre]

The truth is silly enough without my help.

Yes : Phoenix 2.0 and Closures in C

get bonus points ?

Re:It's not for dumb people

[Anonymous Coward]

> I repeat, they just don't match the normal person's mental model of computation.

No, they just don't match an imperative programmer's mental model of computation.

Re:It's not for dumb people

[DragonWriter]

And the reality is that procedural languages better match the way the human mind works.

I don't think there is any evidence that procedural languages are easier to understand; SQL, which (like functional languages) is declarative rather than procedural seems to be at least as simple as most programming languages for even neophytes to understand.

Procedural programming is probably easier to understand if you started out for years learning procedural languages, or if you come from a hardware-centric background; OTOH, if your first experience with computer programming is spending years exclusively with functional languages, or you come to programming with a background heavy in math and formal logic, functional programming is probably fairly easy.

Re:It's not for dumb people

[OrangeTide]

That is where we disagree. I refuse to use C++ and it's crufty design in any professional project, precisely because it's a bunch of unnecessary bits tacked on that prevents it from being "small and simple".

Re:It's not for dumb people

[OrangeTide]

I'm a C# guy. To me, -everything- C++ short of the curly braces is damn ugly syntax. I can't tell whats "super ugly" and what is normal :)

How does being a "C# guy" qualify you to know what good syntax looks like? The logic just isn't there.

Oh! I just took it the wrong way, it qualifies you to know what "damn ugly syntax" looks like. Well sure I agree with you. (at least I was nice enough not to touch your "super ugly" comment)

Re:It's not for dumb people

[grumbel]

You don't need to understand stacks for that, you simply have to know that objects aren't valid beyond their scope.

Re:It's not for dumb people

[mdmkolbe]

Don't be ridiculous. Functional vs procedural isn't a matter of intelligence. It's simply a way of thinking.

And the more ways you know how to think, the smarter you'll be. Don't learn one or the other, or even both. Learn as many as you can (e.g. logic programing, meta-programing, etc.). You'll be smarter for it.

Re:It's not for dumb people

[DragonWriter]

But no sane person would believe that pure functional programming languages will every really leave their niches.

When one of your niches is "large, distributed, fault tolerant systems", you don't need to leave your niche to become more popular.

(Now, whether lazy functional programming languages will ever find niches outside of academia, much less leave their niches, remains, I think, to be seen; pure functional programming languages, OTOH, can do quite well without leaving their niches.)

Re:It's not for dumb people

[Abcd1234]

SQL, which (like functional languages) is declarative rather than procedural seems to be at least as simple as most programming languages for even neophytes to understand.

You said it yourself, SQL is declarative, not functional. But more importantly, people can think of SQL in procedural terms, which is why it's easy to understand. "Take X from table A, join it with Y in table B and pull out rows that match criteria W, U, and V".

OTOH, if your first experience with computer programming is spending years exclusively with functional languages

Sure, after spending years with any computational model, it will become natural, at least to some degree (the same is true of, say, Quantum Mechanics, but no one would call it intuitive). But I don't believe this is the case for neophytes.

See, people understand steps. They understand the idea that a computer executes instructions one after the other, and the aggregate of those steps is a software program. It's intuitive because it maps to how people think of algorithms in the real world.

Functional programming, on the other hand, has no analogy in human experience. It's an alien thought process, which is why it's difficult to grasp. Yeah, take someone with no prejudices, and I'm sure they can learn functional programming. But I maintain and procedural programming is simply more natural.

Re:It's not for dumb people

[DragonWriter]

You said it yourself, SQL is declarative, not functional.

The two are not opposed.

But more importantly, people can think of SQL in procedural terms, which is why it's easy to understand.

You can think of any set of instructions, in any model, that can be interpreted to produce a result in any paradigm in which one can design a Turing-complete language.

But, again, I don't see any support for your assertion that SQL is easy to understand because it can be thought of in procedural terms; in fact, I'd argue that SQL is useful precisely because it is easier to understand on its own than it would be to understand the necessary procedural steps to operate on the data to produce the same results, not because it can be translated into those steps.

See, people understand steps. They understand the idea that a computer executes instructions one after the other, and the aggregate of those steps is a software program. It's intuitive because it maps to how people think of algorithms in the real world.

Yes, procedural programming has a close relation to step-by-step instructions, just as functional programming has a close relation to definitions. Both are things that people commonly understand and work with in the real world.

Functional programming, on the other hand, has no analogy in human experience.

As noted above, I think this overlooks quite a lot of human experience.

Re:It's not for dumb people

[TuringTest]

And the reality is that procedural languages better match the way the trained programmers mind works.

There, fixed for you.

There's nothing natural in the "change-one-byte-at-a-time" von-Neumann bottleneck languages, other than they're the ones taught in standard programming courses.

Oh, you mean that the human mind keeps track for changes of state in the environment? Sorry to break the news to you, but that can also be done in functional languages.

Re:It's not for dumb people

[TuringTest]

>blockquote>they just don't match the normal person's mental model of computation.

That's because the "normal person" (read: normal programmer)'s mental model of computation is based on imperative languages, which are a degenerated child of Turing's calculus in which every side effect or state change is implicit in the underlying execution machine, not visible in your code.

In functional languages since the invention of the mighty Monad, side effects are again in charge of the programmer, not the platform developer. You can program in a functional language following your precious mental model of computation, it's just that the side effects are made explicit in the abstractions of your program. You can choose how many side effects will there be, and in which parts of the program they can or can't take effect. So the "sequence of states" mental model is nothing unique to imperative programs, functional programming also can do it.

(Have you heard of continuations applied to web programming, where the possible states are not lineal - but a branching tree? Functional can do "sequence of states" even better than imperative!)

Re:It's not for dumb people

[TuringTest]

Monads are a tough concept, until you realize that they serve the same concept as Inversion of Control in Object-Oriented Programming. If you have managed to do the jump from structured programming to object-oriented, you'll see that Monads are really close to Design Patterns and Aspect-Oriented Programming (the next step in OOP).

The point of monads is not to "make Input/Output wokr" or "provide exception control"; monads work for that and much more.

The real point of monads is that they are a "Structural Pattern": they serve to create the architecture of your functional program, in a way that is powerful and flexible. I like to describe them as an Abstract Data Type to abstract away computations instead of data; they're a good way to encapsulate common functionality to update your data structures, and have it triggered automatically as a side-effect instead of calling them woven with your business logic.

Re:It's not for dumb people

[TuringTest]

I suspect that one day a language more like haskell and less like C will end up being the most popular.

BTW that language may already be here. F# is Mozart in disguise - and its new computation expressions are a way to make monads palatable to C (and C#) programmers. There's no real need of strong maths to use computation expressions (although it might be required to *build* new types of computation expressions).

Re:It's not for dumb people

[TwistedSymmetry]

Nonsense. It will be called (+ c 2).

Re:It's not for dumb people

[jbolden]

grumbel already gave an example of stacks. As for the State Monad. Consider the random function. In an imperative language
random has a "global variable" which is the last random number and really looks like:

random()
new_number = function (last_number)
last_number = new_number
return new_number

Now it is pretty you could also do if you wanted by making random a function of one variable

random2(float last_number)
new_number = function (last_number)
return new_number

And then make the calling functions responsible i.e.
a = random2(global_last_number)
global_last_number = a

Now if you didn't have globals you just append a float "global_last_number" to all your data structures

and then the calls would look like:
x.global_last_number = random2(x.global_last_number)

Now image the language would take any block of code and automatically append the extra float to all the data structures. That's the state monad.

Re:It's not for dumb people

[Abcd1234]

Yes, procedural programming has a close relation to step-by-step instructions, just as functional programming has a close relation to definitions. Both are things that people commonly understand and work with in the real world.

Perhaps, but I would argue that computation by definition is not, as a general case, intuitive. *shrug* 'course, it's hard for someone to understand this when they've already trained themselves to think that way. :)

Re:It's not for dumb people

[Abcd1234]

Oh, you mean that the human mind keeps track for changes of state in the environment? Sorry to break the news to you, but that can also be done in functional languages.

No, I mean the human mind thinks in linear steps. "I do X, then I do Y, and then I do Z". Every recipe, every instruction book, every mathematical algorithm (say, factoring a quadratic equation) is represented as a linear sequence of steps. It's just the way we're wired. Frankly, I don't understand why this is such a controversial claim. Give me just one single instance of a normal, everyday situation in which humans use a functional model of computation, and I'll be quite impressed (and hopefully enlightened in the process :).

BTW, I'm quite aware that state can be modeled in functional languages. But I'd hardly call monads intuitive.

Re:It's not for dumb people

[Abcd1234]

Agreed, but I think it far more likely that features to handle parallelism will be added to existing languages, rather than a mass migration to pure functional languages, regardless of their superiority.

Re:It's not for dumb people

[Abcd1234]

That's because the "normal person" (read: normal programmer)'s mental model of computation is based on imperative languages

No, it's because the "normal person" (read: average everyday human being)'s mental model of computation is based on instruction books, recipes, lessons, etc. Humans think of algorithms in terms of steps. The jump to a functional model is just that, a leap, and it requires a drastic change in thinking. It is, in this humble programmer's opinion, highly non-intuitive (ie, it is not easily grasped without a great deal of effort), *particularly* when you have to introduce complexities such as monads simply so you can model basic stateful concepts (like I/O).

Incidentally, I realize all the advantages that functional programming offers. I'm simply saying that functional programming isn't, in general, natural.

Re:It's not for dumb people

[Abcd1234]

From my personal experience of teaching people functional programming, it's nothing to do with imperative programming matching the brain better. Instead, it's to do with people learning to write imperative programs first, and then having a very steep unlearning curve to deal with at the same time as the learning curve for functional programming.

I disagree. Which is easier, explaining Quicksort in terms of a linear sequence of steps, or using a functional declarative model? In my experience, the former wins out, hands down, as far as intuitiveness goes. Why? Because, every day, people encounter algorithms, and they are invariably expressed as a sequence of linear steps. Recipes, instruction books, knitting patterns, you name it. Thus, to understand procedural programming, they need only translate what they are already familiar with (linear algorithms) into a computational model (incidentally, this is also, I think, why recursion is so difficult for programmers to grasp at first... there is really no natural, real world example of algorithmic recursion, and so the concept is alien).

Now, maybe the people I know and interact with are just really dumb :), but that's universally been my experience.

Re:It's not for dumb people

[Abcd1234]

As noted above, I think this overlooks quite a lot of human experience.

Incidentally, I'd love to see a real world example, outside the sphere of computing, where functional computation is used. Because every algorithm I encounter out in the real world (how to look up names in a phone book, how to bake bread, how to replace a tire) is expressed as a linear sequence of steps (aka, procedurally).

Then again, maybe my view of computation is too narrow, but I think of computation as taking inputs, performing operations, and generating outputs (which maps to the various "algorithms" I listed above), and I can't think of an example, in normal human experience, where a functional programming model is used.

Re:It's not for dumb people

[Abcd1234]

Right, so that fits with my understanding. Given an operation F, you pass in some state, the operation is performed, and the output is a modified state (eg, the cursor is moved to the next line, etc). So the state is the monad? And in the case of Haskell, where is the state? Is it implicit? Explicit, and I just didn't notice it?

Incidentally, I still don't think this is terribly intuitive... I've just spent a lot of time trying to "get" it. :)

Re:It's not for dumb people

[johanatan]

Yes, I think you're exactly right. I did not even take my first programming course until freshman year of college and it was in C++. It was a couple of programs into the course before I realized that there was a strict top-down ordering of instructions (I know, in retrospect, this seems rather obvious). But, I was looking at loops and function calls as simply transformations (and the programs were so simple that they could be re-ordered without a problem).

It seems to me that functional programming is actually more intuitive, not less (especially since we teach mathematics for many years before we start teaching programming [or at least we did before computers became so ubiquitous]).

It's also a lot like using a stack-based calculator like the HP-48G. It's so much easier!

Re:It's not for dumb people

[johanatan]

Exactly. And, everyone does come from a background in math. After all, it is a required course for many years before students start a CS degree.

Re:It's not for dumb people

[TuringTest]

If you follow the link I provided above, you'll see it points to something called "do notation". In pure functional glory. Monads made intuitive (at least as much as in your preferred imperative language).

Impressed yet?

Re:It's not for dumb people

[TuringTest]

The average everyday human being don't do programming, bud.

As someone already pointed out before, the normal person also thinks of algorithms in terms of definitions; that's where functional really shines. And as I already pointed out, functional *can* represent algorithms in steps.

The only change in thinking required to understand monads is this one:
- in imperative programming, all side effects are predefined in your language's virtual machine. And you'll have unexpected side effects even where you don't want them.
- with monads, you can use the predefined side effects, or you can build your own new ones. You'll only have side effects in the places where you activate them, and the only possible side effects will be the ones that you allowed.

Other than that, code inside a monadic do-block is real imperative code. But the state handling is not hidden inside the implementation of your language, it's exposed in your program and libraries.

You can trust me, monads are not really that complex - the problem with them is than nobody teaches them in standard programming (that's because it's a too young discipline, and hasn't entered the mainstream). If you know anything about the inner workings of programming languages, monads are just a special syntax for them. The average programmer is spoiled to understand them with ease because they are rarely taught how a program is executed by the underlying machine; a monad describes how that underlying execution is carried out step by step, and allows you to change it.

Funny that you mention "basic stateful concepts (like I/O)", since your well known I/O *is a monad* at its core. You already know monads! Go figure.

With this "monads-expose-parts-of-the-virtual-machine" mindset, understanding them is not that weird.

Re:It's not for dumb people

[TuringTest]

As for an "instance of a normal, everyday situation in which humans use a functional model of computation":

SELECT Name, Age FROM My_country
WHERE Age > 18
GROUP BY Age

You'd be hard pressed to find someone thinking of the age groups in their country using a "for..next" model.

Re:It's not for dumb people

[bar-agent]

Haskell syntax looks like LISP, if you took away the parentheses, added 5 kinds of arrows, allowed random ASCII operators, and made whitespace significant. Significant whitespace sucks, custom operators suck, and LISP doesn't have enough delimiters as it is. I have to guess what stuff means in Haskell. Does not make me happy.

Re:It's not for dumb people

[jasticE]

there is really no natural, real world example of algorithmic recursion, and so the concept is alien.

I object. Recursion is a fundamental property of just about any natural language. You can make sentences infinitely long by recusively adding attributes, subsentences, clauses and whatnot.

I do agree though that the fact that many instructions are expressed in a steap-by-step manner may influence the way we think about algorithms - but it works the other way around too: If we think about algorithms as stepwise instructions, we may forget to look at them in a declarative manner, which can make such programming concepts harder to grasp if you are accustomed to the imperative style.

Re:It's not for dumb people

[pezezin]

Quicksort in C:

int partions(int l[],int low,int high)
{
    int prvotkey=l[low];
    while (low<high)
    {
        while (low<high && l[high]>=prvotkey)
            --high;
        l[low] = l[high];
        while (low<high && l[low]<=prvotkey)
            ++low;
        l[high]=l[low];
    }
 
    return low;
}
 
void qsort(int l[],int low,int high)
{
    int prvotloc;
    if(low<high)
    {
        prvotloc=partions(l,low,high);
        qsort(l,low,prvotloc-1);
        qsort(l,prvotloc+1,high);
    }
}
 
void quicksort(int l[],int n)
{
    qsort(l,0,n);
}

Quicksort in Haskell:

qsort [] = []
qsort (x:xs) = qsort lt ++ [x] ++ qsort gt
    where
    lt = filter (<x) xs
    gt = filter (>=x) xs

Now, tell me imperative version is easier to understand than the functional one.

Re:It's not for dumb people

[Abcd1234]

Well, to me, it is, although I'm obviously biased. Still, it's important to note that terseness doesn't equate to intuitiveness. Yeah, the Haskell version is shorter, but just looking at the code, I haven't a clue how it works. Worst case with the imperative version, I can take a list and walk through each step of the algorithm in order to understand what's happening. Not so with the Haskell implementation (again, at least in my mind, although it's clear it's firmly locked in the imperative world).

Re:It's not for dumb people

[Abcd1234]

You'd be hard pressed to find someone thinking of the age groups in their country using a "for..next" model.

Are you sure? When I examine an SQL statement, I specifically think about it in terms of how the data is processed. In my head, I imagine the database going through the My_Country table and pulling entries that match the select clause, then grouping them accordingly.

In short, just because the statement is declarative, doesn't mean people, in general, don't think of it in terms of a procedural, step-wise process. *You* might not, but I bet if you took a survey of 1000 programmers, a large number of them would examine SQL expressions in procedural terms.

Meanwhile, I said "normal, everyday situation", not "normal, DBA situation". :) My original point was that the human mind is strongly biased toward thinking of algorithms in an imperative mindset, and that functional thinking is atypical. Oddly, no one yet has provided an actual *real world* example of functional/declarative computation in one's everyday life. Until that example is provided, I think my point still stands: functional programming is not analogous to anything in typical human experience, and so it takes specific training and effort to think in such a model.

Re:It's not for dumb people

[Abcd1234]

The average everyday human being don't do programming, bud.

That's kinda the point. :) My original supposition was this: the human mind is better suited to thinking procedurally because that's what we encounter in everyday life.

Yes, you can train a programmer to think functionally (just like you can teach a right-handed person to use their left). But I contend that it's not immediately natural or intuitive because the human mind is accustomed to thinking procedurally. And this is why functional languages have taken a back seat to procedural ones... in the end, procedural programming is simply more intuitive.

As for definitions, as I've said elsewhere, people aren't used to defining computation in terms of definitions (which harks back to my original supposition). Find me a real world, non-computing example where people encounter a functional/declarative model, and I'll be surprised.

As for Monads, fundamentally, I think my problem is that I insist on understanding *how* and *why* mechanisms in a language work. I'm not happy just using Monads in order to activate side-effects in a pure functional language. I insist on understanding how Monads work, and why they work. Problem is, *that* isn't so easy to explain, at least in my experience (though, the fact that monads were invented by mathematicians and computing researchers probably doesn't help... far too many explanations go into the computational and algebraic theory behind monads, which I couldn't give a crap about).

Re:It's not for dumb people

[tkinnun0]

Because, every day, people encounter algorithms, and they are invariably expressed as a sequence of linear steps. Recipes, instruction books, knitting patterns, you name it.

How about "you can have dessert after you've eaten your greens"? Or "let's put socks on, then shoes".

Re:It's not for dumb people

[tkinnun0]

The average everyday human being don't do programming, bud.

If you tell a bartender what kind of a drink you want, is that programming? If you tell a robot bartender what kind of a drink you want, is that programming?

As someone already pointed out before, the normal person also thinks of algorithms in terms of definitions; that's where functional really shines. And as I already pointed out, functional *can* represent algorithms in steps.

Ok, so how would a functional algorithm to cooking oven baked salmon look like?

Re:It's not for dumb people

[tkinnun0]

If your age is 19, you're a 19-year-old, if your age is 20, you're a 20-yead-old, and so on and so on?

Re:It's not for dumb people

[CableModemSniper]

You don't even need to understand stacks to implement subroutinues, you can do it all with CPS instead.

Re:It's not for dumb people

[Anonymous Coward]

Well, noone is saying that people who program in procedural languages are dumb. People (including me) are saying that when you learn a functional language, you *open yourself to new ways of programming* also in procedural and OO languages.
I am a professional Java developer and my code style, correctness, readability and productivity have been changing *radically* once I read SICP and started learning functional languages.
There were quite a few problems that I solved in java, but with usage of elements of functional style, and I don't know how I could solve them at all if I didn't know any FP concepts. I would end up with something messy, completely not understandable and unmaintable.

Try thinking of it this way: Functional languages add another, very powerful, kind of abstraction: the abstraction of higher-order functions, which abstract away computational patterns. Adding another way of abstraction that is easy to use is a huge advantage. Think what could have been programming in C like if you removed one of its ways of abstraction - struct's.
Well, Haskell is to C like C is to C without struct's.

Re:It's not for dumb people

[pezezin]

The Haskell version is very easy to understand:

• If the list is empty, there is no need to sort it, so terminate.
• If the list has at least and element x and a tail xs:
  • Create a list with all the elements lesser than x: lt = filter (<x) xs.
  • Create a list with all the elements greater or equal than x: gt = filter (x) xs.
  • Sort them recursively, and concatenate them with x in the middle: qsort lt ++ [x] ++ qsort gt.

That's all. You may not be familiar with Haskell's syntax, but Quicksort is a recursive algorithm, so it is natural that it is better expressed with a declarative language.

Re:It's not for dumb people

[TuringTest]

When I examine an SQL statement, I specifically think about it in terms of how the data is processed.

That's because you're a programmer. I thought we were talking about "the average everyday human being" here. Or are you talking just about programmers, and all that rhetoric about "how the human mind works" was really about "what programmers in this current generation would do"? Because then you're confirming my position, that your way of thinking is something that programmers learn.

My example was meant to show how non programmers would think of the definition of a data type, and show that they would express it in terms similar to those of a functional declaration. An average person from the street (again, without training in programming) would definitely *NOT* "go through the My_Country table pulling entries that match the select clause". Only a procedural programmer would do that.

no one yet has provided an actual *real world* example of functional/declarative computation in one's everyday life

Your requirements seem contradictory. If you're talking about "one's everyday life", you can't include programming, because in the real world people don't do programming. Clarify what kind of information are you looking for, so that I can tailor an example accordingly.

Re:It's not for dumb people

[TuringTest]

If you tell a bartender what kind of a drink you want, is that programming? If you tell a robot bartender what kind of a drink you want, is that programming?

If you have to tell the bartender how the drink is made, yes. If the instructions for the drink are already known by the bartender, no.

Ok, so how would a functional algorithm to cooking oven baked salmon look like?

Exactly the same as a procedural algorithm, but wrapped in a do block. **Functional languages can do procedural programming**, that's my whole point. But they are better than imperative languages, because side effects are controled.

Re:It's not for dumb people

[Abcd1234]

That's because you're a programmer.

Heh, touche. :) Although, I would contend that, given an SQL expression and a table of data, an individual will still understand the results of that statement by performing the operations procedurally. 'course, that could be my own shortsightedness creeping through.

My example was meant to show how non programmers would think of the definition of a data type,

Interesting, I didn't see that example as defining a data type. I saw it as selecting a subset of data from a larger set. Furthermore, I don't think of declaring or defining data types as computing... in my mind, computing is the act of taking inputs, performing operations, and generating outputs. Data types are merely decorations in order to perform those tasks.

But, again, I may be betraying my own ignorance, here. It certainly seems like Ocaml, Haskell, and other languages, take datatypes to a level with which I am unfamiliar.

If you're talking about "one's everyday life", you can't include programming, because in the real world people don't do programming.

I disagree. Right now I can show you an everyday example of imperative "programming". Just go to your cupboard and pull out a cookbook. Okay, now open up your school math textbook and see how it explains to factor a quadratic equation. These things are examples of "computing" in real world... they are algorithms for completing some task.

So how 'bout a functional example where people "compute" (ie, take inputs, perform some operations, and generate outputs) in a functional sense?

Re:It's not for dumb people

[TuringTest]

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).

Re:It's not for dumb people

[TuringTest]

Interesting, I didn't see that example as defining a data type. I saw it as selecting a subset of data from a larger set.
Yes, that's the typical usage of SELECT. But in this case the GROUP BY creates a classification of the data selected, so that the different subsets created have a meaning. It would have been clearer if I knew how to create groups by age brackets in SQL. :-)

Furthermore, I don't think of declaring or defining data types as computing... in my mind, computing is the act of taking inputs, performing operations, and generating outputs. Data types are merely decorations in order to perform those tasks.

But, again, I may be betraying my own ignorance, here. It certainly seems like Ocaml, Haskell, and other languages, take datatypes to a level with which I am unfamiliar.
I think you might have hit an important intuition here. You're on the right track: for programmers with a mathematician mind, programming is the accurate description of data transformations. The changes in state are not that important - if you can describe with precision the relation between input and output, there's no need to know the intermediate operations. Datatypes are a basic building block in that process. The whole SQL language was designed with that intention: you shouldn't need to know how the data is retrieved from the database, just what form and properties will it take after the query ends.

Functional languages often follow the same philosophy (that's why their programs are often called 'declarative'). After you get right the definition of something (say, a type of object in your application), you no longer need to know the details of the definition - you can use that object as an atomic element, a primitive of the language. Imperative languages tried to achieve the same result with encapsulation and structured programming, but the process is not as transparent because the definitions often break due to side effects.

In functional programming you control and limit (or even forbid) the side effects, so you can take care yourself that they never break your encapsulated definitions. So there's no limit to what you can define - you can mix more and more elements to build higher and more complex abstractions.

Does it make any sense to you?

So how 'bout a functional example where people "compute" (ie, take inputs, perform some operations, and generate outputs) in a functional sense?

With this in mind, any example where people think of getting "something new" from "something old", without taking care of the steps by which the new thing is done, would be an example of functional thinking. An example: I pay an accountant to calculate my taxes, and I get all the paperwork solved. Or I press a button on the wall, and my living room is lit. Equations or wiring are not something a normal person would care in those situations - just the desired functions and the requirements to have them executed.

That's also the reason when something breaks (I press the button, but there's no light) people doesn't know what to do: I've fulfilled all the requirements (pressed the switch), why I don't have the result? Since the inner working is not known, that person won't know which of the intermediate operations is failing, so they can't make a correct diagnosis.

Re:It's not for dumb people

[jbolden]

Right, so that fits with my understanding. Given an operation F, you pass in some state, the operation is performed, and the output is a modified state (eg, the cursor is moved to the next line, etc). So the state is the monad?

No. Remember you asked me how to use monads. Trying to understand them is what makes them hard. Now image the language would take any block of code and automatically append the extra float to all the data structures. That's the state monad. That is the State monad / Random number monad is the monad that appends that extra float to all your data structures and makes sure all your functions pass them back properly so you don't have to write any code to allow for random numbers. That is you write your code as if you didn't need random numbers and just "lift it" via. the monad.

Remember in Haskell there is no "then". You are not assured when things happen (except for ordering monads like I/O). You simply tell it function f needs values a,b, and c computed and it is none of your business what gets computed when. The state monad / random number monad will take care of making sure that each generated random number gets used only once behind the scenes. The same way the random function does in your current language.

And in the case of Haskell, where is the state? Is it implicit? Explicit, and I just didn't notice it?

Explicit in the monad but not present in the rest of the code at all.

Incidentally, I still don't think this is terribly intuitive... I've just spent a lot of time trying to "get" it. :)

I think you get it. You just don't believe me yet that it can be this easy.

Re:It's not for dumb people

[DragonWriter]

Perhaps, but I would argue that computation by definition is not, as a general case, intuitive.

And I would argue that you are right, only because nothing is, as a general case, intuitive. What is intuitive is a function of personal experience and background. As in many other areas, one size does not fit all.

Re:It's not for dumb people

[IpalindromeI]

Honestly, the most difficult part of monads is that everyone thinks they're so hard to understand. The stigma that it's some hugely complicated mathematical concept is getting in everyone's way.

Monads in Haskell are basically just wrappers. Here's a straightforward explanation by someone much smarter than me: You could have invented monads

Lazy disfunctional language

[Anonymous Coward]

Slashcode.

uniq: command not found

Yes. Lazy Functional Programming Language...

[Anonymous Coward]

And it is a suck-up functional programming language.

The output of all my Haskell programs is: "Gee Mrs. Cleaver. You look nice today."

Re:Yes. Lazy Functional Programming Language...

[stoolpigeon]

so I'm not the only one thinking along those lines - good to know.

Holy Crap!

[CSMatt]

13 pages? And no print version? No wonder no one reads articles on Slashdot.

Favorite word?

[octothorpe99]

Seems like "interesting" is the author's favorite word

Why "lazy"?

[VoyagerRadio]

Why are they referred to as "lazy"? Is it simply because their have a singular purpose, (usually) unable to multitask?

Re:Why "lazy"?

[tuffy]

They're "lazy" because they don't do any work until necessary. For example, a function can return an infinitely long list, but only the elements you request will actually be calculated. Or, to compare them to Python, it's like having everything function like an iterator.

Re:Why "lazy"?

[Anonymous Coward]

The "lazy" attribute means the language won't do anything until it's absolutely necessary.

This allows us to store infinite lists and only access the elements of it we need. The best example is the Fibonacci Sequence (i know, not useful, but portrays the point):

> let fibs = 1 : 1 : zipWith (+) fibs (tail fibs)

If we want the first 100, we can use a statement like this:

> take 100 fibs

It really adds a lot to your tool set when programming.

Re:Why "lazy"?

[Anonymous Coward]

See Lazy evaluation, which says:

In computer programming, lazy evaluation (or delayed evaluation) is the technique of delaying a computation until such time as the result of the computation is known to be needed.

Consider a function that may or may not use one of the parameters you pass to it. In a language with lazy evaluation, there is no cost to passing the result of a lengthy expression to that function if the function never reads the result.

For example, MaybePrint( DoSomethingVeryExpensive() ). The expensive part is never evaluated if the MaybePrint function doesn't decide it needs to print the result.

Re:Why "lazy"?

[Anonymous Coward]

Laziness has nothing to do with multitasking.
It refers to 'lazy' parameter evaluation; this means parameters to a function are only evaluated if they are actually needed. The opposite is 'eager', which is the way almost all other languages work, ie. all parameters are evaluated _before_ the function is called, regardless of whether they're actually used in the function or not.

Re:Why "lazy"?

[nabsltd]

I don't see the point at all.

int fib(int x)
{
int fib1 = 0, fib2 = 1;
for (int i = x; i > 0; i--)
{
int temp = fib1 + fib2;
fib1 = fib2;
fib2 = temp;
}

return fib2;
}

int bignum = fib(100);

This function is just as "lazy" in that until the call to it, nothing is calculated, and only the minimum required work is done.

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.

Re:Why "lazy"?

[mgiuca]

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 ;)

Re:Why "lazy"?

[Anonymous Coward]

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 ;)

This is something I've heard touted as a major selling point of functional languages, but it's never made sense to me. In both cases, you have to define the calculation to generate elements of the list.

Re:Why "lazy"?

[DragonWriter]

This is something I've heard touted as a major selling point of functional languages, but it's never made sense to me. In both cases, you have to define the calculation to generate elements of the list.

In Haskell-like functional languages, where side effects can be avoided without surprise, its possible to be declarative rather than procedural in how you "define the calculation"; this doesn't stop you from having to describe something, but often produces more definitions that are both more compact and more clear (in a "what are you getting" sense, not a "what is the computer going to do to get it" sense). This advantage of declarative programming is a big reason why SQL is useful; expressing simple concepts that have simple expressions in SQL in a procedural language is often less than straightforward. Lazy functional languages, though structurally different than SQL and having this advantage in, usually, different use cases than SQL, have the same kind of advantage in terms of declarative programming.

Re:Why "lazy"?

[feldicus]

That really seems like splitting hairs to me, but maybe there's a flash of light that hasn't hit me. In both cases, you're describing the steps required to calculate something; the difference is that Haskell looks like it lets you assume or not bother with things you might have to worry about if the same thing was being written in something like C++.

I've always been fascinated with the ideas behind functional programming, but every time I try to learn it, I'm immediately struck by the complete mental disconnect needed to stop thinking about problems from an imperative or OO-based perspective. I've learned enough Python to use it for quick prototyping and testing, and I managed to get far enough into Lisp to realize it wasn't made for humans, but my one foray into Haskell was roughly equivalent to having the math team from my high school kick me repeatedly in the head while shouting, "WHY DON'T YOU GET THIS? THIS IS EASY! YOU MUST BE A RETARD!"

feldicus

Re:Why "lazy"?

[grumbel]

Very simple example try to call a function, like say "sin(45)", in a language with side effects like C the code has to be evaluated at runtime, in a language without side-effects it is trivial to prove that the return value is always the same and thus the compiler can simply insert the result into the code by evaluating it once at compile time and never at runtime. Since you don't have side effects the compiler has a much easier job at optimizing things than a compiler in a language with side-effects, because it can't guarantee that changing the order of two procedure calls will lead the same result. This by the way has nothing to do with the language being lazy, such optimization would work just as well in a non-lazy functional languages.

One of the main issue with C is simply that it just one step away from assembler, you tell the computer not only what you want, but also how you want it to be done, so a C optimizer can only optimize things in such a way that is guaranteed to not change the result and figuring that out is pretty hard or even impossible due to all the side effects.

Re:Why "lazy"?

[DragonWriter]

That really seems like splitting hairs to me, but maybe there's a flash of light that hasn't hit me. In both cases, you're describing the steps required to calculate something; the difference is that Haskell looks like it lets you assume or not bother with things you might have to worry about if the same thing was being written in something like C++.

That's pretty much exactly the advantage of programming in a more declarative style, which is one of the big draws of functional programming (not the only one, but one of them.) I mean, really, in Turing-complete languages, the only possible meaningful distinctions are:
(1) Expressiveness,
(2) Library support, and
(3) Performance.

Enabling more declarative programming is an advantage in #1.

I've always been fascinated with the ideas behind functional programming, but every time I try to learn it, I'm immediately struck by the complete mental disconnect needed to stop thinking about problems from an imperative or OO-based perspective. I've learned enough Python to use it for quick prototyping and testing, and I managed to get far enough into Lisp to realize it wasn't made for humans, but my one foray into Haskell was roughly equivalent to having the math team from my high school kick me repeatedly in the head while shouting, "WHY DON'T YOU GET THIS? THIS IS EASY! YOU MUST BE A RETARD!"

Something about Haskell's syntax, or maybe just the presentation of the tutorials I've found, gets in my way, too.

Re:Why "lazy"?

[KagakuNinja]

In C, the programmer can realize that sin(45) is a constant and inline the value by hand. While it would be nice for the compiler to figure this out, I don't see it as a big gain. I'm sure languages like Haskell can evaluate chains of statements and function calls and determine that ultimately the result is a constant. This might be cool, however I have yet to write a significant program where this would be the case.

My vague understanding of functional languages, is that I/O functions have side effects, hence their historical problems in dealing with I/O. Writing programs with highly constrained I/O is of little interest to real world programmers (outside of a few niche fields).

Re:Why "lazy"?

[feldicus]

That's true to a point, but at some point, you risk making each line of code too dense. Content density is a tricky thing, and something that can very easily be used in a nefarious manner. A lot of the examples I've seen have done in one line what might take me ten or twenty lines of C++ or C#.

If I know the language, then extracting information from a given line is a lot easier than someone looking at it with little or no concept of the syntax. I've tried learning Haskell, so I'm not completely unexposed, but
let fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
Is not trivial for me to parse. I don't think that the difficulty lies entirely on my side, either. I managed to get to the point that I could write some pet projects in Lisp, and that wasn't easy, despite Mr. Graham's protestations to the contrary. I think part of the problem is that Haskell's syntax just differs a lot more from my standard fare than other languages.

feldicus

Re:Why "lazy"?

[TuringTest]

You're right about the density of code; but that's a property of the programmer,, not the language.

Re:Why "lazy"?

[TuringTest]

The I/O problem has been solved. Modern functional languages have nothing to envy from procedural ones; and the reverse is not true. Nowadays functional languages manage state changes much better than imperative ones (specially when dealing with concurrency i.e. multiprocessors and networks).

Re:Why "lazy"?

[SrgntJack]

This function is just as "lazy" in that until the call to it, nothing is calculated, and only the minimum required work is done.

You're missing the point entirely.

The definition of a strict function is one where

f _|_ = _|_

Where the funny "_|_" symbol means "bottom," i.e. the system might diverge, error unrecoverably or do any number of things, but these are things you generally don't want to happen.

In most languages you are used to functions for example, evaluating their parameters "inside out," meaning in a call like

f (g x) (h y)

where

f x y = x + y

You first evaluate 'g x', then 'h y' and finally you evaluate 'f' with the results of those two evaluations. In contrast with a lazy language, functions evaluate "outside in" meaning that in the above call, you immediately call f and in the body of f, we only evaluate the 'x' and 'y' parameters if their value is forced, i.e. its concrete representation is needed (for example being printed.)

In haskell functions are not only lazy, all values are lazy by default. The result of a function is lazy, any regular computation is lazy. But what does this buy us?

It gets us a cleaner separation of concerns and laziness buys you modularity, basically.

Take for example the completely contrived function:

tenEvenNums = take 10 (filter even [1..])

The important thing here is that with laziness, the generation of the infinite list of 1 to infinity is separated from the consumption of the list by functions take, filter and even (take takes n elements from a list, even returns true/false if a number is even/odd, and filter takes a list and returns a new list based on a predicate.) The entire definition is just built up from a few compositions and nothing else.

Laziness gives us a powerful glue to compose functions and re-use them. Contrast this with the C version of the same thing:

int tenEvenNums(int *arr) {
    int i;
    int j;

    for(i = 1, j = 0; j < 10; i++)
        if(i % 2 == 0)
            arr[j++] = i;

    return 0;
}

Note there is no longer as clean a separation of concerns - we must consume and prune the values at the same time we generate them. This isn't as good for modularity because we can't as easily abstract out the more common parts like we can when we're lazy - it wouldn't be possible in this instance to have one function which generates the infinite list; C is strict, so it'd just be an infinite loop.

Like I said this example is extremely contrived but it conveys the point that when you're lazy it's a whole lot easier to build functions out of smaller, more general functions (generality has a bit to do with the type system, however.) When dealing with larger blocks of code this can be more and more important, because if you're lazy (and by association also pure since laziness and impurity don't at all mix in any way,) it's a whole lot easier to glue functions together rather than repeating common things so much.

I recommend you go read "Why Functional Programming Matters" by Hughs for a more in-depth treatment, and it also covers HOFs which are also quite great.

Re:Why "lazy"?

[feldicus]

I don't know. The programmer in question has a lot to do with it, but it seems like some languages lend themselves to certain densities.

feldicus

Re:Why "lazy"?

[grumbel]

In C, the programmer can realize that sin(45) is a constant and inline the value by hand.

Thats just a trivial example. The whole point is simply that lack of side-effects makes the optimization far easier and gives the compiler far more freedom in what it can do to make the code fast. Of course you can do that all by hand in C or Assembler or whatever, but the whole point of programming languages is that you can describe your problems at a higher level and let the compiler do the grunt work.

Re:Why "lazy"?

[Anonymous Coward]

And laziness is what's really stunning about Haskell. I saw a Haskell program to once that involving file management. In essence, it defined an array of every file on the hard drive and inside that an array of every word in each file. A few basic definitions, and they were accessing these data structures as if they actually existed. Haskell loads the parts you interact with "just in time" and just makes the abstraction work.

Re:Why "lazy"?

[BollocksToThis]

f _|_ = _|_

Where the funny "_|_" symbol means "bottom,"

Oh, so you meant:

f (_|_) = (_|_)

Re:Why "lazy"?

[nabsltd]

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.

So, basically, if you do want to do something that actually approaches infinite (say the 1,000,000,000th Fibonacci number), Haskell will croak trying to keep all one billion numbers of the list around, while other languages will just output the result (although it would take a fairly long time, I suspect).

I'm sure that a "good" Haskell implementation will not actually roll over and die given this sort of request, but it would have to throw away most (if not all) of the list, thus making it pretty much like other languages.

So, it's a language for defining "infinite" data structures and not blowing up at the point of definition, but when it comes to actually executing with truly large datasets, it suffers the same problems as every other language.

Re:Why "lazy"?

[mgiuca]

So, basically, if you do want to do something that actually approaches infinite (say the 1,000,000,000th Fibonacci number), Haskell will croak trying to keep all one billion numbers of the list around, while other languages will just output the result (although it would take a fairly long time, I suspect).

Uh, yes, I believe that's the gist of it. And no, I don't think a "good" Haskell implementation can really throw them away, in case you need to use it again (though a really good static analysis possibly could throw it away on the last usage).

As I said, it was probably a bad example. What this stuff is good for is the dynamic programming where you actually do need to explicitly track the other data elements. Haskell will of course also allow you to write an explicit version which works exactly like your C version.

But yes, the point of this is not to make things more efficient, but make them more elegant from the programmer's point of view. (Though as a programmer I think I'd rather have explicit control of my data structures than mathematical elegance -- I'm not defending Haskell, just explaining it).

Re:Why "lazy"?

[TedRiot]

This is one of the very few times I really, REALLY wish I had modpoints. :)

Re:Use the handicapped stall

[Anonymous Coward]

for me to poop in!

Rule?

[MadKeithV]

This must be some use of the word "rule" that I was previously unaware of!

Re:Use the handicapped stall

[Anonymous Coward]

Wherever you are is the handicapped stall by definition. Now go back to sleep.

Erlang

[Anonymous Coward]

This is why I've started to learn Erlang. ;)

Awesome Article

[theverylastperson]

The first 4 pages are a nice look at the history of Haskell (which I knew nothing about). The rest of the article gets a little technical for someone with no experience or real world understanding of it.

When I saw the size of the article it was a little intimidating, but there is a wealth of information in it and by the end I found myself googling for more.

How widely used is Haskell?

What a crock of shit.

[Anonymous Coward]

"Unfortunately it makes it almost impossible to do things they didn't expect"

Name just ONE such thing. This is FUD, plain and simple. And it doesn't look like you've ever even learned haskell to be making such claims.

"A separate, but related problem is that the community doesn't seem interested in practical use of it"

Yeah, nobody is doing practical stuff like writing the best X11 window manager ever, or an extensible editor, or web application servers, or IRC bots or distributed version control systems in haskell. Oh wait, that's exactly what people are doing. Oops, you are a liar!

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

Maybe not as many as perl, but easily just as many as ruby. There's tons in hackage.

"Heck, even doing i/o at all isn't really supported very well"

Are you fucking kidding me? Clearly you have never bothered to try and are just repeating bullshit you heard trolls spew. I/O is simple and easy, and it even uses a familiar imperative style syntax.

"Functional programming is very good for the pure computer science part of programming, but unfortunately that's going to make up less than half of any given program. You also need to be able to interface."

Actually, most people realize when they try that about 90% of their program can be pure functional code with far fewer bugs and much easier to maintain code. So they write the core program in nice pure functional haskell, and then write the 10% in haskell as well using the imperative style syntax for monads. See xmonad for a good example of this approach, and how stable the resulting wm has been as a result.

Re:What a crock of shit.

[m50d]

What's with all the swearing and insults? Guess I must've hit too close to home.

Re:What a crock of shit.

[Anonymous Coward]

Responds to irrelevant detail.
Completely ignores facts and neglects to substantiate his assertions.

Would you like to be a little more obvious? Perhaps you could stick "I am trolling" in your sig.

Re:What a crock of shit.

[m50d]

Responds to irrelevant detail.

Hardly irrelevant; I'm happy to reply to those interested in polite discussion, but someone who'll sit there anonymously and call me a liar isn't worth trying to be reasonable with.

Perhaps you could stick "I am trolling" in your sig.

Sure, why not.

one of the best practices

[fermion]

At least since the late 70's, and certainly through the 80's, one of the best practices was functions that had limited scope and data knowledge. Of course this was codified into OO languages, but even in old style languages it was always bad to know too much or make too many assumptions about what was going on elsewhere.

We can see this philosophy in C where, except where huge data structures are involved, it is best to make a copy of data rather than work to work on someone else's copy. Likewise functions do one thing, do it well, and, again except for huge data structures, return a copy. Memory is manually allocated, and deallocated, possibly from the functions local heap.

It is interesting to me how it all comes back to just best practices. Make sure you know how much memory you need. Make sure you are only doing what needs to be done right now. Make sure the interfaces are clear. If data is ready, then it should be ok to work on it. To me functional programming is what happens after data models, or objects, are defined. Once the data structure is defined, you can treat it as stateless immutable input. Output is a another structure. Again, the only limitation is if the object is so large that duplicating become a cost performance issue.

Re:one of the best practices

[JasterBobaMereel]

We need a simple language - C
This OO thing is nice - C++
This Virtual machine thing is nice - C#
Lazy Functional languages are nice - C@ ?

If in doubt bolt it onto C ... ;-)

probably because...

[Anonymous Coward]

most of us are lazy but functional also.

Interview

[kabloom]

It figures that this article would be an interview. That way Simon Peyton-Jones didn't need to evaluate the answer to any question until it was asked.

Haskell is fun, but painful for procedural code...

[Tetsujin]

Features of Haskell I really enjoy are how it handles constructors, pattern-matched function arguments, user-definable infix operators (with configurable precedence!) and the way it handles higher-order programming and lazy programming. But I never got monads...

Of course, my philosophy is that that's not necessarily a bad thing. Haskell is, IMO, a domain-specific language specialized on functional problems. I feel it's better to have different specialized languages working together well, rather than have one that attempts to do everything...

A broader perspective

[Weasel Boy]

Just because a language is not widely used outside academia does not mean it isn't a good teaching tool. You can pick up a new language in a few weeks, but a strong understanding of the fundamentals lasts forever. In a teaching setting, you want a language and dev tools that do not get in the way of illustrating the concepts.

At my university, a professor chose C++ to teach computational linguistics to non-programmers. HUGE mistake! We spent about 80% of the course learning C++ badly, rather than linguistics well. The CS department, wisely I think, taught its newbies in LISP.

Lazy Functional vs Lisp?

[rolfwind]

What's the difference between a functional language like Lisp and a lazy functional language?

Just asking.

Re:Lazy Functional vs Lisp?

[clampolo]

Lazy evaluation means that a value won't be calculated until it is absolutely necessary. So in the example in the above discussion, you can make things like an array of all the Fibonacci numbers. This works because the environment won't actually calculate anything until it is necessary.

Lisp doesn't support this behavior by default. In LISP all function arguments are evaluated left to right. Although using macros, you could probably write your own lazy evaluation mechanism.

Re:Lazy Functional vs Lisp?

[mdmkolbe]

In a lazy language (more properly called "call-by-need"), every expression has a thunk wrapped around it and thunks are automatically forced. (They have thunks in Lisp/Scheme but they must be explicit rather than implicit.)

Lazy languages allow you to "use" values that haven't been defined yet. For example

a = 1 : b
b = 2 : a

Which would produce two lists of alternating ones and twos (a starts with 1 and b starts with 2; also ":" is infix "cons").

In Scheme (which I know better than Lisp), you could accomplish the same with

(let ( [a (cons 1 #f)]
[b (cons 2 #f)])
(set-cdr! a b)
(set-cdr! b a)
...)

But being lazy (1) frees you from thinking about order of evaluation and (2) allows some constructs to be expressed more easily (e.g. taking the fixed point of a composition of functions (example to complicated to post here)).

At the end of the day, any program written in one style can be written in the other so its all differences of ease and different ways of thinking about the program.

Re:Lazy Functional vs Lisp?

[tripa]

In Common Lisp, the reader lets you enter one directly:

#1=(1 2 . #1#)

Oh my god!

[Vexorian]

Could this be the year of Haskell in the developer's tool box?

Combinatorial Parsers, etc.

[Tetsujin]

One thing in Haskell that always intrigued me was the idea of combinatorial parsers - a parser that accepts a string and yields not a single parse tree, but all possible parse trees based on the language rules... Simple implementations of those can be implemented in Haskell pretty straightforwardly. Combinatorial parsers for individual rules are stuck together - and while rules may generate a bunch of possible parse trees these are culled by successive rules...

I don't know too much about the practical efficiency of these - but in terms of how they're expressed I think they're great...

Re:Combinatorial Parsers, etc.

[mdmkolbe]

I don't know too much about the practical efficiency of these

Time to write the passer for a medium sized language (Java sized) with yacc or Antler: 2 weeks.

Time to write it in Parsec (based on parser combinators): one afternoon.

(*) These are actual times from an actual project and anecdotally seem to be typical. However, this might not have to do with Parsec being combinator based (though the anecdotes suggest that); it might be that Parsec is simply better designed.

Re:Combinatorial Parsers, etc.

[Tetsujin]

I don't know too much about the practical efficiency of these

Time to write the passer for a medium sized language (Java sized) with yacc or Antler: 2 weeks.

Time to write it in Parsec (based on parser combinators): one afternoon.

By "practical efficiency" I meant runtime efficiency... Wasn't trying to raise doubt, I just couldn't personally vouch for the efficiency of combinatorial parsers (especially unoptimized ones), you know?

I will have to give Parsec a spin one of these days... Combinatorial parsers have intrigued me since I learned about 'em, but I haven't used them much for anything.

Re:Combinatorial Parsers, etc.

[mdmkolbe]

By "practical efficiency" I meant runtime efficiency... Wasn't trying to raise doubt, I just couldn't personally vouch for the efficiency of combinatorial parsers (especially unoptimized ones), you know?

There are two halves to that question: asymptotic performance and how big is the constant on real problems.

As to the first I believe Parsec and most other combinator libraries are LL and are usually (*) linear in the size of the string being parsed.

As to the second, I would have no idea, though I would hazard to guess that on modern CPU's parse times are fast enough that the relative efficiencies don't matter that much (unless maybe you're parsing Ethernet frames on a busy server).

Finally I should note that while Parsec is the most well known parser combinator library (and the only one I've actually used), the number of parser combinator libraries seems to have exploded in the past couple years so there may be better ones than Parsec out there now.

(*) "Usually" assumes you have a deterministic CFG and no back-tracking. Non-deterministic CFG's are nessisarily somewhere(**) between O(n^2) and O(n^3) though practically speaking sub-cubic algorithms have too high of constants to pay off.

(**) Exactly where between O(n^3) and O(n^2) is (very important) open research. Any technique that will improve the asymptotic performance of CFG parsing will improve the performance of matrix multiplication which will improve the performance of half the scientific computing programs out there. This in turn helps weather forecasting, structural engineering simulations, semiconductor design, etc.

Re:Use the handicapped stall

[Anonymous Coward]

And eat up after licking my fingers clean of poo-dinglers!

The lazy language

[jd]

...is the one with the newspaper over its face, snoring in the corner, cans of soda piled up on the desk. The functional language is the one that has finished psychotherapy, is fully alert and active, and has a far higher risk of suffering a heart attack from overwork.

Arrrr, it's Stephenson again!

[Mr. Underbridge]

I haven't really been able to figure out how to do anything significant in Haskell. But I suspect that one day a language more like haskell and less like C will end up being the most popular. Monads and all that kind of confuses me.I think it helps if you have a strong math background and are comfortable with Lambda calculus.

Monads, lambda, calculs...arrr, matey, now I know why Haskell's such a bloody mess - Neal Stephenson wrote it! That be why it seems good at first and falls apart at the end.

Except...

[Anonymous Coward]

the fib example given isn't tail recursive. Actually, it's usually not a good idea to use tail recursion in Haskell since it can force you into strict evaluation when you don't need it.

Mmmm, Kay-Stigma.

[Anonymous Coward]

I wouldn't say it's just slashdot. Functional languages have always had a stigma about them. Why else do you think "C took off so much?

I don't want some lazy programming language!

[frank_adrian314159]

I want one that will work hard for me!

Your example really sucks.

[Medievalist]

I have never found any practical use for the Fibonacci sequence. Ever. Not even for modeling snail shell formation for a malacologist, where you'd think it would be handy.

How do you parse a free form string that contains a person's name, typed in by someone being paid minimum wage, and determine the the probability that the name matches input from a cheap microphone? That's a better example, show me how Haskell makes that easier than some other language.

The C in GHC...

[Tetsujin]

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'"?

Haskell rocks.

[Anonymous Coward]

Ill tell you from experience that while Haskell may be difficult to pick up and program efficiently in, if your program is going to be multi-threaded and ran on multiple processors it will be much safer, easier to debug, and less likely to run across nasty race conditions. With the push for these types of applications the move to functional languages is not very surprising, and although there is a slight performance loss to a language like C++ the ability to run reliably on multiple cores or an distributed array of servers kinda makes up for it.

How is X better than Y?

[Tetsujin]

Actually, when you're able to do it naturally in your language, it becomes a very useful thing to do. For example, when you want fresh variables in a compiler

How is that better than doing (or basically the same in Java/C/perl/ruby/etc.):

__compiler_var_num = 0
def next_fresh_variable():
  global __compiler_var_num
  __compiler_var_num += 1
  return "_id_%d" % __compiler_var_num

I hate to say "you're missing the point" because I feel that's unreasonably dismissive - though I kind of feel you are...

IMO the point isn't necessarily that one method is "better" than another - it's that this idea represents an important and useful way of approaching programming problems. If you understand the style you can appropriate it - it becomes a useful concept for expressing problems and their solutions.

So for instance - while you may not use recursion in C for general problem solving (due to the lack of tail-recursion optimizations which turn the thing into a loop) - understanding the recursive expression of a problem is useful for structuring your solutions, understanding what assertions must be made with respect to the state of the data at what points in the code, etc. - even if you structure your solution as a loop rather than a recursion.

And it should be noted that you can implement infinite sequences in C++, etc. - generally the way to do this is with iterators, and the use case would be for feeding those iterators to algorithms that expect iterators... What Haskell brings to the table is that it encourages you to think of problems and solutions in those terms - learn the method and what you can do with it, how it affects the expression of your code - if you find it a useful idea it's easy enough to implement in most object-oriented languages...

Re:How is X better than Y?

[jonaskoelker]

So for instance - while you may not use recursion in C for general problem solving (due to the lack of tail-recursion optimizations which turn the thing into a loop)

If you read the gcc man page, you will learn that -foptimize-sibling-calls enables sibling and tail call optimization, and is enabled on -O2, -O3 and -Os :)

-- Jonas K

Re:How is X better than Y?

[Pseudonym]

Sadly, that rarely works in C++ due to the semantics of auto-variable destructors. Still, understanding recursion is vital for C++ programming, too.

Re:How is X better than Y?

[johanatan]

And it should be noted that you can implement infinite sequences in C++, etc. - generally the way to do this is with iterators, and the use case would be for feeding those iterators to algorithms that expect iterators... What Haskell brings to the table is that it encourages you to think of problems and solutions in those terms - learn the method and what you can do with it, how it affects the expression of your code - if you find it a useful idea it's easy enough to implement in most object-oriented languages...

And, I would add that modern C++ programming in fact encourages this style of programming. Take a look at Alexandrescu's _Modern C++_ for more info. All of the good C++ programmers these days are doing lots of generic and functional programming and even C#/.NET now has LINQ.

There are a couple of big differences between C++ and Haskell though.

• Syntax. Haskell is much tighter.

• Automation. C++ is still an imperative language so you're still required to drive (i.e., implement yourself) such things as lazy evaluation if you want that.

Software Engineering Mantra

[fartrader]

The key to being a good software engineer is doing just enough to get paid. This is too much.

Be professional. Write simple. Be understandable. Recursion as a primary control structure violates at least two of the latter.

Re:Software Engineering Mantra

[Anonymous Coward]

So you'd not do recursion for iterating the elements of a tree in some order?

Re:Use the handicapped stall

[Anonymous Coward]

Ironically, the metaphor made here works... While vulgar (and therefore maybe flamebait,) it's not really off topic.

quantification of productivity

[j1m 5n0w]

The same way they should measure the productivity of any team of programmers: are they able to solve the problem they're given within time and budget constraints. "Lines of code" is not a good measure of productivity in any language.

fast functional languages

[speedtux]

There have been functional programming languages that actually work well for high performance computing. One of them is called SISAL. Unfortunately, the FP community didn't care and SISAL's funding was canceled.

Haskell is largely an academic exercise: cute but hard to use and slow. Functional programming will become ever more important in the future, but it won't look anything like Haskell when it meets the real world.

Re:fast functional languages

[DragonWriter]

Functional programming will become ever more important in the future, but it won't look anything like Haskell when it meets the real world.

Functional, even purely functional, programming languages have already "hit the real world". Erlang is purely functional, and came out of industry.

Lazy functional languages haven't, that I'm aware of, hit their stride in much serious application, but explicit laziness is often easy to add, where it is useful, to other languages, so the big question is whether universal laziness (or even just laziness-by-default) brings enough benefit to make it superior to explicit laziness.

Re:fast functional languages

[speedtux]

A few deployed applications doesn't make a programming language "real world"; there have been far more successful functional programming languages than Erlang, and they are still not considered mainstream.

The distinction between lazy and non-lazy functional programming languages is also not as clearcut as you seem to think; hence, my comment that functional programming languages will not look like Haskell; Haskell's approach to laziness is one of its (many) problems.

Re:fast functional languages

[DragonWriter]

A few deployed applications doesn't make a programming language "real world"; there have been far more successful functional programming languages than Erlang, and they are still not considered mainstream.

"Mainstream" and "real world" are two very different terms. I would argue that a language (like Erlang) that is well-established in a particular industry niche has hit the "real world", whether or not it is "mainstream". There are certainly more widely used functional languages than Erlang, though most of them are not pure functional languages, and that raises the question of where you draw the line between non-pure functional languages and languages that have functional features but aren't primarily functional (does Ruby count as "functional" language?).

The distinction between lazy and non-lazy functional programming languages is also not as clearcut as you seem to think;

You seem to have missed (hard to do in such a small post, I would have thought) where I pointed out that the distinction is not particularly crisp since laziness is easily implemented in language that aren't inherently "lazy" in the sense that Haskell is, including (but not limited to) other functional languages. In fact, since that's the only thing I said about the distinction, I have no idea where you got the idea that I think the distinction is "clearcut".

They can be useful for testing worse cases

[Sits]

I've seen the Fibonacci sequence used to show worst case input scenario in at least one algorithm.

Re:They can be useful for testing worse cases

[Pseudonym]

It's a pessimal case for Huffman codes.

Re:They can be useful for testing worse cases

[Sits]

Thanks for following up - I'd been flipping through algorithms books looking for this : )

try something real for a change

[speedtux]

Yes, and now, why don't you write something that computes a digital filter over an audio signal in Haskell and compare its performance and resource usage to the C version. Spend as much time as you like. It's infinite streams, it's recursive, it should be easy, right?

No matter how much time you invest, you cannot get Haskell code to run as fast as well-written C code; not even close.

The problem with languages like Haskell is that they make easy things easier, and the stuff that actually takes development time in real-world systems hard or impossible.

I wish there were high performance functional programming languages, I really do. But people like the Haskell developers have always ignored those needs. Until language designers like that start taking real world needs seriously, FP will not catch on.

Re:try something real for a change

[DragonWriter]

No matter how much time you invest, you cannot get Haskell code to run as fast as well-written C code; not even close.

The problem with languages like Haskell is that they make easy things easier, and the stuff that actually takes development time in real-world systems hard or impossible.

The stuff that actually takes development time is often getting correctly functioning code in place (and then doing that again when requirements change); expressiveness in functional languages can help that.

Now, in some cases, lots of development time goes in to speed optimization, and in those cases your criticism would seem to be on point, but that doesn't seem to be the main place that development time gets consumed in most projects.

Re:try something real for a change

[speedtux]

It's true that correctness is harder in C than in Haskell. But a correct program that doesn't meet performance requirements is useless, and Haskell and similar languages lack the primitives to ensure that you can make software run fast after you got it correct. That's not because it's impossible, it's because the people developing Haskell and similar languages simply don't seem to care (this has been going on for at least thirty years).

That's why most people who like FP (including myself) have resigned themselves to using a mix of scripting languages like Python, that offer some FP support, with C/C++ code.

Re:try something real for a change

[ThePhilips]

I second.

Functional languages are fun and very nice. But they also have major problems when it comes to resource management, since they try to distant programmer from it (== "lazy programming").

And I'd really love to have some Haskel analog for high-performance needs.

In past my friend went from Prolog to C++ (went from academia to real world: there were nobody to pay for expensive Prolog compiler license) and after rewriting his stuff in C though he has noticed that performance dropped he also noticed that memory consumption dropped by factor of four - allowing him to easily cram more optimizations into C++ code making it (with gcc) about twice as fast as Prolog version with some high end highly parallelizing compiler.

And now to the point of Prolog to C++ conversion. My friend found literally hundreds easy to access libraries for C++ which allowed to build e.g. nice GUI visualizer for his pet project. Something he didn't even dreamed of on Prolog: it was possible but all GUI libraries were poor and complicated to program .

The point is that academia keeps the functional languages slaves to their niche tasks very often forgetting that for language to be relevant to real world it also has to have many many libraries to solve all the particular real world problems and to solve them efficiently.

But right now, most such languages, when faced with new real world problem .... Well it just happen that they make another language to solve that particular problem.

Transactional Memory

[wirelessbuzzers]

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.

Re:Transactional Memory

[Peaker]

Correct me if I'm wrong, but I thought ST was intentionally separate from IO, so as to allow having a less dangerous realm than IO to do work in. ST work can be wrapped in a pure interface, safely, while IO can't.

Re:Transactional Memory

[wirelessbuzzers]

The idea is to set IO = ST RealWorld. Since you can only purify things of type (forall a . ST a), you still can't purify IO. On the other hand, you then don't have separate types for IORefs and STRefs, IOArrays and STArrays, and so on.

It'd be extra neat if they could do it with STM as well, but that seems unlikely. IORefs and STRefs are the same on the inside, but TVars are not, so it'd take some deep compiler hackery.

Infinite Supply of Crax0rs Trying Buffer Overflows

[mosel-saar-ruwer]

Sure they do. On my computer, there's an infinite stream of ethernet frames arriving, an infinite stream of video frames leaving, an infinite stream of keyboard events arriving, etc.

1988 just called - it wants its reputation back.

visibility of hackage

[j1m 5n0w]

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.

Re:visibility of hackage

[Anonymous Coward]

That's totally fine, I'm just saying, you need to go out and actively advertise what great things you can do with Haskell, and get excitement in the community at large. Just having a good library won't help otherwise, and there's a huge benefit both to the quality and to the perception of the language/library if you have more users. This was just meant to be constructive criticism. Take a look at Ruby for example - once Rails gained popularity, Ruby became familiar to most developers, and also associated with working, production applications. Now it's making its way into startups and enterprises. Nonetheless the language is non-traditional and beautiful like Haskell, and the interpreter is pretty slow to boot. A similar thing happened with Python, though Python still doesn't have a "killer app" that is as well-known as Rails.

Hard to imagine that, but I suppose it's possible.

[Anonymous Coward]

I've seen the Fibonacci sequence used to show worst case input scenario in at least one algorithm.

We depend on normal users for that around here.

We get supposedly clean address data that's got pipe characters in it. No lie. About ten years ago we had a Sun system running software we bought from Xerox, and we fed it a normal data file from a large hospital, and it deleted its own /var partition. The Xerox guy said "it's not our fault, you shouldn't have dozens of metacharacters in the data" and we said "dude... you must really suck at programming. Of course the data's filthy, this isn't a college lab here."

When I worked in engineering, we used to test stuff by running the output of an AM radio tuned to static through a A/D converter.

What happens when you take the ask out of Haskell?

[LuxMaker]

.... You get Hell, Hell I tell you.

What?

[Estanislao Mart�nez]

Functors and generators will do the same thing for you in a more mainstream languages like C++ and Python. And they'll be a hell of a lot more understandable to your average still-wet-behind-the-ears programmer.

Um, are Python generators any easier to understand than lazy evaluation to your "your average still-wet-behind-the-ears programmer"? The only way I can imagine this being so is that your programmer already did the hard work to learn C++ or Python, but didn't do any such work for Haskell--which begs the question, frankly.

Python generators ain't easy stuff. They're completely out of left field with regards to the rest of the language's stack-based flow control. How is the concept of reentering a local execution context that you exited before any simpler than lazy evaluation?

Richard Stamos's high F

[Tetsujin]

They did mention F# in the article - hadn't heard of it before... I'll have to check it out.

worse is worse again?

[brm]

Have things changed since Gabriel pointed out that Worse is Better?

Developer tools

[pediddle]

I love Haskell -- maybe the most elegant language I've seen and my favorite underdog. But you've just pointed out the problem. All of the big efforts in the Haskell community are oriented around developer tools!

Compilers, source control, tools for other languages, build systems... and of course fancy libraries using advanced GHC extensions that are barely more understood than theory... all wonderfully powerful in case somebody... somewhere... wants to use them.

(A crappy 3D shooter that doesn't hold a candle to dozens of mainstream games each year doesn't count, I'm afraid.)

Haskell sucks.

[master_p]

It sucks because programming is 99% about "side effects" than mathematical formulas.

Please note the use of quotes for 'side effects'. They are called 'side effects', although they are the most interesting part of programming. It's the part that things happen inside a computer that change the world.

Haskell makes it really difficult to write useful code (where useful means 'with side effects').

They may show you how to create 'infinite' number sequences and process them.

Cool. Ask them to make a Model-View-Controller application in Haskell, where the model is a tree of nodes modified by user actions. Trivial in imperative languages, hard as hell in Haskell: you have to use the a special monad, mix the useful code with visitation to the tree nodes, because the only way to modify tree node links in Haskell is via local arguments that 'pretend' to be the tree's nodes...