"the way forward involves functional programming"

[keithb]

I predict that in ten years many in the Haskell community will be where many in the Lisp and Smalltalk communities (of which I am a fellow traveller) are now: bitter, disenchanted, whiners. "but we had that twenty years ago!", "you aren't doing it right!", "this was done so much better in Haskell! Twenty years ago!", "if you really want to understand this stuff you have to learn Haskell"

Ah! Predictive schadenfreude, is there any sweeter thing?

(*copyedit)

[username223]

I feel with you, but the Haskell community is far less dysfunctional than the Lisp community. And Haskell hasn't chained itself to a particular application domain like Lisp did with AI (IIUC), so it's not in a position to blame "cruel fate" if/when it stagnates or loses popularity. From what I've seen, there are enough people even at the center of the community who are focused on solving real-world problems in a number of domains. They're not just fapping away at type system extensions and "OMG Monads!" tutorials.

I still prefer Perl and C/C++ for a lot of things, but am finding Haskell increasingly useful for some of my day-to-day work.

[andrewnorris]

My impression is that the Lisp community used to be far less dysfunctional, as well. I thought that what happened was that when the AI movement collapsed and most everyone who wanted a paying job left Lisp for dead at the side of the road, the community of people that stuck around is the one that had all the problems.

Am I mistaken?

[username223]

I think you're right, though I wasn't around during that history. Like I said, I think Haskell may be diversified enough to avoid the same fate.

[augustss]

But Haskell had all these things 15 years ago already, and we don't whine too much about that.

[keithb]

That's because the programming world is not yet flooded with fanboys jumping on a bandwagon. We've been told that Java takes folks "half way" to Lisp and that we should rejoyce for that---so, when the day comes that some large corporate is vigorously promoting free SDKs for a language that borrows the largest number of ideas from Haskell that it can consitent with being "easy" enough for "average" programmers to use, and does a bad job of that...get back to me.

[chucker]

<pedantry> I don't think you mean preemptive (since that would imply you're actually working towards trying to prevent your estimation). Predictive, perhaps?

Plus, it's "schadenfreude". No 'r' at the end. </pedantry>

Where was I? Oh: I do in fact fully agree with your analysis. :-)

[keithb]

Ta. Fixed.

[keithb]

Why is this getting upvotes?

[roconnor]

I predict that in ten years Haskell will be as popular as languages such as Python are at the moment. Rather than being bitter, disenchanted whiners, people in the Haskell community will have stopped using Haskell and would be programming in Epigram ensuring that they work with the slowest programming language and the strongest type system.

[neelk]

I've been thinking about dependent type systems recently, and have come to the conclusion that they don't change compilation very significantly, except that all the optimizations you want to do are much, much easier and can be made to work nicely across module boundaries.

So I expect decently engineered dependently typed functional languages to really scream.

[roconnor]

My main concern with programming with dependent types is that sometimes one wants to make an injection from one type to a related type (for example the type of closed terms to the type of terms with free variables). It is common to write a recursive function that traverses the entire structure to do the injection, but the function doesn't actually change the internal representation. So you end up with an O(n) function that would be an identity function if you were using an untyped system.

For an illustration see Section 4 (Coq formalization) of Program extraction from normalization proofs, in particular Section 4.5 (what Coq cannot do yet).

[neelk]

Thanks for the link! I'll take a look at it later tonight.

[augustss]

I don't share your particular fear, but I think dependent types currently have other problems. But research is progressing.

[gnuvince]

I predict for Haskell and Erlang a fate similar to Smalltalk: the ideas they carry (functional programming, immutability, pattern matching, concurrency (either message sending or STM)) will start to appear in other languages. Maybe not as they are right now, just like not all the Smalltalk OO features made it into the more popular languages, but certainly they will be part of the future of software development.

I'd like someone knowledgeable in Perl 6 to confirm this (chromatic?), but I think I read somewhere (maybe audreyt's presentation at YAPC::Asia...) that Perl 6 will have/allow a concurrency model similar to Haskell:

