TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Programming as Theory Building (1985) [pdf]

211 点作者 beryilma4 个月前

13 条评论

peterkelly4 个月前
One of the most important papers in software engineering, which I believe everyone in this profession should read and internalize.<p>Every time I see another startup trying use LLMs for code generation I sigh in despair. As AI technology improves and becomes better at producing code, what looks like a win in the short term will end up creating more and more code that has been created without a human going through the necessary thought processes and problem solving steps to build the theory of the software as described in this paper.<p>It&#x27;s also why its critically important for companies to do what they can to retain the people who built the software in the first place, or at least ensure there&#x27;s enough continuity as new people join the team so they can build their mental model by working alongside the original developers.
评论 #42594586 未加载
评论 #42595208 未加载
评论 #42594738 未加载
评论 #42597419 未加载
评论 #42596774 未加载
triska4 个月前
As relevant as ever, arguably more relevant than ever as more programs are being written and need to be adapted, in more and more complex domains.<p>Note what Naur means with <i>Theory</i> here. Quoting from the paper:<p><i>&quot;What will be considered here is the suggestion that the programmers&#x27; knowledge properly should be regarded as a theory, in the sense of Ryle [Gilbert Ryle, The Concept of Mind, 1946]. Very briefly, a person who has or possesses a theory in this sense knows how to do certain things and in addition can support the actual doing with explanations, justifications, and answers to queries, about the activity of concern.&quot;</i><p>This is not &quot;theory&quot; in the sense we sometimes encounter in colloquial speech in the sense of (exclusively) &quot;assumption&quot;, especially not with the connotation &quot;<i>unjustified</i> assumption&quot;. It is also not a set of rules:<p>&quot;<i>The dependence of a theory on a grasp of certain kinds of similarity between situations and events of the real world gives the reason why the knowledge held by someone who has the theory could not, in principle, be expressed in terms of rules. In fact, the similarities in question are not, and cannot be, expressed in terms of criteria, no more than the similarities of many other kinds of objects, such as human faces, tunes, or tastes of wine, can thus be expressed.</i>&quot;<p>Yet, it plays a central role in programming:<p><i>&quot;For a program to retain its quality it is mandatory that each modification is firmly grounded in the theory of it. Indeed, the very notion of qualities such as simplicity and good structure can only be understood in terms of the theory of the program, since they characterize the actual program text in relation to such program texts that might have been written to achieve the same execution behaviour, but which exist only as possibilities in the programmer&#x27;s understanding.&quot;</i>
softwaredoug4 个月前
This has so many implications for software team design<p>Like hiring that one unicorn dev to solve X hard problem isn&#x27;t a great &quot;theory building&quot; exercise. It can build theories for that one person, but without feedback they&#x27;re never tested, they&#x27;re never adopted by the whole team<p>So you actually NEED juniors, &#x27;stupid&#x27; questions, outside points of view, and ways of openly and scientifically evaluating theories instead of defaulting to the authority of supposed experts. You also need to retain seniors who have context and a good historical working definition of the problem.<p>But a lot of teams are focused on just the next problem and &quot;shipping it&quot;. Rather than using &quot;shipping&quot; to help the team develop a better theory of the problem.<p>The value isn&#x27;t what&#x27;s shipped, its the working knowledge of the team.
评论 #42598612 未加载
dang4 个月前
Related. Others?<p><i>Programming as Theory Building (1985)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38907366">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38907366</a> - Jan 2024 (12 comments)<p><i>Programming as Theory Building (1985) [pdf]</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37263121">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37263121</a> - Aug 2023 (36 comments)<p><i>Programming as Theory Building (1985) [pdf]</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33659795">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33659795</a> - Nov 2022 (1 comment)<p><i>Naur on Programming as Theory Building (1985) [pdf]</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31500174">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31500174</a> - May 2022 (4 comments)<p><i>Naur on Programming as Theory Building (1985) [pdf]</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30861573">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30861573</a> - March 2022 (3 comments)<p><i>Programming as Theory Building (1985)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23375193">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23375193</a> - June 2020 (35 comments)<p><i>Programming as Theory Building (1985) [pdf]</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20736145">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20736145</a> - Aug 2019 (11 comments)<p><i>Peter Naur – Programming as Theory Building (1985) [pdf]</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10833278">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10833278</a> - Jan 2016 (15 comments)<p><i>Naur’s “Programming as Theory Building” (2011)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7491661">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7491661</a> - March 2014 (14 comments)<p><i>Programming as Theory Building (by Naur of BNF)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=121291">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=121291</a> - Feb 2008 (2 comments)
digdugdirk4 个月前
Relevant episode from a great podcast:<p><a href="https:&#x2F;&#x2F;futureofcoding.org&#x2F;episodes&#x2F;061.html" rel="nofollow">https:&#x2F;&#x2F;futureofcoding.org&#x2F;episodes&#x2F;061.html</a>
评论 #42597459 未加载
评论 #42621578 未加载
myflash134 个月前
This also explains the unreasonable effectiveness of solo programmers and small teams, and why the famous adage is so true: adding programmers to a late project makes it even later.
stevan4 个月前
It seems to me that one consequence of the &quot;Theory Building View&quot; is that: instead of focusing on delivering the artifact or the documentation of said artifact, one should instead focus on documenting how the artifact can be re-implemented by somebody else. Or in other words optimise for &quot;revival&quot; of a &quot;dead&quot; programs.<p>This seems especially relevant in open source, or in blog posts &#x2F; papers, where we rarely have teams which continuously transfer theories to newcomers. Focusing on documenting &quot;how it works under the hood&quot; and helping others re-implement your ideas also seems more useful to break silos between programming language communities.<p>For example a blog post that introduces some library in some programming language and only explains how to use its API to solve some concrete problems is of little use to programmers that use other programming languages, compared to a post which would explain how the library works on a level where other programmers could build a theory and re-implement it themselves in their language of choice.<p>I also feel like there&#x27;s a connection between the &quot;Theory Building View&quot; and the people that encourage rewriting your software. For example in the following interview[0] Joe Armstrong explains that he often wrote a piece of code and the next day he threw it away and rewrote it from scratch. Perhaps this has to do with the fact that after your first iteration, you&#x27;ve a better theory and therefore in a better position to implement it in a better way?<p>I also believe there&#x27;s some connection to program size here. In the early days of Erlang it was possible to do a total rewrite of the whole language in less than a week. New language features were added in one work session, if you couldn’t get the idea out of your brain and code it up in that time then you didn’t do it, Joe explained[1] (17:10).<p>In a later talk[2] he elaborated saying:<p><pre><code> “We need to break systems down into small understandable components with message passing between them and with contracts describing whats going on between them so we can understand them, otherwise we just won’t be able to make software that works. I think the limit of human understandability is something like 128KB of code in any language. So we really need to box things down into small units of computation and formally verify them and the protocols in particular.” </code></pre> I found the 128KB interesting. It reminds me of Forth here you are forced to fit your code in blocks (1024 chars or 16 lines on 64 characters).<p>Speaking of Forth, Chuck Moore also appears to be a rewriter. He said[3] something in similar:<p><pre><code> “Instead of being rewritten, software has features added. And becomes more complex. So complex that no one dares change it, or improve it, for fear of unintended consequences. But adding to it seems relatively safe. We need dedicated programmers who commit their careers to single applications. Rewriting them over and over until they’re perfect.” (2009) </code></pre> Chuck re-implemented the his Forth many times, in fact Forth’s design seems to be centered around being easily re-implementable on new hardware (this was back when new CPUs had new instruction sets). Another example is Chuck’s OKAD, VLSI design tools, to which he comments:<p><pre><code> “I’ve spent more time with it that any other; have re-written it multiple times; and carried it to a satisfying level of maturity.” </code></pre> Something I’m curious about is: what would tools and processes that encourage the &quot;Theory Building View&quot; look like?<p>[0]: <a href="https:&#x2F;&#x2F;vimeo.com&#x2F;1344065#t=8m30s" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;1344065#t=8m30s</a><p>[1]: <a href="https:&#x2F;&#x2F;dl.acm.org&#x2F;action&#x2F;downloadSupplement?doi=10.1145%2F1238844.1238850&amp;file=m6-armstrong-h.mov" rel="nofollow">https:&#x2F;&#x2F;dl.acm.org&#x2F;action&#x2F;downloadSupplement?doi=10.1145%2F1...</a><p>[2]: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;rQIE22e0cW8?t=3492" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;rQIE22e0cW8?t=3492</a><p>[3]: <a href="https:&#x2F;&#x2F;www.red-gate.com&#x2F;simple-talk&#x2F;opinion&#x2F;geek-of-the-week&#x2F;chuck-moore-geek-of-the-week&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.red-gate.com&#x2F;simple-talk&#x2F;opinion&#x2F;geek-of-the-wee...</a>
评论 #42594530 未加载
评论 #42594213 未加载
评论 #42596048 未加载
评论 #42595137 未加载
Abishek_Muthian4 个月前
Doesn’t declarative programming and by extension functional programming adhere more to the ethos of ‘Programming as Theory Building’ ?<p>I recently started building mobile apps using Flutter after a decade of developing apps using imperative programming languages and I’m really in love with the declarative nature of flutter.<p>Similarly for web development, I always loved HTML and so HTMX has been a boon for me. I’m using Go for backend, but I’ve been thinking whether I should move on to a proper functional programming language like Elixir with Phoenix since I’m liking declarative programming very much?
snikeris4 个月前
How good are LLMs at reducing code? For example, will they recognize a common problem and build an abstraction around it? I imagine that the solutions they produce tend to have a lot of repetition with small differences that could be improved by abstraction.
CoastalCoder4 个月前
Is there an OCR&#x27;d version of the provided paper?
评论 #42595672 未加载
评论 #42619314 未加载
pbw4 个月前
I always heard it as &quot;software development is an exercise in knowledge acquisition.&quot;
评论 #42599520 未加载
fussylogic4 个月前
better quality scan<p><a href="https:&#x2F;&#x2F;pages.cs.wisc.edu&#x2F;~remzi&#x2F;Naur.pdf" rel="nofollow">https:&#x2F;&#x2F;pages.cs.wisc.edu&#x2F;~remzi&#x2F;Naur.pdf</a>
评论 #42597272 未加载
n00b1014 个月前
I think you nerds need to stop reading obsolete academic fad papers from 1985. Imagine if your girlfriend was unironically reading articles of Cosmo from 1985 to figure out what to wear.<p>A computer program is a &quot;model&quot; of some thing. For example:<p><pre><code> float m = 1e10f; float a = 9.8f; float F = m*a; </code></pre> Another example:<p><pre><code> if(employee is still employed): float paycheque = getSalary(employee); else: float paycheque = 0.00f;</code></pre>
评论 #42597427 未加载
评论 #42599179 未加载
评论 #42600418 未加载