Adriaan Leijnse
04/04/2023, 3:39 PMChris Knott
04/04/2023, 6:21 PMgreg kavanagh
04/04/2023, 6:24 PMAndrew F
04/04/2023, 9:00 PMNick Smith
04/05/2023, 12:23 AMAdriaan Leijnse
04/05/2023, 1:17 PMAndrew F
04/05/2023, 1:27 PMAdriaan Leijnse
04/05/2023, 1:28 PMJarno Montonen
04/06/2023, 7:09 AMBeni Cherniavsky-Paskin
05/14/2023, 3:23 PM#include <stdio.h> // OS input/output facilities
int main(int argc, char **argv) { // OS calling convention
char *name = argv[1]; // OS calling convention (I skipped the error handling)
printf("Hello, %s!\n", name); // OS input/output facilities
return 0; // OS calling convention
}
All the attention is on process<->OS interfaces 😦. Which would be appropriate if teaching a shell, where you compose processes, but is irrelevant noise for teaching modularity within (say) C.
If you accept this argument, you must start teaching in a REPL (or better), where you don't build an OS executable; you define a function (or method etc.) and the user "interacts" with it by using the language's normal call syntax.
>>> def greet(name):
return "Hello, " + name + "!"
>>> greet("Alice")
"Hello, Alice!"
[Corollary: the 1st language mustn't be a compiled language.] /rant
So, if you're writing a game where you move a piece, or attack, the MVP is appending | move ...
or | attack ...
to the program code!
Which would take previous game state & compute next state.
Well, not necessarily append at the end. At highest level a game is a compute_inner_state | render
pipeline, and the place to append player actions is compute_inner_state
where you work on inner state. [Game-travel debugging requires an env where you can stop at middle of compute_inner_state
as if the rest is commented out and run | render
from there.]
• If you have multiple moving units/pieces, it's tempting to append code into their individual "state functions", instead of descending a data structure to modify the right one. [200% vaporware]
• I'd hope collaborative editing can stretch this into MVP for multi-player turn-based games. [300% vaporware, requires tricky modeling of time and concurrency. I have some ideas around "wait until _T_" meaning "this function does early return if time < _T_" but entirely unproven...]
Well, that's minimal but won't feel like a "normal game UI".
Plus, need some constrained mode temporarily restricting coding to "legal actions in the game".
OK, but I want "UI buider" which is explicitly about binding key presses or a clickable screen regions to be shorthands to code modification.
Like Emacs, one should not code explicit "I/O". Just customize the environment's event loop.
(3) Even more ideological: I want people exposed to the subversive idea that it's any action they take interacting with a computer (key press, click etc.) is a form of programming. And that they can always script bigger programs out of those.