Yes, this why/how distinction that is beginning to matter much more. There is a funny relationship between the questions though. I'm finding that a sufficiently precisely specified why tends to force the how.

I'm not sure that I agree. The first example that pops to mind is the use of relational programming, like Prolog. In Prolog programs, you write relations declaratively and let the Prolog engine decide "how" to achieve the result. If you were writing the code for the Prolog engine, though, you would need to specify a lot of "how". The functional code for miniKanren implements an engine that is used to support a different way of thinking. HTML - without Javascript - is declarative, too. HTML code contains a lot of "what" and "why" and no "how". In my mind, our functional and function-based mindset actually leads to blurring of "why" with "how". That mindset is too restrictive for anything but a small class of problems. You can express a lot of programs with this mindset, but that doesn't mean that you should or that it results in the cleanest / most-concise solution. The engine for function-based programming - mapping functional notation onto real hardware - is a big blob of code called the "operating system" (it converts functions into state machines that provide the necessary scaffolding to keep the illusion of functions-mapped-onto-hardware alive). Being stuck in a rut and over-doing the use of a single paradigm used to be called "epicycles". The (original) idea behind DSLs was to separate "what" and "why" from "how". For example, BNF is just a DSL for expressing string matching.

@guitarvydas While I can translate the lua code, the reason I went for direct port to C + TCC is to make improvements to the prototype version. For example some of the code differs drastically from the prototype, because there are objectively better ways to implement some actions, like stack unrolling via setjmp.h or using arena allocation to keep garbage collection out of the project.

@guitarvydas I've noticed your last 2 posts converge towards meta computation and I was wondering if you have thoughts on interaction nets or graph rewriting systems in general. I've always felt like the von Neumann architecture is a bottleneck in defining a deeper foundation that allows more flexibility on the systems layer. What if the fixed way we define/manage memory is the problem with modern compute? (Neurons remember by changing themselves a tiny bit with every activation. So processing is memory, validation, etc.) @Dave Ackley is working on https://movablefeastmachine.org/. I think it's close to your proposal of isolated CPU+memory. It's the best attempt I've found at a working local-first, asynchronous compute model. I'm currently pondering how structurally evolving computation capable of redefining interfaces at runtime is possible

@Kheyas Dev I'm interested in finding low-hanging fruit. Writing code that writes code has become immensely easier in this century. My PBP kernel (Parts Based Programming == system construction using "black boxes") is essentially a multi-tasking kernel written in a "meta language" which generates Python, Javascript and Common Lisp (I ran out of steam for generating other languages. I think I did Odin at one point, i.e. a non-garbage-collected language). [Links available for the asking, to code, to articles, etc.] I think of this in terms of easily-creating DSLs (I call them SCNs), and tend to think that premature formalization discourages this approach. I looked into some of the stuff you mention but didn't dig deeply other than to decide that I could pick low-hanging fruit more easily in other ways.

I've always felt like the von Neumann architecture is a bottleneck

Definitely.

