The Malleable Systems Collective is a new group that's launched just December 2019 and looks really exciting.

<< Modern computing is far too rigid. Applications can only function in preset ways determined by some far away team. Software is trapped in hermetically sealed silos and is rewritten many times over rather than recomposed.

This community catalogs and experiments with malleable software and systems that reset the balance of power>>

h/t @jfred

omg YES

<< 1. Software must be as easy to change as it is to use it

2. All layers, from the user interface through functionality to the data within, must support arbitrary recombination and reuse in new environments

3. Tools should strive to be easy to begin working with but still have lots of open-ended potential

4. People of all experience levels must be able to retain ownership and control >>

Show thread

<< 5. Recombined workflows and experiences must be freely sharable with others

6. Modifying a system should happen in the context of use, rather than through some separate development toolchain and skill set

7. Computing should be a thoughtfully crafted, fun, and empowering experience >>

Show thread

<<Today's software landscape wants you to believe anything is possible, but apps today act like black holes that ingest your data and actively prevent you from mixing them together in ways that work for you.

We're on a mission to change all of that! >>

did... did someone clone me

I'm scared

Show thread

don't forget that "malleable" literally means "should be hit with a hammer"

we have a lot of malleable technology in this world

also "ductile" means "can take it with you crawling through an air duct" and "tensile" means "makes you really tense if you hit it with a hammer while crawling through an air duct"

Show thread

@polychrome maybe! I don't even know what Squeak does anymore. I should probably boot it up sometime and take a look.

@natecull I remember being impressed by how I could select and drag widgets away from applications and they'd still work in that interacting with separate from their 'window' would still send the relevant message to the core program. The whole thing felt like a toy box for me to play with.

@natecull I'm glad there are more people into this kind of thing! It's been a longstanding frustration of mine ever since I've started using Emacs and since I've seen the Alto and Lisp Machine demos.

I'd assumed that GUIs couldn't be as expressive and as malleable as the CLI, but no, that's not the case! Today's GUIs can't, but there's so much potential that we're all missing out on, and researchers were doing better *decades* ago!

@jfred Yes!

It's taken me years to try to second-guess what happened, but I think the GUI emerged at a time right when the big question for computing was "how do we make computers simple for users". The GUI and the idea of "direct manipulation" made things simple (AI speech recognition was another attempt, but GUIs turned out to be cheaper), but another big concern was "how do we prevent untrained users from messing everything up?" And so the idea of "form-filling" took over at this point...


.. and replaced some of the more interesting, truly malleable, approaches to GUIs.

Everything in the GUI became rigid and restricted via forms and menus *because that's what corporations wanted*. Including Steve Jobs in the 1980s. They wanted the computer to be like a telephone or TV; an information appliance, where the user couldn't break it and companies did the heavy lifting, and could sell their work as a product/service.

The Licklider track of "intelligence amplifier" faded away.

@natecull The thing I've been wondering lately is... if we wanted to build a malleable GUI for e.g. smartphones, what would it look like? Because they're undoubtedly useful for some things, but they're traditionally/currently also very restrictive.

The Alto and Lisp Machines are good inspiration for desktops/laptops, and Dynamicland is good inspiration for something on a larger scale, but when it comes to small personal devices without a keyboard I don't have too many ideas.

@jfred I don't know for sure, but some guesses:

* We need to drop the idea of one screen per 'app', and make a screen/window represent a set or view of *data*.

* to the extent that an 'app' exists, it needs to just be a handler for a specific data type.

* so there really should be only one 'app' on a device, and that's a generic 'information browser'. Not 'web' browser, *information*.

* Information should be recursively structured like a dictionary or list.

* Maybe a grid view, with zoom?


The whole 'system' viewable on your device needs to be a big soup of dictionary-like data, mostly pure-functional, no side-effects. Physical buttons for 'in', 'out' and 'home', probably. You need to always be able to break out from a node, and also keep a running list of favourite places.

How side effects (eg sending commands to change things in the physical world), privacy and parallel tasks work, I'm not sure. I think side effects need some serious physical confirmation to action.


