I was originally going to write a normal prose article regarding the topic of Pragmatism in Programming, however I thought I’d experiment in style by writing in a proverbial style.
The following concepts express the school of thought that I subscribe to which I call Pragmatism in Programming.
Proverbs written by Ginger Bill
The concept of programming
Programming is a tool to solve problems that you have in the domain of computers
The purpose of a program is, and ought to be, something that transforms data into other forms of data
Try to solve the specific problem you have, not a general problem you might have
Programming languages, compilers, libraries, etc, are just tools, they are not worldviews nor signals of social status
Understand the purpose of the program that you are writing
To solve a problem there are four steps of thought that need to be taken sequentially and cannot be skipped:
Reality is part of your problem
The hardest thing about programming is understanding the problem you are trying to solve
Try to think locally about your problem
Once you go generic, you lose information about the specific
Being generic is rarely what you want
If the data changes, so does the problem
When trying to solve a multifaceted problem, try to solve for the most common case first and not the most generic
Do not worry about the implementation of a program most of the time. If you understand the purpose, function, and usage of your problem, the implementation will usually be trivial
You cannot become good at programming without practice, experimentation, and failure
Do not be afraid to try to new tools, but look for tools that have proven themselves to be useful
In order to interpret anything, you require a model of interpretation
It is a fallacy to try to model your problem around a model of world, as this is a category error. The reality of your problem is probably different to a reality of an analogous thing not on a computer.
For any argument, proposal, or alternative algorithm, remember to ask yourself:
- compared to what? (what other ideas exist?)
- what hard evidence do you have? (empirical, experiential, quantitative, qualitative, etc)
- at what cost? (performance, speed, memory, energy, sanity, monetary, etc)
Be sceptical of any new idea proclaiming to solve all your problems without any evidence nor counter-examples
The only thing you should orientate around is the problem you are trying to solve
Hard problems are hard
The hardware is part of the domain that you are trying to solve
Similarities between code and the real world do not imply causal relationships
A model is only as good as the predictions it makes and the explanatory power it has
Most “best practices” rarely have any evidence to back up their claims, especially about being the best
Different people will have different styles which are more productive for them
Simplicity is complicated
Clear is better than clever
Be kind to your future self
Strive to program around the principle of least surprise
Make the zero value useful
Copying is usually better than dependency
Errors are nothing special, treat them like every other bit of code
Document the usage of a procedure, don’t describe the signature
The compiler knows nothing about the meaning of your program
As a program scales in size, so do the problems
Experimentation and emergence
- Don’t be afraid to expand upon an idea, but remember to clean up the mess that you have made in the process
- Objects are values with associated behaviour, which implies agency
- Objects will naturally arise for certain problems; do not orientate around the concept of an object
- Object orientation is not a silver bullet
- Functional programming is not a silver bullet
Not everything can be known a priori, experimentation may be necessary to discover solutions and a posteriori truths
Holistic models rarely exist; reality is more complicated than we expect, do not worry about having specialized models for specific things
Knowing whether or not something is useful requires skin in the game in order to get feedback
Object orientated programming is a form of misinterpreted and misapplied Aristotelian Metaphysics applied to a domain it was never meant to model
Academic computer science is not an empirical science but a formal science like mathematics
Academic computer science rarely has any skin in the game regarding the concepts it espouses
Programming is a relatively new craft with very little wisdom
People will naturally gravitate towards flash fads looking for wisdom in them; there are proven cultural practices that contain wisdom
Associating behaviour with data implies agency, however this agency is not real and only the cause of an interpretive model of the data
Many people do not think beyond the paradigm they embody. They can rarely think beyond the concepts since they do not know realize they think in a (flawed and incomplete) model, and that there are different models of interpreting the world.
You cannot teach virtue, you can only learn it. Look towards virtuous programmers for wisdom, and ask about their ideas on virtue.
Bodging is doing a job out of necessity using whatever tools and materials come to hand and which, whilst not necessarily elegant, is nevertheless serviceable.
Most people think they are being pragmatic when programming, however they are usually bodging it.
Bodging has a huge cost to it and should be not be relied upon.
- Package managers are a trivial program if the concept of a package is well defined
- Bikeshedding is common in trivial topics by people with trivial knowledge
- Assembly is a direct representation of machine code; (naïve) C is one of the simplest type-theory based representations of Assembly languages.
In every systematic inquiry (methodos) where there are first principles, or causes, or elements, knowledge and science result from acquiring knowledge of these; for we think we know something just in case we acquire knowledge of the primary causes, the primary first principles, all the way to the elements. It is clear, then, that in the science of nature as elsewhere, we should try first to determine questions about the first principles. The naturally proper direction of our road is from things better known and clearer to us, to things that are clearer and better known by nature; for the things known to us are not the same as the things known unconditionally (haplôs). Hence it is necessary for us to progress, following this procedure, from the things that are less clear by nature, but clearer to us, towards things that are clearer and better known by nature.
- Phys. 184a10–21
Our proper course with this subject as with others will be to present the various views about it, and then, after first reviewing the difficulties they involve, finally to establish if possible all or, if not all, the greater part and the most important of the opinions generally held with respect to these states of mind; since if the discrepancies can be solved, and a residuum of current opinion left standing, the true view will have been sufficiently established.
- The Nicomachean Ethics
We must consider it, however, in the light not only of our conclusion and our premisses, but also of what is commonly said about it; for with a true view all the facts harmonize, but with a false one they soon clash.
- The Nicomachean Ethics
Excellence is never an accident. It is always the result of high intention, sincere effort, and intelligent execution; it represents the wise choice of many alternatives – choice, not chance, determines your destiny.
- The Nicomachean Ethics
The pleasures arising from thinking and learning will make us think and learn all the more.
- The Nicomachean Ethics 1153a23
A great many people think they are thinking when they are merely rearranging their prejudices.
The world we see that seems so insane is the result of a belief system that is not working. To perceive the world differently, we must be willing to change our belief system, let the past slip away, expand our sense of now, and dissolve the fear in our minds.
The art of being wise is the art of knowing what to overlook.
The purpose of all programs, and all parts of those programs, is to transform data from form to another.
Different problems require different solutions.
If you have different data, you have a different problem.
If you don’t understand the hardware, you can’t reason about the cost of solving the problem
Everything is a data problem. Including usability, maintenance, debug-ability, etc. Everything
Solving problems you probably don’t have creates more problems you definitely do.
Latency and throughput are only the same in sequential systems.
Rule of thumb: Where there is one, there are many. Try looking on the time axis.
Rule of thumb: The more context you have, the better you can make the solution. Don’t throw away data you need.
Software does not run in magic fairy aether powered by the fevered dreams of CS PhDs.
Reason must prevail, like if anything is unreasonable for any reason, or imaginary, then it has to go.
Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.
- The Mythical Man-Month: Essays on Software Engineering (1975, 1995)
A little retrospection shows that although many fine, useful software systems have been designed by committees and built as part of multipart projects, those software systems that have excited passionate fans are those that are the products of one or a few designing minds, great designers.
- No Silver Bullet
The language designer should be familiar with many alternative features designed by others, and should have excellent judgment in choosing the best and rejecting any that are mutually inconsistent… One thing he should not do is to include untried ideas of his own. His task is consolidation, not innovation.
The most important property of a program is whether it accomplishes the intention of its user
Alan C. Kay
Most ideas come from previous ideas.
- The Early History Of Smalltalk
Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
Rule 1. You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.
There’s nothing in computing that can’t be broken by another level of indirection.
When there is no type hierarchy you don’t have to manage the type hierarchy.
Fancy algorithms are slow when N is small, and N is usually small.
Reliable and transparent programs are usually not in the interest of the designer.
- A Digital Contrarian Retires (1999)
… we do not consider it as good engineering practice to consume a resource lavishly just because it happens to be cheap
- Project Oberon
Increasingly, people seem to interpret complexity as sophistication, which is baffling – the incomprehensible should cause suspicion, not admiration. Possibly this results from the mistaken belief that using a mysterious device confers [extra] power on the user.