4 ms·

Peter Naur's "Programming as Theory Building" also addresses this topic of a "theory" which is built in tandem with a piece of software, in the minds of the pro

by panic 9y ago

Peter Naur's "Programming as Theory Building" also addresses this topic of a "theory" which is built in tandem with a piece of software, in the minds of the programmers building it, without actually being a part of the software itself. Definitely worth a read: http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf

btilly 9y ago
Seconded. In fact I would suggest it instead of this article - it is much better.
- dang 9y ago
  Thirded. It is a classic and was far ahead of its time. There are some great comments about this buried in https://hn.algolia.com/?query=naur%20theory&sort=byPopularity&dateRange=all&type=comment&storyText=false&prefix=false&page=0 https://hn.algolia.com/?query=naur%20theory&sort=byPopularit....
- joe_the_user 9y ago
  The article looks good but I don't see why that should take away from the OP. The OP makes excellent points concerning the relative independence of design and code in the context of the "extreme programming" paradigm having become very common if not dominant.
jrochkind1 9y ago
Nice, that's great! I hadn't known of it before.
runevault 9y ago
Thanks for linking this, don't think I'd ever seen it before and as someone who's a second generation holder of a very large system's underlying theory it feels extremely accurate, but puts things into terms I never considered before.
jacobolus 9y ago
The biggest problem is when users of software, programmers of software, and the software code itself have 3 different incompatible theories of how it works. Sometimes it gets worse still: you can have different theories according to (a) scientists doing basic research into physics or human perception/cognition, (b) computer science researchers inventing publishable papers/demos, (c) product managers or others making executive product decisions about what to implement, (d) low-level programmers doing the implementation, (e) user interface designers, (f) instructors and documentation authors, (h) marketers, (h) users of the software, and finally (i) the code itself. Unless a critical proportion of the people in various stages of the process have a reasonable cross-disciplinary understanding and effective communication skills, models tend to diverge and software and its use go to shit.
- deleted 9y ago
  [deleted]
- azernik 9y ago
  This is why during software design the first thing I talk about is not the UX flow or the software architecture, but the user's mental model (or the mental model we want to give them).
- taneq 9y ago
  This is why dogfooding is so important - you're updating the programmers' model to align with the users' model, reducing the total problem space (and thus the available avenues to get it wrong) by many degrees of freedom.
jiggunjer 9y ago
> I shall use the word programming to denote the whole activity of design and implementation of programmed solutions. Isn't this definition circular, using "programmed" in defining "programming"?
- edmccard 9y ago
  I think for circularity you'd need a pair of definitions -- "programming: making a program" and "program: the result of programming". In this case, we already know what a program (or a "programmed solution") is -- that is, we can tell that something is a program without necessarily knowing how it was made. So the definition at least provides some new information on top of that -- the name for the activity of creating programs.[1] Also, by including the concept of "design", it lets you know when the author says "programming", he doesn't just mean the acts of writing source code, or typing it in. [1] You could have probably guessed that the name was going to be "programming", but it might not have been.
amelius 9y ago
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus Torvalds

by panic 9y ago

btilly 9y ago

Seconded. In fact I would suggest it instead of this article - it is much better.

dang 9y ago
Thirded. It is a classic and was far ahead of its time. There are some great comments about this buried in https://hn.algolia.com/?query=naur%20theory&sort=byPopularity&dateRange=all&type=comment&storyText=false&prefix=false&page=0 https://hn.algolia.com/?query=naur%20theory&sort=byPopularit....
joe_the_user 9y ago
The article looks good but I don't see why that should take away from the OP. The OP makes excellent points concerning the relative independence of design and code in the context of the "extreme programming" paradigm having become very common if not dominant.

jrochkind1 9y ago

Nice, that's great! I hadn't known of it before.

runevault 9y ago

Thanks for linking this, don't think I'd ever seen it before and as someone who's a second generation holder of a very large system's underlying theory it feels extremely accurate, but puts things into terms I never considered before.

jacobolus 9y ago

The biggest problem is when users of software, programmers of software, and the software code itself have 3 different incompatible theories of how it works. Sometimes it gets worse still: you can have different theories according to (a) scientists doing basic research into physics or human perception/cognition, (b) computer science researchers inventing publishable papers/demos, (c) product managers or others making executive product decisions about what to implement, (d) low-level programmers doing the implementation, (e) user interface designers, (f) instructors and documentation authors, (h) marketers, (h) users of the software, and finally (i) the code itself. Unless a critical proportion of the people in various stages of the process have a reasonable cross-disciplinary understanding and effective communication skills, models tend to diverge and software and its use go to shit.

deleted 9y ago
[deleted]
azernik 9y ago
This is why during software design the first thing I talk about is not the UX flow or the software architecture, but the user's mental model (or the mental model we want to give them).
taneq 9y ago
This is why dogfooding is so important - you're updating the programmers' model to align with the users' model, reducing the total problem space (and thus the available avenues to get it wrong) by many degrees of freedom.

jiggunjer 9y ago

> I shall use the word programming to denote the whole activity of design and implementation of programmed solutions. Isn't this definition circular, using "programmed" in defining "programming"?

edmccard 9y ago
I think for circularity you'd need a pair of definitions -- "programming: making a program" and "program: the result of programming". In this case, we already know what a program (or a "programmed solution") is -- that is, we can tell that something is a program without necessarily knowing how it was made. So the definition at least provides some new information on top of that -- the name for the activity of creating programs.[1] Also, by including the concept of "design", it lets you know when the author says "programming", he doesn't just mean the acts of writing source code, or typing it in. [1] You could have probably guessed that the name was going to be "programming", but it might not have been.

amelius 9y ago

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus Torvalds