Re:Mathematics and Computation
by TheRealPomax on Monday December 30, 2019 @12:58PM
(#21915288)
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.
Re:Mathematics and Computation
by antonvs on Monday December 30, 2019 @02:53PM
(#21916114)
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.
Re:Mathematics and Computation
by garganzol on Monday December 30, 2019 @02:32PM
(#21915982)
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.
Re:Mathematics and Computation
by contravariant on Monday December 30, 2019 @05:50PM
(#21917405)
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.
Re:Mathematics and Computation
by chongli on Monday December 30, 2019 @03:21PM
(#21916337)
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?
Re:Mathematics and Computation
by AnimalMuppet on Monday December 30, 2019 @03:45PM
(#21916559)
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.
Re:Mathematics and Computation
by chongli on Monday December 30, 2019 @04:02PM
(#21916694)
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.
Re:Mathematics and Computation
by AnimalMuppet on Monday December 30, 2019 @04:22PM
(#21916824)
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.
Re:Mathematics and Computation
by garganzol on Monday December 30, 2019 @02:24PM
(#21915930)
Not born, but at least educated.
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.
Re:Mathematics and Computation
by aratakareigen on Monday December 30, 2019 @04:14PM
(#21916773)
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.
Re:Mathematics and Computation
by garganzol on Tuesday December 31, 2019 @05:33AM
(#21920105)
JavaScript is a LISP due to following properties:
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.
Re:Mathematics and Computation
by lispm on Tuesday December 31, 2019 @05:58AM
(#21920198)
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.
Re:Mathematics and Computation
by contravariant on Monday December 30, 2019 @05:51PM
(#21917411)
That's cheating, with LISP just being a method for manipulating abstract syntax trees pretty much all languages are syntactically sugared dialects of it.
Once you get LISP you will never separate math and programming again. Two slightly different facets of the very same computational thing.
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.
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.
Like most insights it's very hard to stop seeing the connection, but that's not usually a bad thing.
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
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.
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.