Related discussions on HN:
10 months ago: https://news.ycombinator.com/item?id=20487652
2 years ago: https://news.ycombinator.com/item?id=10833278
5 years ago: https://news.ycombinator.com/item?id=7491661
Programming as Theory Building (1985)
31–39 of 39 posts
Re: Programming as Theory Building (1985)
#32"If you lose the people, you lose the program."
I had a protracted, bitter struggle with this at one job. We had a business process, really in the top two of business processes, that was neglected as it was critical. When I was new to that role, I said, "We should rewrite this. This is scattered across multiple servers, the code has almost no comments (in the places where we still had source code), and more importantly, people were leaving."
One of the original programmers had died. People responsible for the why of certain decisions were retiring or leaving. And so on and so forth. I used to joke that our process was documented in C, except for the places it was bash, or borrowed Powershell, or ... Like an evolved process, instead of problems being solved, later systems were added to correct issues, only epicycles, even as the bus factor continued to decrement every so often.
I still have a low level of sour antipathy when I think of it, that my efforts to "do the right thing" came to nothing.
It's a shame. When I had a freer hand to work as I liked, systems I built could detect, in a limited fashion, when the world had changed, that is, if the theory of the world was wrong. If the vendor changed some critical portion of the database, the program would identify the new column or the missing table, then loudly expire after issuing its complaint.
This understanding of the slice of the world a program must interact with is so critical and worse yet, fragile, subject to both breakage and decay.
Re: Programming as Theory Building (1985)
#33The topic of how we as developers implement solutions in code has been on my mind for years. The one insightful idea I found in this essay is that coding is a lossy one-way operation, from which you cannot fully derive the original idea or the 'theory'. That seems similar to losing information when compiling source code, making it impossible to restore the exact source code from its machine code representation. So if…
As a life-long programmer, I've also wondered often about how we express human thought and ideas in(to) software. The process is lossy, as you put it, in that so much is lost in translation.
On the other hand, it's also "enriching" in that software can (or must) define the concrete details of models and logic that were missing in the source (human thought).
> ..another way to express a higher level thought other than language?
If software development is the modelling ("theory building") of higher-level human thought (often ambiguous or ill-defined) into textual source code in a programming language..
The answer may come from the "language environment", richer features in an IDE/editor that integrate with the compiler and the abstract syntax tree. When you mentioned "projections", I thought about how text is one of many possible perspectives into a program. I can imagine other representations, perhaps UML-like, that an editor could provide as a view mode - that would allow exploring the models and logic flow of a program visually.
Another aspect I think of, is that programming is a collaborative process that almost always involves people with domain-specific knowledge outside of programming. It could be that the biggest information loss occurs not in the encoding/programming, but in the (cross-cultural) communication between these spheres of thought.
..Which seems to imply that there ought to be developed a shared language - or conceptual framework - between experts in software development and those outside of it.
A shared language/framework would allow the encoding to happen at a higher-level of abstraction, collaboratively - instead of one side encoding in (vague) human language, then the other side encoding in (precise) programming language.
My line of thought keeps returning to something like interactive UML diagrams that can be developed together by all stake-holders. Ideally, these would be living diagrams that are directly used by the software itself, to generate database schema, internal models/classes, control flow.. But I'm skeptical whether "visual programming" as a paradigm is the answer, mainly because there have been countless unsatisfying attempts.
I find inspiration in the works of people like Seymour Papert ¹, Alan Kay ², Bret Victor ³, who challenge our existing notions of what programming is and could be.
A common thread among them is the focus on interface and environment, how textual representation of software is only one of many possible perspectives, that there's room for innovation in how we interact, explore, develop and communicate about software. A vital part of that is including "non-programmers", the rest of the world, in the development process.
I'm fond of the Whole Code Catalogue ⁴, and what the Future of Coding initiative is doing. I think this area of investigation is an important one, to continue to attempt to bridge the gap between human thought and software.
² http://www.vpri.org/work/our_work.htm
Re: Programming as Theory Building (1985)
#34Earlier quoted context omitted.
We get "around" this by ostentation: words in a spoken (natural) language refer to the world. I point to examples of trees and say "tree", etc. "New" ideas are acquired by example -- language is not a closed system.
Which is harder than it sounds if you are trying to do it from scratch. Even pointing is a part of language, and trying to convey that concept is far from trivial. I think a big part of language learning in children involve the child seeing other people react to language and imitates. E.g., father points and mother gaze in the direction of finger, child follows mother's gaze.
To further this idea, dogs intuit the meanings of commands, some more easily than others, but teaching a dog to understand a human pointing at something is hard. My own dogs seem to interpret it as "just keep looking"
Re: Programming as Theory Building (1985)
#35This concept evokes many familiar memories of reading other people's code, which is always extremely hard. I feel multiple ways about this concept. On the one hand, I believe programs can be sectionally reduced to a inputs, outputs, and a sequence of states in between, and a programmer can understand those things well enough to extend an existing programmer competently in many cases. It must be true, because it does…
So if reading code means reconstructing a theory, that could explain why we have so much NIH.
NIH?
Re: Programming as Theory Building (1985)
#36Earlier quoted context omitted.
So if reading code means reconstructing a theory, that could explain why we have so much NIH.
NIH?
Re: Programming as Theory Building (1985)
#37> A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it.
Absolutely. The plain English definition for the word "program" that Google shows is (noun) "a set of related measures or activities with a particular long-term aim", (verb) "arrange according to a plan or schedule".
A software program fulfills a certain set of behaviors, serves a certain purpose, is a materialization of an idea, or otherwise is a transcription of something from a certain domain into the domain of software. The "source of truth" of what that something is is external from the program.
The knowledge domain of a programmer is therefore not only both their code and the idea it represents but the mapping in between. Both ends are easily documentable (in the narrow context of their specific domains), and it feels like this could have led to a possible convolution of what it takes to be a good programmer.
We have endless measures, philosophies, and codifications for what makes for good form when drawing back the bowstring, what release techniques make for the least disturbance to the arrow's path, what arrow shape makes for the most optimal flight, etc, but less for an archer's aiming technique. All we can do is just look to see if the target's been hit or not.
How an org "aims" the "arrow" of code towards the business target is a higher level concern than how awesome the arrow shot is or how straight it flies. If you're not controlling how you aim you lack the context to fully qualify your assessment of how arrow choice, pull/release form, or even flight path affected your result.
Codifying not only how your org builds product ideas and how it implements software, but how your org maps from one domain to the other helps mitigate knowledge siloing.
Re: Programming as Theory Building (1985)
#38OP here, much of this paper resonates around the knowledge we need to build a system, lot of this is like the understanding of business rules, is the context we need to build a working software in the first place. The problem is that knowledge is mostly "tacit", and tends to grow as the software evolves. For example, several development tasks are normally completed not only based on the documented user stories, but t…
> The problem is that knowledge is mostly "tacit", and tends to grow as the software evolves
Totally agreed. I agree that the missing codification is the context that was needed at the genesis of the program -- the context necessary to understand it holistically.
Seems to me a valid way of understanding this problem is that there is a missing piece of documentation. It's generally well documented where/what the starting point product/business idea is as well as where/what the end point code is, but how point B was derived from point A is oftentimes not well documented. This method of derivation highly informs the structure of the result, and is a lossy conversion. It can be thought of as the "spirit" of a program/an org's engineering department (what happens in between the product ideas you can see going in and the lines of code output you can see coming out).
If that part, and the methods and techniques by which an org maps and translates an idea from the domain of business into the domain of code, is codified and documented and evolved alongside the programs the org produces then it may help.
Re: Programming as Theory Building (1985)
#39The topic of how we as developers implement solutions in code has been on my mind for years. The one insightful idea I found in this essay is that coding is a lossy one-way operation, from which you cannot fully derive the original idea or the 'theory'. That seems similar to losing information when compiling source code, making it impossible to restore the exact source code from its machine code representation. So if…
Have you looked into Flow Based Programming by J P Morrison?