In the 80s, my aunt (a child) and my grandmother (someone who, today, can't even effectively operate her Television) wrote a series of computer programs from which they ran my grandfather's business.
They generated invoices and printed them, scheduled jobs, kept a list of customers, etc.
They did it all with an Atari 8-bit computer, and the included BASIC.
@ajroach42@ACTupper I think the problem with Scratch is that itโs self-contained. You canโt link external information and actions to it, which makes it effectively useless for a lot of the tasks non-programmers want to achieve.
I actually really like tools like IFTTT and Zapier. I was super impressed with zapier in particular when I tried it, itโs basically iOS shortcuts for the internet, with a surprising amount of power. A free tool like that would be awesome.
"The solution isn't to push users back to the command line. The solution must be to bring composability to the graphical environment."
Definitely agree on this.
I've been waiting for a "composable graphical environment" ever since the 1980s and wondering what the holdup has been! Still am!
(because I was a kid who read Byte magazine, which talked about 1) GUIs and 2) Lisp/Smalltalk, so it seemed obvious to kid me that GUIs would be programming languages... and then they weren't)
The whole "Reactive" paradigm in web apps seems very much inspired by flow-based / functional-reactive programming, but I'm sure there's a much tinier programming model trying to claw its way out of the current big reactive mess.
A node would be a function; the tricky part I think is how you nail down timing/signalling and what Elm calls "FoldT" (fold over time).
I haven't yet seen a clear, tiny explanation of how to do this.
I've always thought it would be pretty cool to have a GUI based on flow-programming (like the Blender node system). Where programs would be programmable nodes with defined inputs and outputs.
It's very similar to the notion of Unix streams and pipes, but actually more flexible, since you can have more channels.
There's a Qt library for doing this kind of design, called "Floppy", I don't know if it would apply as a GUI shell.
@ajroach42 I hear back in Windows 3.1 you could define an entire text box with like one line or something like that. You just had to tell it what the buttons you wanted were and what they should do and the OS would do everything else for you
You had an entire domain specific language which was solely dedicated to user interface control layout, called "resources". This is probably what you're thinking of.
If you did the same thing in C, it would've taken a lot more code.
On the other hand, the resource editor/l layout language was very constrained in what you could accomplish. It always assumed a rigidly sized window or dialog box, and so you couldn't describe responsive layouts at all. So, making something that could respond to the user resizing the window still involved a decent amount of C code to back it up.
@comrad@ajroach42 That's a bit circular. Why aren't people using the command-line? Maybe because the tools they need don't offer it? Note that users in the boot-to-Basic era did use the equivalent of the command line and have since been trained not to.
The idea is to provide something with the power equivalent of the command line, something that isn't a siloed environment, but that also isn't a command line.
@ajroach42 one thing I thought might be a step in this direction was the plug and socket system in Xorg, which was implemented in Gtk3, whereby one process could be embedded into another window. I always felt like this had a lot more potential applications than were ever explored. Alas, it has no counterpart in Wayland.
I do like the sound of command line style composability in a graphical environment. It sounds like a paradigm shift.
@rafial@ajroach42 I have a HomeWorx (a set-top box for broadcast TV) that takes longer to boot that a vacuum tube TV would to warm up. It's as if the digital revolution has more than cancelled out the gains from the solid state revolution.
@rafial@ajroach42 Boot to anything would be the ultimate antidote to constant updates, therefore it would be seen by the business side as contempt of business model, and therefore it won't happen.
@n8chz@ajroach42 lulz, the fact that my super-modern TV can crash and frequently pesters me to install software updates when all I really want is a monitor that will display what the Roku box or Chromecast streams to it is definitely not ideal.
@ajroach42 If it existed here I'd use up my lifetime ration of 1 quote toot on this thread and the reply from @jlbesq.
The manuals for my ZX81, VIC-20 and a BBC Micro set me up for the rest of my hobby and occasional work-related life. Entering *and especially debugging* programs from badly printed magazine listings taught me another skill too. Patience. I've forgotten most of the last as I got older though. :)
@ajroach42 Itโs there. But in order to be minimally useful, youโll need tcllib+tklib (huge goodie pack, big math library among others), tcl-tls, tcl-snack (audio playback) and TkIMG (used by tklib). It isnโt a big install by no means, just a few MB, and you can do a lot with that even underpowered Pentium II-III era machines.
@hhardy01@ajroach42 There's intrinsic complexity and then there's accidental (or sinister, depending on your cynicism) difficulty in structuring and automating tasks.
@ajroach42 It is absolutely absurd, and is also a massive accessibility issue. I am learning disabled and effectively canโt understand coding, but I would also benefit massively from being able to create my own utilities because of the unique way my brain engages with information- I can visually imagine applications I could create that would help me, individually, but I am completely cut off from the means of making much software without making investments I donโt have money for.