I disagree with your first statement there. In Unix, everything is a file, including all devices, which also consist of protocols for driving them which are read and written via binary encodings. You ...
No, I'm not muddling things up. Binary encodings are trivially improving performance compared to real-world WebSockets + compression for bandwidth and processing. I know that while many canonical implementations of JSON are suboptimal, the one I made is so fast it competes closely with binary encoding performance — which I also completely smashed the top position on.
The Unix law about preferring plaintext is not about shells. It's about observability during development and for diagnostics during troubleshooting.
Anyway, for me — especially now with such amazing analysis, documentation, debugging, and code generation tools — the problem of building it is trivial. The focus can be on promoting adoption, which is the real hard problem.
Tossing it all away and starting fresh, like that Carvalho guy did with Pubky, threw the baby out with the bathwater and discarded the value of a loyal userbase. I stand ready to man the engines; we just need captains and navigators to take on the job of getting the dev community on board.
Unlike Carvalho, all of my solutions don't leave Nostr users stuck on an island with no bridge. Bridging is key if we want to actually keep this train rolling forwards.
Building a new train completely — when unlike physical devices, we can build them a little more complex but, if architectured cleanly, modular — is more like the difference between ICE, hybrid, and EV. Which of the second two have had the best sales performance in the marketplace? Yes, hybrid — because it's a bridge between electric and oil-powered vehicles, with two options for how to refuel it for longer range, and countermeasures for the problem of cold battery, battery heating, and loss of range, as well as presenting a lower lithium fire risk.
I favor the approach that the Go authors take — and Rob Pike's 10-year challenge. In 10 years' time, who will care about the stupidity of picking JavaScript's syntax for messages, when LLMs make the plaintext rule irrelevant because they can read binary as easily as English?
At this point, that is not the case. I would give it minimum two years before that is the case. At that point — especially if LLM-type technology is turned into a hybrid discrete/continuous system that cheaply processes tree-structured data as well as smooth but quantized sampled data like sound and image/video — and the most important part is that discrete logic — then automatic translation between programming languages, human languages, and exploring concept spaces as graphs instead of fuzzy blobs becomes feasible. The 10-year challenge becomes irrelevant because your mobile phone can run an agent that can do any kind of translation and refactoring from any base, even raw binary code.
But that's speculative, whereas my approach with it is concretely proven right now.
The Unix law about preferring plaintext is not about shells. It's about observability during development and for diagnostics during troubleshooting.
Anyway, for me — especially now with such amazing analysis, documentation, debugging, and code generation tools — the problem of building it is trivial. The focus can be on promoting adoption, which is the real hard problem.
Tossing it all away and starting fresh, like that Carvalho guy did with Pubky, threw the baby out with the bathwater and discarded the value of a loyal userbase. I stand ready to man the engines; we just need captains and navigators to take on the job of getting the dev community on board.
Unlike Carvalho, all of my solutions don't leave Nostr users stuck on an island with no bridge. Bridging is key if we want to actually keep this train rolling forwards.
Building a new train completely — when unlike physical devices, we can build them a little more complex but, if architectured cleanly, modular — is more like the difference between ICE, hybrid, and EV. Which of the second two have had the best sales performance in the marketplace? Yes, hybrid — because it's a bridge between electric and oil-powered vehicles, with two options for how to refuel it for longer range, and countermeasures for the problem of cold battery, battery heating, and loss of range, as well as presenting a lower lithium fire risk.
I favor the approach that the Go authors take — and Rob Pike's 10-year challenge. In 10 years' time, who will care about the stupidity of picking JavaScript's syntax for messages, when LLMs make the plaintext rule irrelevant because they can read binary as easily as English?
At this point, that is not the case. I would give it minimum two years before that is the case. At that point — especially if LLM-type technology is turned into a hybrid discrete/continuous system that cheaply processes tree-structured data as well as smooth but quantized sampled data like sound and image/video — and the most important part is that discrete logic — then automatic translation between programming languages, human languages, and exploring concept spaces as graphs instead of fuzzy blobs becomes feasible. The 10-year challenge becomes irrelevant because your mobile phone can run an agent that can do any kind of translation and refactoring from any base, even raw binary code.
But that's speculative, whereas my approach with it is concretely proven right now.
2❤️1❤️1
