Happy Path (Part 1)
Happy Path
A happy path is defined as the control flow followed by a program to handle the backbone of an application.
The assumption is that there is only one backbone for an application, and other paths are exceptions, by definition.
The assumption is that the Happy Path is a first-class construct, while the rest of the paths are second-class constructs.
I disagree with the above assumption.
I believe that a program must handle all paths through an application and that all paths are first-class constructs.
With the rise of distributed programming[^distributed], it is important to consider all paths.
[^distributed:] For example, blockchain, p2p, internet, and HTML.
I think that Dave Ackley’s[^ackley] MFM and Robust Computing work also denies the existence of only a single path, although he may describe the problem differently.
[^ackley:] https://www.cs.unm.edu/~ackley/
I believe that most PLs (Programming Languages) emphasize the single-path perspective and relegate all other paths to a lesser status[^secondclass].
[^secondclass:] For example, JavaScript callbacks, and thread libraries.
I believe that notation influences thinking, and, therefore, we must begin using PLs that treat all programming paths as first-class constructs.
Wikipedia
The Wikipedia entry for “Happy Path” perpetuates this unfortunate perspective:
“… is a default scenario featuring no exceptional or error conditions. …”
[^wiki:] https://en.wikipedia.org/wiki/Happy_path
PLs Focus on The Happy Path
Every Other Path Must Be Sad
(tbd)
Abdication of Error Handling
Elm
Functional Programming Model
Functions are one-in-one-out constructs, everything else is an exception.
Drakon
http://drakon-editor.sourceforge.net
Railway Oriented Programming
https://vimeo.com/113707214
Diagrams
Diagrams allow expression of multiple outcomes while retaining the essence of mathematical manipulation (aka copy/paste).