7 ms·

Yes, JavaScript Is a Lisp

21 points by Akronymus 4y ago

bitsavers 4y ago
"But saying that JavaScript is “a” Lisp when talking about JavaScript… That’s a different matter. It makes one pause. The obvious response is to ask “In what way?” This leads to conversations about recursion and trampolining and the use of IIFEs to create block scope." At which point the author should have SAID something, instead of just being clever.
- sublinear 4y ago
  > I do not think it adds value to thinking about Scheme or Lisp to think that there is a meaningful relationship between Scheme or Lisp and JavaScript. but I do think it is interesting and productive to think about what JavaScript draws from Scheme and/or Lisp, and to that end I often say that JavaScript is “a” Lisp when talking about JavaScript. The summary gets to the point well enough... you'd expect the point to be there rather than in the middle of the post.
- readthenotes1 4y ago
  He had to say something clever because the obvious answer is that JavaScript is not a lisp because it does not use a superabundance of parentheses.
- hayley-patton 4y ago
  Which of these conversation topics relate to Lisp?
sourceless 4y ago
It's not homoiconic, which makes it not a lisp for me.
- dgb23 4y ago
  That's the most fundamental one, plus the lack of expression based syntax (!), macros, quoting, (truly) interactive development... It seems to me that there isn't much there outside of proper closures and data literals? Go has those as well and it's hard to compare to a Lisp. When JS was invented it was inspired by Scheme and apparently having those two features was more out of the ordinary then. But that's hardly true today.
  - easrng 4y ago
    wdym, JS has good interactive development with browser devtools. and you can write pretty much all js as expressions if you want to.
    - kaba0 4y ago
      That’s just as true of Java nowadays, though. Plenty of languages have REPLs.
    - dgb23 4y ago
      I agree, I write JS professionally. But there is a _qualitative_ difference between interactive development between JS and a Lisp like Clojure. And "pretty much" is also qualitatively less expressive than "everything is an expression". I write expression based, simple, mostly functional JS and I use tools to make that as interactive as is practical. But there's still a lot of friction and differences between that and development with a Lisp (in my case Clojure).
- Barrin92 4y ago
  The entire Javascript language is not striclty homoiconic, then again many lisps aren't if you're exceedingly hawkish about that term, but the "code is data" mentality is obviously present in the way Javascript and JSON interact.
karmakaze 4y ago
It's no accident. If you read any early historical accounts[0] of Mocha -> LiveScript -> JavaScript, you can see why. From the linked: > What was meant to be a Scheme for the browser turned into something very different. The pressure to close the deal with Sun and make Mocha a scripting companion to Java forced Eich's hand. A Java-like syntax was required, and familiar semantics for many common idioms was also adopted. So Mocha was not like Scheme at all. It looked like a dynamic Java, but underneath it was a very different beast: a premature lovechild of Scheme and Self, with Java looks. [0] https://auth0.com/blog/a-brief-history-of-javascript/ https://auth0.com/blog/a-brief-history-of-javascript/
neilv 4y ago
Our doom was pretty much sealed when Norvig called Python a Lisp. :) https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html
gabrielsroka 4y ago
From 2013
neoncontrails 4y ago
Absolutely zero information in this article.
deterministic 4y ago
I don’t agree. AST-as-syntax (the S-expressions) is the thing that makes a language a Lisp. Everything else (macros/non-typed/GC/Lambdas/REPL/…) is available in other languages. Note that it is AST-as-syntax that is important. Not the concrete S-expressions syntax. You could use XML or JSON to write the AST-as-syntax instead and you would have a Lisp. However S-expressions are much more concise that XML/JSON.
- lispm 4y ago
  Lisp code is written in a simpler notation than ASTs, it's written as nested lists of objects. Hierarchical data-structure: the s-expressions are based on nested lists of arbitrary data. Like symbols, numbers, strings and many others. Lisp code is then written as s-expressions, given some syntax rules, which s-expressions are valid Lisp expressions. S-expressions are no abstract syntax trees, since they capture no syntax information about the meaning of the symbols. That gives an extra degree of freedom: the input to the Lisp evaluator is not an AST (either read or generated by a parser), it's just nested lists of symbols and other objects. That means for example that Lisp macros accept code in an arbitrary syntax. For example this is valid Lisp code when LOOP is a macro and implements its own syntax. (loop for i upto n and j in list when (and (= i j) i) sum it) We could write above as (loop for for upto n and in in list when (and (= for in) for) sum it) and it would still work. The s-expression does not encode basic information like what the meaning of the identifier is. That depends on the macro. An AST would encode what the construct is: operator, variable, class, ... Lisp s-expressions don't do that. So it's important for Lisp that the code is NOT written as an AST. It's just tree-like -> in the Lisp case it's nested lists of symbols and other atoms.
  - deleted 4y ago
    [deleted]
  - deterministic 4y ago
    > Lisp code is written in a simpler notation than ASTs, it's written as nested lists of objects. That is exactly what a simple AST is: A tree structure representing the semantics of the code you wrote with no syntax info. > Hierarchical data-structure: the s-expressions are based on nested lists of arbitrary data. Like symbols, numbers, strings and many others. This is exactly what AST’s do as well. Whether it contains the semantics of Lisp code or (say) C code. > S-expressions are no abstract syntax trees, since they capture no syntax information about the meaning of the symbols. This is a misunderstanding. AST’s capture semantics not syntax. You can pretty print AST’s into a different semantically equivalent syntax if you want. That is what some compilers do: Lisp syntax -> AST -> C syntax. > That gives an extra degree of freedom: the input to the Lisp evaluator is not an AST (either read or generated by a parser), it's just nested lists of symbols and other objects. This is not correct. The input to Lisp macros are runtime data structures. Not syntax. Different Lisp interpreters/compiles use different runtime representations. Typically linked lists. The nodes in the linked list typically have a lot of additional information like type information, column/line data for error reporting etc. > That means for example that Lisp macros accept code in an arbitrary syntax. Nope. As I said above, macros accept runtime data. You need to clearly separate syntax from semantics/runtime in your head to understand what is really going on. > For example this is valid Lisp code when LOOP is a macro and implements its own syntax. Macros are runtime code executed during the parser stage. It has nothing to do with syntax. Other languages execute macros the same way. That’s why I said above that macros aren’t unique to Lisp. > The s-expression does not encode basic information like what the meaning of the identifier is. That is correct. You can define different semantics to the same S-expression. However for the S-expression to be interpreted as Lisp you need to use the Lisp semantics to run it. I use S-expressions all the time for configuration files etc. However I use a different semantics. So the S-expression might look like Lisp but it isn’t Lisp in those cases. > An AST would encode what the construct is: operator, variable, class, ... Lisp s-expressions don't do that. Nope that is not true. A typical AST for Lisp would have the following semantics categories: List, Symbol, Integer, Float, String. That’s it. There aren’t many. That’s what makes Lisp so easy to implement. In other languages you might have 20+. That’s exactly what I mean when I say that the Lisp syntax directly represents the AST. And no other language does. That is the one feature that makes Lisp unique.
