A programming fallacy is something about programming that many people believe is true, but is not actually true. For various reasons, many of these fallacies get taught in beginning programming courses. Eventually, the student needs to realize this and change how they do programming before they start teaching new students the same fallacies. Some of these will be covered with examples and how one might integrate the ideas into a beginning programming course (as done by the author). Understanding the general nature of the fallacies is useful for anyone working with programmers, managing programmers, etc. The (now retired) author, with a PhD in computer science in the area of applied programming language theory, has spent many years teaching in academia, doing software research and development in industry, and, in the process, writing about a thousand pages of code each year for useful programs, small and large, in many different programming languages.

Truth: Programming fallacies, once learned, are hard to unlearn.
A programming fallacy is something about programming that many people believe is true, but is not actually true. For various reasons, many of these fallacies get taught in beginning programming courses. Eventually, the student needs to realize this and change how they do programming before they start teaching new students the same fallacies.

There is only one thing that is harder than learning something new.

What is it? The only thing that is harder than learning something new is unlearning something old.

This can be seen as a "confirmation bias". Everyone has it.

Try the following.

• Switch your keyboard layout from Qwerty to Dvorak.
• Placement of keys
• Alternation of keys

• Try switching a foreign language from one dialect to another.
• In programming, change the way you indent code.

You cannot teach an old dog new tricks.

• No way.
• We've always done it that way.
• I don't think so.
• Ain't happening.
• NIH = Not Invented Here

One should not use programming "tricks" except when necessary and then they should be well documented/commented.

• Text formatter system. About 1,500 pages of Python (and growing)
• Editor macro system. About 1,000 pages of Lua.
• Web infrastructure: About 500 pages of PHP and JavaScript
• Graphics infrastructure: About 500 pages of PostScript
• Management of images, students, etc. About 5,000 pages of Delphi.

[comment on the typical student CMS = Content Management System. as a TPS = Transaction Processing System]

Chapter model	Embedded code model	Separate code

[slide user interface demo, UI state, content changes]

Lua, PHP, Python
JavaScript, Java, Kotlin
Bash, Batch, PowerShell
PostScript, Forth, Perl
R, SQL, XUL, AHK
ASP, ASPX, VBA, VBS
C, D, C++, C#, Rust
Go, Julia, Pascal, Ruby
Clojure, Haskell, F#
Racket, Scala, XSLT
Erlang, Prolog

The text formatter system can format itself.



Keep in mind the "Back to the future" movie series and what Doc. Brown tells Marty.

There are now two of me here, and there are two of you here.

In the formatting system, text decisions can be made at the following places.

• Editor macros (Lua, based on Borland Sprint editor macros)
• Formatter macros (based on Borland Sprint formatter macros)
• Embedded Lua
• Python block formatting and custom classes
• Custom code (many languages), image processing, etc.
• PHP web sever pages
• JavaScript web client pages

[demo on content change] [advice about UI (User Interface) decisions]

The same document source code can be formatted into the following.

• Word document
• PowerPoint presentation
• Web page
• plain text

The same program code source code can be formatted into many different programming languages.

Code (in many languages using the same macro format) in the document can be run, with input from the document, to generate output that is included/embedded in the document.

All document and program diagnostic output can be clicked on and the user is taken to the source code or the source data (if applicable).

Debugging output is distributed and can appear on one of many target computer systems.

Mouse and keyboard are seamlessly connected via Synergy among 10 to 20 monitors (as needed).

Source code change are made in the editor. A good editor is important. I use SciTE (based on SCIntilla) customized.

Some editors provide editor macro support to help automate tasks.

• Lua is used to process every keystroke typed with custom and context-sensitive keystroke processing.

An "issue system" can help in feedback of changes from the formatter to the editor - since user approval is needed. Example: case of identifiers.

Servers help process the distributed user interface and processing.

• node.js (JavaScript)
• custom Python server
• custom batch server (TCC for Windows, BASH for Linux)
• Thunderbird and Firefox and Chrome (JavaScript)
• client page JavaScript server as needed
• vDOS server (for legacy Python and legacy formatting)

Cluster computing is used when needed.

Fallacy: You should require beginning programming students to use top-down programming.
Problem solving in computer science is best done using top-down programming.

• top-down programming
• goal-driven programming
• backward-chaining logic

Why do many computer science programs require beginning students to do "top-down programming"?

Fallacy: One should implement a computer program in a top-down manner.
The phrase "top-down programming" is deceptive. Have you ever tried to write a program "top-down"?

Do it once and you will see that it does not work very well. The phrase "top down programming" refers to a "top-down program design" and then a "bottom-up program implementation".

Many people try to do "top down programming" by doing "top-down coding".

Some teachers who have never really used the method will teach this fallacy to their students. How would you define a "programmer".

A top-down design insures one will get to the goal.

