but do you really need to install gigabytes of visual studio to use it [on windows]? there's no way it's like this for other programming languages; i mean a full gcc installation doesn't even make a single gigabyte
i just don't want all this stuff i never wanted just to use this one language
it can poll motion tracking data from my peripherals - dozens of sensors on each tracker, headset, and controller - thousands of times each second,
it can use all of that information to transmit an idealized version of myself to 10, 20, sometimes 30 or more other people all over the world, in less than a tenth of a second,
it can render their avatars and project them directly to my retinas at 120 hertz, giving me the illusion of motion, of reality,
it can do all of that with off the shelf consumer-grade hardware.
and yet, on the same machine, microsoft teams takes 10 seconds to draw its ui in slow motion whenever i try opening an office document in its shitty web browser ass approximation of an application what the FUCK microsoft
thinking about terminal emulators and shells designed with the understanding that touchscreens exist
give me an MFD with tappable aliases at the very least.
give me a list of envvars I can paste the contents of by tapping their buttons. there's so much here that can be done with existing tools even
(this is a bit stream-of-consciousness writing here, and a lot of it is copied from things I noted earlier.)
honestly, I've done some brainstorming on what a shell should become, and I think I have some answers.
Ideally, you can operate this entire shell from a mouse or touchscreen, or a menu interface, without having to bring up a keyboard or open a manfile into another window, because all of the manipulable objects, shell commands, and all their possible arguments, are available from the library and browser panels, and their documentation is viewable inline.
First, some definition of what a "shell" is, opposed to a "console" or a "terminal".
A console is an interface by which one works with the computer. For equivalents on Windows: The local desktop is a console; Microsoft Management Console is a console in the Windows Desktop; Hyper-V Manager is a console within Microsoft Management Console.A terminal is an interface by which serial data, usually text, is received and generated. A VT-100 is a terminal, an IBM 3270 is a terminal, as is a terminal emulator, the Windows Terminal, KDE Konsole and Xterm.
A shell is an interface by which the programming of the machine (machine language monitor, BASIC ROM, C compiler, API) is abstracted from the user, by way of manipulating objects or commands.
The key here is that all three of them are part of a user interface. A shell can run on/to a terminal to present a console to work at.
In our case, the shell is what weāre working on defining here, though elements of the terminal (especially UI) play a part here.
This is a new shell, and it should act like it.
Anything short of outright revolutionary, in terms of shells, will land us with yet another āincompatible Bash-like with Featuresā, like zsh, fish, dash, and others before it.
While terminal/vt100/tty serial buffer compatibility is a nice-to-have, it shouldnāt be the defining feature of the shell, it shouldnāt be the mandatory interface. We have a GUI, we should use it. Therefore, this will be a GUI application, unless it is launched from within a vt100-like/ANSI terminal session.
Make it a visual, and block-oriented agglutinative language.
Iām not talking about a node-based scripting environment (like Quartz Composer, Blenderās node graph UI, or Unrealās Blueprint system) - Iām focusing more on a ālegoā, agglutinative series of code and function blocks, which can themselves contain code and function blocks.
Iāve always had this idea of doing a shell as āScratch, for adults.ā
The gist of it is, you can freely enter commands line-by-line typed out, and theyāll be parsed into blocks transparently as you go along; or, you can attach together blocks to specify the operation that youāre performing, with transparent on-the-fly documentation and a menu or ālibraryā of available commands to pull from.
This format would save to plain text, and be parsed into command blocks; or be saved as a compact token/AST form, and āreconstitutedā on the fly.
Either way, itās intended to be accessible to newcomers or less-experienced computer users, while not getting in the way of people who intend to program scripts for the shell like the way theyāre used to. A skilled command wizard could hide away the panels and simplify the ācoding blockā UX to being little more than on-the-fly syntax highlighting; the code is entered by keyboard, as usual.
Reach into the desktop, and allow rich scripting through both API and UI.
This shell should also be able to comprehend and automate UI interactions, namespacing and identifying specific UI elements in terms of code, in a way thatās less liable to breakage. Iām thinking along the terms of AppleScript and Automator, on that end.
One UI puzzle that could be solved for automation tasks, is a drag-and-drop āconnectorā line, which you pull from the shell window to a specific UI element, and then that element is referenced into the code transparently.
It should also be able to do object introspection on the desktop model and API, where present, to provide a cohesive scripting language to wrap around both command invocation and function calls to the API.