musicale 4y ago
Have people forgotten The Little JavaScripter? "Because of this deep similarity, all of the functions in The Little Schemer can be written in JavaScript." https://www.crockford.com/little.html https://www.crockford.com/little.html (HN readers may also appreciate the JavaScript Y combinator.)

21 points by Akronymus 4y ago

"But saying that JavaScript is “a” Lisp when talking about JavaScript… That’s a different matter. It makes one pause. The obvious response is to ask “In what way?” This leads to conversations about recursion and trampolining and the use of IIFEs to create block scope." At which point the author should have SAID something, instead of just being clever.

sublinear 4y ago
> I do not think it adds value to thinking about Scheme or Lisp to think that there is a meaningful relationship between Scheme or Lisp and JavaScript. but I do think it is interesting and productive to think about what JavaScript draws from Scheme and/or Lisp, and to that end I often say that JavaScript is “a” Lisp when talking about JavaScript. The summary gets to the point well enough... you'd expect the point to be there rather than in the middle of the post.
readthenotes1 4y ago
He had to say something clever because the obvious answer is that JavaScript is not a lisp because it does not use a superabundance of parentheses.
hayley-patton 4y ago
Which of these conversation topics relate to Lisp?

sourceless 4y ago

It's not homoiconic, which makes it not a lisp for me.

dgb23 4y ago
That's the most fundamental one, plus the lack of expression based syntax (!), macros, quoting, (truly) interactive development... It seems to me that there isn't much there outside of proper closures and data literals? Go has those as well and it's hard to compare to a Lisp. When JS was invented it was inspired by Scheme and apparently having those two features was more out of the ordinary then. But that's hardly true today.
- easrng 4y ago
  wdym, JS has good interactive development with browser devtools. and you can write pretty much all js as expressions if you want to.
  - kaba0 4y ago
    That’s just as true of Java nowadays, though. Plenty of languages have REPLs.
  - dgb23 4y ago
    I agree, I write JS professionally. But there is a _qualitative_ difference between interactive development between JS and a Lisp like Clojure. And "pretty much" is also qualitatively less expressive than "everything is an expression". I write expression based, simple, mostly functional JS and I use tools to make that as interactive as is practical. But there's still a lot of friction and differences between that and development with a Lisp (in my case Clojure).
Barrin92 4y ago
The entire Javascript language is not striclty homoiconic, then again many lisps aren't if you're exceedingly hawkish about that term, but the "code is data" mentality is obviously present in the way Javascript and JSON interact.

karmakaze 4y ago

