[comment]: # "markdown: { smartypants: true }" ## Software Engineering's <br>Greatest Hits

> By the mouth of 2 or 3 witnesses... - God <small>(not my words!)</small>

> Software engineering is programming, with respect to time and _across_ people <small>(paraphrasing Rob Pike as quoted by Russ Cox, paraphrasing Titus Winters)</small>

Go with Versions (2018) <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/F8nrpe0XWRg?start=198" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=F8nrpe0XWRg&t=200s">https://youtube.com/watch?v=F8nrpe0XWRg&t=200s</a></small> <small> <ul> <li>3:20 - 3:58 (or 4:39)</li> </ul> </small>

A "Live at Head" Language <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/tISy7EJQPzI?start=495" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=tISy7EJQPzI&t=497s">https://youtube.com/watch?v=tISy7EJQPzI&t=497s</a></small> <small> <ul> <li>8:17 - 9:40, 9:54</li> </ul> </small>

> The most important archaeological finds of the 22nd century. <small><a href="https://creedsofcraftsmanship.com">Creeds of Craftsmanship . com</a></small>

The Zen of Python (2004) <img src="https://github.com/ewjoachim/zen-of-python/raw/master/zen_web.png" />

<img title="The Go Proverbs" src="https://github.com/BeyondCodeBootcamp/go-proverbs/raw/main/Go%20Proverbs%20(300dpi).png" /> <small>(2015)</small>

Zen of Zig (2017~) <small> <ul> <li>Communicate intent precisely.</li> <li>Edge cases matter.</li> <li>Favor reading code over writing code.</li> <li>Only one obvious way to do things.</li> <li>Runtime crashes are better than bugs.</li> <li>Compile errors are better than runtime crashes.</li> <li>Incremental improvements.</li> <li>Avoid local maximums.</li> <li>Reduce the amount one must remember.</li> <li>Focus on code rather than style.</li> <li>Resource allocation may fail; resource deallocation must succeed.</li> <li>Memory is a resource.</li> <li>Together we serve the users.</li> </ul> </small>

Axioms of AJ (2022~) <small>(draft)</small> <small> <ol start="0"> <li>"Perfection is achieved, not when there is nothing more to add, <br> but when there is nothing left to take away." - Antoine de Saint-Exupéry</li> <li>return something, or return nothing</li> <li>return await, or await without return</li> <li>let errors bubble until they burst <br> (Correct or Classify, but do not Catch)</li> <li>Gatekeepers at the gates, Doorkeepers at the doors</li> <li>No worthless abstractions <br> (<em>Abstractions should be deep - John Ousterhout</em>)</li> <li>But by the 3rd or 4th time, you should know what it is</li> <li>Optimize for the happy path (not for exceptions)</li> <li><em>When it is broken, it is the right time to fix it - Chinese Fortune Cookie</em></li> <li>The constraint of the medium defines the Art - Sariah Bunnel<br> (<em>"Anything goes"</em> is <em>not</em> a workable constraint)</li> <li>If it sounds cool, DON'T DO IT! 🚨</li> </ol> </small> <small><a href="https://github.com/coolaj86/AJScript/issues/28">https://github.com/coolaj86/AJScript/issues/28</a></small>

### 1. Less is more

<!-- Re: everything that combines discipline and creativity --> > **Perfection is achieved** not when there is nothing more to add, > But when there is **Nothing Left to Take Away** <br><br>- Antoine de Saint-Exupery <small>(and Douglas Crockford)</small>

JavaScript: The Better Parts (2015-2018) <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/XFTOG895C7c?start=118" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=XFTOG895C7c&t=120&list=PLxki0D-ilnqbtvVf7xKP0gmIgp5UPS9hu&index=9">https://youtube.com/watch?v=XFTOG895C7c&t=120</a></small> <small> <ul> <li>2:00 - 3:11</li> </ul> </small>

> Features add complexity, <br>we want simplicity. > <br><br>Features hurt readability, <br>we really want readability.

> Readability is the most important feature of a programming language

> because **readable** means **reliable**. <br><br>- Rob Pike

