3 ms·

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 l

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.

garganzol 7y ago
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.
antonvs 7y ago
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.
chongli 7y ago
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?
- AnimalMuppet 7y ago
  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.
  - chongli 7y ago
    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. [1] https://en.wikipedia.org/wiki/Fitts%27s_law https://en.wikipedia.org/wiki/Fitts%27s_law
    - AnimalMuppet 7y ago
      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.
contravariant 7y ago
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.

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.

garganzol 7y ago

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.

antonvs 7y ago

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.

chongli 7y ago

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?

AnimalMuppet 7y ago
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.
- chongli 7y ago
  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. [1] https://en.wikipedia.org/wiki/Fitts%27s_law https://en.wikipedia.org/wiki/Fitts%27s_law
  - AnimalMuppet 7y ago
    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.

contravariant 7y ago

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.