8 ms·

Bicycles for the mind have to be see-through [pdf]

210 points by mkeeter 7y ago

ssivark 7y ago
I know very little about “mu” specifically, but the title is a highly under-appreciated point. I often notice a tendency to abstract complexity in clean looking interfaces. While that’s convenient for simple projects with pre-envisioned use cases, when using the tool in some novel way often results in bugs due to the abstraction being leaky. For that reason, I personally prefer designs that are transparent, rather than one that attempts to paint a pretty exterior on top of internal complexity. (Obviously correct, rather than not obviously wrong) This leads to a subtle but crucial distinction between software “automating processes” without needing any humans in the loop -vs- amplifying the (expert) humans in the loop to do more stuff. Another subtle (but arguably more important) effect comes from McLuhan’s insight that the medium strongly influences the message. If the medium/tool is not transparent, then so are the biases imposed on the tool user. While that doesn’t lead to obvious bugs, it leads to strutting blinders on human thought processes and creativity. BTW, one last point, in case it isn’t obvious: this goal of transparency in software can be seen as underpinning the free software movement.
- drivers99 7y ago
  I’m looking forward to reading this paper. I feel like I’ve found my kind of people. I’ve had this half baked idea about how people should be able to see what’s going on in their computer, and trying to picture what that would look like. At the simplest level it’s the difference between seeing a trace of what the computer is doing when it boots up vs being shown a pretty screen which freezes up. Another is just the way so many software products are like “let us worry about the details”. I want to be able see everything from the bytes in memory to what’s going on in every level of the system and want a user interface that lets people do that.
  - thulecitizen 7y ago
    Check out the work of the MetaCurrency Project http://MetaCurrency.org http://MetaCurrency.org
chenglou 7y ago
No comment about the Mu itself but: > Our approach to keeping software comprehensible is to reduce information hiding and abstraction, and instead encourage curiosity about internals YES! Precisely. Most "bicycle for the mind" or "tool for thought" approaches go the completely opposite direction accidentally. Many programming languages and communities nowadays too. In reality, if you wanna teach, you have to unveil the guts of the system. Sure, it's "scary" and all, but still, initial hand-holding & letting newcomers see the internals, rather than presenting an overly polished surface at the expensive of everything else, is a much better designed learning process. Design is "how it works" after all. * Related: a common misconception when folks defend abstractions & encapsulation is to raise the issue that letting newcomers explore the internals causes too much trouble. That's an obvious strawman; these methods are not championing everyone writing anything everywhere. They can stay read-only, but public. E.g. an interface can expose its internal data types, without allowing consumers to actually leverage that (enforced through types or something else). This is easily doable, and you don't sacrifice learnability in the service of team programming sanity. * This point seems to get dismissed quickly by folks who only care about visual polish nowadays. Imo this is naive. I care about visuals a _lot_, and we should definitely aiming for both learning polish and surface polish. But you can't let the latter calcify the former. My advice for all the "tool for thought"/"bicycle for the mind" projects: all your opaque designs and small interface flourishes falter in the face of a properly exposed and clean-ed up paradigm, in the long run. This applies on a smaller scope to modern libraries too. That boilerplate generator you mega-fine-tuned to the point you delight yourself in guessing the user's mind, ultimately is a roadblock in the learner's thought process. Expose the boilerplate and document how you're automating it instead. You're trying to teach fishing, not to show off your own fish. Another good analogy I've heard elsewhere is to ask whether you're teaching people how to cook, or just building a microwave. For a tool for thought product ask yourself if you ended up accidentally making "an appliance".
- jacobwilliamroy 7y ago
  Abstraction to me, just makes it easy to delay implementation. There are sometimes when I need to use an interface now but it won't actually be implemented until next week, when the client gets us our API key, or someone else finds time to do it. Using an abstraction means that I don't have to change any of the code that uses the interface, I just have to change the interface. This is also a good way to make a prototype that is easy to optimize, for example by abstracting a very costly computation, you can just focus on making that computation run faster without having to refactor every line of code where that computation is used.
