Mathematics and Computation
math.ias.edu
math.ias.edu
Once 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.
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.
Many links point to Amazon, but there are some that point to free stuff.