Programming as Theory Building (1985)

https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f342fb1

by thunderbong • 3 years ago

50 12 3 years ago

gist.github.com

tmaly• 3 years ago

Very cool idea

dang• 3 years ago

Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=37263121 - Aug 2023 (36 comments)

Naur on Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=31500174 - May 2022 (4 comments)

Naur on Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=30861573 - March 2022 (3 comments)

Programming as Theory Building (1985) - https://news.ycombinator.com/item?id=23375193 - June 2020 (35 comments)

Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=20736145 - Aug 2019 (11 comments)

Peter Naur – Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=10833278 - Jan 2016 (15 comments)

Naur’s “Programming as Theory Building” (2011) - https://news.ycombinator.com/item?id=7491661 - March 2014 (14 comments)

Programming as Theory Building (by Naur of BNF) - https://news.ycombinator.com/item?id=121291 - Feb 2008 (2 comments)

dabei• 3 years ago

Great read, thanks for sharing. Interesting to think about the role AI would play in theory building.

andriesm• 3 years ago

Pretty good, yet obvious to a master programmer, which I define as someone that programs on the conceptual level and ubderstands the thinking about code deserves a lot more attention than the mere effort of banging out code to realise a specific desired output result.

Because most programmers are NOT master programmers, they just bang out code that is a means to an end - bang out code that other people cannot read and immediately retrieve the highlevel concepts that sits behind it.

Master programmers instead make sure that at the highest level the code first explicitly encodes the conceptual design, and then at a lower level of abstraction does all the necessary things that let the code actually produce the required program result.

A master programmer never divorces the logical conceptuap structure ("the theory" in the terminology of this article) from the implementation code.

Most peogrammers however bang on code in ways that quickly and radically diverge from the conceptual design, and they don't care because as long as the program produces the desired results, the code is "perfect" in their minds, never mind that they themselves won't be able to understand the code they wrote today in six months time!

A master programmer can go back to a code base that he hasn't seen in 10 years, and be be productive on it within an hour, because all the core concepts ("the theory") is explicitly encoded in the program source code.

dambi0• 3 years ago

Not impossible that I misread the article, but isn’t one of the points that the theory can’t be explicitly encoded in the code? Again, perhaps I ought to reread it, and I don’t disagree with the general thrust of your comment.

Koshkin2• 3 years ago

This has reminded me of Grothendieck's idea of two styles in mathematics:

https://www.landsburg.com/grothendieck/mclarty1.pdf

corethree3• 3 years ago

No it's not. We build programs with less insight into theory than a civil engineer who builds bridges.

It's all black box experimental testing with little theory. That's why we have unit tests.

When there's a complete theory about something. You can actually build that something very accurately as a theoretical model and rely on that model as an accurate blue print for the real thing. No such theory exists for programming. The complex application you designed has no theory behind it at all.

bridge builders on the other hand first build the bridge theoretically before building the actual bridge. There's some testing but physical engineers don't rely on testing as much as programmers do.

Imagine if we built airplanes the same way we build programs. Let's pretend those airplane builders just use their gut feelings like programmers do and then those builders verify their built planes with a suite of unit tests only.

First off the cost would be insane as likely a failed unit test is a destroyed plane.

Hence why all other engineers besides software rely more on theory while software engineers rely more on the scientific method which is largely less effective.

Koshkin2• 3 years ago

Depends. There's a pretty good theory on building compilers, for instance.

One interesting observation made in the post, on the other hand, is that the source code of a program does not necessary contain the idea(s) behind the program or even its intent. I can attest to that - it is indeed often the case that people who are involved in writing or updating a program's code may have different levels of the (mis)understanding of the code itself and, sure enough, of the "theory" behind it. (Unit tests reflect this situation.)

corethree3• 3 years ago

"Depends" is a misnomer. There are exceptions when it "depends" but the overwhelming majority of programs written are not theory based at all.

So much so. that the alternative is negligible. The language compilers compile is theory based but the implementation of said compiler has a huge part of it getting unit tested and not theory based at all.

mmcdermott2• 3 years ago

No such theory exists for programming. The complex application you designed has no theory behind it at all.

The theory isn't a theory of programming or software engineering, but of the problem domain. From the paper:

In term's of Ryle's notion of theory, what has to be built by the programmer is a theory of how certain affairs of the world will be handled by, or supported by, a computer program.

I've worked on plenty of commercial software with a theory of how some particular domain ought to be handled. A business process is almost always the starting point for the theory.

Similarly, software like Make (targets + recipes), Xorg (client-server model) or TiddlyWiki (reusable content + transclusion) have specific theories about how their respective tasks ought to be thought of.

corethree3• 3 years ago

So can you prove things with this "theory" are there theorems? What are the axioms?

More like there is no theory. You just build it off of your gut feeling. Maybe you use big words like "dependency injection" or "domain knowledge" to make it feel like you have a theory but really you don't.

When you have a theory, aspects of the design are calculated. Diagraming the architecture on a whiteboard is not theory. It's still gut feelings.

Programming as Theory Building (1985)

Related Stories