galaxyLogic 7y ago
"Our approach to keeping software comprehensible is to reduce information hiding and abstraction, and instead encourage curiosity about internals." This sounds rather vague, "encourage curiosity about internals". If I don't need to understand the internals why should I spend time trying to understand them? Isn't it better to "hide their details" into another compilation unit or module, which only exposes its API through an interface so I can easily understand WHAT it is doing, without having to understand HOW it does that? It sounds like they suggest instead of sub-routines/procedures/functions I should have a single big main program, because those sub-routines/procedures/functions would be hiding information from me.
- akkartik 7y ago
  No, I use functions: https://github.com/akkartik/mu#readme https://github.com/akkartik/mu#readme I just propose to not maintain 3 levels of functions where one will suffice, just to preserve some "interface" for "backwards compatibility". You aren't forced to understand internals. But it is an explicit design goal to make the internals comprehensible against the day you want to learn about them.
  - j88439h84 7y ago
    Are you proposing to break backward compatibility?
    - akkartik 7y ago
      Well, it's a new computer so there's no notion of compatibility. But yes, I'm proposing to rely a lot less on compatibility going forward. A big reason for building a new stack rather than building atop existing interfaces is precisely to avoid backwards compatibility. A big reason to keep the codebase comprehensible is to shift the social contract, so that people can fend for themselves in the face of incompatible changes. By the same token, a big reason to avoid compatibility is so that we don't have to indefinitely make the task of future readers more difficult. I think the age of computers is just starting. 99.999% of computer use is yet to happen. It seems shortsighted to hamper the future for the sake of the miniscule past. You wouldn't want to force the adult to hew to the short-sighted decisions of the toddler.
muzani 7y ago
I'd like to read this, but it's triggering my BS radar by the amount of gobbledygook and sentences like "Creating an entire new stack may seem like tilting at windmills, but the mainstream Software-Industrial Complex suffers from obvious defects even in the eyes of those who don’t share our philosophy."
- deleted 7y ago
  [deleted]
- arketyp 7y ago
  It's ironic that the presentation is not very see-through.
