Ink & Switch malleable software essay

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.

s/ArchiCAD/React/g/
s/ArchiCAD/Salesforce/g
s/ArchiCAD/Instagram/g

1 Like

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.

2 Likes

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)

1 Like

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.

4 Likes

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-

3 Likes

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.

3 Likes

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.

4 Likes

I’ll share the graph here for redundancy.

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.

4 Likes

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.