When did Javascript become a serious language?

Levi Pearson levipearson at gmail.com
Mon Dec 9 12:36:49 MST 2013


On Sat, Dec 7, 2013 at 10:33 PM, Eric Wald <eswald at brainshell.org> wrote:

> Functional programming is the notion that functions (almost) never have
> side effects.  Think Haskell.  It makes mathematicians happy, because it
> enables them to prove that programs are correct, but it requires even
> more brain warping and puzzle solving to do any real work.

Actually, proving programs correct is probably done more often for
languages like C and Ada than for languages like Haskell.  Mostly
because there are more real-world systems that need to have aspects of
their operation verified in those languages.  But even the most
procedural languages (or at least a restricted subset of them) can be
given a formal semantics, which essentially recasts the meaning of a
program to a purely functional or logical interpretation.  At that
point, the same techniques for verifying languages work on *any* of
them, though some will prove more complex and difficult to reason
about than others.

The nice thing about functional programming is that the more purely
functional it is, the closer the language as written is to the formal
semantics of the language.  Programmers don't often use this to do
formal proofs, but to do informal reasoning about the behavior of
things and to be able to manipulate programs like you would manipulate
a set of algebraic equations while trying to solve them. It's
difficult to explain the real-world benefits to this kind of thinking
about programs to someone who's used to not having it within easy
reach, but it really is a significant thing that you miss out on when
the only thing you borrow from functional languages is first-class
functions with closures.

>
> What it has contributed to more mainstream (read: usable) languages is
> the idea of functions as a first-class data type.  Once defined, a
> function can be passed around as if it were any other value.  That leads
> to convenient second-order functions, as well as callbacks.
>
> The good news is that Javascript functions are much easier to reuse than
> Java's anonymous inner classes, as well as easier to define precisely
> where you need them.  Where the required effect is so specific that it
> wouldn't be reused, it would frequently be defined inline:
>
>     barFunc(paramVal, function(result) { process(result[0].value); });
>
> Any lines that would have gone below the function call are simply
> wrapped in another block, with perhaps another layer of indentation.
>
>> 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, it's pretty much all about asynchronicity.  When a library requires
> a callback in order to collect a result, it's because the function might
> need to wait for something in order to determine the result, or for
> consistency with other such functions.
>
> The good news is that asynchronous primitives are much easier to treat
> as a synchronous system than synchronous primitives are to morph into
> asynch systems; the latter often involves either threads or gradual
> transitions to a duplicate API.  On the other hand, I have more respect
> for languages that allow the asynchronous aspect to be swept under the
> rug: Google's Go lang, for example, appears to have synchronous-looking
> calls that transfer control back to an event loop until the result is
> ready, while offering a simple keyword to let function calls run in the
> background.  Of course, that requires either suspendable stack frames or
> multiple threads, as well as an event loop.
>
> Anyone care to implement that kind of behavior for Javascript?  Of
> course, we'll need to wait for Microsoft to re-implement the new spec
> before it can safely be used on websites...

Numerous people have implemented that kind of behavior for Javascript,
and there are probably still several that you can easily get for node
via npm.  Some of them do a CPS conversion on your code, others
implement the equivalent of a one-shot continuation-capturing
primitive as the basis of a co-routine library.  But none of them will
see much use in Node or browser-based Javascript programming until
something is put into the language standard. The Node guys are highly
against diverging the language from the same javascript that runs in
browsers, and so there's no cultural buy-in at the library level.  And
when your libraries are all in CPS-style, you're pretty much stuck
building your applications that way as well.

      --Levi


More information about the PLUG mailing list