> 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

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.

> Unfortunately, Lua has statement- rather than expression-oriented semantics (i.e., no "implicit returns").

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

The variable "n" is a counter for the number of bytes sent to the file descriptor "fd". The write callback lambda assigned with OnWrite can always access the appropriate counter "n" based on its creation location. No extra work was needed to create the closure, unlike in languages such as JavaScript.

In Lua, unlike in JavaScript, you don't need to use closures for async programming most of the time.

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

Coroutines aren't as flexible as continuation passing style and add significant overhead for the non-vital syntactic sugar they give you.

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.

Coroutines are less expressive than manually doing CPS, true, but they do make many common cases simpler. They're ultimately as expressive as one-shot continuations.

I never said it did. Of the many complains in-thread about Javascript, it's the main one that also applies to Lua. I'd say Lua's coroutines are a bigger feature for asynch. development, though.

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.

>If I find time to neaten up that code, are you interested in swapping notes?

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.

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.

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.

I don't think I'm quite there yet. Are you saying having to type return vs. it being implicit encourages side-effects in programming? How does this relate to the begin block?

Mostly, yes. "return" isn't the cause, though. Just a sign that the language's primary concern is the side-effect of running statements, not their values (in which case, having a result value would be expected, not a special case). A sign of different priorities in the language design: functional-by-default or imperative-by-default.

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.

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.

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.

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.

I don't understand. I can't tell if you are arguing for or against explicit returns. Can you elaborate?

I suspect he read "typing return" as "return having one specific type" (i.e., "return an int (not string, float, etc.)".

That's a different (but related) issue.