... What if the fixed way we define/manage memory ...(Neurons remember by changing themselves a tiny bit with every activation ...

Yes, mutation. In addition, I view neurons as being isolated from one another, i.e. they have private memory, not shared memory. Neurons are, IMO, an example of massive parallelism. Shared memory is an evil that we've inherited from 20th century biases and constraints and caveman tools like synchronous, sequential programming languages.

...

Yes, I find Ackley to be very interesting. But, I've spent most of my time bloviating and fooling around with black boxes and PBP.

I'm currently pondering how structurally evolving computation capable of redefining interfaces at runtime is possible

I grew up as an Electrical Engineer, wanting to build devices with very fixed interfaces, capable of augmenting human endeavours. I probably don't even get why redefining interfaces at runtime might be useful (but open to hearing ideas on this).

@guitarvydas I relate to finding low-hanging fruit as I'm conservative with my energy. Which is why I'm looking for systems that are more flexible and don't need an overhaul as soon as 1 development iteration is finished. By that time you have collected missing or new requirements, unexpected hurdles and layers and layers of duct taped code. My point is we shouldn't fight the duct tape. We should embrace it because it's useful and allows us to get to the next iteration. But as we build higher we can move all the duct tape to the edges and stop worrying about the core falling apart mid flight Even with a system like ECS you still have to manually define interactions for every system and component added. It's a good example of how things can turn exponential even if they were (supposedly) designed for scalability and elegance. I only took a peek at your PBP kernel and like the visual & meta approach. I can't comment on the functionality but it makes me wonder how it would be presented if you had more resources. I'm debating if I should add bloviating to my vocabulary 😄. Oddly specific and fun but takes away from the importance of the work which is: f***ing around and finding out even if it's just words arranged in different ways. Thinking (talking/writing to yourself or others) is the cheapest way to enact change.

@Kheyas Dev I am, at this very moment, writing more about FDD - Failure Driven Development. The basis is that we have been attacking only 1/2 of the problem. Proving that code is correct does not prove that a Design is correct. My conclusion is that to do the other 1/2 you need to iterate, try things out, discard them and rebuild with new knowledge gained. Building code twice (or more) is cheaper than building it only once and calcifying design decisions too early. To be able to iterate quickly, you need a mish-mosh of various tools and to think like a kid building things with LEGO blocks. Build it, tear it down, try again. Repeat. Failure is the best way to learn about a problem domain. Most of the tools (programming languages, IDEs) that we currently have emphasize the Production Engineering aspect of programming, but tend to push aside the iterative aspects of Design Engineering. PBP is my version of LEGO blocks. T2T is a way to whip up various meta-syntaxes, quickie batch-edit tools and a way to avoid building full-blown compilers before your ideas have converged on a Good Design. It is easy, in the 21st century, to begin using Diagrams as Syntax - DaS (T2T enables that). I want to think in terms of little snippets of laser-focussed code (not necessarily Turing Complete Ultra-Generalized Behemoths), e.g. if I want a decision tree, I draw a diagram and transmogrify it into some existing language (e.g. Python, JS, CL), if I want to think about control flow, I draw a state diagram and transmogrify it into some existing language (e.g. Python, JS, CL). I would be glad to discuss this more, if it interests you (or anyone else)...

@guitarvydas I resonate with the vision. My only concern is that it feels like it should be a collective work. Right now there are few people that work on this and isolated. I'm not sure how much this is needed to concretize some poles/directions vs. how much we should try to come together to start building a growing network of meta computation. I threw this topic at AI and it pointed out that the internet was born out of a new, easy protocol that brought people together. Lego is not about block design but the pegs. I feel like the last protocol innovator was Aaron Swartz: hyping RSS, making the forum aggregator Reddit, free literature platform Jstor, etc. I'm not so much a coder, as a visual thinker. I think I'd rather help others build the tools that I would like to use. I hate what modern programming turned into. I've been looking into new formal logic systems for 2+ years now and have considered a lot of ideas you integrated into your model + many others. It's still not clear what the common ground is and how to bridge all these concept together with a common standard/protocol. But writing this reply made me realize maybe it's about connecting people beyond the web protocols more than rushing to define meta-systems.

@Kheyas Dev 1. We need to break free of the notion that the only way to program is to use 1960s style synchronous, sequential programming languages using operating systems as escape hatches and scaffolding substrates and delivery packaging. 2. LEGO's power comes from it's pegs - i.e. exactly one - and only one - data type for composition. The invention of user-defined data types has led us off of the scent (of KISS). 3. AI is trained only in the "we've always done it this way" kind of programming which dominates the New Library of Alexandria (internet), and, thus, determines how AI can respond. OTOH, AI might be useful as a foil - whatever it says, feel inspired to think differently. 4. We need to stop thinking that syntax must be solely composed of characters based on 600-year old typesetting technology. We can write and think and program visually - our modern machinery supports such concepts. 5. Q: how do interaction nets (or whatever) deal with timing and things like propagation delays? (PBP deals with this by using queues instead of stacks for inter-part communication. (Furthermore, PBP addresses topology blindness and namespacing issues in a simple manner)). 6. We need to stop believing that Engineers should write code. Engineers should create software blueprints. Tradespeople (/ AI agents ("no code")) should write code based on software blueprints specified by Engineers.

@guitarvydas • I haven't managed to get dirty with interaction nets yet. But the reason they exist is because pure lambda calculus needs to look ahead to compute certain expressions. Interaction nets solve this by restricting interactions between 3 types of nodes that can only trigger when the "active" edges meet. This restricts interactions to local-only and between 2 nodes at a time. I think of the resulting field as the process/flow/software part of neural networks. Memory and process in the same form. • There is a company trying to map it to conventional hardware. They focus on absolute reduction/correctness/etc. to build highly parallel languages/solvers. • I think the power of inets is to show that we can start to think of compute as DNA (self-modifying structure) instead of a collection of buildings materials (clay/concrete/etc.) which always need external input.