- akkartik 7y ago
  I wrote it for an academic conference (https://2020.programming-conference.org/home/salon-2020 https://2020.programming-conference.org/home/salon-2020) which had as its theme an essay by Ivan Illich (http://akkartik.name/illich.pdf http://akkartik.name/illich.pdf, pdf, 67 pages) But in the end, your BS radar is your own.
  - muzani 7y ago
    That's fair. But academia is often full of BS, pardon the language, and so the radar needs to be cranked up. With, say, Medium articles, one can skim if it's good or not within seconds. Academic papers can take hours, if not weeks to discover if it's complete BS or whether I'm just not smart enough, and so I can only go off minor cues. It's generally better to read hard things. They're hard because they have a lot of information density or a lot of gaps. But that also makes people confuse poor readability for quality. Something that has no content tries to be hard to read by stuffing it full of gobbledygook. Whereas something that is trying to communicate an idea often goes through a few revisions trying to simplify the idea. If you have great ideas, you want the user to be expending their brainpower trying to comprehend the idea, not translating it into simple English. (exception is using jargon that's common to people at the right level)
    - 7y ago
meesterdude 7y ago
My bicycle has been Ruby on Rails for over 10 years and i think it is hard to beat. most all of the underlying framework is easily inspectable and changeable to suit needs, while still providing sharp knives that one could use to cut themselves if not careful. But I think this push for "stimulating curiosity" is academic wank. That's not what bicycles of the mind are for - they're tools for building, not naval gazing. It sounds like Mu was built more for ego or prestige than to actually do anything meaningful. Show me Mu as a bike I want to ride - not as a philosophical introspection on why Mu is in some way superior. Reading this PDF it's clearly more ideal than practical. And while it may be "see through" it's shape, interfaces, interactions and surface area are convoluted and poorly presented. Maybe I am wrong to expect humanities out of this, but humans are who have to use this stuff/ride these bikes.
h0l0cube 7y ago
The paper name-drops Ivan Illich and "Tools for Conviviality". If you are intrigued by his ideas, you might be interested in the blog by L. M. Sacasas, The Convivial Society. His writing holds plenty of insight on the intersection of technology and society. https://theconvivialsociety.substack.com/ https://theconvivialsociety.substack.com/
deleted 7y ago
[deleted]
Zenst 7y ago
I really wished such papers had double spacing, or better still, the ability of adobe reader to allow you to adjust such spacing - that would be an amazing feature as for some layouts, they are easier to read with better spacing between the lines - at least for me.
Glench 7y ago
I love the effort to make the stack fully transparent and learnable. This seems so important! I wish more people had the ambition to re-invent the basics of our computing platform to see how things could be different. Now my question is does this learnability hold as the code grows? For example, would the transparency enabled by the stack be reflected in the codebase for a word processor built on this stack? I'd expect not. For one, I'm thinking about how the original program in my Marilyn Maloney demo (http://glench.com/MarilynMaloney/ http://glench.com/MarilynMaloney/) had good primitives, grammar, and a visual representation, yet the code is still hard to understand and can be made much easier to understand with depicting behavior (the interactive UI I made). Secondly, I'm thinking of the Alan Kay-ism "architecture dominates materials" i.e. the invention of the arch was much more effective than the invention of the brick. Mu seems like it could be a great, transparent material, but more important to how software is understood and modified is the architecture of how the material is organized (and personally I think this has a lot to do with UI design and human communication more than the technical foundation).
- akkartik 7y ago
  These are good questions! It may well be that there's an architectural breakthrough out there that will obsolete this whole approach. It's one of very many ways it can fail. Think of it as a hedge, at a societal level. What if we aren't able to come up with a technological breakthrough? After all, software has lagged Moore's law for decades now. I think there's a very real danger in the next few decades that software will get regulated like other fields before it, killing the intrinsically motivated aspect of it entirely. That would be a huge loss to society. We'll have to see how higher levels of the stack develop. I started on this quest building a Lisp, so believe me when I say I can't wait to get to the high-level side of things. There doesn't seem any reason to imagine that we can't have good primitives, grammar and visual representation. My claim is merely that in addition to these interface properties the implementation for them is also important. And it gets short shrift in the conventional narrative. That said, let's imagine that there's a strong case that we need to give up parser generators (or something similarly high-level) in order to give everybody the ability to understand their computers. I'd take that trade in a heartbeat.

210 points by mkeeter 7y ago

I know very little about “mu” specifically, but the title is a highly under-appreciated point. I often notice a tendency to abstract complexity in clean looking interfaces. While that’s convenient for simple projects with pre-envisioned use cases, when using the tool in some novel way often results in bugs due to the abstraction being leaky. For that reason, I personally prefer designs that are transparent, rather than one that attempts to paint a pretty exterior on top of internal complexity. (Obviously correct, rather than not obviously wrong) This leads to a subtle but crucial distinction between software “automating processes” without needing any humans in the loop -vs- amplifying the (expert) humans in the loop to do more stuff. Another subtle (but arguably more important) effect comes from McLuhan’s insight that the medium strongly influences the message. If the medium/tool is not transparent, then so are the biases imposed on the tool user. While that doesn’t lead to obvious bugs, it leads to strutting blinders on human thought processes and creativity. BTW, one last point, in case it isn’t obvious: this goal of transparency in software can be seen as underpinning the free software movement.

drivers99 7y ago
I’m looking forward to reading this paper. I feel like I’ve found my kind of people. I’ve had this half baked idea about how people should be able to see what’s going on in their computer, and trying to picture what that would look like. At the simplest level it’s the difference between seeing a trace of what the computer is doing when it boots up vs being shown a pretty screen which freezes up. Another is just the way so many software products are like “let us worry about the details”. I want to be able see everything from the bytes in memory to what’s going on in every level of the system and want a user interface that lets people do that.
- thulecitizen 7y ago
  Check out the work of the MetaCurrency Project http://MetaCurrency.org http://MetaCurrency.org

chenglou 7y ago

No comment about the Mu itself but: > Our approach to keeping software comprehensible is to reduce information hiding and abstraction, and instead encourage curiosity about internals YES! Precisely. Most "bicycle for the mind" or "tool for thought" approaches go the completely opposite direction accidentally. Many programming languages and communities nowadays too. In reality, if you wanna teach, you have to unveil the guts of the system. Sure, it's "scary" and all, but still, initial hand-holding & letting newcomers see the internals, rather than presenting an overly polished surface at the expensive of everything else, is a much better designed learning process. Design is "how it works" after all. * Related: a common misconception when folks defend abstractions & encapsulation is to raise the issue that letting newcomers explore the internals causes too much trouble. That's an obvious strawman; these methods are not championing everyone writing anything everywhere. They can stay read-only, but public. E.g. an interface can expose its internal data types, without allowing consumers to actually leverage that (enforced through types or something else). This is easily doable, and you don't sacrifice learnability in the service of team programming sanity. * This point seems to get dismissed quickly by folks who only care about visual polish nowadays. Imo this is naive. I care about visuals a _lot_, and we should definitely aiming for both learning polish and surface polish. But you can't let the latter calcify the former. My advice for all the "tool for thought"/"bicycle for the mind" projects: all your opaque designs and small interface flourishes falter in the face of a properly exposed and clean-ed up paradigm, in the long run. This applies on a smaller scope to modern libraries too. That boilerplate generator you mega-fine-tuned to the point you delight yourself in guessing the user's mind, ultimately is a roadblock in the learner's thought process. Expose the boilerplate and document how you're automating it instead. You're trying to teach fishing, not to show off your own fish. Another good analogy I've heard elsewhere is to ask whether you're teaching people how to cook, or just building a microwave. For a tool for thought product ask yourself if you ended up accidentally making "an appliance".

jacobwilliamroy 7y ago
Abstraction to me, just makes it easy to delay implementation. There are sometimes when I need to use an interface now but it won't actually be implemented until next week, when the client gets us our API key, or someone else finds time to do it. Using an abstraction means that I don't have to change any of the code that uses the interface, I just have to change the interface. This is also a good way to make a prototype that is easy to optimize, for example by abstracting a very costly computation, you can just focus on making that computation run faster without having to refactor every line of code where that computation is used.

galaxyLogic 7y ago

"Our approach to keeping software comprehensible is to reduce information hiding and abstraction, and instead encourage curiosity about internals." This sounds rather vague, "encourage curiosity about internals". If I don't need to understand the internals why should I spend time trying to understand them? Isn't it better to "hide their details" into another compilation unit or module, which only exposes its API through an interface so I can easily understand WHAT it is doing, without having to understand HOW it does that? It sounds like they suggest instead of sub-routines/procedures/functions I should have a single big main program, because those sub-routines/procedures/functions would be hiding information from me.

akkartik 7y ago
No, I use functions: https://github.com/akkartik/mu#readme https://github.com/akkartik/mu#readme I just propose to not maintain 3 levels of functions where one will suffice, just to preserve some "interface" for "backwards compatibility". You aren't forced to understand internals. But it is an explicit design goal to make the internals comprehensible against the day you want to learn about them.
- j88439h84 7y ago
  Are you proposing to break backward compatibility?
  - akkartik 7y ago
    Well, it's a new computer so there's no notion of compatibility. But yes, I'm proposing to rely a lot less on compatibility going forward. A big reason for building a new stack rather than building atop existing interfaces is precisely to avoid backwards compatibility. A big reason to keep the codebase comprehensible is to shift the social contract, so that people can fend for themselves in the face of incompatible changes. By the same token, a big reason to avoid compatibility is so that we don't have to indefinitely make the task of future readers more difficult. I think the age of computers is just starting. 99.999% of computer use is yet to happen. It seems shortsighted to hamper the future for the sake of the miniscule past. You wouldn't want to force the adult to hew to the short-sighted decisions of the toddler.

muzani 7y ago

I'd like to read this, but it's triggering my BS radar by the amount of gobbledygook and sentences like "Creating an entire new stack may seem like tilting at windmills, but the mainstream Software-Industrial Complex suffers from obvious defects even in the eyes of those who don’t share our philosophy."

deleted 7y ago
[deleted]
arketyp 7y ago
It's ironic that the presentation is not very see-through.
akkartik 7y ago
I wrote it for an academic conference (https://2020.programming-conference.org/home/salon-2020 https://2020.programming-conference.org/home/salon-2020) which had as its theme an essay by Ivan Illich (http://akkartik.name/illich.pdf http://akkartik.name/illich.pdf, pdf, 67 pages) But in the end, your BS radar is your own.
- muzani 7y ago
  That's fair. But academia is often full of BS, pardon the language, and so the radar needs to be cranked up. With, say, Medium articles, one can skim if it's good or not within seconds. Academic papers can take hours, if not weeks to discover if it's complete BS or whether I'm just not smart enough, and so I can only go off minor cues. It's generally better to read hard things. They're hard because they have a lot of information density or a lot of gaps. But that also makes people confuse poor readability for quality. Something that has no content tries to be hard to read by stuffing it full of gobbledygook. Whereas something that is trying to communicate an idea often goes through a few revisions trying to simplify the idea. If you have great ideas, you want the user to be expending their brainpower trying to comprehend the idea, not translating it into simple English. (exception is using jargon that's common to people at the right level)
  - 7y ago

meesterdude 7y ago

My bicycle has been Ruby on Rails for over 10 years and i think it is hard to beat. most all of the underlying framework is easily inspectable and changeable to suit needs, while still providing sharp knives that one could use to cut themselves if not careful. But I think this push for "stimulating curiosity" is academic wank. That's not what bicycles of the mind are for - they're tools for building, not naval gazing. It sounds like Mu was built more for ego or prestige than to actually do anything meaningful. Show me Mu as a bike I want to ride - not as a philosophical introspection on why Mu is in some way superior. Reading this PDF it's clearly more ideal than practical. And while it may be "see through" it's shape, interfaces, interactions and surface area are convoluted and poorly presented. Maybe I am wrong to expect humanities out of this, but humans are who have to use this stuff/ride these bikes.

h0l0cube 7y ago

The paper name-drops Ivan Illich and "Tools for Conviviality". If you are intrigued by his ideas, you might be interested in the blog by L. M. Sacasas, The Convivial Society. His writing holds plenty of insight on the intersection of technology and society. https://theconvivialsociety.substack.com/ https://theconvivialsociety.substack.com/

deleted 7y ago

[deleted]

Zenst 7y ago

I really wished such papers had double spacing, or better still, the ability of adobe reader to allow you to adjust such spacing - that would be an amazing feature as for some layouts, they are easier to read with better spacing between the lines - at least for me.

Glench 7y ago

I love the effort to make the stack fully transparent and learnable. This seems so important! I wish more people had the ambition to re-invent the basics of our computing platform to see how things could be different. Now my question is does this learnability hold as the code grows? For example, would the transparency enabled by the stack be reflected in the codebase for a word processor built on this stack? I'd expect not. For one, I'm thinking about how the original program in my Marilyn Maloney demo (http://glench.com/MarilynMaloney/ http://glench.com/MarilynMaloney/) had good primitives, grammar, and a visual representation, yet the code is still hard to understand and can be made much easier to understand with depicting behavior (the interactive UI I made). Secondly, I'm thinking of the Alan Kay-ism "architecture dominates materials" i.e. the invention of the arch was much more effective than the invention of the brick. Mu seems like it could be a great, transparent material, but more important to how software is understood and modified is the architecture of how the material is organized (and personally I think this has a lot to do with UI design and human communication more than the technical foundation).

akkartik 7y ago
These are good questions! It may well be that there's an architectural breakthrough out there that will obsolete this whole approach. It's one of very many ways it can fail. Think of it as a hedge, at a societal level. What if we aren't able to come up with a technological breakthrough? After all, software has lagged Moore's law for decades now. I think there's a very real danger in the next few decades that software will get regulated like other fields before it, killing the intrinsically motivated aspect of it entirely. That would be a huge loss to society. We'll have to see how higher levels of the stack develop. I started on this quest building a Lisp, so believe me when I say I can't wait to get to the high-level side of things. There doesn't seem any reason to imagine that we can't have good primitives, grammar and visual representation. My claim is merely that in addition to these interface properties the implementation for them is also important. And it gets short shrift in the conventional narrative. That said, let's imagine that there's a strong case that we need to give up parser generators (or something similarly high-level) in order to give everybody the ability to understand their computers. I'd take that trade in a heartbeat.