Programming: Week Zero

Programming - Basics and Beyond


Like the other two short courses on this site the idea progress and mastery and based on my experience with the Bujinkan school(s) of martial arts. Everything before black belt is a discection of the basic principals. Everything after black belt is the refinement and exploration. You wont find many new teachniques, just variations. This can be frustrating for people who believe they can skip ahead, ignore a principal in favor of the ‘secrets’ which come later masking any of thier short comings. The same is true in programming and I hope to show the underlying zen at work here. The scope is narrow, the implications deep.

Coding Topics

  • Application Life Cycle Management (ALM): We start with the simpliest example and ask how concepts like software rot, code entropy, and technical debt impact our work. We want to write something and see it in the world with the minimal amount of fuss. That means: code, test, commit, deploy, evaluate.
  • Architecture and Design:
    • Design Patterns: Finally we land on the concepts of modeling larger problems and reusing the components of solutions in different ways depending on context.
    • UML Diagramming: When and how does modeling via images help? Is it limited to the design phase? More importantly, how do we ensure that all diagrams we produce has a path towards inclusion or future evaluation? That is, a well researched idea is a guide post for future development. It simutansously shows why a solution didn’t work at the time, and highlights which scenarios in which it could be useful in the future.
    • Logic Tools: Karnaugh Maps, SWOT Analysis, Vien Diagrams, GAP Analysis, Pairwise Comparison (with weights). These are an example of various tools we can use to better explore, support, defend, and expand our ideas.
  • Code Quality: Branching off ALM we’ll look at the habits we can practice and ingrain for developing great code. As simple and as difficult as rinsing out a bowl after use so that the food doesn’t dry and stick, thus making our jobs harder in the future. It should be noted that the mind hates paying up front for something it can easily defer.

These topics represent our foundation (i.e. - our black belt). In a short course this is the entire 5 weeks of instruction. In a longer course (13 weeks) the remaining time is spent coding, practicing, and exploring.


Every programmer is a student of logic. Everyone program is fully formed thought requring a user to input a properly formed premise in order to get a result. Bugs in these programs are informal falacies, cognitive blind spots, and bias. It’s no wonder that when (some) people find bugs when reviewing your code they linger in that smug moment of finding the flaw in your argument [read: program]. The following quotes show this relation when it comes to functions in programmming.

_**Functionalism**_ in the philosophy of mind is the doctrine that what makes something a mental state of a particular type does not depend on its internal constitution [^1], but rather on the way it functions, or the role it plays, in the system of which it is a part. - __Standford Encyclopedia of Philosophy_
(1) In programming, a named section of a program that performs a specific task. In this sense, a function is a type of procedure or routine. Some programming languages make a distinction between a function, which returns a value, and a procedure, which performs some operation but does not return a value.

Most programming languages come with a prewritten set of functions that are kept in a library. You can also write your own functions to perform specialized tasks.

(2) The term function is also used synonymously with operation and command. For example, you execute the delete function to erase a word. - __Webopedia__

A ‘class’ is the ‘particular type’ spoken of in the philosophy of mind. So a ‘class’ is not defined by it’s composition but rather on how it functions. Using a cat as an example type we can say that all cats share certain traits 1. Namely they can Purr. How they purr, or why is not necessary to assert an axiom that all cats have the ability to purr. When speaking of software it should be noted that we have the power to set our own controls for testing that axiom. Within programming we use an axiom to suggest safety. We say that it is safe to assume that in this program all cats can purr. The notion of safety then pivots us into a new idea. What does harm look like? Imagine if an observed inconsistency could hurt you. Think about clear pepsi. Clear pepsi is a variation on a brown drink without the dye so that is appears clear. The novelty in sensation when the mind tasted something which contridicted what it saw may be the greatest achievement of any soft drink and also the reason for this one’s demise. Now image if instead of a moment of confusion when presented with reality not matching expectation that instead you yelled, ‘This can’t be true!’ [read: raised an exception], and died. Perhaps you are more mature and instead of passing out you simply panic 2 until you pass out. Within this simple example we has highlighted the following goals for writing software throughout this introduction to programming:

  • Be able to model a particular type of object.
  • Define various abilities to execute an axiom for a given type.
  • Define controls which ensure the safety of executing a given ability.
  • If during execution of an ability there is a drastic contrast between expectation and reality then exit the ability safetly. This event is considered exceptional and should provide details on exit about what caused the error/problem.

