It is absurd that there are not simpler ways for non-programmers to make computers do what they want.

I used to go off about hypercard a lot.

It was a tool, scarcely more complicated than Powerpoint, that enabled anyone who chose to to make programs that do things.

Today, I know a lot of business people who do the kinds of things I would write software for using Excel or Access and macros.

But it's mostly boring business stuff.

My mom used to weave batch files and sidekick databases in to something resembling a computer program.

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.

Part of the problem is one of approachability.

BASIC still works, you know? I wrote programs in FreeBASIC as a kid.

Python is out there, and is fairly easy to get started with, and there are plenty of good guides and tutorials.

But they are not *approachable* you know?

And then there's the whole issue of GUIs.

I have never written a graphical application using a UI framework.

I've started some, but working with UI frameworks sucks. I can't imagine starting with one for my first application.

I've done web UIs for years, and they aren't *easy* but they're way easier than working with modern UI frameworks.

Which, I guess, is why Electron is so popular.

Smartphones and tablets are here to stay. GUIs are a part of life.

The solution isn't to push users back to the command line. The solution must be to bring composability to the graphical environment.

@ajroach42 What are your thoughts on Scratch? While I've never tinkered with it, it seems like it's built with accessibility in mind.

@ACTupper it's a great introduction to programming.

It is not a good tool for empowering non-programmers.

@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.

@rolltime @ACTupper Zapier is neat. Macros for the internet.

I wish more desktop applications supported a basic macro workflow.

@rolltime @ajroach42 @ACTupper Some interesting ruminations on this in Dave Ingalls's chapter in the book Coders at Work (Peter Seibel). He talks about how the image model is great for some things, but tough for sharing code and distribution. My OS is no where near the state of usability yet but since the topic is here anyways.

how would you ideally describe a UI?

@ACTupper @ajroach42 Scratch is pretty good but isn't very useful for non-game/art things. It's severely limited, you can't save data locally or even calculate exponents other than powers of 10 without a workaround (IIRC you have to do (10 ^ ((2) * (log (3))) if you want calculate 2^3 for example)
You can import and export text files, but that functionality is somewhat hidden. (You have to right click on a list reporter to show the menu with those options.)

Also, while it's fairly accessible to non-programmers, it's not accessible at all really to people who need assistive technologies like screen readers. No information is exposed about what's showing on the stage, and IIRC some menus are impossible to escape from with screen reader controls. I don't remember if it's even possible to make scripts without being able to see or use a mouse, but I doubt it is.

@ajroach42 some people like the conversation UI that the voice assistants are hinting at.

I've wondered what people would do with a word based interface that was more forgiving of humans saying things inconsistently.

@ajroach42 (Though separately GUIs are also a fine way to accomplish a variety of tasks. Maybe not every task but certainly a lot of them.)

@ajroach42 what about a gooey gui that’s like skeuomorph’d to look like gelatin


"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)

@natecull @ajroach42

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.

@TerryHancock @ajroach42

I think this would be cool too!

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 don't think I fully understand, but the node system in Blender acts a lot like a spreadsheet. Once you make a connection to an output node or makd changes to the network, it starts backtracking to recalculate the result.



Of course, Unix streams have EOL and EOF events, which presumably provide frames for iterative processing?

I suppose a continuous node network with stream inputs might do the same?


@natecull @ajroach42

Also, in addition to having more channels, you can have more *types* of channels. In the Blender node system, the data can be scalars, vectors, images, etc. The connection points are color-coded by datatype (though there are conversions -- an image input can accept a scalar output by just reading the same value for every pixel).

@TerryHancock @natecull @ajroach42 There's an ancient commercial visualisation tool called AVS that had a flow based system; see: you can just about see at the bottom of that page an example graph; I used it decades ago and it was quite neat, the pips on the nodes correspond to types of parameters.

@TerryHancock @natecull @ajroach42 Windows Workflow Foundation was fairly close to this, but I think it is dead now.

@pulkomandy @TerryHancock @ajroach42

StreamWeaver looks like exactly the sort of thing I was imagining that, eg, OS/2 or Windows NT would provide circa 1990, yes.

I figured "well *obviously* a GUI OS wouldn't ship without a GUI Shell of some kind, smart people must be working on this"

and imagine my shock when the smart people weren't.

BeOS doing it shows that it's possible; the idea just didn't ever seem to get interest or buy-in or any kind of traction, even after Linux.

Beats me why.

@natecull @TerryHancock @ajroach42 here's my biased and inaccurate view of what happened to all these cool OS projects from the 90s:
-Linux (and UNIX in general): the UI ecosystem is way too fragmented for anything likeethis to happen. The closest you get is the X11 clipboards and few people really know how this works (did you know you have at least two separate clipboards, one for ctrl+C and one for select+middleclick?)

Even drag-n-drop is unreliable

@natecull @TerryHancock @ajroach42
Windows: has been following the path of Linux first by introducing a new UI toolkit in each release since Windows 3.11 (and not removing the previous one), and lately by actually running Linux on top of it.
Everyone forgot about COM and OLE, and ActiveX was designed in an unsecure way so now it's disabled by default.
Your best bet is probably doing everything in Excel.

