11–20 of 39 posts
The 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…
The 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…
> What I'd like to ask the HN brain is if anyone can think of another way to express a higher level thought other than language? In his essay, Naur implies that there is no such thing. I wonder if we had made any progress on that front in the 35 years that have elapsed since this essay was written. I think it could be argued that category theory, and categorical thinking more generally are basically in this spirit. T…
— Richard P. Gabriel, “Patterns of Software”
On the other hand, while a programmer can learn from source and documentation the wheres, whens, and whats of the program, there is always the remaining question of "Why?", which is central to this discussion. Here, I think good high-level examples of usage tend to do a good job of covering the inputs and outputs. But with regard to all of the intermediary states of the program... there is too much detail there to really document it. Those details evolve as an evolution more than a design. There is code added, then replaced or omitted entirely. Things are designed which work, but then are restructured for performance, organization, or to eliminate repetition. In these cases, there is information that is manifested in the absence of code, and the second rendering of the code better captures its function, but obscures its evolutionary history.
Here's something I've been consuming lately: https://www.youtube.com/watch?v=wbpMiKiSKm8
This game programmer (Sebastian Lague, who is excellent, by the way) walks through the development of procedural terrain generation in Unity. What's fascinating to me is the way he does it does this really effective job of "theory building". Things are implemented; results are observed; some code is deleted altogether that was only ever present to allow building up to that illustration, but will no longer be necessary at the next stage of evolution.
This is the way programmers work. Information is lost. If you weren't there to experience it at inception, only a great imagination and testing can replace it--at which point, you may find yourself actually rewriting the code, using existing code as a reference.
The 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…
You're butting your head against the fundamental paradox of communication: in order to communicate an idea that's in your head to somebody else, you have to encode it in a way that the other person will recognise and decode; that is, you need to already have some shared context. However, if you have a new idea then by definition it can't be part of the shared context, so it can't be communicated. We get around this b…
I point to examples of trees and say "tree", etc.
"New" ideas are acquired by example -- language is not a closed system.
This is perhaps the best paper ever to explain the nature of collaborative program development and maintenance.
If I had a company I would make this mandatory reading for everybody - everybody, not just programmers.
The 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…
Shameless plug: it's been on my mind for a while as well. I'm writing a book on this that has (I believe) several novel insights.
There's far too much to cover in an HN essay, but perhaps my best response is that your idea of working backwards from machine code to thought is a mistaken paradigm. There's no translation or mapping, at least not in the sense that coders like to think. That's one of many fallacies we've ran into on our journey over the last several decades to write better and more useful code.
Earlier quoted context omitted.
You're butting your head against the fundamental paradox of communication: in order to communicate an idea that's in your head to somebody else, you have to encode it in a way that the other person will recognise and decode; that is, you need to already have some shared context. However, if you have a new idea then by definition it can't be part of the shared context, so it can't be communicated. We get around this b…
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.
The 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…
It's well worth reading and made me appreciate the importance of Information Theory (and computers)!
[1] I refer to what are called SSII (société de services en ingénierie informatique) in France.