21–30 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…
Personally I think the problem starts at “shared understanding” and I think the most promising solution lies within combining ontologies (such as ones based on BFO, perhaps) with Abstract Syntax Trees or Concrete Syntax Trees. I suspect future development will occur merging tests as examples of program functionality with data models and call graphs derived and annotated based on common ontologies. We would have, in t…
Peter Naur is one of the unsung(?) giants of software. His name should be instantly recognizable. 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.
This 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…
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 don't agree with that statement, but I don't think the primary aim is to produce a program either.
I believe the primary aim is to enable users to use a program. For that they need a mental model. Maintaining a consistent and simple theory among developers is a means to that end.
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…
This would explain why a lot of corporate software isn’t good. There is no shared understanding and a lot of people make changes without understanding the big picture.
The primary aim of programming is to solve problems. The moment you forget that one simple fact you are already heading in the wrong direction.