Functional languages will rule (but not this year)

http://goodstuff.im/functional-languages-will-rule-but-not-this-y

by harryh • 15 years ago

63 44 15 years ago

goodstuff.im

T_S_• 15 years ago

Is the Haskell Singularity approaching?

http://www.reddit.com/r/haskell/comments/hezgk/haskell_singu...

kjksf• 15 years ago

The article contradicts its own title.

The author claims, in the title, that functional languages will rule, some day.

Then he does a tour describing each would-be-ruler functional language (erlang, haskell, ocaml, F#, scala) and explicitly says that all of them will remain niche languages i.e. will not rule.

harryh• 15 years ago

His thesis is that none of the current crop of functional languages will rule, but that some new functional language not yet invented (or widely known) will.

gaius3• 15 years ago

A language can't come out of nowhere, because it won't have the critical mass of people, libraries, etc to be usable for "real work". IF a functional language is going to be mainstream in only 5 years, then there are a significant number of people using it today, and it will be generally known in the FP community.

Even F# was a) in beta for years b) solved the library problem by piggybacking on C# and c) had a critical mass of OCaml users who could jump straight into it.

ankrgyl2• 15 years ago

His arguments about the existing functional languages can be roughly split into two categories: 1.) Languages refuse to make compromises and therefore are obscure (Haskell, Erlang) 2.) Languages are crippled by making too many compromises (F#, Scala).

He presents good arguments about why both types of languages can't currently break into the mainstream, but it unfortunately seems like these options form a partition of the possibilities (i.e. a functional language must fall into one of the two). If this assumption is correct, then by his analysis no functional language can break into the mainstream.

I'd love to see a discussion over whether or not that assumption is valid, but for now let's assume it's true. I don't think the languages are the problem. Instead, I think it's the general momentum and consensus of the community. Without books like Learn You a Haskell (http://learnyouahaskell.com/), Haskell would be an order of magnitude more difficult to begin learning. I'm still trying to figure it out, and there are a lot of examples of topics where a similarly good tutorial would ease my learning. Eventually, as the language gains popularity, more and more such work will exist. Furthermore, if popular companies demonstrates that it's a great choice, more people will want to pick it up. If all this stuff happens, our intuitions will grow and adapt to make such a language a natural choice. In summary, the future of functional languages depends more on our understanding and promoting them as a community, as opposed to the languages themselves.

evangineer8• 15 years ago

You make an excellent point about the primacy of the community. I can't remember where I first came across the idea that languages are communities, possibly Richard Gabriel's Patterns of Software.

As someone about to embark on the Standard ML learning curve (motivated primarily by Ur/Web - Ur is a ML-like language), it is striking that the SML community is fragmented to the point of non-existence (not even a Planet SML, the sml-list is dead, & the SML subreddit is pretty lifeless).

Looking at Alice ML which has significant advancements over both Objective and Standard ML, it has great features, but no momentum which isn't helped by the fact that there hasn't been a release since 2007.

anon_d• 15 years ago

Looking at Alice ML which has significantly more features than ...

FTFY

My favorite thing about SML is that it only has known-good features.

ankrgyl2• 15 years ago

I learned a lot of SML in college, and it is really a great language. In my opinion it has the best syntax and REPL of any language I've used.

But Haskell has a much better chance of becoming main stream. The type classes allow things like drop-in, easy-to-use hash maps and a simple, type-safe print statement (SML's requires explicit string conversions). Furthermore, GHC consistently pushes modern features; my current favorites are the extremely performant userspace threads (managed by epoll). From what I can tell, the SML folks are more focused on PL research projects than trying to implement a standard library, which is completely fine.

If everything goes well and we as a community build intuitions for strong, static typing, one of these good languages (IMO probably Haskell) could end up as the next Python.

BTW, if you're looking for resources on learning SML, I'd look at Bob Harper's books (http://www.cs.cmu.edu/~rwh/)

cageface• 15 years ago

This is a refreshingly honest analysis from someone that has a lot of skin in the game. I completely agree on both points. First, the functional paradigm is important and a step forward for most problem domains. Second, none of the current crop of functional languages is going to truly break into the mainstream.

I think it's more likely that we'll see more and more functional techniques trickle down into mainstream languages than it is that we'll see a pure functional language adopted as-is. C++ just picked up lambdas, after all. I do regret somewhat my dalliance with FP over the last decade though. If I'd invested that time in mastering DSP or graphics programming instead I'd be better off overall.

evangineer8• 15 years ago

There is a definite functional trickledown effect going on with mainstream languages.

I have the suspicion that the breakthrough functional language will be like CoffeeScript in that it compiles down to Javascript taking advantage of the high performance Javascript runtimes and the functional core of Javascript.

Homunculiheaded2• 15 years ago

It's somewhat funny that this article seems to miss the very practical rise of functional programming style in JavaScript, especially with the rise of libraries like underscore.js

Of course JavaScript has some pretty severe limitations as far as functional programming goes, the biggest being really cumbersome lambdas, and a lack of implicit return. If you try to program in a functional style in JavaScript you'll be fighting the language more than you'd like. However both of these issues are remedied in CoffeeScript.

As someone who was a lisper before getting into web development I'm really surprised to see lambdas, closures, pattern matching/de-structuring bind, let statement equivalents and more be part of a language that is not even talked about too much as being lisp-like or functional. Also important is that CoffeeScript's main selling point is that it's practical and more sane then JavaScript, not that it's functional or lisp-like. At the same time CoffeeScript is probably the closest thing I've seen to a (potentially) successful lisp-without-parens

Functional languages will gain serious traction, but I think it will be when their users find their features convenient and helpful (coffeeScript) rather than interesting/mind-blowing/etc (scala, haskell, erlang..)

davidhollander4• 15 years ago

> Also important is that CoffeeScript's main selling point is that it's practical and more sane then JavaScript, not that it's functional or lisp-like. At the same time CoffeeScript is probably the closest thing I've seen to a (potentially) successful lisp-without-parens

Have you tried Lua? It has full lexical scoping like Scheme (so you don't have to (function(){})() all over your code to create closures) and has saner built in types than vanilla JS, while also being much faster (around SBCL\Java speed with LuaJIT).

I'm writing a basic functional library for it here if you need some stuff like map, foldl, foldr, partial, filter to get started: https://github.com/davidhollander/fn

silentbicycle6• 15 years ago

Unfortunately, Lua has statement- rather than expression-oriented semantics (i.e., no "implicit returns"). It's quite nice otherwise, though, and its integration with C is hard to beat.

I wrote a library for pattern-matching in Lua, btw (http://github.com/silentbicycle/tamale). May be of interest.

mb214• 15 years ago

I think I'm currently in the "I just don't get it camp" when a significant deficit of a language is the lack of implicit returns. Is typing return that bad? I quite like the readability. Is it that you can only return once per function? I already do that, but recognize that some developers don't. If that's part of it then a lot about these languages is to keep the riff-raff out? If that's true then I think we can probably all agree they will never be mainstream since in most cases mainstream == rif-raff.

gaius3• 15 years ago

It's because it makes it harder to prove that a function does one of only two things: returns a known type, or throws and exception. In Python it's legal to have a function that can return 0 or return "hello" or nothing at all.

silentbicycle6• 15 years ago

It's not about readability or "keeping the riff-raff out". Needing to type "return" itself is a minor detail, but explicit returns are a strong sign of having statement-oriented semantics, rather than expression-oriented semantics.

In languages based around statements, things are done for their side-effects. Returning a value is itself a kind of side-effect, hence an explicit return statement.

In languages based around expressions (Lisp, ML & Haskell, APL, etc.), the language itself gently encourages side-effect-free programming. In Scheme, for example, you usually use a begin block when you need to do things for their side-effects. While it doesn't prevent side-effects entirely, it does make them stand out, and adds a subtle pressure against their overuse.

kikibobo69• 15 years ago

One reason for not having return, has to do with symmetry, which Scala is full of.

For example, val x = if(foo) { a } else { b }

This is a lot nicer than the alternatives, and I suppose you could force people to write:

val x = if (foo) { return a } else { return b }

...why, why? It doesn't really add much. Once you get into the functional mindset, it becomes natural how this works, and the occasional place where you are forced to add a return statement becomes a place where there is almost certainly code smell. No returns is basically one of those constraints that helps guide you towards more functional code with fewer side effects.

Homunculiheaded2• 15 years ago

I know this is 10 days late, but the big factor is not whether you type 'return', it's knowing that everybody else has. When you have implicit returns you can always know that a call to a function will return a value, this is essential to proper functional programming technique.

patfla• 15 years ago

All the machinery of functional programming languages that's creeping into non-FP languages is great. I actually think that FP one-liners are usually _more_ transparent than the corresponding non-FP loop.

However if I'm not mistaken an important point of FPLs was to eliminate side-effects and that the ultimate goal was program verification (not validation). I.e. you could prove a program correct in the mathematical sense. That seems still a long way off.

evangineer8• 15 years ago

The trend I'm seeing isn't towards verification by proof but leveraging the type system to ensure that the compiled program is correct and secure. Both Opa and Ur/Web take this line.

smackay• 15 years ago

So how does the tooling problem get solved? This would seem to be the limiting factor presented in the article not necessarily how opinionated the language is.

evangineer8• 15 years ago

TypeSafe have money in the bank and a serious commitment to fixing the Scala tooling for Eclipse.

lurker19• 15 years ago

Maybe 3rd time will be the charm.

hugh4life• 15 years ago

One language he left out was Nemerle... I like it more than Scala...

http://nemerle.org/About/

F# 3.0 will have type providers which provide functionality similar to Gosu's open type system.

The Future of F#: Data and Services at your Finger Tips

http://channel9.msdn.com/Events/PDC/PDC10/FT12

http://i51.tinypic.com/300chly.jpg

Not new, but Websharper for writing Javascript in F# is pretty cool...

http://websharper.com/samples/WebGL http://websharper.com/samples/Canvas

evangineer8• 15 years ago

Nemerle's been around for years and I don't see it getting any traction, especially in the shadows of both C# which has been cherry picking functional features & F# which has the backing of Microsoft.

gar1t• 15 years ago

A power and persuasive essay on the essential merits of functional languages.

Erlang is ugly

Haskell is beautiful, like Karate

OCaml is impenetrably unexciting

F# is polished. And mainstream

Scala is a tour de force of concepts. Tiobe Top 20

evangineer8• 15 years ago

I wonder if the author would feel the same way about OCaml if he had come across it before Scala.

I suspect not somehow.

fhars• 15 years ago

I came to scala because it is in fact an acceptable ocaml that runs on the JVM.

mb214• 15 years ago

scala is in the 50-100 range now according to http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

gaius3• 15 years ago

It's an interesting analogy. Whenever Karate fighters enter MMA contests, they get their arses handed to them by BJJ fighters - the beauty of their art doesn't translate into effectiveness in competition.

ubojan• 15 years ago

Yes it does. It's hard to be a successful MMA fighter relying on just one martial art. Just look at Machida how he beautifully incorporates karate in MMA game.

kumarshantanu• 15 years ago

Mention about Clojure (which is more functional than Scala) is curiously absent from the blog post.

Functional languages will rule (but not this year)

Related Stories