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

But users WANT control over their own space.

Is there a "design" that empowers users?

@pnathan Sadly the CLI concept didn't extend even as far as the X Windowing System.

There may be a reason for that.

@natecull @pnathan What of stuff like Applescript?

(NB: I'm aware it exists. I've not used it myself and don't know its capabilities. A point which might factor into any possible response.)

@dredmorbius @natecull I would say the ergonomics of applescript are such that it's not full of use.

I didn't dink much with it because it didn't relate to the GUI paradigm that I worked in too well and I could already write bash etc by the time I encountered it.

@pnathan @natecull @dredmorbius hypercard was one of my early inroads to building software, so i used hypertalk some - similar vibes, i think?

hypercard was an amazing thing and i still miss aspects of it, but language-wise hypertalk suffered a lot from mistaken ideas about english-like ergonomics, i think.

@dredmorbius @natecull @pnathan
re: 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.

@brennen @pnathan @dredmorbius

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)

Tcl/tk, though, I think does use Unix pipes?

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

@brennen @pnathan @dredmorbius

Well, because X is about *graphical components* of which 'windows' are just one tiny, tiny subset

Like you might want your program to accept input from and send data to buttons? Grids? Charts? Images? Textboxes?


None of that is even really possible with the 'a simulated VT-100 running just inside a window' use case of X.

So CLI is not interfacing with X 'as X', just X 'as a VT-100'.

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

@dredmorbius @natecull @pnathan modulo a handful of toy projects and tiny utilities, every "GUI" i've ever built has lived inside a web browser, so i s'pose i'm in much the same boat.

@brennen @natecull @pnathan I ... have markedly better CSS chops than I care to discuss in polite, or impolite, society. No JS though. Yet.

@pnathan @natecull @brennen Virtually all of that picked up out of necessity trying to salvage my sanity and/or vision from the present state of HTML maldesign.

@dredmorbius @pnathan @brennen

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'

@natecull @pnathan @brennen Interesting case in point: I've always found awk scripts far more intuitive than Excel spreadsheets. Even for simple stuff.

For sufficiently simple stuff, I write utilities that I'd otherwise use a spreadsheet for. E.g., summing a sequence, or generating univariate moments.

@dredmorbius @natecull @pnathan @brennen see, people are REALLY underestimating excel here

excel is a funcprog environment that

1., normal people use, and normal people use to great effect to get things done

2. actually offers a non-linear way to do programming; instead of a linear program, you operate on cells of a 2D space containing either data or formulae, and operating on ranges is easy

adding VBA was a terrible mistake that added complexity and inelegance

@calvin @natecull @pnathan @brennen I'm not contesting that Excel /isn't/ a functional programming environment.

I'm contesting that it's a /good/ FPE.

It is *VASTLY* too error-prone and difficult to debug. Not to mention awkward. OTOH, *it is often the only tool available since "real" programming tools are denied to front-office workers.*

(Including awk.)

Ray Panko, Univ. Hawaii, has studied Excel errors since the 1990s:

@dredmorbius @calvin @pnathan @brennen

I suspect this is because spreadsheets don't offer *grouping* constructs, which are pretty important for humans to organise information.

A 2D grid gets you a long way, but not really far enough.

If you had a sort of web of nodes which you could expand or shrink, and had a natural mapping TO a 2D grid if you wanted it...

@natecull @dredmorbius @pnathan @brennen well, there are "sheets" but it's a bit clumsy

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)

@calvin @natecull @dredmorbius @pnathan put me in the camp of "syntax irregularity and the friction of defining new structures aside, sql is basically pretty good".

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

· · Web · 0 · 0 · 0

@natecull @brennen @pnathan @dredmorbius well, hierarchial DBMSes exist (a lot of NoSQL can be considered as such) but then you lose the advantages of RDBMSes. the problem is that mappings in SQL between tables are clumsy. what if RDBMSes had typed pointers between objects that made it easier to related between objects between tables?

@natecull @brennen @pnathan @calvin Having learnt RDBMS and various mainframe hierarchical data formats more-or-less simultaneously, I've been aware that There Is More Than One Way to Fuck Things Up.

Relational 2D data is convenient. It does /not/ fit all sets of circumstances. Normalising hierarchical data may or may not be possible. And often you're dealing with a cross of "what is present state" and "what is most recently-added transaction" (or "what is the full transaction history"?)

@calvin @pnathan @brennen @natecull There's also the realisation that many mainframe hierarchical formats appear to have been lifted straight off the underlying *paper* forms in use at the time.

At which point you realise that it was easier for the programmers *then* to simply duplicate the paper record in electronic form than to rationalise it.

@calvin @dredmorbius @pnathan @brennen and a sea of objects, or even dumb objectlike key-value data like JSON, doesn't have this restriction!

so it's naturally a lot simpler to work with 'an object full of objects full of objects'


'a database, which I gotta get my RDMBS administrator to spec a server and provision for me and define a schema which if I ever then change I gotta file a helpdesk request to do it and butwhooops the user just put a new data type in and crap...'

@natecull @calvin @pnathan @brennen Is JSON really a persistent data /store/?

Or is it a way of shuttling data between systems?

@dredmorbius @natecull @calvin @pnathan anything is a persistent data store if exists in the vicinity of enough half-educated programmers.

ANYWAY, this thread is a lot of fun but now i'm going to go fuck around with a pile of music gear i don't understand, which is probably also a good place to think dark thoughts about the state of interfaces and modularity.

@brennen @dredmorbius @natecull @pnathan for parting thoughts on spreadsheets, simmer on stuff like Quantrix, "3D" structured spreadsheets

@dredmorbius @calvin @pnathan @brennen

yes and yes.

I keep thinking that JSON is the new '80-column IBM card'.

It's terrible, but it's at least a defined 'plug shape and pinout'

so data stores are gonna assume it as the 'shape' of the data they store, just like 80-column screens and text files stayed the standard well into the disk and VDU era

@natecull @dredmorbius @pnathan @brennen I mean, JSON column types exist in everything from MySQL to DB2/400 (which is by far the weirdest SQL server I can think of)

@natecull @calvin @dredmorbius @pnathan meh. i'm not really pining for more hierarchy in my datastores, though it has its place (hierarchical filesystems are certainly useful). my gripe is more that there's a bunch of friction to making new tables.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!