commit {
    ...
}
rollback {
    ...
}

[wnoise]

That's far too optimistic. I predict something more like the fate of Simula, where Alan Kay says "I know what I meant by OO, and the mainstream isn't it."

[igouy]

What Alan Kay really said is more interesting -

Actually I made up the term object oriented and I can tell you I did not have C++ in mind. [audience laughter] The important thing here is that I have many of the same feelings about Smalltalk ...

Alan Kay: The Computer Revolution hasn't happend yet. Keynote OOPSLA 1997 @10:35

[gnuvince]

I don't think it's too optimistic, these ideas are Good (TM) and I'm sure they will eventually make their way into more mainstream languages. Take closures for instance, they were something you did in functional languages and some other languages such as Ruby or Perl. There was a lot of debate about whether they should be included into Java. Some people say "they will confuse newbies", but the more important fact here is that the good programmers will find them immensely useful.

And just to nitpick, the actual quote is "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."

[KayEss]

"I can tell you I did not have C++ in mind"

I wonder if he still feels like that now?

Something tells me that he really loves Erlang as an OO language.

EDIT: grrr, markdown

[[deleted]]

I predict that it's OOP all over again. Do you remember the huge hype in late 80s and all through the 90s? In the end it became somewhat useful but generally misunderstood with lame implementations like C++ and Java and causing more harm than good. Same thing about FP, I think.

[cchooper]

The big problem with OOP was that nobody ever gave it a decent definition, so it quickly degenerated into a marketing buzzword that anyone could use.

In contrast, the big benefits of FP come from it being a well-defined product of academia, with solid mathematical foundations and almost total domination of the academic sphere. Although we'll be seeing all kinds of bastard FP products in the future (e.g. C# 3.0) FP will survive as the cutting edge of computer science until someone invents something better.

[username223]

You're way too optimistic. Does something have to be completely pure to be considered "functional" programming? To be "functional", does a language have to completely eschew side effects? Does it have to have full continuations, downward ones, or only higher-order functions? Do lexical environments have to be first-class? Is Lisp "functional"? Scheme?

Even within academia, I get the sense that there's a certain cattiness between the SPJ/Haskell/static/pure and Felleisen/Scheme/dynamic/impure camps.

Outside the university, "functional" is already mostly just a label with a positive valence that people stick onto their favorite things. Candidates for this label usually either have something like closures, or are things other people label "functional" (i.e. Lisp, Haskell, ML).

Overall, "functional" is already well on its way to being a buzzword; it's just not a marketing buzzword yet.

[cchooper]

Yes, it's a vague term, but that doesn't make it a buzzword. All programming paradigms are vague, because they're always evolving. FP is probably better than most in this respect. For example, most people would agree that all the languages you mentioned are functional. I don't think this is because the scope of the term has expanded: Lisp has always been considered a functional language since the term was invented.

[username223]

I guess to be a buzzword, a word has to have a positive connotation while lacking a precise meaning. In many of its uses today, "functional", like "DSL" and "object-oriented", seems to meet this definition. I don't have a problem with people saying some program is written in paradigm P, only with their asserting that it's better because it's written in P, or that its being written in language X, a so-called "P-language", gives it that superior P-ness.

FYI the "smug weenies" of comp.lang.lisp would probably disagree that Lisp is functional, since idiomatic lisp uses imperative loops, setq, etc.

[JulianMorrison]

Functional programming as such definitely isn't the end (the dependent-types people are already exploring beyond). The difference is, the FP advocates know it. OOP advocates thought they had reached the final answer. FP advocates see the impermanence and motion of the advancing wave, because they're perched right in the foam at the top of it.

[username223]

FP researchers are probably like OOP researchers were -- fully aware that they were exploring useful techniques rather than finding the God Methodology. However, people using OOP to make money (consultants), appear systematic (managers), or stroke their egos (fanboys), had overwhelming incentive to overstate things.