@natecull @TerryHancock @ajroach42
NeXT: had a good start on this but for the last 20 years they have been busy figuring out how to merge the Mac OS user interface with theirs, and porting the OS to phones, TVs, and wristwatches. I guess they will work on toasters next, or maybe cars?
MacOS: they had AppleScript and Hypercard. Both got lost in the merge with NeXT it seems?

@natecull @TerryHancock @ajroach42
PalmOS Cobalt (which was to include features from BeOS: died when Palm split its hardware and software divisions into separate companies, and the first thing the hardware company did was announce they wouldn't buy anything from the software side. So no one else did buy from there either.

@natecull @TerryHancock @ajroach42
Android: thiss is where the BeOS engineer ended up (at least the ones who didn't go back at Apple). A few nice ideas initially (activities, binder, …) but all the funding they get is from Google so their current focus is on collecting user data and showing targetted ads, not on mabing useful apps.
Fuchsia: we'll see, probably headed a similar way

@natecull @TerryHancock @ajroach42
AmigaOS: still busy supporting 68k CPUs and deciding if memory protection is a good or a bad thing
MorphOS: insists on running only on PowerPC machines, despite no new hardware being available.
Both have a few interesting things in this area (AREXX scripting) but it's still command line based
AROS: not sure what they're up to lately but the focus is on redoing what the two above already do, but opensource

@natecull @TerryHancock @ajroach42
BeOS: Haiku is working on rewriting it from scratch for the last 20 years. Everyone who tries to write an apps for Haiku eventually hits a serious bug in the OS and ends up fixing that and contributing to the OS itself. A small team tries to provide some maintenance and updates to hundreds of old BeOS apps for which they recovered the sources. No time left for cool innovations. Beta phase will last a few years more

@pulkomandy @TerryHancock @ajroach42

Aw man Cobalt! I was a Palm fan in 1998 and it hurts me so bad that they destroyed their company and nextgen OS to the point that Apple just strolled in and ate their entire lunch with a fricken dumb MP3 player. (That then became a phone and then finally a Palmpilot replacement, but, Palm had like a decade's headstart!)

@pulkomandy @TerryHancock @ajroach42

Palm's self-inflicted breakup was so disastrous I almost wonder if it wasn't the inspiration for the corporate shenanigans in Inception.

Someone hacked into the brain of whoever was running Palm and convinced them that tearing their company in two and putting a barbed wired fence and machine gun nests in between the two halves would be the greatest business plan ever.

@natecull @pulkomandy @TerryHancock @ajroach42 Robert X. Cringely predicted in his early ‘90s book that Windows NT would be the last big development in operating systems, because each new generation of OSes cost an order of magnitude more than the previous one to develop, and NT had cost so much that even mighty Microsoft could barely afford it.

He wasn’t wrong!

@ajroach42 Android and iOS already do that to some extent by providing a system-wide interface to share content. It would be a really nice addition to the Freedesktop standard

What you do on the command prompt isn't usually any of the things an end user wants to do.

@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.

Man, ive been thinking about this since last night. I have feelings but no real ideas...

When I had a running mac it was just a little too old for AppleScript..

I've never done anything with a proper Smalltalk or lisp gui, or BeOS.

I feel like the Oberon OS sort of leans towards this, but its not exactly the same thing (those ideas ended up in Plan 9's acme)

i dunno man.

@goosey @ajroach42 I've written as much AppleScript as anyone outside Sal & other automation-only people. Great language for gluing apps together, worst environment possible, no real UI for "applications" (for a while you could make AS-Cocoa Mac apps in Xcode! But it's an obsolete bridge now.)

There is a new version of Script Debugger
which I should look at;  Script Editor sucks ass, Automator is a tinkertoy, old SD (10+ years ago) was not a lot better.

@ajroach42 heard a lot of people using godotengine to design apps with UIs

@ajroach42 I think the 'solution' there is to realise that GUIs aren't that useful. So not using one is better for many things.

@ajroach42 And that encouraging people into the terminal more is also a incremental approach to programming: command -> script -> program is a natural evolution of a work flow.

And I think this is part of the answer: command line and scripting is the good simple entry point.

The effort to make it a better entry point is to make command line apps less scary and more uniform (could we have better default shells please, a blank canvas isn't optimal)

@LovesTha Fundamentally disagree.

Even if its just for presentation, allowing the end user some control over the way their data is displayed is a net good.

@ajroach42 yes, and there are many ways to do that from a command line.

@LovesTha from a terminal, yes, from a command line, no.

Curses is not a command line interface, it's a user interface for the terminal.

@ajroach42 The actual display doesn't have to happen in a terminal at all.

@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

@Canageek @ajroach42 yes and no.

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.

@vertigo @ajroach42 Makes sense! I knew it was pretty limited, but didn't know it was that bad

@Canageek @ajroach42 Sounds like Windows GUI had an API similar to Tk's

@lispi314 @ajroach42 Even a limited GUI would help I think. I think it would be a lot less intimidating to people if they could click a desktop icon, them paste the file names into a box that pops up, then have to deal with the command line

Sign in to participate in the conversation
R E T R O  S O C I A L

A social network for the 19A0s.