The wheels that need the most reinventing are our habits based on old biases, e.g. languages and operating systems. The old biases - CPUs are expensive, memory is scarce and expensive - are no longer true.
REAMDE.md: https://guitarvydas.github.io/2021/10/03/Wheel-Reinvention.html
I didn't read the essays yet, but I find the linked read me hard to read. The first part is ok, but after the Wrapup title, I don't know what I'm looking at.
Thanks for your comments, RealHumanNeo and mrmixer.
I will try to make this more clear.
[The submission consists mostly of revelations (derived from writing essays) and a small amount of exemplar code.]
Well, I read most of the things linked in the "readme", and it looks a lot like notes not meant to be read by others. If that's the case you can dismiss the following paragraphs, otherwise I think it would be nice to have a more textual thing rather then a list of points. It might also be that I didn't understood what the project is.
The most structured/readable one was the CALL RETURN Spaghetti essay and, in my opinion, it lacks context (why is that needed) and the only "metrics" is that the output order is guaranteed (which wasn't stated as a requirement in the "introduction" of the essay).
Other essays are less "written" and contain a lot of abbreviations I didn't recognize, and often don't justify assertions.
If it helps, here is an essay I wrote just before the jam. I didn't include it because it wasn't created during the jam.
https://guitarvydas.github.io/2021/09/23/Manifesto.html
I touch on:
- Notations
- Software Architecture, dataless languages, any language with
+is an implementation language - Diagrams as Syntax (hybrids of diagrams and text)
- Asynchronous Software Components (Snapping software together like LEGO® blocks)
- Concurrency (teachers teach hard realtime notation to 5 year-olds...)
- Removing Dependencies
- Simplicity
- Isolation
- Programs that write programs
- Computers are Machines
- Computer are More Than Merely Calculators
and highlight several other essays.
Edited by paultarvydas
on
Isn't your premise antithetical to the handmade manifesto?
It seems like your premise is "performance is now infinite and we can do whatever we want".
IMO...
11th Rule of Programming: every GPL (e.g. C++, Python) is a meagre implementation of an IDE.
Our workflows are rooted in the biases and realities of the 1950's.
The realities are different in 2021, but we continue to use a 1950's workflow. (For example, RPis are cheap CPUs with their own sand-boxed cheap memory. Servers don't fit the 1950's model of everything-must-be-synchronous).
PEG makes it possible to side-step GPLs completely and create notations (syntaxes) at will.[^1]
I think in terms of dividing the development work up into pieces and using the machine to do as much for me as possible:
- Waste machine power for the development UX.
- Waste machine power for Production Engineering.
Don't waste machine power in the final product.
The performance goals of (1) are very different from the performance goals of (2).
Combining 1&2 into a single GPL results in an LCD union which is mediocre at best.
Currently, we waste machine power on the LCD, then we, also, waste brain-power on trying to make the LCD fit our problem-at-hand. (For example, we perform DRY manually. The machine should help with DRY, refactoring, etc.)
If I concentrate on (1), then the first thing I think of is a REPL. That is what I think that Live Coding is all about - REPLs. A REPL is certainly not needed in the final product. Currently we use languages that are biased towards (2) and forego ease-of-development.
[I would be glad to discuss further...]
[^1]: My favourite PEG is Ohm-JS and Ohm-Editor.
further thoughts, comments and opinions about this question https://guitarvydas.github.io/2021/11/23/Peformance.html