A bottom-up design may require extra work and may not get to the goal.

Fallacy: Type in all your code and then make changes until it works.
Should a teacher help a student debug their code that they typed in, changed, etc., and the code does not appear to be working correctly? How about using stepwise/iterative refinement?

There is only one way to eat an elephant: a bite at a time. Desmond Tutu.

There are tools for doing automatic compares. Described below.

Every beginning course should cover how to use the command line to complete an assignment. If the IDE = Integrated Development Environment stops working ,the student has a way to complete the assignment (on time).

Students should be able to install software without help.

Instead of having students type everything at the command line, I created a Bash script system to make it much easier to edit,, compile and run. On every compile, the (one) source code (file) is uniquely saved. (Lots of research data for me).

Bash is short for "Bourne Again Shell" which is a play on words on Bourne, who created the better scripting system for Linux and the "Born Again" religious movement (made famous by President Jimmy Carter).

Note: We are here ignoring discrete mathematics that involve only integers.

A slide rule (not slide ruler) was once used to do manual computations.

Whenever a slide rule is used, it is very evident that any computation involving real numbers is an approximation.

What are the values of the following (using a computer program)?

Note: These are rational numbers, not irrational like √2 or transcendental numbers like π or e.

Here is the mathematics result expressed as real (rational) numbers.

Here is a simple Lua program to add values of 1/10 as 0.1.
sum1 = 0.0 for count1=1,10 do sum1 = sum1 + 0.1 print(string.format("%2d/10 = %1.17f",count1,sum1)) end
The 17 places in the output is important to being exactly precise.

Here is the result from a computation point of view as the output of the above program.
1/10 = 0.10000000000000001 2/10 = 0.20000000000000001 3/10 = 0.30000000000000004 4/10 = 0.40000000000000002 5/10 = 0.50000000000000000 6/10 = 0.59999999999999998 7/10 = 0.69999999999999996 8/10 = 0.79999999999999993 9/10 = 0.89999999999999991 10/10 = 0.99999999999999989
Even when symbolic math can solve a problem, any attempt to compute real answers involves the same approximations.

The difference is small at each step but the difference can add up to a significant amount over many iterations.

Note: One can fix this specific instance by using a fixed decimal notation, but that only works, in base 10, for numbers and increments that are multiples of 2 or 5, the prime factors of 10.

Rounding errors need to be addressed in fields of computer science such as numerical analysis.

Fallacy: Dollars and cents should be represented using floating point variables.
The general rule, sometimes taught, that if the number has a decimal point, it should be represented as a floating point variable does not hold for dollars and cents.

• The amount $123.56 is not a floating point value. It an integer value. That is 12345¢ cents.

Rule: Convert dollars and cents to cents, do the arithmetic, then convert back into dollars and cents (for display purposes). This distinction needs to be carefully handled in languages such as JavaScript and Lua which do not have integer variables.

The approximation issue involves floating point division so every such division needs to result in an integer value.

Fallacy: Social security numbers and phone numbers should be represented using integers.
How should social security numbers and phone numbers be represented? They appear to be numbers. That is, integers.

Are you ever going to add, subtract, multiply or divide these values? If not, use text.

• SSN: 999-99-9999 (1 billion values, originally geographically located)

Ask your self the following question.

• Are you ever going to add, subtract, multiply or divide these values?

If not, represent them using text. Note:

• Leading zeros are lost using integers.
• If an ordering is present, care must be taken when sorting lists of such values.

My style, which I started using many years ago, is, essentially, the same style used by Python, Lua, Modula-2, and some others. That is, the open curly brace can be visually omitted, the ending one can be visually omitted (since indentation provides that cue), and fewer expensive screen lines are used (than other styles).

This style distracts the eye with the ending curly brace. The popular language Python shows that this ending brace is not needed and, in languages that do need it, it can be "hidden" from the eye with the previous style.

This style requires two more lines than the previous styles.

It is not hard to write a small program to perform (or update) indentation using simple rules. Note: Provided a consistent style is used to start.

Details are left as a future topic.

Fallacy: In a well-written production program, every part of the program is important.
In a first programing course, every part of a program code assignment should be important. If not, it should be removed and the program should continue to work as desired.

This rule can be (and should be, at times) violated in larger software systems. Why?

Some common programming fallacies have been presented. Many more were omitted.

• Fallacies in general, truth and lies
• Learning and unlearning
• Top down design and bottom-up implementation (coding)
• Integer and floating point approximation
• Single-entry single-exit blocks and indentation and screen space
• Flow/flaw charts and pseudo-code
• Making code run fast (or take less space)

Questions and comments and more information.

• https://robinsnyder.com
• https://robinsnyder.org (mirror)
• https://powersoftwo.org
• https://ycp.powersoftwo.org (class web site from 2019-2020)

[circle back]