Simplicity is Complicated (2015) <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/rFejpH_tAHM?start=323" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=rFejpH_tAHM&t=325">https://youtube.com/watch?v=rFejpH_tAHM&t=325</a></small> <small> <ul> <li>5:25 - 6:59 (or 7:26 or 8:51)</li> </ul> </small>

> All of these languages are evolving by **adding features**.

> That means they're becoming more **complicated**.

> Their complexity is growing, while they are simultaneously becoming **more similar** to one another.

> I would summarize that is **bloat without distinction**. - Rob Pike

Simplicity is Complicated (2015) <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/rFejpH_tAHM?start=63" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=rFejpH_tAHM&t=65s">https://youtube.com/watch?v=rFejpH_tAHM&t=65s</a></small> <small> <ul> <li>1:05 - 1:42</li> <li>3:05 - 3:23</li> </ul> </small>

> Composition over Inheritance <br>- The Gang of Four <small>(and every thought leader Richard Feldman has ever heard of)</small>

Why isn't Functional Programming the Norm? (2019) <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/QyJZzq0v7Z4?start=1190" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=QyJZzq0v7Z4&t=1192s">https://youtube.com/watch?v=QyJZzq0v7Z4&t=1192s</a></small> <small> <ul> <li>19:52 - 23:08</li> </ul> </small>

> If you write the most clever program you can, given the unknowns (bugs), it's more complex than you can understand

Overheard at the Water Cooler... <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/OYMk4Zws-jE?start=3716" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=OYMk4Zws-jE&t=3716s">https://youtube.com/watch?v=OYMk4Zws-jE&t=3716s</a></small> <small> <ul> <li>1:01:56 - 1:02:34</li> </ul> </small>

> RISC

<img src="https://images.macrumors.com/t/vAKsAXh9KGPBHskUiaqA-t6Pu6g=/2500x0/filters:no_upscale()/article-new/2022/03/apple-silicon-chips.jpg" />

### 2. Emergent Design (Delay Decision-Making)

> We did what we always do when there’s a problem without a clear solution:

> we waited.

> Waiting gives us more time to add experience and understanding of the problem

> and also more time to find a good solution. <small><a href="https://go.dev/blog/toward-go2">https://go.dev/blog/toward-go2</a> (2017)</small>

> Don't make the most difficult to change decisions at the start - that's when you have the least correct information to guide it. - Yours Truly

> If type hierarchy is the foundation of your program

> it's often easier to struggle along with an incorrect type hierarchy

> than it is to change it.

Go Programming (2010) <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/jgVhBThJdXc?start=650" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=jgVhBThJdXc&t=652s">https://youtube.com/watch?v=jgVhBThJdXc&t=652s</a></small> <small> <ul> <li>10:52 - 11:22</li> </ul> </small>

> We can't always identify the correct solution, <br><br> > but we _can_ identify _incorrect_ solutions. <small>(paraphrasing of John Ousterhout)</small>

A Philosophy of Software Design (2018) <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/bmSAYlu0NcY?start=708" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=bmSAYlu0NcY&t=710s">https://youtube.com/watch?v=bmSAYlu0NcY&t=710s</a></small> <small> <ul> <li>11:52 - 12:12</li> </ul> </small>

> Perfect is the enemy of good (1770)

> **[Abstractions] should be deep.** <br><br> > A shallow [abstraction] doesn't help you in the fight against complexity. <br>- John Ousterhout <small>(paraphrased from David Parnas)</small>

A Philosophy of Software Design (2018) <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/bmSAYlu0NcY?start=751" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <small><a href="https://www.youtube.com/watch?v=bmSAYlu0NcY&t=753s">https://youtube.com/watch?v=bmSAYlu0NcY&t=753s</a></small> <small> <ul> <li>12:34 (or 13:05) - 14:20 (or 14:52)</li> <li>15:17 - 15:50 (or 16:26 or all of it)</li> </ul> </small>

```java private void addNullValueForAttribute(String attribute) { data.put(attribute, null); } ```

> The **body of a function** should fit in **a single scroll**, > more or less.

> The **functionality of a module** should fit in a **file**, > more or less.

## GEFN