Differences

This shows you the differences between two versions of the page.

--- javascript_terminal_v3_rant [2023/11/24 04:53] – created appledog
+++ javascript_terminal_v3_rant [2023/11/29 01:03] (current) – appledog
@@ Line 1: / Line 1: @@
-= JavaScript Terminal V3 Rant
+[[JavaScript Terminal v3]]
-Your god damn right this is going to be a rant.
-So many ideas and rationales clashing together. A desktop CPU runs a million times faster than a 6502. 1000x in terms of 1MH to 1GH alone. Not to mention instructions per cycle and //multithreading//. Mind blown. Hold that thought.
-War never changes. Hold that thought.
-JavaScript put us back into the world of single-threaded hell. But we have been there before, and we have conquered; C and UNIX. Hold that thought.
-We are also in event driven hell. Blocking input is impossible because you must lose program context to let the 'system' switch to running UI code. When your program sees a keypress it is ancient history. Its not even triggered when it happens. It triggers (in your code) when the system lets your code run and you read it in a historical record of events. You don't even know where you are in the event stack until after you process that key. Maybe there's 20 keys after it. And a mouse click. You don't know where you are.
-You know what this feels like? It feels like the early days. It feels like the days when we had the bare metal and we had to program drivers. We had to write programs that helped us write programs, which in turn helped us write programs that helped us write programs. Hold that thought.
-Computers got so fast that Java became the most popular language in the world. Wait. What? Java runs on anything? Pretty much.
-== What set you off brother?
-getkey() and input().
-You can't do getkey() in JavaScript. You can't do input() in Javascript. You lose program context. I came up with a system where the program split into terminal mode when you wanted to 'input' a string. When you hit enter it exited terminal mode and put the string on the 'string input stack' along with all the other events. It made a sort of sense. You could get 'SET_NAME Edward' put on the stack. It kinda worked. The code to process it all looked kind of ugly since it implied it would be an endless series of IF statements, but, at least it theoretically worked.
-Then I realized I should just do this using flags. Like an input mode flag, which changed the behavior of a terminal emulator. Input mode diverted characters to a special buffer which was added to a command string. So the command input("SET_NAME", "What is your name?") became possible -- but you had to RETURN after the command. You couldn't keep going. That always annoyed me.
-You could also do getkey() now. The system would put the event-command GETKEY on the stack. When the engine saw this it would leave it alone and check again on the next cycle. As soon as a key was detected it would change to GETKEY x or GETKEY Space or whatever, and the event would be deleted.
-But it bothered me you couldn't say c = getkey() and then act on the key. So I made it retain the state of it; GETKEY had a state which you could read later.
-== An accidental invention
-It's true that if all I wanted to do was name an object or have notes play at the bridge as you entered them I could just create a special scene and game loop and have it work. But it would complicate the code. I began to realize that the solution was to create more and more state. So c = getkey() could be simulated by storig the context of the getkey and then the next command event would be something like SELECT_ITEM_BY_GETKEY and it would automatically read the state and select an item. If there was no state it would insert a GETKEY and the system would getkey() first then select the item from the menu.
-I began to realize what I had done is create a polling system for input, which is not as good as an interrupt system, but it would at least still work. So the code would look something like
-<Code:JavaScript>
-    GETKEY ITEM.       // this stores the value of getkey in an array indexed by 'item' the string.
-    SELECT_ITEM ITEM   // this selects an item based off the data in memory location 'item'.
-</Code>
-This began to look like a programming language to me.
-I also realized that in order to escape the confines of JavaScript and the ridiculous shared-UI-thread model of event driven programming, and build a program that worked well with the input() model described above, that I had to break my program down into chunks that could read these little state values I had stored with commands like INPUT and GETKEY.
-It all came together in a flash as I realized where all of this was leading; the construction of a virtual machine, a specialized programming language that would allow me to write the game the way I wanted to write it.
-== Shared Network Virtual Machine
-I had always had this idea of a virtual machine that would manage the hardware it's running on, and allow contributions from secure or trusted network nodes which allowed it to access resources on the other machine, and share them -- like RAID -- into one giant unix-like system that would be the user layer for people to use. This would truly commoditize hardware. Lag would be an issue, but these are issues that could be solved with physical logistics. The point is that there is a virtual machine, and it works (more or less) and that is the target environment.
-JavaScript in the browser is a million times faster than a 6502. And UNIX ran on a 6502. Yeah it did. There was Lunix and there is semu-c64. There was also minix on 8086 and others. It's possible. It's possible to simulate everything.
-FIXME