Pragmatism in Programming Proverbs

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

Problem solving

• 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:

  • Purpose
  • Function
  • Usage
  • Implementation/Form

• 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

Practice

• 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

Model building

• 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

Management

• 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

Philosophical concepts

• 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.

Other topics

• 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.

Quotes

Aristotle

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

William James

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.

Mike Acton

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.

Fred Brooks

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

C.A.R Hoare

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

Rob Pike

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.

Niklaus Wirth

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.