Contents

Homogeneous vs. Heterogeneous ?

Flat vs. Scoped ?

Modeling vs. Compiling ?

Typing vs. Pattern Matching ?

Compile-Time, Runtime vs. Fractals ?

UNIX® Pipes vs. Libraries ?

Complexity vs Simplicity ?

Dependencies vs. Simplicity ?

Syntax Checking ?

Relative vs. Absolute ?

Arcitecture vs. Code ?

Hardware Progress vs. Software Progress ?

Telecom Four Nines 0.9999 ?

PEG - Easy Language Design ?

Architecture vs. Code ?

Dynamic vs. Static Types vs. Assembler ?

Normalization ?

Visual Programming vs. Textual Programming vs. Diagrammatic Programming ?

Whiteboards ?

Org Charts ?

Portability ?

Rule of Thumb - Compiler Builder Inspired ?

5 Questions ?

One Language to Rule Them All ?

DRY vs RY ?

Abstraction ?

Snap Together Like LEGO® Blocks ?

3 Times ?

PLs Are Too Complicated ?

Scalability ?

Silver Bullet ?

70 Years ?

Code is Cheap ?

Deprecate Recursion and Loop ?

Tired Paradigms ?

Syntax Checking vs. Traceback ?

HTML ?

Strong Typing ?

Commas and Semicolons ?

Blockchain ?

Miscellaneous

Homogeneous vs. Heterogeneous



Flat vs. Scoped

Modeling vs. Compiling

Typing vs. Pattern Matching



Compile-Time, Runtime vs. Fractals

UNIX® Pipes vs. Libraries

Complexity vs Simplicity

Dependencies vs. Simplicity

Syntax Checking

Multiple Syntaxes for Every Language

Relative vs. Absolute



Arcitecture vs. Code

Hardware Progress vs. Software Progress

Telecom Four Nines 0.9999

PEG - Easy Language Design

https://bford.info/pub/lang/peg/


PEG is like REGEXP on steroids.

Architecture vs. Code

Architecture and Coding are two different things.


They should not, both, use the same PL.


Dynamic vs. Static Types vs. Assembler

Normalization

Visual Programming vs. Textual Programming vs. Diagrammatic Programming

I divide programming up into several camps:


In my mind

Whiteboards

Software Professionals use whiteboards.


Why?

Org Charts

Org charts are used to structure businesses.



Just about everyone understands what an org chart is.



People expect that all kinds of Engineering is built in an org-chart-like manner.



People expect that software is built using black boxes arranged in some sort of org chart.



They are wrong.

Portability

Portability is a chimera, at least in my mind.


Programmers try to create portability by using glue-ons - preserve the existing code and glue new behaviours onto the syntax.  (This kind of thinking is very prevalent in the Common Lisp community, which uses *features* to create glue-ons).



I prefer the Engineering model instead.



Specialize, don't generalize.



In electronics, this model manifest itself as a chain of filters that implements only what is needed.



Electronics designers use black boxes of functionality.  At the lowest level, a chip is composed of various kinds of rust that exhibit various electrical properties.  At higher levels, the rust is encased in blobs of epoxy that expose only certain functionality via pins.  At even higher levels, designers contstruct schematics and boards (e.g. motherboards) and VLSI designers use libraries of functionality (like FPGAs)


When a designer can rely on black boxes, a designer can build specific solutions to specific problems.



The fact that programmers need to resort to parameters and #ifdefs is a tell that demonstrates that programmers do not, and cannot, rely on black boxes of software. 

Rule of Thumb - Compiler Builder Inspired

When building compilers, one uses the rule-of-thumb:


An optimization is worth it only if it reduces code size.


This rule can be extended in many other directions, e.g. to optimize for runtime.


The same kind of rule can be applied to Type Checking - what <thing> does the type checking reduce?


When profiling code, one attacks the worst problem first.


Correctness is not the worst problem in software design.


Some design rules can be checked using automation.  


What are the "worst" problems in software design?


The answer to the above question might depend on one's viewpoint - are we discussing how to deliver a product, are we discussing pure research, … ?


In my opinion, the worst problem in software is that of dependencies.  Chains of dependencies need to be snipped and made shorter.


5 Questions

Daniel Pink suggests asking a series 5 questions, e.g. ask "Why?" 5 times.


This method can be applied to programming.


