💾 Archived View for bbs.geminispace.org › u › mediocregopher › 11718 captured on 2023-12-28 at 17:30:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-14)
-=-=-=-=-=-=-
Re: "When it comes to arbitrary, "realtime" composability, the..."
the Unix model of files, streams, and processes has yet to be topped
Excel begs to differ :) when the entirety of the world's financial system is supported by a piece of software it's hard to overlook that
Nov 14 · 6 weeks ago
@mediocregopher but stocks run mainly on linux, not excel
🚀 clseibold · Nov 14 at 13:23:
Unix didn't create streams or files or processes. All of those predate Unix.
🐉 gyaradong · Nov 14 at 20:35:
The differentiation I'm trying to make is between command line and GUI in the context of permacomputing. GUI software needs to constantly be tweaked and updated and take on the features of other software. Efficiency matters and it is tackled through complexity. GUIs don't have a model for composability, but a system based on text? You could probably create 5 different composable text oriented systems without any issue. So, is text more fundamental than GUI? Is symbolic manipulation the only way to build on top of logic gates?
🐵 cquenelle · Nov 15 at 04:37:
You can also think of this in terms of programming languages. There have been attempts at a visual programming language, but I don't think any of them really took off. Although I remember being impressed with the Self programming environment a while back. I think there's something fundamental about language wired into our brains by evolution.
🐉 gyaradong · Nov 15 at 07:38:
assuming this is true, a keyboard really is the fundamental input device for computers. all the other form factors aren't really going to be scalable.
🐉 gyaradong · Nov 15 at 10:53:
could one get to a notebook with free form writing and drawing but "self hosted" software from the firmware through bios and to OS and apps?
in traditional oberon system there are no processes that run in parallel or pseudo-parallel. the task switching occurs when one function finishes its work and the other function takes over.
they consider that the commandline concept is outdated, since it was about printing on the paper and the text printed on the paper would become immutable. that concept came from the time when we didn't have yet crt monitors.
still, traditional oberon system is text based. it is modular, and the module named Texts is one of the base modules of the system.
everything is text in oberon system.
the manuals are text files with extension .Tool.
they contain ready to use commands: module.procedure
let's say the compiler command is there in two ways:
Compiler.Compile ^
Compiler.Compile *
you can write Compiler.Compile somefile.Mod everywhere, in any place you can find in the Oberon tiling ui.
however if you have the manual (the abovementioned .Tool file) opened in one of the viewers (windows are called viewers there) and then you select the file name to compile in any other viewer, then click with the mouse middle click on
Compiler.Compile ^
then instead of ^ the Compiler.Compile function will pickup the file which name you selected.
or maybe you wrote some test code in an editor in one of the viewers but didn't save it to the file system.
you just navigate the mouse over that window and press F1 button. then the viewer will be marked with the asteriks sign.
after that click on
Compiler.Compile *
and the code in the marked viewer will be compiled.
some of these concepts are borrowed in ACME text editor of plan9 by rob pike. however it feels much more consistent in the oberon system text oriented system.
i think our 'monolite' gui programs are what the capitalism and marketing produced to sell us software.
even in unix (and unix is still a government funded research project, it is not a startup) we have window managers, then we have terminals, we have text editors, compilers, debuggers etc.
each of the programs in this chain can be replaced. twm can be replaced with dwm or fvwm or windowmaker.
emacs can be replaced with vim or nano or whatever.
xterm can be replaced with rxvt or mrxvt or st or whatever.
everything is replacable.
on the contrary in the capitalistic software we have IDE's that replicate the functionality of everything below.
IDE's have own window managers - but we already
but we already have window managers.
plus we could use other window manager instead of this one, but we cannot when we are in IDE. IDE has its own window manager and you should deal with that.
IDE has its own editor.
oh, you don't like it? MS VSCode will support vim mode, but it is still MS VSCode. MS VScode will make everything possible for you to use it and not understand the taste of underlying interchangable interoperable system.
i think it was possible to find another path.
swiss found, as i presented in previous comments.
and i can imagine a modular ui program. you have a chat program pidgin? what it consists of? a window to show contacts. you don't like it? why cannot you replace it with other window that can show contacts?
you have window divided in to two field? on the topper one you see what was written to you and in the bottom you write your text?
why cannot you replace it with other window like that?
and those both can communicate with each other and with the service that implements the protocol.
oh you have a video call viewer? why cannot you replace it with other one?
or why pidgin doesn't communicate with the program like mplayer with pipes to pipe the video stream to mplayer so that you could watch the person you are talking with?
why pidgin has to implement it again?
well - we have shared libraries - you would say.
and then i'll come back to the oberon ideas. they don't have shared libraries. the module is compiled to the object file.
each object file can have multiple entry points, there is no main(). as in case with Compiler.Compile there can be Draw.Curve and Draw.Line.
there are no linked 'programs' that contain one entry point.
everything is a library or a program - why should be there a difference?
When it comes to arbitrary, "realtime" composability, the Unix model of files, streams, and processes has yet to be topped. GUIs are vey rarely composable, and also hard to script. It makes me think maybe composability has to be one dimensional, and textual. This idea that a keyboard is fundamental to a computer but a different pointing device doesn't feels slightly off. I wonder if there is an elegant multi dimensional method of composability which simplifies down to simple compute models and...