Hi! Found my way by wandering through different communities (malleable software, javidx9, graphics programming, some reddit threads and etc). I'm mostly into self-taught, especially if I find the thing is fun. Most of the work I did were prior finding those communities and forum posts. Meaning while I'm open to novelty and challenges, in some places I have quite a lot of disagreements on what future of software is. Not like I disagree with the movement entirely, but mostly with the goals on how it's reached and what future of software is. (I also disagree with "Computation is everything") I came with current ideas, because I had quite a lot of successful niche projects that died just because they lost their purpose and I realized that porting them would be a waste of time, because it would be doing same work over and over again. So I had and Idea "what if I try to formalize the idea of program, rather than computation, so I can port it to anything, given the implementation of foundation", I already had at that time programming language in the works, so I just reworked it for that idea. I despise the world being focused on implementing X on Y, because from outside it looks like we are running in circles and not doing anything to move on.

Sounds like you'll fit right in here.

It's like decentralized web instead centralization common sense. In programming its too, to abstract away from implementation is also long dreamed idea. Have you looked at Lisp? People start from that.

Yes, I have looked at Lisp. It was too pure and quite isolated from practical computing. Sure, the 'everything is a list' philosophy is cool, but our interfaces and thoughts are not lists - they are contexts, negotiations, and state machines. Lisp doesn't have proper context management. Lisp tries to abstract away the von Neumann machine. It wants to live in a pure mathematical realm. But practical computing doesn't happen in a mathematical realm; it happens on hostile, unsafe terrain. Lisp is a beautiful, static palace built in the clouds. I’m trying build an off-road vehicle designed to navigate the actual dirt of the C substrate. I can elaborate on that, if you want proofs.

You really want the clouds? That's Haskell. Keep in mind that "Lisp" is a category. Common Lisp is old as dirt. Racket is the more education oriented and has an interesting way of stacking Lisp-like languages. Clojure is the serious Lisp dialect for the JVM. Some of us have been at this programming thing for quite a while and have seen many proofs of many things.

No, I need a vehicle, not clouds. I need language that abstracts over implementation, not away from it

Can you give an example of what that kind of vehicle is like, what it does for you?

The vehicle exposes the engine block while the car is moving, and it lets you swap parts without stopping. When I say "abstract over the implementation, not away from it," I mean that the language doesn't hide the von Neumann machine from you behind a mathematical curtain. It gives you a structured, safe way to manipulate it directly. Here is an example from my runtime of defining a native function (

print

):

repl
>print : NegI "Artifact" = source "return function (self, arg) print(arg.state) end"
{
  chunk = 'return function (self, arg) print(arg.state) end',
  chunkname = 'NegI_Artifact',
  mode = 't'
}
>print "the flowers that bloom in the warmth of the sun\n are there to be loved by everyone"
the flowers that bloom in the warmth of the sun
 are there to be loved by everyone
nil
>

In most languages,

print

is a magical intrinsic built into the compiler. In my system,

print

is just a

Manifest

- a data structure wrapping a

Protocol

and a

state

. I am defining an

Artifact

by just passing a string of Lua code (

source

) to the

Artifact

constructor. The runtime compiles it and hands back a standard object. On next line it shows you the raw

chunk

, the

chunkname

, and the

mode

. The machinery is completely transparent. Because everything is a Manifest, you can introspect and construct any object in the system, including the core ones. There is no privileged caste of "primitives" that only the compiler author is allowed to touch. - Want to inspect a

Number

? It's just a Manifest with the

p_Number

protocol and a state pointing to a float. - Want to build a new number type? You assemble a new

Protocol

(defining how it handles

call

,

get

, math operations, and memory cleanup), wrap it in a Manifest, and inject it into the environment. This is where the "vehicle" metaphor comes in. A cloud palace (like a pure Lisp or Haskell) says: "You can only build things out of the clouds we provide. If you need to touch the earth, file a request with the compiler." My vehicle says: "Here is the gas pedal (dispatch), here is the steering wheel (context layers), and here is the wrench (Artifacts/Manifests). The road is made of whatever current environment provides (for example: C - pointers and memory, Lua - tables and functions). Drive carefully, but you are fully allowed to rewire the engine while going 60 mph." The practical payoff is context management. Practical computing isn't just mapping functions over lists; it's negotiating state across different environments, rolling back transactions when things fail, and cleaning up resources when a context dies. Because my core runtime treats everything as a negotiated Manifest state (rather than a pure AST) it can manage memory lifetimes and context shifts dynamically, at runtime, without the user having to beg the compiler for an escape hatch.