The Software Ceiling

Who Uses Software?

• End users (non-programmers)
• Domain experts (non-programmers)
• Software Professionals (programmers)

End User Expectations

Apps

• e.g. Minecraft
• e.g. Weather

Inexpensive

Simple One-Purpose App

• e.g. loyalty cards
• e.g. credit cards

Hierarchy

• End users understand hierarchy
  • e.g. org charts in business
  • e.g. government (layers)

Uninterested in Details

• options unwelcome
• don't welcome interruptions
  • e.g. "where to save file"
  • e.g. "what kid of document to create"
  • e.g. "updates available"

Learn Incrementally

• learn in a hierarchical / fractal manner
• learn only a few things at a time

Domain Expert Expectations

LEGO® Blocks

• Expect to be able to snap software together like LEGO® blocks
• Expect to choose functionality from a palette
  • limited options
  • easily browsed
  • e.g. fixed set of functions available in spreadsheets
• Do not care about abstraction
• Understand scripting
  • e.g. cooking recipes

Whiteboards

• Domain experts use whiteboards

Eschew Software Expertise

• Do not want to become software experts
• Expect the benefits of software
  • flexibility
  • easy to design solutions within their domains
    • e.g. VisiCalc (spreadsheets)
• Simple things are simple to implement
• Call in Software Professionals to handle complexity

Tools

• Spreadsheets
• AppleScript
• Hypercard
• (Sikuli?)

Software Professionals

Software LEGO® Blocks

• Software Professionals use:
  • git
  • GitHub, etc.
  • libraries
• Result:
  • not LEGO® blocks
  • growing complexity
  • decreasing reliability

Whiteboards

• Software professionals sketch designs
• The, they transfer the designs to code
  • Why?
  • Why not use code instead of sketches?

"Software is Complicated"

• excuse?
• or, reality?

Hardware Advanced Faster Than Software

• Hardware Advanced Faster Than Software
  • Why?
    • glib answer: software is "just" more complicated
    • possibility: there is an inhibiting technology underlying all of software
    • possibility: is there a new technology?  Something different from what we call "programming"?

QWERTY Effect

• Technology lock-in
• Incremental
  • QWERTY vs. other keyboard layouts
  • VHS vs. Beta
  • 808x vs. other CPU designs
• QWERTY Effect
• New Technology?
• Many Uses of Computers

New Technlogy?

• Can QWERY effect mask inhibiting technology?
• does lock-in stop progress?
  • e.g. QWERTY design did not stop progress on document preparation
  • software improvements decrease QOS^[1] over time
    • e.g. LibreOffice runs more slowly on new Macs
    • e.g. git fails mysteriously sometimes
    • e.g. continuous stream of "update available"
    • e.g. continuous stream of new PLs
    • e.g. Telecom offered four-nines (0.9999 uptime) technology in 1960's, but no more
    • e.g. CI/CD (why is this necessary?)
• A completely different paradigm?
  • Is a technology - minus the inhibitor - the same technology, or is it something completely different?
  • Is it "wrong" to think of computing as a single kind of thing or are there multiple kinds of computing?

Many Uses of Computers

• Calculators
• Event-driven controllers

Computers as Calculators

• Ballistics
• Cryptography (not Blockchain!)
• One-in, one-out
• Synchronous
• Functional Approach
• CALL RETURN
• Hidden global variable

One In One Out

• One input —> one outcome
• one input always leads to one outcome
• Exceptions are a "special case" tacked onto the side
  • syntactic sugar

Synchronous

• each step waits for sub-step to complete
• dynamic dependency chain
  • who calls what is determined at runtime
• led to incremental band-aids
  • e.g. removing state
• Loop, Recursion allowed

Functional Approach

• "Order Out Of Chaos", Ilya Prigogene (Nobel laureate)
  • [paraphrased] Functional thinking has set Physics back 100 years
• FP - Functional Programming
• Eschew Time
• Eschew State

Eschew Time

• Functions are reversible
• hence, time must be removed, no f(t)
• does not model physical reality

Eschew State

Removing state

• when it's a good idea
  • building a calculator
  • building a filter
• when it's a bad idea
  • needing state for functions of time, f(t)
    • e.g. controllers
    • e.g. robots

CALL RETURN

• Implicitly uses the stack
• Creates a dynamic record of invocations
• dependency chain <— dynamic record of invocations
• useful only for calculator model of computing

Global Variable

• All PLs, incl. FP and Smalltalk, share a global variable
• The Stack
• CALL / RETURN manipulates this global variable

Computers for Event-Driven Control

• Asynchronous
• Components run forever
• Multiple outcomes
• Eschew Dependencies
• How to Implement Synchronous Paradigm in Asynchronous Paradigm
• Isolation
• Examples

Asynchronous

• Events can occur at any time
  • e.g. sensor
  • e.g. GUI
  • e.g. browser
  • e.g. mouse
  • e.g. keyboard

• Loop, Recursion not allowed 
  • not applicable
  • what does it mean to Recur/Loop a system of independent components?

Components Run Forever

• Components run forever
• implies State
• implies Send() to receive data

• implies Send() to send results

• implies Send() to send exceptions

Multiple Outcomes

• One input —> one output
• One input —> multiple outputs
• One input —> no outputs
• See also
  • Javascript FileReader() 
    • [multiple outcomes handled with multiple callbacks]

Eschew Dependencies

• Scalability requires lack of dependency

Implementing Synchronous Paradigm Using The Asynchronous Paradigm

• Blocking
  • ACK / NAK
• Already explored and understood in…
  • networking
  • electronics

Isolation

• Isolation is more important than encapsulation
• Must encapsulate data and control flow

Examples

• Statecharts
  • https://computingsimplicity.neocities.org/blogs/StateCharts.pdf

Blockchain

TWO paradigms - not one

1. Calculation
   • cryptography
2. Event-Driven
   • time-based obfuscation
   • p2p

Accidental Complexity

• Due to choosing wrong paradigm for a problem
• example
  • threads, multitasking built on top of synchronous paradigm
    • epicycles on top of epicycles 
      • e.g. promises
  • Mars Pathfinder disaster

Shuhari

• Shu
  • end users
• Ha
  • domain experts, non-programmers
• Ri
• software professionals

---

[1] Quality Of Service