Continuing the example: We know that all cats have the trait of purring. We know that while this trait may vary in any number of ways between cats, it only matters that funcationally all cats do purr. A lion will implement the trait of purring differently than a house cat. So what do we know? In the next section we’ll talk about how philosophy uses propositional calculus to describe how asking a cat to ‘bark’ is unsafe and as unexpected as drinking clear pepsi. Later we’ll discuss how in programming we can use things like interfaces to help ensure that only safe calls are made. These interfaces are contracts [read: rules] that can be checked as early as while you are typing the code!


It may surprise some that concepts and annotation that confuse students for years in the math class room are easily covered within the first few weeks of learning to program. As a premise of this course we state that the ulility of math as it is taught in the United States to foster the patterns of thought which seem to accompany or are directly influenced by learning the reason mathematically. We then further assert that computer programming allows an alternative tapestry on which to practice that skill. The actual use of math in programming [i.e. - gaming, drawing, video editing, etc] is not a focus of this course.

Previously we arrived at an axiom. All cats purr. What happens when you ask a cat to bark. Does it die? Does it look confused and then walk away? In nature and philosophy we observe these things. In programming we take those observations and translate them as requiremnts and into logic.

Let’s take a second to really break that last statement down. In programming we take those observations and translate them as requiremnts and into logic. The ‘as’ keyword there is special in programming and logic. We are saying that we will be speaking of obervations as if they were requirements. We really can’t get around this relationship of philosophy, logic, math, and programming if we tried. The following comes from a discussion concerning the difference between function in math versus computer science.

For example, consider a Python program which prints the current date and time n times for some argument n. At first glance, this isn't a function, since you can give it the same n and get a different result. However, if you view the state of the world, namely the current date and time, as an argument to the program, then it always does give the same result for the same input, it's just that input is physically impossible to reproduce because we don't control the passage of time. (You could fudge the computer clock if you wanted, but you can apply the same principal to physical sensors and such).


The above example showcases that a function is at it’s core an abstraction. An abstraction is an imperfect model (read: representation) of an object. Above we are dealing with an inability to model the physical world. We allow certain assumptions to implicitly add context to our code. This is somewhat straight forward and common in mathmatetics where you routinly remove aspects of a problem and create a statement which is true regardless of that missing information.

This becomes more interesting when we look to model human behavior. We turn to logic to answer questions concerning how best to accomplish this.


Digging deeper into this subset of philosophy we’re curious to see how many concepts relate directly to the goals of programming.

Take the following syllogism:

If all men are mortal, and if Socrates is a man, Socrates must then be mortal.

In software we often have to deduce a certain amount of information before taking any action. Assume that the action we want to take is to simply remember that Socrates is moral? I am a human being, a type of thing that has the ability to remember things. This function is an axiom about human beings. That being said I should be able to safely ask myself to remember that I’ve deduced Socrates is mortal.

let memory = new Memory();

if(Socrates.Type == Human){"Socrates is mortal.");


So back to our cat.

In order to decide what the cat does when asked to bark we need to model a fault diagnosis 3. In programming this is error handling.

Knowledge Graph

Perhaps most excitingly we will be building a knowledge graph that helps link concepts between fields of study. So far this is what we have:

The center of the knowledge graph represents the our a priori knowledge4. That is, we start with the premise that I’ve defined about the link between programming philosophy and all agree it represents a truth. At least, as true as is required to serve as a learning example. (i.e - For the sake of arugment…)

Closing Thoughts

With that you will earn your black belt in coding. Like the black belt in martial arts it is a layer in your toolbox. Your journey is just begining and there are many other tools required to be successful on the career battlefield of life. Soft skills like emotional intelliegence, public speaking, and community envolvement will complement the hard skills of coding, technical writing, and system design.

Let’s get started.


  • JavaScript the Goodparts
  • Why Study Math pdf in one drive
  • Logic Text book
  • The war of art
  • The psychology of everyday things
  • Data Viz book
  • Hacking: The art of exploitation
  • Clean Code
  • UML book that Matt. U recommended
  • Head First Design Patterns


Stanford Encyclopedia of Philosophy

  1. A trait is something you embody. Consider it like an actor playing the role and the role is a pirate. The traits of a pirate are poor grammer. That is, we need to extend the type of person to include the traits of a pirate. @SEE: Rustlang and the idea of composition. [return]
  2. A kernel panic (sometimes abbreviated as KP1) is a safety measure taken by an operating system’s kernel upon detecting an internal fatal error in which it either is unable to safely recover from or cannot have the system continue to run without having a much higher risk of major data loss. @SEE: Linux [return]
  3. Propositional Calculus can be used to find fault diagnoses. [return]
  4. The Latin phrases a priori (lit. “from the earlier”) and a posteriori (lit. “from the latter”) are philosophical terms of art popularized by Immanuel Kant’s Critique of Pure Reason (first published in 1781). [return]