The Opcodes of Tomorrow Part II

205-07-27

In the 1950s/1960s one could build interesting machines using ad-hoc logic using transistors and tubes. Then, that was stepped up to a new level and "opcodes" were invented, which led to one being able to build interesting machines using canned combinations of transistor/tube logic.

Today, we can build interesting ad-hoc networks of machines using nodes internally programmed with async & await. We have not yet stepped up to a new level of expression and have not yet invented a set of "opcodes" for scripting networks of machines using very-high-level-languages, e.g. networking languages.

I think that maybe our "opcodes" might be written in JSON and we need to develop sets of canned operations and the equivalent of ICs which are networkable nodes. For example, at this very moment, I'm building a browser-based editor which accepts commands on a websocket and sends responses (only when needed, like "here is the GUID of the new editor server window that was just created") on another websocket.

Are "arrows" on my diagrams websockets? Are there two kinds of arrows - full-blown websockets vs. internally-more-efficient-message-passing? Maybe we need a language for communicating state machines for building games and communicating state machines across websockets for allowing game nodes to talk to other game nodes?

Previous article (Part I) on this train of thought.

See Also

Email: ptcomputingsimplicity@gmail.com

References: https://guitarvydas.github.io/2024/01/06/References.html

Blog: guitarvydas.github.io

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/65YZUh6Jpq

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Substack: paultarvydas.substack.com