(I don't know if that actually works; since on the Internet you can trigger an action just by viewing data. But any destructive change to your own data or own devices you control, I think should require confirmation like a big ACTION button, and privacy should require data to stay on devices that you own as much as possible.)


One of my personal pet hates/terrors of phone/touch OSes is that the physical finger action for 'nondestructively scroll screen' (drag) is exactly the same as 'arbitrarily click and possibly perform a destructive, permanent action to a physical device anywhere in the world' (tap). Just depending on the length of the press and how the system detects it.

This terrifies me. It's insanely bad.

There must ALWAYs be 'safe' areas on the screen for nondestructive scrolling.

@natecull Scroll-vs-click ambiguity.

(Also focus vs click.)

Yes, one of my absolute haet haet haet issues.


@natecull @jfred not to mention that in some apps a downward drag can suddenly turn into a refresh, or worse, a close current dialog, action just because you've reached the top of the document…

@natecull @jfred Wow, what an interesting discussion. I'm working an ontology-oriented graphical/tabular DSL for data integration/validation. I'm trying to do it with Clojure, which I'm just now learning and starting to like a lot.

Apps like Notion and AirTable are some examples I've considered, and I think they match a lot of the ideas presented here--except, of course, customization because SaaS is kinda garbagey :blobugh:

@pizza_pal @jfred

Interesting! What does "ontology-oriented" mean in the context of a graphical/tabular language?

@pizza_pal @jfred

(I think that 'grid of strings' has a lot to recommend itself as a display/entry format for JSON-like dictionary structured data. Unfortunately I keep struggling to work out how to losslessly map other structured data types, eg Lisp lists, cleanly onto dictionaries. I think I can do it with an escape character, but it's a little messy.)

@natecull @jfred So the idea is that it'll be declarative, functional, version-able, and should fit into a pipeline.

There's a rules language called SQWRL which is basically Datalog with a little bit of SPARQL. So the way it goes, after the rules have been declared, a document containing the ruleset is generated. Then you input some data, the semantic reasoner/rules engine gets run on the data to enrich it. Then it gets validated, and outputs more documents.

@natecull @jfred So it's going to use OWL (Ontology Web Language) for a high level schema. You can use a program called Protege ( to browse and edit the ontology.

The graphical/tabular part of it will allow a user to declare rules based on relations of entities and properties found in the ontology. The idea is to combine a subject matter knowlege-base with business and validation rules.

@natecull Hmm, yeah. Of course there are some cases in which the presentation really matters - incoming messages should probably still do something akin to current mobile notifications.

Maybe that's just a matter of sensible defaults/handlers for different types of data in a stream, "incoming SMS" being one of them.


A few things I would like to see for any system, mobile or desktop, which has 'notification messages':

* ALWAYS ALWAYS ALWAYS KEEP A RECORD OF THE MESSAGE, don't just flash it up and then have it vanish forever. Have there be a message inbox.

* Don't obscure the screen where the user might be doing something important. Have a separate reserved notification area.

* NEVER UNDER ANY CIRCUMSTANCES raise a window and steal keystrokes or clicks. NEVER NEVER NEVER NEVER NEVER. That's bad.


So basically: standard Windows/Mac/Linux application launch behaviour, where you click on an application, it grinds for a minute, pops up a non-dismissable splash screen obscuring your work, grinds for another minute, then steals key focus and starts executing the keystrokes you were typing into another window? That standard behaviour?

That's garbage behaviour. Never do that.

Hmm. A desktop environment with a fixed screen area for notifications could be interesting...
@natecull @jfred
Note that I'm not using "interesting" as a euphemism - this has genuinely piqued my interest!

@mansr @natecull

Can someone explain what's special about emacs? Is it a programmer thing? Wikipedia says it's just a text editor, so I don't get where the magic's at.

@machado @mansr

It's a text editor that's completely programmable in Lisp. So it's more like a Lisp Machine that happens to come with a text editor as a built-in app.

But I've never managed to make friends with it at all. Its standard keystrokes are just so deeply incompatible with the last 30 years of standard UI conventions, since IBM's Common User Access in 1987.

@natecull @mansr

So it's a programmer thing. I'll stick to writing in notepad and doing the final edit in word.

@natecull @mansr

Btw, this right here is why I'm right about the fails of FOSS. The vast majority of text editor users will tell you to go fuck yourself if you try to make them learn Lisp.

@machado @mansr

:) And the extra fun part of Emacs?

Emacs Lisp is so old it predates both Scheme and Common Lisp. It doesn't have lexical closures (or not as standard, or didn't originally).

By modern Lisp standards, it's a Very Bad Lisp. I think there's a recent movement to rewrite it with a Proper Lisp (like Guile, a Scheme variant).

Mind you, it *might* be that interactive things like editors *need* weird non-standard behaviour. That sort of thing makes my head hurt.

But yeah. Nano ftw.

@machado @mansr

(When I say it makes my head hurt, I mean, I worry that there's maybe a good case that a user-reprogrammable system like Emacs just can't be built out of lexical closures as a fundamental abstraction. Maybe we need dynamic variables as a core language element. If true, that would go against several decades of Good Programming Advice and Language Design Best Practices. All of the Functional community, for example, their heads would explode. But maybe Emacs is just silly? Idk.)

@machado @mansr

An example of the problem, which is fairly subtle and deep:

<< In contrast to Scheme, which uses “lexical scoping”, Emacs Lisp scopes its variables dynamically. Guile supports dynamic scoping with its “fluids” facility. See Fluids and Dynamic States, for more information. >>

I'm not sure I want Emacs anywhere near my vital fluids actually

@natecull @machado At least Emacs Lisp has predictable scoping, which is more than Javascript can say.

I guess it's popular because you can have plugins, but it's honestly easier to just use nano and be done with it...
@natecull @mansr

@DHeadshot @natecull @machado When you have a few decades worth of accumulated customisations, _your_ Emacs is the easiest to use by far. Other people's Emacses are just weird.

@natecull Six is the big one for me. It's why I want to see a graphical 'transcript' that's similar to a command line in some ways in that there's a surfaced language you're encouraged to interact with, but does everything in terms of context-aided discoverability, real-time visual manipulation, and other Smalltalky elements.
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!