I find that I can "interview" myself by just asking the same question again and again and again …


For example, start with the statement:

"multitasking is hard".


Ask "Why?".  Keep drilling down.


[I record some of my questions and answers in other essays.  See https://guitarvydas.github.io/2020/12/10/5-Whys-of-Multiprocessing.html, https://guitarvydas.github.io/2020/12/10/5-Whys-of-Full-Preemption.html, https://guitarvydas.github.io/2020/12/10/5-Whys-of-Software-Components.html]


One Language to Rule Them All

Programmers seem obsessed with the notion that there is a "unifying theory" behind all of programming and that one language will be the result.


I was schooled in Engineering (EE, to be exact and spent time in Core Physics courses before that).


I believe that there is no need for one language to rule them all.


I believe that we can use many languages to solve any one problem.


I, also, spent time building compilers (starting with Anatomy of Lisp and Small C), and building operating systems (starting with Ric Holt's wonderful book "Concurrent Euclid, the Unix system and TUNIS" https://archive.org/details/concurrenteuclid00holt and reading the UNIX® V7 source code).


I believe that languages are "easy" to build.  One can build a language in an afternoon.


[See technologies like PEG, and the idea of transpiling by building on top of "good" base languages.  I discuss this line of thinking in other essays.]


I believe that one should build many SCLs (like DSLs, but more focussed) to express the solution to a single problem.  Again, I discuss this philosophy in other essays.


DRY vs RY

- a form of Abstraction - useful only for professionals


DRY means Don't Repeat Yourself.


RY means Repeat Yourself.


DRY is a form of abstraction.


Software professionals use abstraction.


Normal people - non-programmers - don't want to know about abstraction.  They want to start out with something that "just works" (see my essay(s) on Shuhari).


Spreadsheets are popular because they



DRY is focussed on Maintenance Engineering.



I believe that software development should be chopped up into several sub-disciplines, e.g. Software Architecture, Software Engineering, Software Implementation, Maintenance Engineering, Software Testing, Q/A, etc.  [see https://guitarvydas.github.io/2020/12/10/Software-Development-Roles.html]



DRY should be automated and it should make RY inexpensive.  This might be in the form of a better editor and/or git/github/etc.


Looking at Paul Bennett's Frames work might offer suggestions https://www.amazon.ca/Framing-Software-Reuse-Lessons-World/dp/013327859X.


I don't know much about Cordy and Roy's NiCad technology, but the abstract(s) seems intriguing.


[See also https://guitarvydas.github.io/2020/12/09/RY-vs-DRY.html]


Abstraction

Snap Together Like LEGO® Blocks

3 Times

PLs Are Too Complicated

PLs (Programming Languages) are too complicated and encourage attention to optimizations.

For example, I consider a language to be too complicated if it contains a + operator.

I believe that programming should be broken into a number of sub-categories and layers.

Only the bottom-most, implementation, layer of programming should use PLs that contain low-level operations, such as +.

Other layers should only use foreign types and collections of foreign types.

Such layers should refer to typed data, but perform no direct manipulation (nor definition) of the typed data.  

All such operations should be functions.

Compilers should do the heavy lifting - for example, inlining functions.

Scalability

https://guitarvydas.github.io/2020/12/09/Scalability.html

https://guitarvydas.github.io/2020/12/09/Scalability-II.html


Silver Bullet

https://guitarvydas.github.io/2020/12/09/Scalability-II.html

70 Years

"And what have you done"

- John Lennon


70 years.  1950 to 2020.


Code is Cheap

Code is cheap.

Thinking is hard.


Deprecate Recursion and Loop

Computer Science clings to the notion of using Recursion and Loops.


Threads were invented to accomodate time-sharing.


To accomodate deep recursion and loops when using threads, Computer Science invented full preemption.


Ironically, loops make no sense on the internet.


You cannot “loop” a pair of distributed computers, you can only send messages between them.

Tired Paradigms

Syntax Checking vs. Traceback

HTML

Strong Typing

Commas and Semicolons

Blockchain

Blockchain Contains 2 Paradigms

TWO paradigms - not one

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

Blockchain essay

https://guitarvydas.github.io/2020/12/10/Blockchain-Overview.html




[1] Jim Rootham <— L.J. (Ted) Rootham <— William Bushnell Stout ("simplicate")

[2] see also https://github.com/guitarvydas/js-prolog)