On Sat, Dec 7, 2013 at 7:41 PM, S. Dale Morrey <sdalemor...@gmail.com> wrote:
> One thing that I admit I am struggling with, is the idea of functions not
> returning values. Obviously, this isn't a limitation in the language
> itself and more a matter of style. But it seems like most of the libs I'm
> working with want me hand them a function (pointer?) to call back rather
> than returning a value. That works fine for asynchronous code. However
> there are many times I just plain need the code to block and wait for a
> return value, then do something with that value. I don't want to have to
> create a new function just to deal with every single value I need.
>
> For instance
>
> foo = barFunc(paramVal);
>
> Is just so much more intuitive to me than
>
> barFunc(paramVal, fooFunc);
>
> I guess this is what they call functional programming. Nevertheless I
> don't generally like anonymous inner classes in Java (it tends to break
> code reuse) and I'm really not a fan of this in Javascript.
> But maybe I'm missing something here. Other than asynchronous method
> calls, is there any valid reason to take the second approach rather than
> the first?
No, functional programming is based upon functions always returning
values, and in fact always returning the *same* value for the same
input. What you are experiencing with javascript is what's called
"continuation-passing style", which was invented by functional
programming guys, but more as a technique for compiling functional
code than for writing it by hand. It's still used by hand in
functional programming as well, but usually only to build libraries
that implement new kinds of control abstractions. In procedural
languages, you are generally stuck with the control flow abstractions
the language has built-in, so the issue doesn't really come up.
You're right, it's not a very intuitive way to program, but it's a
simple and straightforward transformation away from normal, intuitive
code; so, you can get used to it. Its primary advantage is that it
can be used to implement highly-concurrent program flows in a
single-threaded environment with the language features that Javascript
currently has. For simple control flow, it's actually much *easier* to
get correct behavior and good performance than with shared-memory
threads. That advantage starts to diminish with more complex control
flow, as you typically see in a complex server, but the alternatives
aren't really well-supported by the language yet.
It's a shame that a bunch of programmers are currently learning to
program this way as if it's actually the best way to do it rather than
the best way that can be managed by Javascript as it is now, but I
think that will gradually change as Javascript matures as a language.
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
