3 ms·

It's theory building based off of seat of your pants gut feelings. If you build a shack haphazardly out of sticks and glue that's also "theory building". If yo

It's theory building based off of seat of your pants gut feelings. If you build a shack haphazardly out of sticks and glue that's also "theory building". If you want to build something like number theory or a mathematical theory then you need to start your program with axioms and rules. Then from there compose your axioms via the rules to form the rest of your program. Your program should entirely be a composition of well thought out primitives. Unfortunately almost nobody does this. Rather then create a small set of axiomatic primitives to compose most people just add primitives at will to fix something. They don't think about how it will compose they just see a problem and shove in a new axiom or even modify existing primitives to make everything work until they get this ugly mess of a monster. A program designed like this ends up being made up of thousands of primitives, most primitives likely used once or twice only. Nothing composes. Technically your still theory building just like how building a house out of garbage, straw, glue and tape is theory building. But thinking this way and to build programs as layered well structured lego blocks that compose is hard. What can help us think this way? How do you make your programs more closer to a "theory" in the way we think of it? Is there a theory of theories that govern how primitives should compose that will help us think and actually construct programs that are more inline with what we think of "theory"? Yes. It's called algebra. Algebra based designs Haskell largely facilitates this style of programming. More then that the fundamental primitive of computing itself a function that takes data and processes that data to form new data in itself forms a composable algebra. Constructing logic as a composition of pure functions forms the basis of the algebra of computing then you use that framework to manipulate other algebras you designed and that ends up as a theory that looks like an actual theory. Here's a small example of what a "theoretical" program looks like: https://github.com/pyrofolium/parser_combinator_python/blob/master/main.py https://github.com/pyrofolium/parser_combinator_python/blob/... It's a JSON parser. I started with an axiom: func(string) -> Option<tokens, string> Parsers in essence are functions that take in strings and parse part of that string to output some tokens and the remaining unparsed string. It might return an error too. That is the axiom. From here I built a theory of parsing. How do parsers compose to form bigger parsers? What fundamental set of primitives do I need to build a JSON parser as a composition of simpler parsers? As I constructed the parser I constructed the theory which formed a base set of parser primitives I could compose to form bigger parsers. Biggerparser = smallerparser + othersmallerparser Unlike most custom parsers if you go through this code it's somewhat readable.

crabmusket 3y ago
Nair's use of "theory" in this paper is highly specific and instrumental. Section 4 covers it.
- corethree 3y ago
  We don't really call "Culinary arts" theory, it's more of a "art" Peter is largely not thinking deeply and as a result he defines "theory" in such a way that it refers to "Painting Portraits" as "theory" and lumps it with "The theory of Quantum Mechanics" Generally we don't refer to "Culinary arts" as theory while we do so with "Number theory." A subtle distinction in meaning exists in our subconscious and Naur simply didn't have the self awareness to see the distinction. That's what results in his largely informal and qualitative paper about mostly nothing. Yeah building a program about say E-commerce is Obviously building knowledge around e-commerce... call it "theory" if you want but in essence it's nothing new under the sun. You need to think in terms of the idea of "formal theory." Complex Number theory, The theory of general relativity. These things are distinctly in the same category as "knowledge" but refer to something more precise. Naur likely felt the distinction but failed to put his finger on it. Like many laymen, if you call Scientology a "theory" they think of it on the same professional level as the "theory of Gravity". It's largely what Peter is doing with programming... he's just using the word "theory" to give programming more legitimacy. He's not the only person to do this. Other bullshit like "Color theory" which chooses red, yellow and blue as primary colors is really just an arbitrary grouping that is only called "theory" to give it artificial legitimacy. The color sensors in your eyes are actually red, green and blue and color itself is actually a gradient of frequencies. What Naur failed to realize is that Programming is distinctly the perfect vehicle for formulating formal theories around any subject. Keyword: "formal" Imagine a theory of "e-commerce" as formal and rigorous as Newtonian Mechanics. But we almost never do this as programmers. Instead a program is more like "Culinary arts" a patch work of procedures and steps with no cohesion. I made a JSON parser in the link above. And that parser is built using formal algebraic theory. The entire parser is created as a formula. An equation of smaller parsers. It is literally the formation of a Formal theory of parsing. Or you can think of it as a Formal Algebra of parsing. Obviously there's a larger theory in academia on parsing. But in my program there's a little formal theory there. If programs are theory building. This is what is should be, this is what his paper should have been about. I think this was his intent, he just lacked the background to fully articulate and realize what is essentially a vague equivalence analogy between "programming" and "theory". Largely readers of the paper and people who agree with him fell for the same trope.

crabmusket 3y ago

Nair's use of "theory" in this paper is highly specific and instrumental. Section 4 covers it.

corethree 3y ago
We don't really call "Culinary arts" theory, it's more of a "art" Peter is largely not thinking deeply and as a result he defines "theory" in such a way that it refers to "Painting Portraits" as "theory" and lumps it with "The theory of Quantum Mechanics" Generally we don't refer to "Culinary arts" as theory while we do so with "Number theory." A subtle distinction in meaning exists in our subconscious and Naur simply didn't have the self awareness to see the distinction. That's what results in his largely informal and qualitative paper about mostly nothing. Yeah building a program about say E-commerce is Obviously building knowledge around e-commerce... call it "theory" if you want but in essence it's nothing new under the sun. You need to think in terms of the idea of "formal theory." Complex Number theory, The theory of general relativity. These things are distinctly in the same category as "knowledge" but refer to something more precise. Naur likely felt the distinction but failed to put his finger on it. Like many laymen, if you call Scientology a "theory" they think of it on the same professional level as the "theory of Gravity". It's largely what Peter is doing with programming... he's just using the word "theory" to give programming more legitimacy. He's not the only person to do this. Other bullshit like "Color theory" which chooses red, yellow and blue as primary colors is really just an arbitrary grouping that is only called "theory" to give it artificial legitimacy. The color sensors in your eyes are actually red, green and blue and color itself is actually a gradient of frequencies. What Naur failed to realize is that Programming is distinctly the perfect vehicle for formulating formal theories around any subject. Keyword: "formal" Imagine a theory of "e-commerce" as formal and rigorous as Newtonian Mechanics. But we almost never do this as programmers. Instead a program is more like "Culinary arts" a patch work of procedures and steps with no cohesion. I made a JSON parser in the link above. And that parser is built using formal algebraic theory. The entire parser is created as a formula. An equation of smaller parsers. It is literally the formation of a Formal theory of parsing. Or you can think of it as a Formal Algebra of parsing. Obviously there's a larger theory in academia on parsing. But in my program there's a little formal theory there. If programs are theory building. This is what is should be, this is what his paper should have been about. I think this was his intent, he just lacked the background to fully articulate and realize what is essentially a vague equivalence analogy between "programming" and "theory". Largely readers of the paper and people who agree with him fell for the same trope.