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.

Follow

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

@ajroach42

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

github.com/JLuebben/Floppy

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

@natecull

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.

@ajroach42

@natecull

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?

@ajroach42

@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: avs.com/avs-express/ 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

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

@ajroach42
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
latenightsw.com
which I should look at;  Script Editor sucks ass, Automator is a tinkertoy, old SD (10+ years ago) was not a lot better.
#applescript

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

A social network for the 19A0s.