"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?
@natecull linux cli
@pnathan Sadly the CLI concept didn't extend even as far as the X Windowing System.
There may be a reason for that.
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.
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?
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.
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.
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'
For sufficiently simple stuff, I write utilities that I'd otherwise use a spreadsheet for. E.g., summing a sequence, or generating univariate moments.
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
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.*
Ray Panko, Univ. Hawaii, has studied Excel errors since the 1990s:
Excel offers a *grid of code* model. That's hard to see, visualise, debug, QC, validate, etc.
It's *possible* to write Very Robust Excel. It's not *easy* to do so.
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.
Generalistic and moderated instance.