3 ms·

While I love CoffeeScript, the always-implicit-return thing is my biggest pet peeve. The language really needs a non-implicit-returning arrow like -/> , if noth

While I love CoffeeScript, the always-implicit-return thing is my biggest pet peeve. The language really needs a non-implicit-returning arrow like -/> , if nothing else so that you can make one liners that don't return a value. Unfortunately, this isn't the direction they want to take the project in. The reasoning is that in CS, all functions should ideally have a return value. I think that's silly, since you have to contend with the fact that it's supposed to interoperate with JS, and plenty of builtins and JS libraries don't behave as if every function has a return value, but what can you do?

masklinn 14y ago
> it's supposed to interoperate with JS Definitely the crux of the issue, as languages/ecosystems where "callables always return a value" tend not to have that issue even when dynamically typed (Ruby, Erlang). And it's not just JS interop, but gateless interop: calling JS from CS or CS from JS is supposed to be "invisible" as opposed to e.g. ClojureScript which also has excellent JS interop but where the interop is done through special forms (e.g. the `js/` namespace calls into JS-global objects), managing developer expectations about the seamlessness of the boundary.
- mistercow 14y ago
  Exactly, and the article's example is spot on for how these expectations get violated by CS's behavior. In CS, the assumption is that aside from minor (and easy to detect) performance penalties, returning a nonsensical value from a function is harmless. But libraries like jQuery actually give meaning to "no return" in some callbacks. They cleverly let that be the most common behavior, and then let return values specify less common behavior. An example of this in jQuery that creates even more aggravating bugs is event handling. Here's a simple example: http://jsfiddle.net/63fUY/ http://jsfiddle.net/63fUY/ . The expectation is that each time you click either button, the total count will increase. But because of the implicit return on line 13, preventDefault gets called half the time. That's an incredibly easy mistake to make, a huge pain to hunt down, and awkward to write a test for. And it would be so easy to avoid if the language had a syntax for "default to no return" which we could just use on all event handlers.
  - masklinn 14y ago
    > Here's a simple example: http://jsfiddle.net/63fUY/ http://jsfiddle.net/63fUY/ . Hah. Fun one. > And it would be so easy to avoid if the language had a syntax for "default to no return" which we could just use on all event handlers. Alternatively, rollback the "implicit return" but make the explicit return short and sweet yet still visible. E.g. use Smalltalk's unary `^` (which as far as I know currently exists neither in JS nor in CS) so the callbacks would be: -> totalClicks++ $('#total').text totalClicks ^false # explicitly return false and -> $('#state').text if nextState then "On" else "Off" nextState = !nextState # no explicit return -> undefined as in JS
Zariel 14y ago
You can always look at something like LiveScript, which has the syntax !-> which prevents default return from functions, I started using it over CoffeeScript lately. http://livescript.net/ http://livescript.net/

masklinn 14y ago

> it's supposed to interoperate with JS Definitely the crux of the issue, as languages/ecosystems where "callables always return a value" tend not to have that issue even when dynamically typed (Ruby, Erlang). And it's not just JS interop, but gateless interop: calling JS from CS or CS from JS is supposed to be "invisible" as opposed to e.g. ClojureScript which also has excellent JS interop but where the interop is done through special forms (e.g. the `js/` namespace calls into JS-global objects), managing developer expectations about the seamlessness of the boundary.

mistercow 14y ago
Exactly, and the article's example is spot on for how these expectations get violated by CS's behavior. In CS, the assumption is that aside from minor (and easy to detect) performance penalties, returning a nonsensical value from a function is harmless. But libraries like jQuery actually give meaning to "no return" in some callbacks. They cleverly let that be the most common behavior, and then let return values specify less common behavior. An example of this in jQuery that creates even more aggravating bugs is event handling. Here's a simple example: http://jsfiddle.net/63fUY/ http://jsfiddle.net/63fUY/ . The expectation is that each time you click either button, the total count will increase. But because of the implicit return on line 13, preventDefault gets called half the time. That's an incredibly easy mistake to make, a huge pain to hunt down, and awkward to write a test for. And it would be so easy to avoid if the language had a syntax for "default to no return" which we could just use on all event handlers.
- masklinn 14y ago
  > Here's a simple example: http://jsfiddle.net/63fUY/ http://jsfiddle.net/63fUY/ . Hah. Fun one. > And it would be so easy to avoid if the language had a syntax for "default to no return" which we could just use on all event handlers. Alternatively, rollback the "implicit return" but make the explicit return short and sweet yet still visible. E.g. use Smalltalk's unary `^` (which as far as I know currently exists neither in JS nor in CS) so the callbacks would be: -> totalClicks++ $('#total').text totalClicks ^false # explicitly return false and -> $('#state').text if nextState then "On" else "Off" nextState = !nextState # no explicit return -> undefined as in JS

Zariel 14y ago

You can always look at something like LiveScript, which has the syntax !-> which prevents default return from functions, I started using it over CoffeeScript lately. http://livescript.net/ http://livescript.net/