The thing that strikes me (I have seen others suggest this) is that many could do with a higher-level UI model. Some apps need raw I/O, but most don't. And would benefit from letting a wider diversity of people write renderers which actually work for them.
My personal interest is in treating HTML as a high-level UI model, which suits lots of services. Certainly not all!
But my main example would be UI frameworks like Qt or GTK (or Cocoa or whatever Windows has). These are built on a sizable software stack striving to provide enough options that anyone can work with it.
To me Situated Software would suggest that this shouldn't need to be a single stack, but I do believe in the importance of those options!
@alcinnz I'm not sure how to interpret your post here. It seems like you oppose the idea of situated software (although the reasons why aren't articulated).
It's not what I'm doing in my drive to make a point, but I do understand the appeal. And I can relate.
My complaint with the approaches I've seen with it is the low-level I/O. Sometimes that's needed, but other times I highly suspect (for under-served groups) it gets in the way of it's goal of hackability. When it comes to improving internationalization/accessibility.
I accept Situated Software would approach those differently, but looking at prior art...
@vertigo My attitude accepts this Situated Software approach for apps. If it's just for you & your friends I have no trouble with people ignoring issues not relevant to them.
But I place heavier expectations on platforms. I want to see them be prepared to address accessibility & internationalization issues. Otherwise you're reinforcing privilege.
@alcinnz As Chuck Moore says, everyone is providing general solutions, but nobody has defined what the general problem is yet. What does "high level" mean here?
So far, I think most would agree that "high level" refers to abstractions that are close to the application's ideal level of abstraction in software, but consider that might be what is high level in a mathematical sense. There's high level in the domain sense as well. As if that weren't enough to be confusing, we need to consider which application we're talking about too. A graphics drawing app? Music composition? DNA sequencing? Logistics planning?
Uxn (more precisely, Varvara, which is what most people mean when they mention Uxn) is situational software in its truest form: both in time (hardly the fastest thing out there but, at least for now, plenty fast enough) and in space (it's application domain includes games and game-like programs). Attempting to apply Varvara to other kinds of applications will be met with varying levels of success, including the distinct possibility of utter failure.
But that's ok. If you read Uxn's and Varvara's documentation, this is both expected and considered a feature. If you want to use Uxn's instruction set for writing business applications, perhaps you don't want Varvara; perhaps instead you want a new family of VMs, with I/O mechanisms better suited to that application domain. Or, perhaps you want a whole different virtual machine technology altogether. Java works especially well for business applications; it's what it was built for the most. Etc.
I don't think the existence of situational software implies the invalidity of more monolithic styles of application development. (Most monoliths evolved from situational software if you go back far enough on time.) I think what's being advocated is that we should reconsider situational software as a means of recovering our agency as operators of our computing devices to write our own software, be it for play, pedagogy, or profit. Because, the bigger the program, the harder it is to maintain by the self.
Games do want quite low-level I/O... And Ververa does have fairly capable sound output, based on NES!
Meanwhile I deal in online communication... For which a solid protocol has already been designed (grumble about JS)!
And yes, Situational Software has it's role! Whether it targets Ververa, the web, UEFI, GTK, or whatever platform. Not everything needs to scale, software just for your friends is valuable!
@alcinnz My goal in responding to this is not to belabour the point, but rather to get you thinking about alternative meanings for what it means to "do I/O."
Meanwhile I deal in online communication... For which a solid protocol has already been designed
The protocols (plural) you work with comprise a stack, the lowest foundation of which will be simple message passing from one computer to another using the IPv4 or IPv6 protocol. We can represent such a "socket" (if you will) as a set of memory-mapped registers. Consider this structure:
What magical, mystery hardware would ever implement a direct-to-IPv4/IPv6 (or both!) network interface like this? The most likely answer is a virtual machine.
Here's how it would work: to send a packet, a program would format a buffer in memory, then write its address to tosend_ptr and its length to tosend_length. Upon writing the length field, the transmission would commence in the background, while your program is free to do other things. Or, use tosend_status to poll for completion. Etc.
Similarly, upon receiving a packet, torecv_status would have at least one bit updated to indicate a pending packet. The program would then write a buffer address into torecv_ptr and its length into torecv_length, and the packet would then be copied (again, in the background) while your program was off doing something else. Once again, you'd poll a bit in torecv_status to determine when that copy (or, perhaps, mapping) operation was completed.
I mention this because what this shows is that system calls (as we currently know them) do not imply high-level behavior. The structure above can be extended to support TCP and UDP by tacking on extra fields. UDP need only an additional port field, while TCP will need that and a small handful of other fields to track connection state. But, the point being, high level != system calls.
In fact, much of the consternation I have with the Unix-family of operating systems is that their system calls are frequently too low level. I find it overwhelmingly easier to create a working GUI in AmigaOS' Intution than I have ever had using a wide variety of "toolkits" and frameworks under a POSIX compatible OS. So much easier, in fact, that I've written full-GUI applications in AmigaOS in raw 68000 assembly language.
I will put forth the claim that the simplest, nay, the highest level I/O interface will in fact be the VM-offered memory mapped I/O interface. Because you can just "poke it and forget it." The VM's implementation, however it is written to run on whatever platform you desire, is responsible for implementing the semantics of the I/O interface. This, I feel, is why there is such a huge resurgence of interest in classic retro-computing platforms: the I/O interfaces are stable, fully realizing Java's promise of "write once, run anywhere".
Remember, the AS/400 platform is just a VM. And, these days, so too are IBM Z-architecture mainframes1 .
1 Almost, but not quite. The main CPU still directly executes S/360 and all subsequent generation opcodes. But, some opcodes might not be implemented in hardware (I suspect the SIE instruction is a good example here). However, when it comes to the mainframe's I/O infrastructure, it is almost entirely emulated by PowerPC-based embedded computers these days.
@vertigo What I wanted to highlight with that specific comment is that HTML is a nice format (caveats) which can readily parsed & rendered however suits you. Which is straightforward to write servers for (though you wouldn't know it by Web popculture).
Or there's Gemini & Gemtext! I do support those.
HTML can fill that role of a high-level UI protocol (which I was asking for) for particular uses.
Trouble is different people want different things from it, & many think it should do everything!
With everything I've learned I cringe when I see platforms leave it up to apps to reimplement text. Issue is: How should text interact with the rest of the UI? What do we mean by the rest of the UI?
As you're advocating: There's many answers to those questions.
Add comment