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

31–40 of 46 posts

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

#31

Post by federalauth »

WillAdams wrote: post #15
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…

Unfortunately, the book this was included in: _Computing: A Human Activity_ https://www.goodreads.com/book/show/4594604-computing is out of print, as is _Concise survey of computer methods_ and rather pricey. Oddly, _Knowing and the Mystique of Logic and Rules_ (which has an even lengthier title after a colon...) has four entries at Goodreads and is listed under "P. Naur" and is even pricier, quite expensive on Amazo…

Paging Stripe Press

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

#32

Post by szvsw »

noddybear wrote: post #30
szvsw wrote: post #16

Earlier quoted context omitted.

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.

Do you have any repos or examples you can share? Would love to see an example of that in action!

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

#33

Post by dang »

Related. Others?

Programming as Theory Building (1985) - https://news.ycombinator.com/item?id=38907366 - Jan 2024 (12 comments)

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

Programming as Theory Building (1985) [pdf] - https://news.ycombinator.com/item?id=33659795 - Nov 2022 (1 comment)

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)

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

#34

Post by antistaph »

softwaredoug wrote: post #20

This has so many implications for software team design Like hiring that one unicorn dev to solve X hard problem isn't a great "theory building" exercise. It can build theories for that one person, but without feedback they're never tested, they're never adopted by the whole team So you actually NEED juniors, 'stupid' questions, outside points of view, and ways of openly and scientifically evaluating theories instead…

Value of a product tends to be measured by the number of features shipped, the quality of service and time to market. But knowledge of the team is hard to evaluate and to sell to a manager.

It is good if developer has already it, he is more productive then. But when he explicitly puts effort into gaining knowledge, then he does not deliver during that time so maybe he should not be paid for it.

I can't imagine a relationship between a manager and a developer where knowledge is valued higher than delivery. It could work only if the manager also believes in this value. I think he could believe in it only if he is sure that this project will pay off in the long run. In the era of a fast-changing world, he is putting the value of delivery and satisfying stakeholders on a higher rung.

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

#35

Post by cozzyd »

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;

Sometimes there's a glitch and the employee continues to get paid after being laid off.

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

#36

Post by hcarvalhoalves »

pbw wrote: post #9

I always heard it as "software development is an exercise in knowledge acquisition."

The best programmers eventually become experts in a problem domain they’ve worked on, because to teach a computer to automate a process well requires thinking like an expert and resolving incoherences. Weak programmers complain stakeholders don’t know what they want or that there’s no spec; I have a hunch these are going to be replaced by AI.

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

#37

Post by Abishek_Muthian »

Doesn’t declarative programming and by extension functional programming adhere more to the ethos of ‘Programming as Theory Building’ ?

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.

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?

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

#38

Post by gavmor »

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;

It's not unreasonable to explore historical eras for fashion inspiration.

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

#39

Post by f1shy »

szvsw wrote: post #8
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…

> 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…

In general, I subscribe to your thoughts, but also the ones you are replying to.

But: “And what prevents a human from doing code review on such a system’s outputs?” One word: cost.

At least in my experience, at least right now, it is more effort to review and correct, as doing from scratch.

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

#40

Post by f1shy »

noddybear wrote: post #30
szvsw wrote: post #16

Earlier quoted context omitted.

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.

That is s great idea. I’ve used ChatGPT to help me define the names of the functions of an API. Next time I face a problem where it calls for DSL I will give it a try.
Post reply on HN