(reposting from the MicroQuickJS thread if only because it seems more relevant here)
Always interesting when people as talented as Bellard manage to (apparently) never write a "full-on" GUI-fronted application, or more specifically, a program that sits between a user with constantly shifting goals and workflows and a "core" that can get the job done.
I would not want to dismiss or diminish by any amount the incredible work he has done. It's just interesting to me that the problems he appears to pick generally take the form of "user sets up the parameters, the program runs to completion".
> when people as talented as Bellard manage to (apparently) never write a "full-on" GUI-fronted application
The "full-on GUI-fronted application" is two different problems.
PROBLEM_A = create a minimal interface (arguments to application) and focus on making robust logic that is fit for use and purpose.
PROBLEM_B = make users who resist/object to a minimal interface happy by satisfying an unbounded set of requirements involving a changing stack of tools and OS dependencies.
The latter effort can expand to consume the time and energy of entire teams of people.
Actually, this is missing my point quite a bit. The difference is not the minimal/non-minimal interface.
One can easily imagine (and I think they even exist) GUI front ends for ffmpeg that let a user set up a conversion "more easily" than they might find it using the command line. Bellard has chosen not to do this (lots of entirely fine reasons), but even if you use such a GUI front end the use of ffmpeg still consists of "set the parameters and let the program run". At some point after clicking "Run" (or whatever the button says), then just like after press "Return", the ffmpeg process will have completed its work, and that particular user interaction is over.
By contrast, a video and/or audio editor is really an entirely different beast, in which the user is continually adjusting any and all parameters and states of the project, expecting undo/redo histories, and so on and so forth. There is essentially no "completion state" for the application to reach.
I'm just curious that Bellard seems never to have tackled this kind of application (as is absolutely his right to do, or not do). I'm curious because it creates an entirely different class of programming problems from the "set-and-run" type of application (though they also obviously overlap in many important areas).
> a video and/or audio editor is really an entirely different beast, in which the user is continually adjusting any and all parameters and states of the project, expecting undo/redo histories, and so on and so forth.
If you accept that there is some similarity to game development or a real piloting system for an aircraft, these complex adjustments would be split among components to be developed and tested separately and then integrated.
Could you just call these “interactive programs”?
Sure, it's just a bit of an "old" term that I wasn't sure the young'uns on HN would understand :)
Isn’t a JavaScript engine interactive ?
No regular user interacts directly with a JavaScript engine, not in the sense that they interact with a text editor, a video editor, an audio editor, a CAD application, a medical imaging application etc. etc. etc.
Apparently GUI frontend is not a subject or problem that interests him. He lives and thinks close to the metal, at a lower layer of abstraction. The software he writes for himself and others in that ecological milieu, people who would take his codebase as an embedded library, command-line tool, or wrap it with an abstraction and user interface for their particular purpose, like browsers did with FFmpeg.
He has his favorite niche intellectual and technical subjects, where all his big and small projects are explorations of that space from various angles. It's a lesser concern whether the result has business value, or wider public appeal. He's more of a researcher and scientist.
> Apparently GUI frontend is not a subject or problem that interests him. He lives and thinks close to the metal, at a lower layer of abstraction.
It's not that cut and dried. The application I work on has some notable chunks of assembly code, lots of tricky multithreaded realtime lock free code involving threads, atomics, RCU and more ... and ... a GUI that lets the user continuously interact with it.
Oh, and we use ffmpeg for video decoding/encoding :)
https://bellard.org/qemacs/
Bellard wrote an emacs-type text editor, with full html rendering support, Unicode, X11 GUI, ... in the early 2000s!
That way leaving employment for lesser ones among us