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.
Malleable software: Restoring user agency in a world of locked-down apps
41–50 of 117 posts
Re: Malleable software: Restoring user agency in a world of locked-down apps
#42Creating browser extensions is easy enough. It's hacky web dev which I very much enjoy. The problem relies in distribution.
Re: Malleable software: Restoring user agency in a world of locked-down apps
#43I 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…
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
#44Earlier 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.
Re: Malleable software: Restoring user agency in a world of locked-down apps
#45Most people just don’t have the skills or inclination to tinker even with ham radios or cars.
On the other hand with the right to repair, you could call a repairman. And now — an agent or robot!!
Re: Malleable software: Restoring user agency in a world of locked-down apps
#46I 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.
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
#47I get it too, world moved on, people have to manage APIs, updates... but yeah.
Re: Malleable software: Restoring user agency in a world of locked-down apps
#48I 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,…
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
#49I 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…
Re: Malleable software: Restoring user agency in a world of locked-down apps
#50I 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…
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.)