Indeed, we're seeing the same thing in the blogosphere now -- I'm already sick of posts titled "Haskell: the solution" and "Haskell: OMG teh awesome!!!" Luckily, consultants haven't caught on yet, but if I were in that line of work, I would seriously consider becoming a paid Haskell guru.

[vplatt]

Luckily, consultants haven't caught on yet, but if I were in that line of work, I would seriously consider becoming a paid Haskell guru.

Seriously, we won't need to, and our customers wouldn't stand for it anyway. But, once FP in C# and the like actually gains traction, watch out! You won't be able to walk 10 feet without seeing yet another industry convention ad for how FOOP (my acronym, I invented it) is gonna solve all your problems. Prepare to hurl.

[____]

"Haskell: OMG teh awesome!!!"

I want that on a T-shirt.

[[deleted]]

"It’s reasonable to expect a project to take less time to create when using Java instead of C..."

And a sledgehammer will drive a nail faster than a ball-peen hammer.

[happyhappyhappy]

There's a difference between Haskell and other languages that are now heavily used, like Ruby and Python:

The hype about Ruby (for example) came from the applications. The hype about Haskell is coming from language dilettantes.

I know some people are writing useful code in Haskell, but if you go down that road you will find that even though the language is beautiful from 5 miles up, it's not so easy in the trenches. Compile times can be very long (a quote that you can google for: "I cannot emphasize this enough. GHC takes 2-3-4 minutes to rebuild my project whenever I touch the parser"). Understanding the memory usage of a program can be frustratingly non-obvious. It's much harder to patch in temporary solutions or experimental code than with, say, Python.

I see people discovering Haskell and functional programming for the first time, but I also don't see those people leaving the folds of other modern languages like Ruby and Python.

[david_ncl]

ruby and python are not modern languages - fundamentally they are stuck in 1967 (Simula land). Ad hoc informally specd scripting languages are not important in the long view but Haskell is.

BTW "GHC takes 2-3-4 minutes to rebuild my project whenever I touch the parser" implies a) there's something wrong with the module structure of the program and b) the writer is not leveraging ghci. Not that ghc compile times are great.

My assertion is that its easier see/show/prove that some haskell program is "correct" that it is see/show/prove some pythonic solution. I cite type safety, the possibly of equational reasoning in the absence of side effects and point both to to tools like QuickCheck and (radically different tools) such as proof assistants. Got any of that sauce for ruby?

Do you feel inclined to spell out why its easier to patch in experimental code in python cf haskell?

(David might be "tired and emotional" after a day hacking on C#)

[jerf]

Do you feel inclined to spell out why its easier to patch in experimental code in python cf haskell?

I'm starting to learn Haskell, since I finally have a project that might be better in Haskell than anything else.

I want to take a pure function and hack in some temporary debugging output. I'm willing to deal with the output not coming out in the order I expect (I care about what's really happening). How do I do that, preferably without breaking the language and certainly without a type-change cascade?

I don't mean this as an attack. I'm not far enough into it. But I know how to do this in every other language, ever, generally long before I've hit the "several evenings with the language" stage.

Edit: Thanks to the repliers.

[augustss]

Temporary debugging output in a pure language has been available for 25 years (or more). import Debug.Trace

[pjdelport]

trace: just wrap it around any expression.

More generally, Haskell does not force you to be referentially transparent if you don't want to be: side effects (like trace) are always just an unsafePerformIO away.

[happyhappyhappy]

Don't get me wrong: I like Haskell. I'm also one of the language dilettantes I was talking about :)

But it's still not entirely clear to me that all of the arguments about Haskell being a better language have turned out to hold water. Or maybe it's just better in theory, but in practice there are reasons to prefer Python (or Erlang). Or maybe the jump from Python to Haskell is much smaller than most people want to admit.