Subdividing Problems

[Do you have a heuristic when to use certain paradigms and when to avoid them?]

Fractalize.

FDD - Failure Driven Development.¹

Break a problem down, break each part down into sub-parts. Repeat (recur).

Choose a different paradigm for each sub-part. Choose based on the problem-at-hand.

For example, input is mostly pattern matching — parsing, PEG, S/SL.

Output can be done with printf and JS back-tick strings. When I need tabular output, I use a spreadsheet to edit the final tables (I convert / normalize the data into .CSV files, to make the data more acceptable to spreadsheets).

[N.B. I needed an editor to make the final output format for a project. Spreadsheets are good editors (for tabular data), but tend to lock you into a single paradigm (spreadsheet language). .CSV is a normalized format acceptable to most spreadsheets. If you convert your data to/from .CSV, you can use any editor (built into spreadsheets) you want. Export from the “editor” to CSV. We need a .CSV-like normal form for all data and programs (I suggest triples).]

[N.B. Talking about editors, I like to use Keynote as an editor — it helps me organize my thoughts and to keep my text short. Keynote has the disadvantage in that it doesn’t export well to normalized forms. Keynote does export to HTML, but includes a bunch of JS in the process.]

Queries are exhaustive search. PROLOG has a nice syntax for crafting queries. PROLOG can import and export data in normal form (triples).

Note that I am breaking programming down into two classes (at least): human readable syntax vs. machine readable syntax.

/bin/sh was aimed at machine readability. After that, things like /bin/bash and /bin/zsh only danced around the elephant and didn’t really bring any new advances in think-ability.

In my mind, the next step for /bin/sh is to make it diagrammatic. Visual Shell. vsh. [Experimental version at https://github.com/guitarvydas/vsh]