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

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

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

This is largely irrelevant for anything related to developing asynchronous services such as web or servers. Asynchronous web development using callbacks is a form of continuation passing style, where control is often explicitly passed using a callback. Since you are explicitly passing control, you usually never have to return values anyway. The 'return' keyword just becomes a bonus feature for convenient error handling.

Having a language with good closure support just works phenomenally well for asynchronous web development. For instance, sending an entire message asynchronously can be a pain because it can fail at any point in the message and require restarting at that point and keeping track of when it has finished.

It's a piece of cake in Lua though, due to its excellent support for closures:

    -- SendAll
    -- Start sending a message on connection [c]
    -- Close when done.
    function SendAll(c, msg)
      local n=0
      OnWrite(c, function(c)
        n=n + c.fd:send(msg, n)
        if n>=#msg then
          c.fd:close()
          return 'close' -- just for kicks
        end
      end)
    end

  -- SendAll
  -- Start sending a message on connection [c]
  -- Close when done.
  function SendAll(c, msg)
    local n=0
    while n<#msg do
      yield()
      n=n + c.fd:send(msg, n)
    end
    c.fd:close()
    yield('close') -- just for kicks
  end

I'd much rather explicitly set an OnWrite event that has a one-to-one correspondence to a socket write event from a poll() system call, than create a ton of coroutines and juggle "resumes". This is especially true if you have a usecase where you want to start sending while you are still reading, this would require the creation of 2 coroutines per each context.

While Lua coroutines are significantly better than Python generators by having a more functional than syntactical "yield", I still feel it does more harm than good for structuring asynchronous applications.

I wrote an embedded non-blocking / event-loop webserver in Lua as part of one of my projects (a distributed filesystem). I got sidetracked by other projects, and lost interest in writing non-blocking webservers after I got into Erlang, but plan on getting back to the filesystem soon. If I find time to neaten up that code, are you interested in swapping notes?

One tricky part is error handling - I spent a lot of time on that (and was pretty impressed by Erlang's error handling model). I don't know how well node.js does that, beyond managing control flow by hand.

Yes, I wrote a coroutine-less one here and tried to include design decisions in readme: https://github.com/davidhollander/ox

It works for HTTP but has few features so far. I have a bunch of exploratory code lying around though, so I could be adding message passing or better fileserving to it in the future. I will send you an email at some point.

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.

The begin block is how one indicates "do this, ignore its value (just do it for its side-effect), then do that and return its value" in Scheme. Some forms have implicit begins, however.

I may just be repeating myself, but I hope phrasing it slightly differently helped. What made it clear to me was learning Scheme and (especially) OCaml, then going back to Python and programming in a functional/expression-oriented style, seeing the subtle ways in which the design of the language resists it. Lua is more friendly to functional programming than Python (it has tail-call optimization, for starters), but those explicit returns still show it isn't a perfect fit.

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.

That's a different (but related) issue.

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.

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.

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

I think you're right about the SML folks' focus on PL research.

FTFY

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

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.

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.

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

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

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.

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.

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.

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

I suspect not somehow.