Hacker News Reader

Comment by mb21 | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com