It's no accident. If you read any early historical accounts[0] of Mocha -> LiveScript -> JavaScript, you can see why. From the linked: > What was meant to be a Scheme for the browser turned into something very different. The pressure to close the deal with Sun and make Mocha a scripting companion to Java forced Eich's hand. A Java-like syntax was required, and familiar semantics for many common idioms was also adopted. So Mocha was not like Scheme at all. It looked like a dynamic Java, but underneath it was a very different beast: a premature lovechild of Scheme and Self, with Java looks. [0] https://auth0.com/blog/a-brief-history-of-javascript/ https://auth0.com/blog/a-brief-history-of-javascript/

neilv 4y ago

Our doom was pretty much sealed when Norvig called Python a Lisp. :) https://norvig.com/python-lisp.html https://norvig.com/python-lisp.html

gabrielsroka 4y ago

From 2013

neoncontrails 4y ago

Absolutely zero information in this article.

deterministic 4y ago

I don’t agree. AST-as-syntax (the S-expressions) is the thing that makes a language a Lisp. Everything else (macros/non-typed/GC/Lambdas/REPL/…) is available in other languages. Note that it is AST-as-syntax that is important. Not the concrete S-expressions syntax. You could use XML or JSON to write the AST-as-syntax instead and you would have a Lisp. However S-expressions are much more concise that XML/JSON.

lispm 4y ago
Lisp code is written in a simpler notation than ASTs, it's written as nested lists of objects. Hierarchical data-structure: the s-expressions are based on nested lists of arbitrary data. Like symbols, numbers, strings and many others. Lisp code is then written as s-expressions, given some syntax rules, which s-expressions are valid Lisp expressions. S-expressions are no abstract syntax trees, since they capture no syntax information about the meaning of the symbols. That gives an extra degree of freedom: the input to the Lisp evaluator is not an AST (either read or generated by a parser), it's just nested lists of symbols and other objects. That means for example that Lisp macros accept code in an arbitrary syntax. For example this is valid Lisp code when LOOP is a macro and implements its own syntax. (loop for i upto n and j in list when (and (= i j) i) sum it) We could write above as (loop for for upto n and in in list when (and (= for in) for) sum it) and it would still work. The s-expression does not encode basic information like what the meaning of the identifier is. That depends on the macro. An AST would encode what the construct is: operator, variable, class, ... Lisp s-expressions don't do that. So it's important for Lisp that the code is NOT written as an AST. It's just tree-like -> in the Lisp case it's nested lists of symbols and other atoms.
- deleted 4y ago
  [deleted]
- deterministic 4y ago
  > Lisp code is written in a simpler notation than ASTs, it's written as nested lists of objects. That is exactly what a simple AST is: A tree structure representing the semantics of the code you wrote with no syntax info. > Hierarchical data-structure: the s-expressions are based on nested lists of arbitrary data. Like symbols, numbers, strings and many others. This is exactly what AST’s do as well. Whether it contains the semantics of Lisp code or (say) C code. > S-expressions are no abstract syntax trees, since they capture no syntax information about the meaning of the symbols. This is a misunderstanding. AST’s capture semantics not syntax. You can pretty print AST’s into a different semantically equivalent syntax if you want. That is what some compilers do: Lisp syntax -> AST -> C syntax. > That gives an extra degree of freedom: the input to the Lisp evaluator is not an AST (either read or generated by a parser), it's just nested lists of symbols and other objects. This is not correct. The input to Lisp macros are runtime data structures. Not syntax. Different Lisp interpreters/compiles use different runtime representations. Typically linked lists. The nodes in the linked list typically have a lot of additional information like type information, column/line data for error reporting etc. > That means for example that Lisp macros accept code in an arbitrary syntax. Nope. As I said above, macros accept runtime data. You need to clearly separate syntax from semantics/runtime in your head to understand what is really going on. > For example this is valid Lisp code when LOOP is a macro and implements its own syntax. Macros are runtime code executed during the parser stage. It has nothing to do with syntax. Other languages execute macros the same way. That’s why I said above that macros aren’t unique to Lisp. > The s-expression does not encode basic information like what the meaning of the identifier is. That is correct. You can define different semantics to the same S-expression. However for the S-expression to be interpreted as Lisp you need to use the Lisp semantics to run it. I use S-expressions all the time for configuration files etc. However I use a different semantics. So the S-expression might look like Lisp but it isn’t Lisp in those cases. > An AST would encode what the construct is: operator, variable, class, ... Lisp s-expressions don't do that. Nope that is not true. A typical AST for Lisp would have the following semantics categories: List, Symbol, Integer, Float, String. That’s it. There aren’t many. That’s what makes Lisp so easy to implement. In other languages you might have 20+. That’s exactly what I mean when I say that the Lisp syntax directly represents the AST. And no other language does. That is the one feature that makes Lisp unique.

musicale 4y ago

Have people forgotten The Little JavaScripter? "Because of this deep similarity, all of the functions in The Little Schemer can be written in JavaScript." https://www.crockford.com/little.html https://www.crockford.com/little.html (HN readers may also appreciate the JavaScript Y combinator.)