Dec 2018
Issue
January 2019 Issue
Collins Software's Newsletter
Feb 2019
Issue
Data Structures:
I consider myself a "Data Structure-ist". Give me a data structure and I can tell you what can or cannot be accomplished.  I thought this might be a special talent. I was wrong. My ten year old grand-daughter can easily do the same. I held up a box of candy, which I named about twenty thing I knew about it. I then ask her, she was able to quickly name 3 other things about the box that I had left out.

In a class for an MBA, it quickly tells us that a solution to any problem is not necessarily the first few ideas that come to mind. So we must name all the possibilities, then weigh each solution to determine the best possible choice.  In programming we have five minutes in which to determine a solution in an environment of isolation. Most of the time the choice for a solution is a personal belief, with no knowledge for the reasoning behind the belief: "Chrome is better then IE", "Python is better than R". This is not a religion.


Visualization of Logic:

Alias poor code, it come down to the ability to finish. Without an ability to read code we will never be able to finish any piece of software.


"Nature is the source of all true knowledge. She has her own logic, her own laws, she has no effect without cause nor invention without necessity." -- Leonardo da Vinci

"Most of the mistakes in thinking are inadequacies of perception rather than mistakes of logic." -- Edward de Bono

"From a drop of water a logician could infer the possibility of an Atlantic or a Niagara without having seen or heard of one or the other." -- Sir Arthur Conan Doyal

"Dubium sapientiae initium. (Doubt is the origin of wisdom.)" -- Rene Descartes

"Donít tell people your plans. Show them your results." -- anonymous

 

Logic over Design:
Having programmed for over forty years, it has become obvious that design is the only criteria for writing software products. Worry about syntax is design. We build computers then try to determine how to program them, with absolutely no thought has gone into the logic of what we are to accomplish, only on the logic of adding two number.

If our goal is to add two number together then, If the number are small enough, we have accomplish this. The rest of computer logic is made up of add two numbers together. Is this our goal?

 


Readability of Logic:

Readability: To read code without prior knowledge and without the aid of documentation.

Writing software requires the human to know what the compiler is doing for every statement. He must also know the actions of all the external functions, and their parameters. The manageability, editability, and accountability of software we leave this work to be done be every programmer to do on his/her own. 

The purpose of computer languages is to communicate a desired action that is to performed by the computer. We have not been able to create a computer language that can be read by humans. All the computer languages we have require interpretation by humans as to the assumed action that will be performed by computer.  

For the human the computer languages we have are trial and error. Every instruction we give to the computer we must have external documentation that requires interpretation as to the actual result. This interpretation requires humans to try the instruction to see if the result. This one way communication, languages that only the computer can read, impairs our ability to write software. We use a debugger, if one is available, or we write results out, to be able, to view computer actions. The whole software development system does not really work.


 

Specific Programming:
We have been taught generic programming, to make functions that can be used for multiple purposes. The inverse of this is "Specific Programming" to program for one and only one purpose.

I advocate for writing actions that perform one action, then create a language that can choice which action to perform. The purpose is to eliminate documentation, thus reduce human involvement in the implementation of the design.

The age old use of "qualifiers" and "parameters" to adjust an action is impossible to implement. Each Command Line statement and API function requires volumes of documentation, when in fact we should be striving for no documentation.

I find developers over estimate the benefit of flexibility. It makes for great advertizing, but does very little for production. The human language is powerful enough to describe basic actions. When we get to the micro-actions is where it fails. For instants "walking" describe how we walk. 


Probability and Statistics:

Permutations, a thing programmers avoid like the plague. However we have subsystems with hundreds of functions that we must call in a specific order. The number of permutations are uncountable, yet the actual perfect solution is singular.

We should throw all the API packages away, and package specific actions with a minimum number of parameters (zero, one or two). It really is up to the original developer, who knows, to remove as many permutations as possible. Leaving just the work to be performed in an optimal state for everyone to use.

Author: Clif Collins

http://CollinsSoftware.com
Houston, Texas
January 1, 2019

email: c1@CollinsSoftware.com