"Design" as practiced today by computer people tends to be heavily based on the idea of negative space: that good design is what's NOT in a system, and by extension, what is NOT ALLOWED TO BE ADDED to the system by a user.

A "design-heavy" system, then, is inevitably highly restrictive about user actions, lest they "ruin the cool design" by adding their own desired features that "make it messy".

@dredmorbius@natecull@pnathanre: X, many (most?) of the linux desktop users i know use it to multiplex a bunch of terminals, and people tend to script things within the environment, so i'm not sure it's accurate that the cli didn't carry over.

right, but that's not using X *as X* or to interact *with* CLI. It's using X just as a set of terminals for CLI that's completely unaware of X.

X, the system (as I understand it), does not use CLI. It sends and receives messages of its own devising and format but doesn't expose these to the user or use the CLI or pipe system to do it (except for some command options for programs which are mostly now ignored)

@natecull@dredmorbius@pnathan i mean, X is a windowing environment, so i dunno how using it to contain a bunch of windows isn't using it as that.

and yeah, X is a giant weird beast and i've never actually written code against it in any meaningful way, but i use stuff like xclip, wmctrl, dmenu, rofi, etc., to control facets of it pretty routinely, so it's at least situated in a cli & scripting-driven environment that i use to control my own space.

@dredmorbius@pnathan@brennen all of that though is probably possible with Tcl/tk and maybe with some of the oldschool CLI tools you mention? (which really, really don't get much press at all even among hardcore Linux fans)

like to properly represent the state of X as CLI I think you'd need at least an object model? cos things on the screen ARE objects, they have persistence and state

Maybe all I want is a modern Tcl/tk that works with all the shiny GUI toolkits and OOP systems?

@natecull@pnathan@brennen NB: I'm massively hampered in all this discussion principally by /never having really grokked GUI application design in the first place/. My sense of "application" has always been "something that works on a stream of inputs or polls regularly for state", but not "and presents this with a bow and cherry on top".

I could use pointers on some good books on GUI UI/UX. Don Norman seems to be one source. Brett Victor another.

It seems quite hard to think of how to encapsulate the IO flow and state of a GUI component.

ie the input stream could be a stream of events (mouse/keyboard or underlying widgets, data model) and a similar output stream... but it all seems a bit confused and intertwined compared to a simple script that reads a stream of records and writes a stream of updated records.

Could *maybe* separate the IO flow into 'channels' like 'standard output' and 'standard error'

but it still seems not right. It's a whole nonlinear *data* flow. And that nonlinearity is what makes it hard to modularise. Too many wires snaking out in all directions, all needing precisely matching sockets.

There is also the distinction between "nodal" utilities and "complexity hubs". The latter do stdin/stdout poorly, if at all (though some do in fact do it). Most complexity hubs have *multiple* inputs and outputs.

What if the whole GUI was like an Excel spreadsheet, and widgets were cells? They have a value, the value can be changed, it doesn't care how the value changes but if it does, that change propagates to all observers.

@dredmorbius@natecull@pnathan@brennen I don't think it means the idea is unsound though; on the contrary. There's a lot of ideas to take the spreadsheet and make it a far more useful tool than awk's programming equivalent of a face for radio

I'll also note that I'm talking of my own personal use: I'm not saying that *everyone* who has an Excel-like task should use Excel. I'm saying that when I've got a simple "accumulate a store of values, compute something, kick out report", I prefer awk.

@natecull@pnathan@calvin@dredmorbius a spreadsheet is a shittier-than-average database with what is a better-than-average representation layer for a whole bunch of people to be able to grasp it.

the achilles heel is how bound the physical structure of the data is to the representation & interface, but maybe that's what makes it approachable. there has to be some way for a serious db to be as approachable as excel is, but i don't know what it'd be.

I think perhaps copying ideas from SQL for structure and drilldown would be interesting (another funcprog environment with good ideas, but clumsy tooling; SQL feels like funcprog if it were implemented by programmers who only used COBOL, and half the functions are missing - i'm convinced SQL is also why people swear of RDBMSes to the point of using Mongo et al)

those caveats do matter, though. my hunch is that mostly people get lured into garbageware like mongo because sql rdbms systems make manipulating schema a difficult, largely out-of-band sort of task relative to most of their interface.

@brennen@natecull@dredmorbius@pnathan see, I always think talking about "schemaless" is a red herring when it comes to NoSQL - it's really about SQL as a query language & about making the DB just plain ol' serialization of Plain Ol' Objects - this is easy for a programmer, and it's a *schema*, typed language or not

SQL is only lovable if you're a 70s DBA. I'd want a modern RDBMS protocol of sorts, that makes queries and serialization easy - with strict schemas, since the other end has those

@brennen@pnathan@dredmorbius@calvin yeah, a database where defining a schema is an out-of-band operation seems a little like a functional programming language where you can't pass functions to functions.

One of the defining characteristics of data is that it exhibits recursive structure: things inside other things.

RDMBSes in the SQL model, however, are built assuming that there are certain Things (databases, tables) which May Not Ever Be Put Inside Other Things.

And, for that matter, contrast "X Power Tools" to "Unix Power Tools" The latter was indispensable, and even today remains highly useful despite being first published in 1993 (there have been 3 editions, through 2007). The former was ... dispensable, and seems only to have seen 1 edition.

@dredmorbius@pnathan@brennen One reason for this is probably that GUI actions tend not to be joinable or linkable; there's no fundamental GUI 'grammar' for anything like the concept of 'two symbols separated by a space' in CLI.

other than 'drag icon1 onto icon2' for a kind of primitive 'apply icon2 as argument to icon1 as function', but it executes immediately, it doesn't give you a third object which is the result of combining the two.

Ironically: if you /start/ with CLI and toss a GUI wrapper around the elements, you can address some of this. I'd argue that a problem (and, more to come, quite probably advantage) is that one GUI tool cannot /easily/ "become a keyboard or mouse" to provide inputs.

@brennen@pnathan@natecull That is, tools that /can/ automate GUI bits are generally used for testing and/or QA. I've used a few briefly a long time ago -- can't even remember names. OK, Selenium was one I recall.

The other problem is sorting out /what element you want to talk to / hear from/. You've got a bunch of crap on screen, there's no sense of pipelining or stdin/stdout/stderr.

@dredmorbius@pnathan@natecull yeah, it's funny - we could sure ask for more flexibility and composability in GUIs, but it seems like in a lot of ways the heavily OO-inflected desktops of the late 90s / early 2000s were the high water mark for any mainstream idea that we'd get that.

(There's also the month+ old problem of a nuked Chrome Browser extension's user state that's been on my to-do list for that month+, though I have to dig into the fucking headspace of Chrome and the extension to see how that happens. The developer of the extension himself *does not know and isn't interested in finding out.* Fucking sigh.)

@pnathan@natecull@dredmorbius you can run hypercard stacks in-browser from archive.org's collection. i can't really tell how it'd feel to a new user at this late date, but i think it's worth the attempt.