I was writing about Compound Feelings and then I wrote this for a thousand years: “And so “A Thousand Years” gives me very different things to love/hate about it.”. Don’t know why.
One thing about me is that I love finding the history and root of things. I always read the origin of words, I always go to find the history of things I use. That is trying to have the graph as you can see…
I finally added a new grammar to the Archive so that I can have custom labels for Archive handles. I used to link people in the quotes to their profiles in Archive , and then it would sound so strange, and then I finally decided to have a grammar like @handle[custom label] support in the system. With all of this, it was also necessary to have a support for syntax highlighting in Visual Studio Code, so I created a new language called Archive Essay that supports handles and the Fermata () marks. I have to add support for the special quote language and stuff like these here and there as well…
Sting’s “A Thousand Years” has a profound meaning for me. My childhood was bounded to Sting, and a few different artists that my father loved; but Sting was something else for me. Most artists share the pop templates, Sting had such a strange “vibe” that it was unlike anything else. Given him being British, traveling to all the Arabic countries, you could feel a sort of “oriental” theme in the way he had used instruments in pieces like “Desert Rose” and the “A Thousand Years”. While Desert Rose was a very energetic piece and everyone here loved it, A Thousand Years remained very unknown, and therefore it remained more and more personal to me. It starts with a pad in the background, some exotic noise, and then another string-like pad comes in, they feel like desert sounds, and then you find a piper like instrument that sounds like the “British Idea Of Middle Eastern Sounds”. It is not something you would hear in an Arabic country, it is a dream of the Europeans about what is being played in Arabic countries. It is by definition an oriental piece, and it is one amazing piece.
As with most of our dreams, I find the oriental dream more beautiful than the original piece. I think it has to do with the Platonic Forms and the strange picture that is not reality, but what happens in our embedding spaces. What happens when we put things that we find are the same into a same category and create compound feelings we then export as art…
And A Thousand Years gives me a picture of my childhood that gives its compound feeling nature is impossible to describe, but I will do my best in here to give you some hints.
As you know my father had [I left writing this in the morning, did all of the other things and I’m now picking it up again at 4:30PM] lived in France. He has a very specific style of sculpting and taste, his tate includes so much clay, the shades of brown, an abstract nature that does have lots of African elements, so much of the modern day France, it is by any means him. And so the texture of those sculptures, their shades under the sun… They are a compound feeling for me, and that compound feeling
I was thinking about a few different things and noticed my mind’s workspace for some time and they emerged as being a perhaps new notion of programming or the system design of it. Them simply being:
- Wolfram 's rewriting systems and pattern matching
- The “Composing” idea in languages like Go
- Immutable structures in LISP Languages.
- Dataflow Programming
And so what came out of all of it was triggered by the Strangeloop talk: “Simple Made Easy”; and it basically was describing a world in which things are not tangled. And easier and more beautiful code. So I was thinking and I guess arrived at an idea: What if we apply Ruliad to programming. Ruliad is a bad word; maybe multiway systems or pattern matching on a graph scale.
And so some thing came to my mind: When we try to make systems that are not tied together, we must remove the function and linking barrier. And so I was thinking about systems where functions are not linked together. You must see that the main thing here is not to be limited in the logic you made for a software and be able to extend it any time. So how do you go about doing this?
A classical solution to this is Forth/Smalltalk worlds in which you have systems that don’t link the codes to each other; but have functions that do compile and can have their meaning changed at any time while also preserving the way they run. In Forth there is no communication between functions. They both take what is on top of the stack and push their results back there. This makes it really easy for them to work with each other and never know the “Signature” of another function. Of course; Forth remains a fairly basic language.
And then on the other hand you have Smalltalk that does the exact same thing with some twist. In Smalltalk the code does not link functions to each other but sends messages. And functions there can respond to a message or not; they can even go to function that does not exists. Again that makes it possible to have systems that are not linked but they work. One can redefine a Smalltalk function as they are running and the system works —— amazingly.
None of these makes sense however in updating a software. How can you make the logic of a big system in simple code without them being intertwined? It would be very hard.
And so what you do? You have to go with flowcharts. And when you go with such things; you risk getting into something very very complex very easily that again is very complex.
Now; here I was also thinking about reducers and just what terrible idea they are. Personally they make no sense to me. Okay… So what then? What can we do? Maybe… and just maybe… We can have a system like a Ruliad that pattern matches rules against the state and then you could have them move like this.
Let me explain it better. Imagine you have a system where you can write many nested conditions:
And that they were state machines basically. How would you go about making them happen?
At some point; I would think about events; at another functions that call each other; or server-like state machine making.
But what if you could query for a pattern and pattern match it anywhere it happened? This would then mean you’ll have logic adding to the previous without needing to modify them. This would mean you can add and remove from the system at any time; and it would mean way way cleaner code.
Now the interesting part is that it feels a lot like Eve; not feels a lot; this is Maestro Granger ’s Eve Language and its prior research; the Bloom Language from BOOM Lab. And what is not a coincidence is that Granger used to be one of the most hardcore Clojure developers in the world and so there is no way he had not seen “Simple Made Easy”. Again; and again; reading what others read makes me understand things about them I could never have understood. For so many years I tried to understand Eve and I could not. Then reading something Granger had himself read and liked I finally moved enough towards his Mind Graph that I finally understood. Not only I understood him but arrived at Eve from first principles. As you know this happened with Wolfram ; and Knuth ; and Maestro Victor … How can I put this to education?
And then there are other things. ——- But first lets name this. I think they should be named:
With the meaning:
Something that is so fundamental to understanding a Node; But is so digested and concealed into the sender’s graph that it is left out of the sub-graph transferring and the receiver can not integrate the new node to theirs because of its absence.
And so I could not understand Victor without McLuhan ; I could not understand Kay without Dynamicland; I understood nothing of Knuth 's work on TeX without baselines in rendering and I understood nothing about Eve or Bloom without understanding simple is being LEGO not a fabric.
I have noticed the pattern enough that it needs to be named and oh boy that it is important.
And about the language; What if we could merge Eve and the Wolfram Language? Two different ideas about pattern matching.
Secondly: Given this and similarities to Neural Network and Ruliad; what if this is the natural structure of thinking arising from natural laws of computation coming from the fabric of the universe.
Connected to Kary Mechanics and also 1285
What’s true of every bug found in the field? […] It passed the type checker. What else did it do? It passed all the tests. Okay. So now what do you do? Right? I think we’re in this world. I’d like to call it guard rail programming.
Right? It’s really, really sad. We’re like, I can make change cause I have tests. Right? Who does that? Who drives their car around banging against the door? I’m glad I’ve got these guard rails because I’d never make it to to the show on time. Right? And, and do the guard rails help you get to where you want to go? Like the guard rails, like guide you places. No, those guard rails everywhere. They don’t, they don’t point your car in any particular direction.
What kind of runner can run as fast as they possibly can from the very start of a race?
Only somebody who runs really short races. Okay?
But of course we are programmers, and we’re smarter than runners, apparently (!), because we know how to fix that problem. Right? We just fire the starting pistol, every a hundred and call it a new sprint.
So, what things are complex, and what are the simple replacements? I’m going to dig into the details on these. So I won’t actually explain [
- State and objects are complex, and values are simple and can replace them in many cases.
- Methods are complex, and functions are simple.
- Namespaces are simple. The reason methods are there is because often the space of methods—the class or whatever—is also a mini, very poor namespace.
- Vars are complex, and variables are complex.
- Managed references are also complex, but they’re still simpler.
- Inheritance, switch statements, and pattern matching are all complex, and polymorphism à la carte is simple.
Okay. Now remember the meaning of [
- Syntax is complex. Data is simple.
- Imperative loops, fold—even fold, which seems kind of higher level, still has some implications that tie two things together—whereas set functions are simpler.
- Actors are complex, and queues are simpler.
- ORM is complex, and declarative data manipulation is simpler.
- Conditionals are complex in interesting ways, and rules can be simpler.
- Inconsistency is very complex. It’s almost definitionally complex, right? Because [
consistent ] means to stand together. So [inconsistent ] means to stand apart. And that means taking a set of things that are standing apart and trying to think about them all at the same time. It’s inherently complex to do that. And anybody who’s tried to use a system that’s eventually consistent knows that.
So there’s this really cool word called complect. I found it. Complect—I love it. It means to interleave or entwine or braid.
Okay. I want to start talking about what we do to our software that makes it bad. I don’t want to say braid or entwine because it doesn’t really have the good/bad connotation that complect has. Complect is obviously bad. Right?
It happens to be an archaic word, but, you know, there’s no rule that says you can’t start using them again. So I’m going to use them for the rest of the talk.
So what do you know about “complect”? It’s bad. Don’t do it. Right. This is where complexity comes from. Right? Complecting. That’s very simple.
Right? And in particular, it’s something that you want to avoid in the first place. Right? Look at this diagram. Look at the first one. Look at the last one. Right? It’s the same stuff in both those diagrams—the exact same strips. What happened?
They got complected. And now it’s hard to understand the bottom diagram from the top one, but it’s the same stuff. You’re doing this all the time. You can make a program a hundred different ways.
Some of them—it’s just hanging there. It’s all straight. You look at it. You say, oh, I see, it’s four lines, this program, right. Then you could type in four lines in another language or with a different construct. And you end up with this knot. So you’ve got to take care of that.
So “complect” actually means to braid together, and “compose” means to place together. And we know that, right? Everybody keeps telling us what we want to do is make composable systems. We just want to place things together, which is great. And I think there’s no disagreement, right? Composing simple components—simple in that same respect—is the way we write robust software.