Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Lazy Functional Programming Languages Rule

ScuttleMonkey posted more than 5 years ago | from the laziness-is-the-mother-of-all-invention dept.

Programming 439

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

cancel ×

439 comments

I would have RTFA (5, Funny)

Anonymous Coward | more than 5 years ago | (#25071695)

But I was too lazy to click on 13 pageviews.

Use the handicapped stall (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25071697)

...and shit like a king!

Re:Use the handicapped stall (-1, Troll)

Anonymous Coward | more than 5 years ago | (#25071999)

And your own sink!

Re:Use the handicapped stall (0)

Anonymous Coward | more than 5 years ago | (#25072139)

for me to poop in!

Re:Use the handicapped stall (0)

Anonymous Coward | more than 5 years ago | (#25072181)

Wherever you are is the handicapped stall by definition. Now go back to sleep.

Mmmm, Kay. (4, Informative)

jellomizer (103300) | more than 5 years ago | (#25071731)

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. (4, Insightful)

thermian (1267986) | more than 5 years ago | (#25071935)

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. (4, Interesting)

beelsebob (529313) | more than 5 years ago | (#25072121)

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. (0, Flamebait)

Anonymous Coward | more than 5 years ago | (#25072263)

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

beelsebob (529313) | more than 5 years ago | (#25072321)

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. (4, Insightful)

thermian (1267986) | more than 5 years ago | (#25072533)

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. (4, Interesting)

beelsebob (529313) | more than 5 years ago | (#25072573)

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

Re:Mmmm, Kay. (1)

jbolden (176878) | more than 5 years ago | (#25072799)

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. (4, Insightful)

Dragonslicer (991472) | more than 5 years ago | (#25072417)

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. (4, Insightful)

mean pun (717227) | more than 5 years ago | (#25072567)

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

jbolden (176878) | more than 5 years ago | (#25072823)

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. (4, Insightful)

david.given (6740) | more than 5 years ago | (#25072869)

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. (4, Insightful)

Bill, Shooter of Bul (629286) | more than 5 years ago | (#25072485)

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. (4, Informative)

beelsebob (529313) | more than 5 years ago | (#25072625)

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 [haskell.org] library/tool repository just waiting to help you solve your real world problem. 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.

Re:Mmmm, Kay. (4, Insightful)

Dhalka226 (559740) | more than 5 years ago | (#25072589)

I call FUD.

I call meme misuse.

Re:Mmmm, Kay. (1)

afabbro (33948) | more than 5 years ago | (#25072681)

I call FUD.

I call meme misuse.

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

Re:Mmmm, Kay. (0)

Anonymous Coward | more than 5 years ago | (#25072781)

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

Abcd1234 (188840) | more than 5 years ago | (#25072609)

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. (5, Insightful)

NoNeeeed (157503) | more than 5 years ago | (#25072623)

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

beelsebob (529313) | more than 5 years ago | (#25072643)

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. (3, Insightful)

Rob Riggs (6418) | more than 5 years ago | (#25072633)

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.

Haskell is fun, but painful for procedural code... (1)

Tetsujin (103070) | more than 5 years ago | (#25072737)

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

Re:Mmmm, Kay. (1)

localman (111171) | more than 5 years ago | (#25072743)

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

jbolden (176878) | more than 5 years ago | (#25072871)

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

Vexorian (959249) | more than 5 years ago | (#25072851)

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)

A broader perspective (1)

Weasel Boy (13855) | more than 5 years ago | (#25072859)

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.

Re:Mmmm, Kay. (0)

Anonymous Coward | more than 5 years ago | (#25072265)

"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. (1)

Anonymous Brave Guy (457657) | more than 5 years ago | (#25072827)

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.

Too constrained and academic (5, Insightful)

m50d (797211) | more than 5 years ago | (#25071821)

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 (4, Interesting)

beelsebob (529313) | more than 5 years ago | (#25071941)

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 [realworldhaskell.org] . 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 database [haskell.org] has 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 (1)

m50d (797211) | more than 5 years ago | (#25072405)

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 (1)

cylence (129937) | more than 5 years ago | (#25072457)

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 (1)

beelsebob (529313) | more than 5 years ago | (#25072555)

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 (0)

Anonymous Coward | more than 5 years ago | (#25072657)

"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 (3, Insightful)

raddan (519638) | more than 5 years ago | (#25072663)

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 (1)

beelsebob (529313) | more than 5 years ago | (#25072731)

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 (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25072749)

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 (4, Interesting)

sribe (304414) | more than 5 years ago | (#25071989)

You also need to be able to interface.

Which is exactly why I find Scala [scala-lang.org] 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 (1)

burris (122191) | more than 5 years ago | (#25072395)

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 (5, Interesting)

Unending (1164935) | more than 5 years ago | (#25071997)

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 (0)

Anonymous Coward | more than 5 years ago | (#25072033)

This is nonsense. There are hundreds of bindings and other great libraries [haskell.org] .

Re:Too constrained and academic (0)

Anonymous Coward | more than 5 years ago | (#25072081)

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

Re:Too constrained and academic (1)

Dan East (318230) | more than 5 years ago | (#25072085)

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

Re:Too constrained and academic (1)

cameleon (149744) | more than 5 years ago | (#25072099)

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 (2, Interesting)

cylence (129937) | more than 5 years ago | (#25072599)

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 (1)

AKAImBatman (238306) | more than 5 years ago | (#25072129)

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 (1)

cylence (129937) | more than 5 years ago | (#25072211)

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 (4, Interesting)

AKAImBatman (238306) | more than 5 years ago | (#25072399)

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" [yahoo.com] introduction to the language if you're not familiar with Javascript's functional aspect.

Re:Too constrained and academic (2, Insightful)

cylence (129937) | more than 5 years ago | (#25072719)

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 (2, Informative)

AKAImBatman (238306) | more than 5 years ago | (#25072855)

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 [nott.ac.uk]
--Professor of Theoretical Computer Science Philip Wadler, University of Edinburgh

Re:Too constrained and academic (3, Informative)

AKAImBatman (238306) | more than 5 years ago | (#25072501)

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

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

Other stuff I pulled out of Google for your perusing:

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

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 (0)

Anonymous Coward | more than 5 years ago | (#25072151)

> 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 (3, Interesting)

sergstesh (929586) | more than 5 years ago | (#25072285)

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 (0)

Anonymous Coward | more than 5 years ago | (#25072301)

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 (0)

Anonymous Coward | more than 5 years ago | (#25072429)

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 (1)

clang_jangle (975789) | more than 5 years ago | (#25072383)

And people will start using them there.

Them there what ?

What a crock of shit. (0)

Anonymous Coward | more than 5 years ago | (#25072407)

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

Why they don't rule: (5, Funny)

Kingrames (858416) | more than 5 years ago | (#25071899)

The picture in the linked article is missing a beard.

Re:Why they don't rule: (5, Informative)

Bob-taro (996889) | more than 5 years ago | (#25072019)

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 [microsoft.co.il] , so I decided to post instead. Anyone else want to mod parent funny?

Re:Why they don't rule: (2, Funny)

solraith (1203394) | more than 5 years ago | (#25072045)

Way to take one for the team!

Re:Why they don't rule: (0)

Anonymous Coward | more than 5 years ago | (#25072187)

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

Re:Why they don't rule: (4, Funny)

moderatorrater (1095745) | more than 5 years ago | (#25072155)

Anyone else want to mod parent funny?

Yes, I will!

Oh crap.

It's not for dumb people (4, Insightful)

OrangeTide (124937) | more than 5 years ago | (#25071927)

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 (1)

Nursie (632944) | more than 5 years ago | (#25071975)

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 (1)

OrangeTide (124937) | more than 5 years ago | (#25072391)

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 (1)

Valtor (34080) | more than 5 years ago | (#25072089)

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

Re:It's not for dumb people (3, Interesting)

Abcd1234 (188840) | more than 5 years ago | (#25072561)

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 (1)

Jack9 (11421) | more than 5 years ago | (#25072581)

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 (4, Funny)

LWATCDR (28044) | more than 5 years ago | (#25072125)

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 (1)

Shados (741919) | more than 5 years ago | (#25072393)

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 (1)

LWATCDR (28044) | more than 5 years ago | (#25072601)

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 (1)

rockmuelle (575982) | more than 5 years ago | (#25072733)

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

-Chris

Re:It's not for dumb people (1)

Abcd1234 (188840) | more than 5 years ago | (#25072401)

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 (1)

fedtmule (614169) | more than 5 years ago | (#25072775)

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 (1)

Abcd1234 (188840) | more than 5 years ago | (#25072865)

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 (1)

cylence (129937) | more than 5 years ago | (#25072795)

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 (1)

Prof.Phreak (584152) | more than 5 years ago | (#25072863)

...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/ [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.

Lazy disfunctional language (0)

Anonymous Coward | more than 5 years ago | (#25071939)

Slashcode.

uniq: command not found

Yes. Lazy Functional Programming Language... (1, Funny)

Anonymous Coward | more than 5 years ago | (#25071983)

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

stoolpigeon (454276) | more than 5 years ago | (#25072433)

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

Holy Crap! (0, Redundant)

CSMatt (1175471) | more than 5 years ago | (#25072021)

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

Favorite word? (1)

octothorpe99 (34654) | more than 5 years ago | (#25072055)

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

Why "lazy"? (1)

VoyagerRadio (669156) | more than 5 years ago | (#25072105)

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

Re:Why "lazy"? (5, Informative)

tuffy (10202) | more than 5 years ago | (#25072209)

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"? (0)

Anonymous Coward | more than 5 years ago | (#25072251)

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"? (1)

Anonymous Coward | more than 5 years ago | (#25072275)

See Lazy evaluation [wikipedia.org] , 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"? (0)

Anonymous Coward | more than 5 years ago | (#25072279)

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.

Rule? (1)

MadKeithV (102058) | more than 5 years ago | (#25072145)

This must be some use of the word "rule" that I was previously unaware of!

Erlang (0)

Anonymous Coward | more than 5 years ago | (#25072243)

This is why I've started to learn Erlang. ;)

Awesome Article (1)

theverylastperson (1208224) | more than 5 years ago | (#25072297)

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?

one of the best practices (2, Interesting)

fermion (181285) | more than 5 years ago | (#25072509)

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 (1)

JasterBobaMereel (1102861) | more than 5 years ago | (#25072727)

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

Anonymous Coward | more than 5 years ago | (#25072563)

most of us are lazy but functional also.

Interview (1)

kabloom (755503) | more than 5 years ago | (#25072603)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...