Many people do not realize it, but JavaScript is a syntactically sugared dialect of LISP. The same goes to Logo, a simple language designed for kids, usually taught at schools.
What makes JavaScript a Lisp? I associate Lisps with a small but immensely expressive core, powerful metaprogramming facilities, a very simple syntax, and an emphasis on linked lists as the building block of syntax and, at least historically, of everything else, too. JavaScript has maybe one of those.
2. Everything is a dictionary (globals, locals, objects, prototypes). This is a direct result of relying on LISP notion of an 'env'
3. Functions are first-class citizens
4. JavaScript is a dynamic language
LISPs are fairly easy to spot. Their cores are minimal Scheme-like implementations with everything on top being a syntatic sugar over a few basic concepts.
This approach makes the implementations surprisingly concise and powerful.
JavaScript is not a LISP (aka LISt Processor) because of these properties:
* Lisp is based on efficient procedures (usually with lexical scoping), not objects with properties (-> dictionaries) and complex scoping.
* Lisp has a code representation based on lists of symbols (and other atoms) and an evaluator model for that. Identifiers in code are symbols. This is typically used both internally and externally (as textual source code).
* Lisp is doing list processing at its core and applies it to itself.
* Lisp provides forms of source transformations based on list processing: macros, ...
JavaScript might be considered to be some non-symbolic non-list-processing Lisp/Scheme derived language, turned into an object-oriented language.
That's cheating, with LISP just being a method for manipulating abstract syntax trees pretty much all languages are syntactically sugared dialects of it.
If you never separate those two again, you will have lost the ability to reason about programming at the various levels of abstraction... which would be a net loss, not a net win.
This can work as simultaneous win for both disciplines - one can apply math apparatus on programs, and design paradigms of programming on math.
This is exactly what happens when one tries to create an iO obfuscator mentioned in the article by using FHE encryption.
No way one can do that unless they understand how deeply information and data, computation and math are intervened together.
Touching the LISP is enlightening experience that allows to find all those missing links between aforementioned disciplines. Especially by creating a simple LISP machine in your language of choice. You will touch the holy grail of computation and the world will never be the same again.
All programs can be mapped to a more traditionally mathematical representation, no matter the level of abstraction. You gain reasoning ability, nothing is lost.
Programming language research has also shown that there are many mathematical structures, e.g. in lambda calculus, category theory, graph theory etc. that map directly to useful computational structures. These tend to be more rigorously defined and more generic than the programming equivalents, which are often limited, ad-hoc, special case instantiations of more general structures.
This argues for the opposite of your claim: if you want to reason about programming, you are seriously limiting yourself and your ability to reason about programming by ignoring the mathematical models that underlie the code you're working with.
Could you expand on this? I’m not quite sure what you mean. Are you suggesting that there are levels of abstraction in programming that can’t be modelled mathematically?
Let's say I'm working on a user interface. Thinking of it in terms of lambda calculus instead of user interaction is... let's call it sub-optimal, even though the code can be thought of in terms of lambda calculus.
Now, you can come up with some metrics to mathematically analyze certain aspects of the user interaction. I don't think that's what garganzol was talking about, though.
you can come up with some metrics to mathematically analyze certain aspects of the user interaction
And we have done that! Fitts’ law [1] gives us a very good way of quantifying certain aspects of user interface design. I can’t tell you how many UIs I’ve used (lost count) that have ignored this very basic principle and as a result they’re extremely frustrating to use.
In any case, it may not be what garganzol was talking about, but it did resemble a comment I’ve seen made many times. In the vast majority of cases I’ve seen, people who claim that math is inapplicable to some problem are completely unaware of a rich and storied field of mathematics dedicated to that topic.
Sure. But like TheRealPomax said, that's a different level of abstraction. If you need to be thinking in terms of Fitts' Law, and you're thinking of your code in terms of lambda calculus-level math, you're going to have a rough time.
That's a weird interpretation. Usually when you can consider things to be two sides of the same coin then it's a sign that you can reason about them at more levels of abstraction.
Like most insights it's very hard to stop seeing the connection, but that's not usually a bad thing.
22 comments
[ 3.6 ms ] story [ 63.6 ms ] threadOnce you get LISP you will never separate math and programming again. Two slightly different facets of the very same computational thing.
Many people do not realize it, but JavaScript is a syntactically sugared dialect of LISP. The same goes to Logo, a simple language designed for kids, usually taught at schools.
1. Minimal core modeled on Scheme
2. Everything is a dictionary (globals, locals, objects, prototypes). This is a direct result of relying on LISP notion of an 'env'
3. Functions are first-class citizens
4. JavaScript is a dynamic language
LISPs are fairly easy to spot. Their cores are minimal Scheme-like implementations with everything on top being a syntatic sugar over a few basic concepts.
This approach makes the implementations surprisingly concise and powerful.
* Lisp is based on efficient procedures (usually with lexical scoping), not objects with properties (-> dictionaries) and complex scoping.
* Lisp has a code representation based on lists of symbols (and other atoms) and an evaluator model for that. Identifiers in code are symbols. This is typically used both internally and externally (as textual source code).
* Lisp is doing list processing at its core and applies it to itself.
* Lisp provides forms of source transformations based on list processing: macros, ...
JavaScript might be considered to be some non-symbolic non-list-processing Lisp/Scheme derived language, turned into an object-oriented language.
This is exactly what happens when one tries to create an iO obfuscator mentioned in the article by using FHE encryption.
No way one can do that unless they understand how deeply information and data, computation and math are intervened together.
Touching the LISP is enlightening experience that allows to find all those missing links between aforementioned disciplines. Especially by creating a simple LISP machine in your language of choice. You will touch the holy grail of computation and the world will never be the same again.
Programming language research has also shown that there are many mathematical structures, e.g. in lambda calculus, category theory, graph theory etc. that map directly to useful computational structures. These tend to be more rigorously defined and more generic than the programming equivalents, which are often limited, ad-hoc, special case instantiations of more general structures.
This argues for the opposite of your claim: if you want to reason about programming, you are seriously limiting yourself and your ability to reason about programming by ignoring the mathematical models that underlie the code you're working with.
Now, you can come up with some metrics to mathematically analyze certain aspects of the user interaction. I don't think that's what garganzol was talking about, though.
And we have done that! Fitts’ law [1] gives us a very good way of quantifying certain aspects of user interface design. I can’t tell you how many UIs I’ve used (lost count) that have ignored this very basic principle and as a result they’re extremely frustrating to use.
In any case, it may not be what garganzol was talking about, but it did resemble a comment I’ve seen made many times. In the vast majority of cases I’ve seen, people who claim that math is inapplicable to some problem are completely unaware of a rich and storied field of mathematics dedicated to that topic.
[1] https://en.wikipedia.org/wiki/Fitts%27s_law
Like most insights it's very hard to stop seeing the connection, but that's not usually a bad thing.
Motivation gained to do a MSc in Statistics.
> https://news.ycombinator.com/submitted?id=altro
Many links point to Amazon, but there are some that point to free stuff.