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 ?
https://bford.info/pub/lang/peg/
PEG is like REGEXP on steroids.
Architecture and Coding are two different things.
They should not, both, use the same PL.
I divide programming up into several camps:
In my mind
Software Professionals use whiteboards.
Why?
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 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.
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.
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]
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.
- 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]
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.
https://guitarvydas.github.io/2020/12/09/Scalability.html
https://guitarvydas.github.io/2020/12/09/Scalability-II.html
https://guitarvydas.github.io/2020/12/09/Scalability-II.html
"And what have you done"
- John Lennon
70 years. 1950 to 2020.
Code is cheap.
Thinking is hard.
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.
TWO paradigms - not one
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)