
JavaScript = C + Lisp - raju
http://www.cubiclemuses.com/cm/blog/archives/000307.html
======
PieSquared
Aye, but minus the low level features of C and the high level features of
Lisp. Like pointer and memory manipulation and macros.

Still, it can be a very nice language, I just wouldn't say it is "C + Lisp".
Also I'm not sure what the article had to do with either Lisp or C, it seemed
more like a discussion of haskell... Am I missing something?

Edit: I'm still confused. Anyone want to take a better shot at explaining what
a monad is? Or, more precisely, what's so special about it that it deserves a
special name?

~~~
silentbicycle
A monad is a kind of control structure between functions. Kind of like if you
could overload add extra hook functionality to the Unix shell pipe, besides
just piping stuff along. For instance, seed it with a countdown, and every
time stuff is piped to another process, see how much time has elapsed; if at
any point it's been more than, say, 30 seconds, just stop the whole series and
return an error. Or find a path through a maze by backtracking every time it
hits a dead end, returning to the most recent unexplored path.

They're a necessary workaround to do some stuff in pure functional languages
(which is why Haskell users make such a big deal out of them), but you can do
some really cool tricks with them.

(NB: This is a really vague summary. I found this OCaml-based monad intro
helpful, because it mostly avoids entangling the monad concepts with unrelated
issues in Haskell. [http://enfranchisedmind.com/blog/2007/08/06/a-monad-
tutorial...](http://enfranchisedmind.com/blog/2007/08/06/a-monad-tutorial-for-
ocaml/) There's a good Monads-in-Scheme intro, too, I forget where.)

~~~
procrastitron
"They're a necessary workaround to do some stuff in pure functional languages"

This isn't actually true. You can still write imperative programs in a pure FP
language. The most obvious way is to write your code in continuation passing
style and pass the new state of the world to each continuation; taking the
implicit state changes of an imperative language and making them explicit.

The real reason for using monads is that the scheme I just described is
inhumanly complicated. Monads are a much more structured way of doing the same
thing. Instead of writing these state passing CPS functions, you write
functions that build them for you. A consequence of this is that monads
perform much the same function as macros in Lisp; they are programs that build
programs.

~~~
silentbicycle
Agreed. I guess I should have added, "without making things unnecessarily
complicated.".

I think that monads, too, are generally presented in a way that makes them
more complicated than they really are. (Hence, I suppose, SPJ's comment about
how they should have been called "warm fuzzy things".) Part of my trouble
understanding them confronting the basics of Haskell at the same time, and I
(along with much of what I read) focused on the IO monad. That's probably one
of the most complicated ones. The ideas started to click when I switched to
the Maybe monad -- not only is that one considerably more straightforward, but
I (and probably many others) had already written essentially the same
construct elsewhere, albeit without the formal notation.

------
SwellJoe
Not really news, is it? Brendan Eich himself has said that he wanted to use
Scheme as the embedded language in the browser, but the higher ups thought
people would be frightened off by all the parentheses. So, he sneakily
implemented Scheme with C-style syntax and nobody seemed to notice for a few
years.

~~~
silentbicycle
It seems like many of the strengths of Lisp/Scheme are an emergent property of
the S-expression syntax, though. Expressions like ((if test func-one func-two)
arg1 arg2 etc) are certainly more awkward with infix notation, for example.
Using OO/polymorphism is one way around this, but that's a bit heavy-handed in
situations where it's just a workaround for infix syntax. (Duplicated code
with a switch or if block is even worse.) Also, macros / code generation are
vastly easier with a consistently prefix notation.

Similarly, many of the advantages of stack-based languages like Forth and
Factor emerge from postfix notation. Very interesting to compare the two.

It's really too bad that non-C-style syntax freaks people out so much, from a
technical standpoint it's almost certainly the worst of the three. </fighting
words>

~~~
gruseom
_It seems like many of the strengths of Lisp/Scheme are an emergent property
of the S-expression syntax, though._

I agree, and I think your use of the word "emergent" is exactly right: the
properties in question were unanticipated, yet orderly and beautiful.

This point explains why abortive attempts to "fix" the s-expression syntax are
about as old as the syntax itself.

------
smanek
As my old boss used to say:

"JavaScript is my favorite language with curly braces" (we were lispers)

------
martinflack
JavaScript = subset(C) + subset(Lisp)

~~~
cheponis
More like SyntaxOf(C) + subset(Lisp)

------
d0mine
Just a side note:

 _acceptOnlyIf_ name doesn't tell what the function does. _acceptEach_ or
_acceptAll_ could be a clearer alternatives (at least for a python programmer
(there are _any()_ and _all()_ general functions in Python)).

------
volida
javascript is javascript, i don't see the need to say it's C with Lisp...

