As a programmer it is easy to adopt a view of the world in light of our experience. The workings of the world starts to look as something out of the matrix. This has some funny consequences: While listening to a person reasoning about the complicated events today from the point of view of famous thinkers; You can get the feeling of hearing a formalized thought pattern executed by a very complex machine. This sort of meta thinking naturally can be attributed to the formalization of execution that you work with, i.e. it is a view of programmable minds from the view of a mind programmed by thinking about programming.
This kind of thinking is useless unless it can be applied.
In the terms of a programmer: We are looking into how to debug the domain. The most important aspect of getting to know a domain is learning the language of that domain. The meaning of words inside that discussion context.
How do we reduce the task to something manageable? Simply learning all the language and statements associated with a given domain a huge undertaking. What is it that we want to learn? One of the interesting aspect of the domain is the grammar and the macro expansion of that domain. If we apply this to the world of programming, what kind of form of statements and what kind macros are we thinking in?
Most programmers work with the following concepts (I’m trying to simplify it): methods, classes (and instances of the classes), variables The most important execution constructs are: if, for
Naming methods, classes and variables turns the execution into a meaningful flow. Mostly we are working with details surrounding execution of our concepts. A programmer is working a lot with detail management (much like a weaver of a tapestry have to manage the the threads in order to get a working picture). A very serious problem is that it’s hard to find the right level of detail and abstraction to work with. The concepts above can be used to create detail at arbitrary levels. Kind of like Lego versus Duplo.
For the most part, many tend to prefer immutable constructs: Specified classes that do not change their behavior after initialization. This greatly simplifies reasoning.
Since programmers are working so much with abstractions, we tend to overdo abstraction.
What kind of conclusion can I draw from this? I’m not sure. It reads like the exact opposite of statistics. Mostly we program in predictable ways that get unpredictable due to the complexity rather than randomness of the input. Do we expect people to behave in this manner? Well, they sometimes behave similarly at a cursory glance. The big question would be what kind of programming we would write for people?
Do you want to send a comment or give me a hint about any issues with a blog post: Open up an issue on GitHub.
Do you want to fix an error or add a comment published on the blog? You can do a fork of this post and do a pull request on github.
Comments