Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming as Theory Building (1985) [pdf]

pages.cs.wisc.edu

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Programming as Theory Building (1985) [pdf]

#21

Post by WillAdams »

stevan wrote: post #4

It seems to me that one consequence of the "Theory Building View" 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 "revival" of a "dead" programs. This seems especially relevant in open source, or in blog posts / papers, where we rarely have team…

Sounds like a job for "Literate Programming":

http://literateprogramming.com/

I couldn't easily count the number of re-writes for my current project, but it keeps getting better, and each new iteration has had an updated architecture allowing for new features. When I re-wrote it as a Literate Program (first a .dtx, now a "normal" .tex) things got much more expressive and easier to work with.

Re: Programming as Theory Building (1985) [pdf]

#22

Post by quick_brown_fox »

lolinder wrote: post #12
szvsw wrote: post #8

Earlier quoted context omitted.

> 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 We might not be there yet (well we definitely are not) but it does not seem out of the question that within a generous 10 years we will have systems which can leverage graphs, descriptive language, interpreters, and so on to plan out and document and iterate and refi…

What you're describing is the siren call of No Code, which has been tempting manager-types for decades and which has so far failed every single time. The trouble with No Code is that your first paragraph is already my job description: I plan out and document and refine the structure of a problem and its architectural solution while simultaneously developing the system itself. The "sufficient explanation of the goals/…

> The "sufficient explanation of the goals/problem" is the code—anything less is totally insufficient.

somewhat in that spirit, I like Gerald Sussman's interpretation of software development as "problem solving by debugging-almost right plans", in e.g. https://www.youtube.com/watch?v=2MYzvQ1v8Ww

Re: Programming as Theory Building (1985) [pdf]

#23

Post by revskill »

peterkelly wrote: post #6

One of the most important papers in software engineering, which I believe everyone in this profession should read and internalize. 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 n…

I thought it's about solving Leetcode problems.

Re: Programming as Theory Building (1985) [pdf]

#26

Post by n00b101 »

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.

A computer program is a "model" of some thing. For example:

    float m = 1e10f;
    float a = 9.8f;
    float F = m*a;
Another example:

    if(employee is still employed):
       float paycheque = getSalary(employee);

    else: 
       float paycheque = 0.00f;

Re: Programming as Theory Building (1985) [pdf]

#27

Post by wwarner »

peterkelly wrote: post #6

One of the most important papers in software engineering, which I believe everyone in this profession should read and internalize. 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 n…

Respectfully, this seems upside down to me. Tools incorporating LLMs will be the knowledge repository for s/w projects of the future, and will capture and then summarize ideas, create mocks and finally render code (on command with guidance and iterations involving teams). My point being that the LLM era will be a deeper realization of code as theory building.

Re: Programming as Theory Building (1985) [pdf]

#28

Post by Centigonal »

n00b101 wrote: post #26

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. A computer program is a "model" of some thing. For example: float m = 1e10f; float a = 9.8f; float F = m*a; Another example: if(employee is still employed): float paycheque = getSalary(employee); else: float paycheque = 0.00f;

Fashion changes quickly over time, while good models of real-life processes are infrequently supplanted.

For your argument to work, you need to prove that the original article is closer to a 1985 Cosmo article than it is to something like Clayton Christensen's 1995 article on Disruptive Innovation, which remains relevant today (or disprove one of the premises in my comment).

Re: Programming as Theory Building (1985) [pdf]

#30

Post by noddybear »

szvsw wrote: post #16
lolinder wrote: post #12

Earlier quoted context omitted.

What you're describing is the siren call of No Code, which has been tempting manager-types for decades and which has so far failed every single time. The trouble with No Code is that your first paragraph is already my job description: I plan out and document and refine the structure of a problem and its architectural solution while simultaneously developing the system itself. The "sufficient explanation of the goals/…

I mostly agree with what you were saying, but I don’t think I was advocating for “no code” entirely, and certainly not the elimination of engineers entirely. I was trying to articulate the idea that code generation tools will become increasingly sophisticated and capable, but still be tools that require operation by engineers for maximal effect. I see them as just another abstraction mechanism that will exist within…

The DSL paradigm is generally how I go about using LLMs on new projects, I.e use the LLM to design a language that best represents the abstractions and concepts of the project - and once the language is defined, the LLM can express usecases with the DSL and ultimately convert them into an existing high level language like Python.
Post reply on HN