Live data from Hacker News

Malleable software: Restoring user agency in a world of locked-down apps

inkandswitch.com

41–50 of 117 posts

Re: Malleable software: Restoring user agency in a world of locked-down apps

#41
> we created Patchwork—a web-based collaboration environment for malleable software... storing both user data and software code in Automerge documents. On top of that, it adds version control utilities like history views and simple branching. These tools apply to any document in the system—whether a piece of writing, or code for a software tool... Eventually we also plan to release Patchwork as an open-source tool

What milestones would you like to hit before open-sourcing it? As an outsider, it looks like it has a LOT of features, and I wonder if there's feature creep. Still, version control for everything is a tall order, so perhaps it needs plenty of time to bake.

Re: Malleable software: Restoring user agency in a world of locked-down apps

#42
post #37

Creating browser extensions is easy enough. It's hacky web dev which I very much enjoy. The problem relies in distribution.

Yes, nowadays all the main browsers are pretty much locked down and you have to use the official app stores to sign and distribute your extensions, even if it's just something for your own use. I really wish this would be more open, since extensions allow for so many cool usecases because they don't have all the same restrictions that regular webpages have (CORS for example).

Re: Malleable software: Restoring user agency in a world of locked-down apps

#43
post #3

I love the optimism, but I'm a pessimist. Even at the first paragraph: > "The original promise of personal computing was a new kind of clay—a malleable material that users could reshape at will. Instead, we got appliances: built far away, sealed, unchangeable. When your tools don’t work the way you need them to, you submit feedback and hope for the best. You’re forced to adapt your workflow to fit your software, when…

Coauthor here. You make a fair point! Ease of use matters. We all want premade experiences some of the time. The problem is that even in those (perhaps rare!) cases where we want to tweak something, even a tiny thing, we’re out of luck. An analogy: we all want to order a pizza sometime. But at the same time, a world with only food courts and no kitchens wouldn’t be ideal. That’s how software feels today—-the “kitchen…

Look at HyperCard (more or less dead, regrettably) or Excel and you'll see many useful "applications" created by non-programmers over the years.

People want to create, but need tools to make this easier / more abstract than regular programming. Most companies want to get them into their walled gardens instead, especially web-based companies today.

Re: Malleable software: Restoring user agency in a world of locked-down apps

#44
post #43
post #3

Earlier quoted context omitted.

Coauthor here. You make a fair point! Ease of use matters. We all want premade experiences some of the time. The problem is that even in those (perhaps rare!) cases where we want to tweak something, even a tiny thing, we’re out of luck. An analogy: we all want to order a pizza sometime. But at the same time, a world with only food courts and no kitchens wouldn’t be ideal. That’s how software feels today—-the “kitchen…

Look at HyperCard (more or less dead, regrettably) or Excel and you'll see many useful "applications" created by non-programmers over the years. People want to create, but need tools to make this easier / more abstract than regular programming. Most companies want to get them into their walled gardens instead, especially web-based companies today.

you should take a look at TFA; both of those are mentioned in great detail! it's a good read

Re: Malleable software: Restoring user agency in a world of locked-down apps

#46

I remember having this idea in undergrad in 2011. My big wish was that every app would ship with a scripting language or an api. The problem is that it’s not at all straight forward to do this. The more complex an app, the more important a facade (like a front end) becomes.

Apple did this back in the mid 1990's (before OSX) with AppleScript. Every application was supposed to ship with metadata that described its object model along with methods that could be invoked on them. AppleScript was an sort of a protocol or interface standard that allowed scripts to automate application actions (and more) without having to use GUI macros. Scripts could be written with a variety of syntaxes. It was pretty cool. However, it turned out that providing an object model and API surface was a pretty heavy lift for application developers and most just half-assed it. And while a fairly robust community developed around AppleScript, it was too small to generate any noticeable uplift in sales for either Apple or independent software vendors. Thus not really commercially viable.

And Microsoft has had OLE -- which is sort of analogous to the object-model portion of AppleScript -- for ages.

Re: Malleable software: Restoring user agency in a world of locked-down apps

#48

I was thinking a lot about software malleability - but from a technical perspective. I am on the verge of building something useful - only if I could find the time to do it. Here's my premise - if you use something like a game engine, say Unity, and Unreal, you basically have the ability to modify everything in real time, and heve it reflected inside the editor immediately - you could change textures, models, audio,…

I mean, Tcl/Tk has had this since the 90s. Rewrite your procs (functions) on the fly, delete GUI items on the fly, generate new events, create listeners on the fly, etc, etc.

Quite easy to create a GUI that's interactive AND a console you can script on at the same time to inspect / edit / change code.

For example, don't like your window attributes? Write code to destroy it, and re-create it and keep your "live" data unchanged, and it will redisplay in the new style / layout.

And sure, you could code up atomic transactions quite easily.

Itcl even lets you create / add /remove classes or specific class instances on the fly, or redefine class methods.

Re: Malleable software: Restoring user agency in a world of locked-down apps

#49

I appreciate the idea behind the post, because certainly, we need more hackable apps now that everything is becoming a SaaS that effectively cannot be archived or hacked on (unlike, say, WinAmp or major releases of Windows and their respective fan updates, or for a more common example game mods). Unfortunately I think that while there’s a decent number of power users and people who have the aptitude to become power u…

Well with cars I think many would appreciate if they too were more malleable. My Dad has often told me of a car he once had that was really easy to repair (edit: it was a VW Beetle) as he was not known as someone who was terribly handy. Doubtful anyone would have that experience with today's cars.

Re: Malleable software: Restoring user agency in a world of locked-down apps

#50
post #39

I was thinking a lot about software malleability - but from a technical perspective. I am on the verge of building something useful - only if I could find the time to do it. Here's my premise - if you use something like a game engine, say Unity, and Unreal, you basically have the ability to modify everything in real time, and heve it reflected inside the editor immediately - you could change textures, models, audio,…

But not code code but that's not true: smalltalk, lisp, pike, erlang and some other languages allow you to change code at runtime, only requiring the recompilation of the changed unit of code (depending on the language. in pike it's at the class/object level) process-like isolation barriers isolating small pieces of programs, and an object database-like datastore that can never be corrupted due to transactional chang…

Tbh, I have never heard of Pike or societyserver before, will check those out!

As for smalltalk, I am also not intimately familiar with the language, but what I have in mind is somewhat lower level, with emphasis on C-like struct layouts stored in a POD way (so raw structs inside arrays and the like).

I'd say a key difference is in my language (working name Dream (because I started the project as my 'dream' language, and picking names is hard)), is that these isolation contexts are explicit, and you pointers can't really cross them.

There are special 'far' pointers that do have the ability to reference external objects in different context, but there's an explicit unwrap operation that needs to happen that can fail, as that object is not guaranteed to be reachable for whatever reason. Processes can be explicitly deleted, meaning all reference operations to them will fail.

To be clear, when i say process, i mean my lightweight internal isolation thing.

So in summary, my langage is procedural inside processes, with in-process garbage-collection, C-like performance and explicit method calls. Between processes, you either have smalltalk-like signals, or you can do Rust-style borrows, where you can access objects inside the process for the duration of a method call.

It has erlang-like 'just let it crash' philosophy, but again is a C-like procedural language (or shall I say Go-like, since it has total memory safety and GC).

It also has familiar C-like syntax, and quite a small(ish) feature set outside of the core stuff.

I have a huge doc written up on it, no idea if it would work and if it did, it would be useful, but I do have some tentative confidence in it.

(Also no claims on being original or inventive.)

Post reply on HN