It’s not lack of education that I was suggesting here, but too much! Maybe I’m too steeped in Ivan Illich and assumed this would be taken another way.
Let’s take ArchiCAD or other BIM software as an example. People use ArchiCAD because it’s the current trend in architectural design. Education at institutions inculcates in them, schools them to believe that to be an architect is to use BIM. Not using BIM is a failing. This gets compounded when you try to look for a job and are hired by a firm which explicitly needs you to know ArchiCAD in order to work. Of course, this is a network effect, not only is the tool needed for coordination internally, but it becomes a tool that’s used to coordinate with others. The construction company is expecting technical drawings in a format that’s only able to be built from BIM. In sum, trends/education/skills for emplyoment/network effects restrict the freedom of the aspiring architect who simply wants to contribute positively to the urban environment.
This is unfortunately not solved by making an open-source, interoperable CAD software.
I think until we finally end capitalism or otherwise figure out a sustainable way to fund open source software, closed source professional tools will continue to run circles around the OSS versions.
Blender is a rare exception, and notably started out as a commercial company.
I also think a flexible product with exceptional documentation may be more malleable than an undocumented and more narrowly scoped product, even if you’re technically able to edit the code of the latter.
Its hard to make things work as you want without having a good enough understanding of how things work.
When I program, I personally prefer to be controlled by the tools I use. They were build for a reason, for a specific workflow. I want my program to typecheck. I dont want to have the freedom to write untyped programs. I don’t want git to also have the ability to crop images. At this specific moment, I want to perform a specific task and I want the tools to help me do it, nothing more complex , or annoying , that could allow me to shoot myself to the foot.
Control is bliss. Control is bliss as long as it is self control, society’s self control.
Malleability is about changing the tools that control you, no not having control or tools.
(eventually I will read ink & switch’s document and report my opinion)
A community is a group of agents that interact asynchronously. Thus it has the same complexity as any distributed system. One could simply only allow specific communication patterns, but true malleability requires us to decrease the cost of programming distributed systems.
Ahh thanks, this helped me articulate some dissatisfaction with this thread and zoom out to the neighborhood of “malleable”. I ended up giving it its own link.
It appears we both have similar way of digesting information. I’ve also just started scribbling down a few notes on which things interested me most about malleable systems, and maybe which way I could help or contribute.
Re: Code literacy, I was talking with Rek yesterday, and we got wondering about this: if you had 80k hours to advance the field, are you be better off making a hundred spreadsheet programs for people to use, or teach a hundred people how to implement their own-
The ideal course of action probably won’t fit neatly into one of the two categories. Instead you’ll find out after 40k hours the best way to spend the remaining 40k. And the first 20k how to spend the second. And so on, fractally. Ready, fire, steer is the only way that works for me. Though who knows if it’s all going anywhere. These days I’m happy when I find one person to talk to in detail, to understand what it’s like to be them, try to figure out what would most help them.
Interesting discussion! I sense a recurrent topic here: the granularity of malleability. As @tobyshooters pointed out, even with today’s dominant apps with silo tendency, there’s always room for malleability on top of it, at the level that in my professional domain (scientific computing) would be called a workflow. But often we need malleability at finer granularity, at the level of functionality that one app implements.
The ink & switch essay that started this thread is mostly about just one level below the surface. Which is why @neauoire’s very valid criticism of using a platform with ever increasing walled-garden tendencies is not so relevant for the examples given in the essay. Nevertheless, it is a communication problem, the essay has a bit of “do as I say but not as I do”.
In @neauoire’s notes, we see a diagram with four levels of granularity. I love those labels, and I hope we can use them productively here in future discussions. The part on concatenative languages makes a good point. At the outermost level, all imperative computation is concatenative. For example, shell scripts and Lisp programs can be concatenated. GUI events as well. Concatenative language generalize this to all levels of granularity, which indeed looks like an advantage for deep malleability, though I doubt that it would be sufficient.
Unfortunately, this seems to be in conflict with another important idea in @neauoire’s notes: designing for differences. It’s about bottom-up construction, gluing together pieces that weren’t designed uniformly. For me, bottom-up construction matters more than uniform notation across the software stack. And it doesn’t preclude malleability at all levels, even if it’s a bit more messy. That’s a price I am very happy to pay, but I understand the opposite point of view as well.
I think, like you said, that the malleability across systems is undervalued a bit too, it’s definitely more important than just having a full concatenative stack, or a full object oriented stack, which is yeah, not enough. This scenario where a notation wins over all the others would demonstrate corporate capture, more than malleability.
The Maude mixfix example is the best I could find for a project that tries to bridge the gap between notations themselves, which is kind of uncommon, Modal(which is also documented on this forum) shares some of this interlingua capabilities, but I was having trouble finding better examples than just either localized notation, or array languages - Which don’t meet the operator half-way.
There’s this excellent essay classic about OOP from a few years back
In which someone who’s been in this monoculture space has an enlightenment that goes:
But in the end, we don’t advocate changing the way we work on and with objects and object-oriented languages. Instead, we argue for diversity, for work on new paradigms, for letting a thousand flowers bloom. Self-healing, self-repair, massive and complex systems, self-organization, adaptation, flexibility, piecemeal growth, statistical behavior, evolution, emergence, and maybe dozens of other ideas and approaches we haven’t thought of—including new physical manifestations of non-physical action—should be allowed and encouraged to move ahead.
The notes are all kinds of work in progress, I just put down stems I wanted to explore, but it’s quite rough. I started off as a kind of reply to the original Ink & Switch essay, but I think it might be more interesting to just see what else there is, instead of riffing on top of something that does an excellent job at surveying the land.
Indeed. On the other hand, Maude is a bad example for interoperability, because it has exactly none. Otherwise I would probably be using it. But the only way to get data into Maude is by reading a text file in Maude syntax.
Which is why I am interested in it. I like its very basic but general mechanism for interfacing to the non-modal. That’s something I’d like to play with.
Indeed. It’s just disappointing that Richard Gabriel’s vision for a post-OO world has not been taken up seriously by anyone, as far as I can see.
A. Even if mac os is not malleable, installing a “virtual machine” (or a framework) on top of which we have full malleability, that is indistinguishable from having linux as the os. As long as we define the boundaries correctly.
My opinion is that we do not have the resources to build a fully malleable operating system at the moment. But everyone has its own interests and inclinations, so any effort on this is well appreciated.
B. Malleability induces or is induced by a specific workflow, or as one might say, a specific user experience. I heard somewhere on Dynamicland that we start from the medium and the interaction and then go backwards to the technology/implementation. I think that Ink & Switch also follows this paradigm.
C. I think it is useful to do B and build something that is eventually not useful. I don’t know if I agree with the choices they make. But research is about being 99% wrong. it helps narrow the path for the next iteration, as long as we have introspection and learn for the previous step.
Take the good parts and point to the bad parts.
D. The problem has many aspects, it is difficult, thus it is useful to take inspiration from many sources that tackle different aspects. Don’t judge others for not solving all the problems. At the same time do not dismiss parts of the problem that needs solving.
(again sorry I am very busy at the moment and I can’t follow the discussion very closely)
Totally agreed. The arcan project, which I like a lot, calls the idea an Overlay OS - in that its a new OS that runs atop an existing one, getting a lot of the work for free, and meeting people where they are.
I also love genode, but even with a fairly mature system for porting Linux device drivers it doesn’t run perfectly on any of my three devices.
Also totally agreed on research! All of this site is utopian, I think its lovely just to see cool ideas and where they may lead without necessarily making something that solves everything for everyone
I really like this framing. One may posit that natively a computer offers the possibility of complete malleability and as we build software, we shut this down as we try to strike a balance between expediency/economics, control/resilience and flexibility (you can argue what these variables are but they are always conflicting constraints).
But in my experience, once you take malleability away, trying to bring it back never seems to work out (I am thinking of things like Macros and VB Scripting in MSOffice). Maybe the question to ask is, to what extent we should preserve malleability at every level of software abstraction?
This to me is probably the most frustrating part about the current state of affairs. Software is meant to move at the speed of thought, ideally as malleable as writing or the act of thinking itself. I believe it will get there eventually, maybe a decade or two, where we can think software into existence and shape it by talking with it. But what we have now is a very awkward medium, slow as molasses - not only does it resist our attempts at molding it into a shape resembling what’s in our minds, the software molds us instead. I feel torn about the conventional sense of “code literacy” and, for example, block-based programming for education - it’s about learning to think with computers as an extension of the mind, just as we learn to think with words, numbers, and logic - but it’s also training people to adapt their thinking to fit a narrow view of what computational media can be, the result of a poverty of imagination and the religion of economic incentives. If code is literacy, we’re being taught to write and think in Latin (or C). Even pig Latin is better than that, at least it’s a circuit-bending of language to reclaim its power. But I respect Latin and C, the latter more so, and maybe everyone should learn a bit of it.
I like the memorable term, meta-jig. It’s a tool-making tool, that’s what software is. A malleable medium and tool for thought that you can shape into any tool you imagine. It’s a modern philosopher’s stone.
(I had no idea what a jig is when I wrote the above. It’s not a maker of anything, it’s a “tool used to control the location and/or motion of parts or other tools.” Moreover, “A jig’s primary purpose is to provide repeatability, accuracy, and interchangeability in the manufacturing of products.”)
the malleability is in the user, not the tool.
Malleability is in the relationship between the person (participant and artist) and the tool (medium). It’s a quality of the holistic system they form through interaction as they shape each other.
It’s about the power structure between the system maker and the system user, whether the user has the ability to become the maker, or at least participate in the design and making of the system. Otherwise, the user is being used by the system, as a mere tool and cog in the machine.
Recipe for yogurt: Add yogurt to milk.
Bootstrapping is about building a compiler using tools smaller than itself, as opposed to building a compiler using an already built version of itself. The problem with the second is: Where did that prebuilt binary come from?
After the eatening, software is digesting the world now, into a planet-scale distributed cognitive computing system made of billions of smaller computers, satellites, data centers, power plants, controllers, sensors, cameras, speakers, drones, robots, implants, cultivated neurons.. And there’s an ethical and democratic responsibility as individuals and companies to not let ourselves be robbed of personal and social agency, the right to participate in the design and control over the system we’re living in. We’re almost too late.
I see tangents of: advocacy, agora as public forum, the third place, free libraries, demonstrations, public experiments, temporary autonomous zones.
An important concept of situationist theory was the primary means of counteracting the spectacle; the construction of situations, moments of life deliberately constructed for the purpose of reawakening and pursuing authentic desires, experiencing the feeling of life and adventure, and the liberation of everyday life.
I enjoyed this Interview with Ton Roosendaal, the man behind Blender (2018), where he talks about why going open source was the right decision for the project. I think his choice was either let it die as a commercial product (selfish paradigm), or open it up as a community resource (selfless or serving the collective self). The software took the latter path and flourished.
Yesterday I watched The little editor that could, about Ken Thompson’s first version of ed that he used to write Unix with. It’s been called “the most user-hostile editor ever made,” and the narrator explains why this is not true: the editor was perfectly suited for the needs of the author as the main user and the computing environment in which it ran, particularly the teletype interface.
I think the text editor is the extension of our minds into the world of the computer. They’re a kind of cognitive projection into that world.
It’s not a metaphor, it literally extends the mind. Text as a medium of thinking and communication will always have a place, even as other media and interfaces emerge to complement (and probably overtake) it.
I don’t think we’ve even seen the tip of the iceberg. I think the potential of what the Internet is going to do to society, both good and bad, is unimaginable. I think we’re actually on the cusp of something exhilarating and terrifying.
I’m talking about the actual context and the state of content is going to be so different to anything that we can really envisage at the moment where the interplay between the user and the provider will be so in simpatico that it is going to crush our ideas of what mediums are all about.
That describes the situation well, I feel. It’s a state of collective creative discontent, where people are not satisfied and searching for different ways to untangle ourselves, to loosen and liberate by parts, layers, subsystems. I think that kind of communal frustration is at the root of the GNU project and free software movement.
The contrarian take in “Against Malleable Software” has a point, in a torque’d way, that we already have the most malleable system in front of us, built over generations as a gift and communal resource. I disagree that therefore people don’t need or want malleability, because we’re all here in this forum driven by the dissatisfying state of affairs, wanting to participate in making things more malleable somehow, at least for ourselves.
At this point, I think we want to let a thousand flowers bloom, and encourage any effort and experiment in the right direction. Or even wrong directions. As they say, throw things at a wall and see what sticks. Rigorously of course. (;
Elsewhere a term was brought up, lithification. If I understand correctly it’s meant as a direction on the opposite side of the spectrum of malleability, where a curated set of opinionated design decisions are “frozen” into the system, so everyone can stop talking about it and just benefit from that abstraction layer with embedded intelligence and experience.
Interesting you mentioned type checking and static type system as an example of this kind of “tool controlling you in a good way”. Rust’s borrow checker and Go’s standard formatter are examples I think about often, how these tools enforce strict rules in a way that’s freeing, positive and affirming of the community, where we can let ourselves be guided by the wise design and learn from the tool/language/medium by using it.
Granularity again. If you want a practical malleable system at some level of the software stack, it almost certainly build on lithified subsystems at lower layers. From that perspective, the holy grail of malleability is to find good lithified components that provide maximum affordances with minimal constraints.
We do have such components in the universe of atoms. It’s what you buy in a hardware store, for example.
With regards to control, I am saying that we cannot and should not have complete freedom. We need something that controls our behavior, limits our freedom, as long as we can change the rules, the controller. We dont want to be controlled, or be out of control, we want to be in control.
Every interface is a controller, it limits the actions of the user.
Imagine editing an image.
All the actions you should do to the image should preserve the format of the image. You shouldn’t be able to change arbitrary bits of the image file. So the fact that you can only do specific actions is very useful.
At the same time, there are multiple actions that preserve the image format. You should be able to change your tool to help in your own personal workflow.
You shouldn’t let an external entity, like a big corporation to determine your workfow, your types of interactions you can perform.
This last observation leads to the fundamental difficulty of cyberinfrastructure design: path dependence – what you do now affects what you can build in the future. We have all suffered the deleterious consequences of path dependence as we have struggled over the years with Windows operating systems, or with QWERTY keyboards (the only technical artifact in the world to favor left-handers). Path dependence recognizes that past decisions limit future options. These limits are all the more obdurate when built into large, complex infrastructures. Is there a way to include flexibility in infrastructure design in order to facilitate change, potentially making infrastructure more responsive to evolving conditions?
This is a challenging problem, but it can be tackled in several different ways. For example, one can emphasize modular design of technical components. Another possibility is to focus on standards as a means of creating flexibility. Standards are knots in the web of infrastructure technologies and concurrent socio-institutional provisions. They are key focal points for actors’ negotiation of their differences, interests, and opinions.
Standards are often associated with freezing development, in the light of enhancing system flexibility. It requires a different mindset. This mindset or conceptual framework is being developed and applied across infrastructures (i.e. transportation, information, batch processing industry, energy) to explore the conditions of and restrictions to our flexibility claim. Key concepts in the framework are: the gateway (dedicated and generic), compatibility between the political, operational and technical domains; flexibility objectives and flexibility characteristics of standards. Important work on these objectives is now being carried out by the Next Generation Infrastructures project based at Delft, the Netherlands (www.nginfra.nl/).
To design for flexibility, at each stage, with each dynamic, and in every type of intervention or evolution, possibilities for seeking alternative pathways must always be kept open. However, it is crucial not to underestimate the economic context within which such flexibility is permissible, and the resources it demands in both human and financial capital. Research communities should think of “resource pooling” or “collaboration” by first auditing what is being shared, comparing and contrasting across projects, in different countries, different parts of the world, in different experiences.
