Arc Forumnew | comments | leaders | submitlogin

You said above that chopping a tree is permanent, even though new trees may grow. We're of one mind there. It's worth dwelling on this distinction, because it is the essence of what I'm trying to get across.

It's not about the single tree. Trees grow and die, and every step of the process seems natural in isolation. The problem with externalities lies in the scale, in the disruption of the natural balance between competing forces.

Yes, individual rules are not directly connected to each other, and their effects are often isolated. The trouble lies in their implementation and how the interactions of implementations of different disparate rules often reduces the degrees of freedom in future rule making/management.

Say you have 100 people creating new rules or software. Each of them only cares about a few projects of rule-making, and the different projects are largely independent. If 90% of the rule-makers are making badly designed rules, the whole will gradually grow unmanageable. This story doesn't depend on what the rules are about in the real world. All we are concerned about are the implementation details. Are they implemented parsimoniously, or is the overall effect a result of two clauses combining from hundreds of pages apart? Are they easy to understand, or are they deliberately phrased in a convoluted manner to make it difficult for newcomers to join in the business of rule making? Do they follow some meta-rules consistently, or do they normalize deviance (http://lmcontheline.blogspot.com/2013/01/the-normalization-o...)? There are many such tests, and we think of them as 'design'. The design of a system is a meta-commons even if each of us has a different use case within it.

Even if you think you don't care about the rules most people follow, the rules care about you. For example, it's harder for me to find other C++ programmers to collaborate with because the pool of people who care about the same domain as me is further diluted by people who care about the same subset of C++ as me. The parts of C++ I don't use still affect my life.


> When the mechanisms are simple and easy to reason about, it's easier to delegate because worst-case analysis of human nature is possible. When the mechanisms are powerful, we need greater understanding of human nature to navigate the complexity of incentives and unforeseen consequences.

That helps tie the two together, thanks.

I'm still not convinced though on what you think the downsides would be, or why; specifically, why they couldn't be bounded and partitioned in some way, or why you have to get them all correct up front instead of adapting later with better information.

If we look at the truly long term, the butterfly effect might indeed paralyze us as to what the potential consequences of any single action might be. But a butterfly-flap does not directly cause a hurricane; they are connected by a myriad of intervening causes, many of which could have stopped the storm. Planning ahead is good, but how far? Specifically, how far given how little we actually control.

> We need more software driven by intrinsic motivation, that is more likely to try to grapple with long-term consequences.

This helps a lot for explaining your vision, and sounds much more agreeable.

I read After Virtue by Alisdair MacIntyre [0] recently, and this sounds like an appreciation for the virtues necessary for the successful practice of software development. It would be interesting to explore that further.

> the ... tragedy-of-the-commons effects we've already introduced into the world, But at some point enough trees get chopped down that it gradually gets more and more urgent to not dig ourselves deeper.

Mentioning a tragedy-of-the-commons and an analogy of tree-chopping makes it sound as though industrial software was producing destructive and indelible environmental effects. The idea of "digging ourselves deeper" also implies that it's cumulative and aggregate. That is, something like there being a "bad-software gas" effect, and every emission of bad software contributes to it and won't easily dissipate.

I think this is a contrast I keep trying to come back to; maybe eventually I'll figure out how to state it clearly.

Chopping a tree is destructive and permanent; it doesn't respawn, though eventually new trees might grow. This makes tree-chopping cumulative unless managed properly. It is also really does reduce the aggregate number of trees and thus whatever benefits trees provide the environment. That is, lost trees could hypothetically affect everyone. Eventually, tree-chopping could add up to something significant. Furthermore, each tree chopped is a larger percentage of the remaining trees, so later chops may be more serious than earlier ones.

I don't think any of these attributes apply to software though. Writing software is constructive. Each project is independent, and does not cause any effects unless directly invoked or linked. This means new projects create more options, but not more liability; there is no aggregate externality. There are hundreds of thousands of projects on Github, and thousands of more companies with private source, and I am aware of and affected by very few of them. If one of those projects causes harm when I link it into mine, that's as much my fault as the original author's because I chose to link it.

The existence of vague, aggregate negative externalities for software needs further justification. Specifically identifying the issue may also help identify better how to fight it.

I think a common error in macro analysis (such as in Keynesian economics) is to treat members of a type as an aggregate quantity. The capital in an economy isn't a homogeneous quantity C that can be easily shifted to different industries, but actual machines and experts coordinated in a structure of relationships that can't be so easily changed. Software doesn't exist as some abstract quantity S that increases or decreases and correlates to a quantity of harm H. Each project is unique, and used by other projects in unique ways - or may not have any effect on them, if they are not so connected.

> Hopefully this clarifies things even if I didn't answer every last question of yours. Do let me know if you'd still like me to answer some other bit.

That's fine; it's enough if my questions help you understand my perspective and confusion, so you can better address them. I'm trying to work out more precisely my thoughts on these things as well. The better I understand the problem and the value of these particular software virtues, the better I can incorporate them into my own work.

---------

[0] https://en.wikipedia.org/wiki/After_Virtue


> A cool idea, but completely unrealistic given chaos theory.

Agreed.

> In contrast to your statement of needing better understanding of human nature, this statement makes it sounds like the dynamics and unpredictability you're considering is the behavior of software components in composition with other components. Which is it?

When the mechanisms are simple and easy to reason about, it's easier to delegate because worst-case analysis of human nature is possible. When the mechanisms are powerful, we need greater understanding of human nature to navigate the complexity of incentives and unforeseen consequences.

> Are you really suggesting that the only software anyone uses should be software they wrote themselves?

Yeah, this bears clarifying. I'm not hung up on some sort of notion of purity that I came up with. I wouldn't make this recommendation in the '80s. Then things didn't seem so far gone. My recommendation takes into account the amount of software and complexity and tragedy-of-the-commons effects we've already introduced into the world. We have enough bespoke software. We don't need more that is driven by extrinsic motivations like pay. We need more software driven by intrinsic motivation, that is more likely to try to grapple with long-term consequences. Someone inexperienced may still pollute the well, but they may learn from their past decisions. Software professionals like me are largely unlikely to think hard about these things, because our salaries depend on us not understanding.

When the first truffula tree was cut down I wouldn't get too hung up on it. (Assuming I had the same worldview I have now.) But at some point enough trees get chopped down that it gradually gets more and more urgent to not dig ourselves deeper.

Hopefully this clarifies things even if I didn't answer every last question of yours. Do let me know if you'd still like me to answer some other bit.

2 points by akkartik 4 days ago | link | parent | on: Why I'm betting on Julia

> Traceability at least is facilitated by shorter traces; that is, fewer layers of abstractions to navigate.

akkartik nods particularly vigorously to this


> I don't intend to suggest that the problem of delegating rule-making is destined to be forever impossible. But it does seem about as difficult as the fictional science of psychohistory

I wasn't thinking along those terms, but the clarification is still helpful. Also, I like the reference to psychohistory. A cool idea, but completely unrealistic given chaos theory. If we can't even manage the dynamics of the logistic map [0], successfully predicting the behavior of more complex nonlinear systems is even more unlikely.

I'm still not sure it's fair to characterize all of software as unpredictable or having unpredictable effects though. The limit of the iterated logistic map is unpredictable for certain parameter ranges, but that doesn't mean that all math functions have unpredictable limits. I think for the purposes of this discussion it would be very helpful to identify which systems do and why, so that we can better understand what should or even could be done about it.

To some extent I accept the unpredictability premise, because software is written and used in a social context (which your statements about psychohistory imply is your primary concern) which has very complicated dynamics. But at the same time, the software artifact itself is basically static information that doesn't have any dynamics at all.

This emphasizes the question of which effects you are concerned about?

> In rules and software, action at a distance is the norm rather than the exception.

In contrast to your statement of needing better understanding of human nature, this statement makes it sounds like the dynamics and unpredictability you're considering is the behavior of software components in composition with other components. Which is it? Even so, I think in principle I could agree with that as well; in general unless you know what's in the components, and what all of the components of the system are, you can't predict what the behavior of a system will be. Specific cases are another matter, however.

That said, there's lots of work on atomicity and confinement that can help with identifying boundaries. Imperative code is exposed to possible side effects when invoking functions, but functional languages are not. I think proper security models can also help with this; in an object-capability system, nothing can perform operations but that you provide them with that capability. Loose coupling (services, protocols, dataflow) limits the possible externalities as well. I grant that the 'action at a distance' problem exists, but there are other possible solutions besides "avoid delegation entirely".

> I would not hire a programmer [...] and I would not recommend any of my loved ones do so

Are you really suggesting that the only software anyone uses should be software they wrote themselves? That hardly seems scalable or effective. Like subsistence farming. One might think that subsistence farmers have more control over their diet, since they get to control most of the inputs. They can hypothetically choose which varieties of vegetable to plant, and what fertilizers and techniques to use in growing them. In practice though, a true subsistence farmer is very constrained to use only what they can produce, and vastly more exposed to the environment since they have no alternative sources. Buying food at a modern supermarket does give one less direct control over how the food is grown, but there are many, many more options to choose from around the world. Perhaps you won't find exactly what you want, but you're much more likely to be able to find it year round.

The software available for sale may not be what you want, but you have lots of choices and you don't have to buy any of it. I can agree that being able to understand the internals could help make better choices, but I can't understand an absolute injunction against delegation.

> The current software industry is not "effective", for any meaning of the term that is related to the end user over any reasonably long term

I think this is probably the key point. How would you define "effective"? Given that people do pay for software, they must consider it effective for their objectives.

I suppose another line of reasoning might be to consider not a specific configuration of software, but rather the changes in its objectives over time (which may have been what you were alluding to with the reference to psychohistory). In that case, the specific objectives don't matter but rather some level of adaptability. That fits with what you've said earlier about being able to jump into a system and make changes with only a few hours of effort to understand the surrounding behavior. I can definitely see how that would be an argument for easily understandable and accessible internals, similar to the car maintenance analogy. However, I still don't see an argument against delegation.

Indeed, another key question is: what are you proposing is different about writing software oneself than letting someone else do it?

A third party could easily be better at building maintainable and understandable systems than myself (I could have hired you to build Mu...), and I can be cautious to hire only people I trust and take security precautions. If it has something to do with consequent understanding of the system that was built, I would argue that after a fairly short amount of time all of those differences are erased by forgetfulness. As I said before, any software you wrote 6 months ago was written by somebody else.

Again, I am not at all questioning the value of accessible and comprehensible internals, just the seemingly unrelated arguments against delegation etc.

----------

[0] https://en.wikipedia.org/wiki/Logistic_map

2 points by shader 4 days ago | link | parent | on: Why I'm betting on Julia

Yeah, I didn't even really register his prediction because I'm used to taking such statements with piles of salt.

Without a clear niche and "killer app", most languages don't have any way to draw attention or attract new programmers. I've run across Julia before, but never had a reason to look at it for more than a few seconds. Today I looked at it long enough to read half of the metaprogramming page, and file it away for potential future use if I need an array-oriented language or have a data science project, just for fun.

But most people won't hear about it, and won't have the same tendencies I do to try doing new projects in new languages. Perhaps Julia does have a specific problem it's trying to solve, and people with that problem are more likely to discover and adopt it, but that doesn't translate to the broader community very quickly.

> I'm bootstrapping from machine code not to keep things fast but to control the total implementation stack and so keep it comprehensible.

Yes, and I think you've made that point fairly well, but this was a fairly helpful clarification and restatement. Perhaps there are several dimensions to "exposed internals": visibility, accessibility (that is, manipulatability), and comprehensibility or traceability. And I think attempting to maximize these attributes will lead to a design much like you have in Mu of minimizing the overall surface area of the internals - otherwise they may start to obscure each other. Traceability at least is facilitated by shorter traces; that is, fewer layers of abstractions to navigate.

It seems that formal systems often follow an axiomatic model, parsimoniously adding layers as necessary, while industrial systems are more of the 'large, flat' model that build on top of an existing platform but don't add more than a few layers of abstraction. Generally just classes, interfaces, and service APIs. At the same time, the formal systems don't necessarily add true "layers", because identities are preserved across abstractions. Something to ponder more I guess.

Also, regarding performance, I'm not really sure how merely seeing the assembly code output by Julia helps that much if you can't directly control it. I could see it being helpful for sanity checks, or for learning about how the machine works (that's why I thought it was relevant), but it would be really hard to use for tuning.

> Do you know if building the Julia compiler relies on a previous version of the Julia compiler?

I don't know for certain, but it looks like the src directory contains a lot of CPP and some "flisp", so I would guess not.


I went back and reread my grandparent comment here, and I actually wouldn't change much if I was phrasing it more carefully. I'm much more certain about the problem than about Mu as a solution to it.

The one thing I would change is to add a "given current technology". I don't intend to suggest that the problem of delegating rule-making is destined to be forever impossible. But it does seem about as difficult as the fictional science of psychohistory (https://en.wikipedia.org/wiki/Psychohistory_(fictional)). It's not a hard science, but requires far better understanding of human nature than we currently have.

> > As a result they're impossible to safely delegate.

> That doesn't follow. Long-lasting results could just as easily be an argument for hiring an expert to do the best possible job. E.g. an architect for a stone cathedral vs. a DIY shed.

Let me requote myself to add the sentence it follows from: "Both are systems of rules that have unanticipated long-term effects on the lives of people. As a result they're impossible to safely delegate." The crux here is the 'unanticipated'. A badly built stone cathedral can cave in, that's about the worst case. If you were rich enough that may seem like a reasonable worst-case risk. You can protect against it with some diversification. But installing the wrong program on your computer can cause the whole to become compromised. And it's not just a theoretical possibility either. In rules and software, action at a distance is the norm rather than the exception.

> I would think that the existence of the software _industry_ rather than a network of niche artisans flatly disproves this statement. People do hire others, and it proves to be a more effective and profitable way to develop usable products than trying to do everything by oneself.

You're right, when I say "impossible" I mean what should be rather than what is. I would not hire a programmer (even though I am one and I get paid by others; this is a painful self-criticism to admit to) and I would not recommend any of my loved ones do so. We all rely on hired programmers. I have grown painfully aware of this exposure. At least we should try not to increase this reliance.

The current software industry is not "effective", for any meaning of the term that is related to the end user over any reasonably long term. It certainly is profitable. I'd much rather the world had been a lot more measured in its incorporation of software into every aspect of modern life.


This side is definitely not absolutist. In my opinion, Java started out encouraging people to rely on the compiler for type errors. We got used to refactoring in the IDE, and if nothing was red we expect no type errors.

With a dynamic language you never start out relying on the compiler as a crutch.

This argument isn't about anything directly technical about the respective compilers, just the pragmatic thought patterns I've observed..

2 points by akkartik 4 days ago | link | parent | on: Why I'm betting on Julia

Indeed, that was a fun article to reread. Interesting that 6 years on, his prediction hasn't come to pass.

I should clarify that I don't actually care much about performance. I'm bootstrapping from machine code not to keep things fast but to control the total implementation stack and so keep it comprehensible. Julia's use of native assembly is just to help people make their programs faster, not to help more people get into the compiler. It's yet another language telling you to use it as "an abstraction" and not worry about the details. Which compromises the whole point of open source: getting more eyeballs on the code.

Do you know if building the Julia compiler relies on a previous version of the Julia compiler? I couldn't tell from https://github.com/JuliaLang/julia/tree/v1.4.0

2 points by shader 4 days ago | link | parent | on: Why I'm betting on Julia

Evan Miller's appreciation for Julia is based on similar concerns to our recent discussion on transparent bicycles [0].

Apparently Julia, a dynamic language built on LLVM, provides REPL access to the intermediate representation and assembly versions of a function.

For additional relevance to the remnant arc community, it also provides a very easy-to-use FFI, and is a homoiconic language like lisp with s-expression support [1].

------------

[0] http://arclanguage.org/item?id=21379

[1] https://docs.julialang.org/en/v1/manual/metaprogramming/


Yeah, I guess I could have phrased that better.

In my mind, "not necessary" didn't imply "necessarily not", but I can see how it might sound like I wanted to just let the world burn and walk away. I only intended to suggest not worrying about it and not putting that popular-opinion cart before your original-objective horse.


Why are runtime type errors acceptable in Lisp but not in Java? Or was there some other reason for dynamically-scoped variables to be acceptable in Lisp?

Yes, if it was a game that would be true, because (within the rules) you can't just walk away from the game, and there is only one winner.

However, software like most things in real life isn't a game. There aren't any rules. You can just fork it, or ignore it, or employ any number of other subversive strategies.

You keep thinking in zero-sum terms, and in ultimate terms like "doom" that I don't think actually apply to the domain.

How do you define "doom" anyway? Sounds like there's an objective you want the meta-system to be moving toward, but you expect it to fail. I'm not convinced there is such a perfect destination, or that there's anything like predictable determinism in the system.


I feel like much of the disagreement in this conversation comes down to a question of degrees, as you mentioned in your other comment.

Many of your comments seem to imply an absolutism that you may not actually mean; I know I sometimes overstate my arguments when I'm trying to keep a point concise anyway. Or possibly I'm being pedantic by requesting that you qualify all of your claims.

I agree that laws and software last a long time. Most other systems would wear out and need replacing eventually. The need to explicitly repeal laws gives them incredible inertia, and is a good argument for sunset clauses. At first glance software seems like it could last as long, since it's only information, but in practice I think the underlying systems and surrounding environment change enough that the software must also adapt or die.

Perhaps it's a change in perspective. If you look at the software application itself, it doesn't have to change and can last forever. But systems change, and eventually leave the application behind. That's a (possible) victory for those of us on the side of active replacement.

> As a result they're impossible to safely delegate.

That doesn't follow. Long-lasting results could just as easily be an argument for hiring an expert to do the best possible job. E.g. an architect for a stone cathedral vs. a diy shed.

> You can't pay programmers to write code for you.

I would think that the existence of the software _industry_ rather than a network of niche artisans flatly disproves this statement. People do hire others, and it proves to be a more effective and profitable way to develop usable products than trying to do everything by oneself.

> because they'll drown you in technical debt

If that's the only argument against hiring someone else, it's not a very good one. For one thing, companies can choose to set style and documentation requirements, so that little information is lost when they leave. On the other hand, I am quite capable of drowning myself technical debt on my own; I might even be more likely to take shortcuts if I have to do everything myself. To paraphrase my father, software written by someone else is hard to understand and maintain, and software you wrote more than 6 months ago was written by someone else.

I think my main point in all of this is to try to convince you not to be so pessimistic, because a lot of the things you're focusing on either aren't actually that big of a problem, or aren't necessary to solve. Part of it is also about strategy. I generally agree your design decisions and objectives, but based on the HN discussion it's going to be a hard sell if you present your ideas in direct opposition to everything else. Someone pushed back on the idea that everyone needs to understand implementation details. Truth is, they're right, but instead of explaining how the availability of details can still be valuable even if they aren't needed by everyone on a daily basis, you tried to counter. I'm not holding that against you; I have a tendency to do the same thing (it's easy to just respond point-by-point to all the flaws in a post, and forget that I should be working towards an objective). But I think you can do better.

Still, kudos to you for getting this far in the first place. I have too much fun talking about ideas to actually build them.


That makes sense. I think my criticism is really for Guice, which has the effect of making Java a dynamically typed language that can throw type errors at run-time. But if you start out with a dynamic language like Lisp, dynamically-scoped variables are much more acceptable.

Regarding the term "injection", I'm following https://en.wikipedia.org/wiki/Dependency_injection. It feels like a marketing term, but now we're stuck with it.


Yes, I suppose "dependency injection" as a concept doesn't actually require anything sophisticated like a framework or IoC containers etc. But the term "dependency injection" sounds to me like it's doing more than just passing in a parameter, and I normally wouldn't expect it to be used unless it meant something more.

I think that's because "injection" is active. It sounds like intrusively making some code use a different dependency without its explicit cooperation. Passing parameters to a function isn't really "injecting"; it's just normal operation.

> Automating the injection decisions defeats most of the purpose of DI, I think.

I don't know about "automated" decisions, but the value of something like "injection" to me seems that you could avoid explicitly mentioning the dependencies at intermediate layers of code, and only reference them at the entry points and where they are used. The way your code works, every function that depends on anything that could call 'print has to have a screen in its parameter line. For Mu, that may be a reasonable design decision; you want to keep things transparent and obvious every step of the way, and don't want to add any more complexity to the language than necessary. However, I think there is a case to be made for something like dynamic variables to improve composability in a higher-level context. That's a discussion for a different language (like the one I'm designing, which gets around the various problems of scoping by making almost everything static anyway).

This is probably talking past your point, but I'm trying to argue that there might be value in some degree of DI beyond parameterizing functions. I have not necessarily justified "automation", and since I don't have a good definition for that anyway, I don't think I'll try.


It's the difference between a game of chess and a game of Nomic (https://en.wikipedia.org/wiki/Nomic). Being able to change the rules makes every move much more powerful, and the game much more chaotic. If you have inequality between people who can make moves and people who can't, I think that dooms the system in the long run. (It may well be doomed in the long run anyway, but again, I think there's only one direction to go here.)

Ah, I see.

> > It is not necessary to save or change the rest of the world.

> I absolutely disagree.

In my mind the poles of this disagreement were zero change to the world vs non-zero change to the world. I was saying it seems futile to try only to change myself but not some others. The thought of a universal quantifier, zero vs infinity, that didn't occur to me at this point.


Maybe I should clarify that I mean dependency injection but not a dependency injection framework. Automating the injection decisions defeats most of the purpose of DI, I think.

Here's an example of the ways that laws affect your life in umpteen ways: http://akkartik.name/post/2010-12-19-18-19-59-soc

> You haven't clearly explained how software is like laws, or made clear arguments for why leaving laws to experts is the source of the problem, why software would suffer the same fate, and what should be done differently.

Both are systems of rules that have unanticipated long-term effects on the lives of people. As a result they're impossible to safely delegate. You can't pay programmers to write code for you, because they'll drown you in technical debt that only washes over you long after they're paid and gone. You can't expect legislators to make good laws because they'll constantly take the easy way out and leave a mess for future generations to deal with. (Now maybe you can't expect people to make good laws in general. But if there's a way out, that's the direction to look for it.)


Based on the fact that we're discussing this on the arc forum, and you've built languages to replace-ish assembly and C, and I'm designing a language to replace pretty much everything else, I'd say we're much more on the same page than nearly everyone else.

This particular back-and-forth was that I said we "don't need to save the whole world", and you "absolutely disagreed". It sounds like you've agreed with all of my points or softened yours, so I'm not really sure where that leaves us.

Somewhat ironically, I sometimes think of the design I keep hinting at basically as a rebase of most of computer science onto a virtual computer with 32byte pointers to ROM.


> Such abstractions are great -- if you can find them. Once in a lifetime things.

Maybe we're discussing different when it comes to abstractions.

They don't have to be paradigms and approaches, like your reference Lisp as a whole. I'm not even sure how "Lisp" fits into the "don't lie" model; it's on a completely different scale. I'm just concerned with how things are represented. UDP doesn't lie; it says up front that its datagrams are unreliable. TCP on the other hand pretends to be a reliable ordered stream; that pretense comes at a cost, and sometimes fails anyway.

Another one that came up recently was Golang vs Rust and how they handle file paths (or pretty much anything really). Golang takes the path of least short-term resistance, and tries to make things easy by pretending paths are strings. Turns out that isn't always true. Rust in contrast works hard to ensure correctness; for file paths they use a custom OsStr type that covers the possible cases. There are lots of examples where Rust uses result types to present a more complex but accurate set of outcomes.

> Not lying is not easy. You have to take responsibility for basically every misunderstanding someone may make with your ideas.

That sounds like a good point, but after thinking for a second I don't think I agree. If I was really trying to guarantee that no one misunderstood my work, that would be a problem. However, that's not the objective of the principle, which is a guide for choosing representations. Apply the same logic to human honesty. Is it really that impossible to avoid lying in conversation? Am I suddenly lying if someone misinterprets what I said?

I think avoiding lying in abstraction design should be similar to personal honesty in conversation with other people. Don't intentionally misrepresent something. If someone misreads the specification and makes a mistake, that's their fault.

I will go a step further though and say that simply having a disclaimer doesn't match the spirit of the principle. Surely the TCP documentation (or a little critical thinking) will reveal that it can't truly make streams reliable. The problem though is that it tries, and wants you to believe it does except for "rare circumstances." I would prefer a system built using UDP with full expectation of the potential failures, than one on TCP that thought it had covered all the edge cases that mattered only to run into a new one.

I guess the Erlang "let it crash" philosophy is almost a corollary. If you don't have illusions that your code won't crash, and prepare for that worst possible case, then any unhandled errors can just be generalized to a crash.

The purpose of the principle is to make better designs by giving more accurate and flexible options to the user. If a design choice is between exposing the internals as they are, or trying to cover up the complexity to coddle the user, choose the former. Give the user the flexibility and power of handling the details themselves (possibly via library). Don't lie.


I have a metaphor I like to use sometimes to describe the perils of over-extending metaphors. That's not exactly the same, but maybe it's relevant enough to share.

  A metaphor is like an old rusty wheelbarrow; if you put too
  much into it and push it too far, it will break down, you'll
  trip over it, cut yourself, get infected with tetanus, and
  end up in the hospital filled with regret.
I'm still not satisfied with the ending and tweak it slightly each time. It fits the pandemic humor rather well though.

Yep, that answers my question perfectly.

You had said "dependency injection" somewhere, so I thought there might be more to it.


> my analogy with legislators a superior alternative to computers as cars or planes.

I think what you're trying to say is that modifying software is more like amending a law than tinkering with a personal car. Legislators are to laws what programmers are to software, and we have gotten bad results from leaving law to experts, so we shouldn't leave software to experts either.

You haven't clearly explained how software is like laws, or made clear arguments for why leaving laws to experts is the source of the problem, why software would suffer the same fate, and what should be done differently.

> So the fallacy in the argument is that implementation details are relevant to everyone. They aren't. They're relevant to system builders and people who like tinkering because that is a separate domain to the user domain.

Quoting the guy you responded to, his main point seems to be that implementation details aren't relevant to everyone. He uses cars as an example; some people tinker, others just drive. Empirically his point is borne out: most people just use Instagram on their iPhone without any concern for implementation details.

> Given the outsized effect that software infrastructure has on our lives, I think computers are more like laws

I think I disagree regarding the "outsized effect". I don't have many personal interactions with the law so I don't think it effects me much, but I use software every day so I feel its effects. Also, the effect that laws have is community-wide and enforced, but nobody is compelling me to use any particular piece of software.

> laws are too important to be left to legislators

Too important in what sense? What other alternatives? The problem is, laws are fundamentally a community rather than individual concern. Laws are hard to modify because they can only be enforced by a community as a whole. You could pick a different process, but however you propose changes to a law they have to survive the politics of the community to be enforced, and to the degree that a community does not unanimously agree on general interests those laws will be created for special ones. In contrast, software use is voluntary and personal.

> it would be great to separate the user experience from the developer experience if we knew how

The points you take up in this argument are 1) implementation details are relevant to everyone, and 2) the developer and user experience can't be separated. With these points, I disagree. There are many users who are not developers, and don't care about internals. Just like both cars and laws, most people don't care about the details until they have to. At that point, some will look for professional help (mechanic, lawyer), and others will do it themselves. Yes, the details are important, but that's why we hire mechanics and lawyers who know them well, and not an argument for learning them yourself.

However, your main point was that mind-bikes should be see-through. The argument that not everyone cares about internals is actually irrelevant to that point, and I don't think you need to quixotically defend against every attack. Details should be accessible simply because that makes tools ergonomic and maintenance easy, regardless of who's doing it. I really like the fact that the oil filter on my car is right on top of the engine; makes changing it really easy. Even if I didn't change the oil myself, it would still make the task easier for the mechanic. That's not just altruism either; if it's easier for him, I probably get better service at lower prices.

I don't always care about the details, but when I do, I like them to be accessible and easy to understand.


> My reference to math was not an analogy, but a description of an approach to abstractions. In Mathematics, abstractions are held to rigorous standards: they must actually be proven to behave as claimed, any exceptions must be included in the definition, and any application outside of the assumptions is invalid or at least highly suspect and must be justified.

Such abstractions are great -- if you can find them. Once in a lifetime things. Pretty much nothing we use in software comes close to this. Not even Lisp.

Not lying is not easy. You have to take responsibility for basically every misunderstanding someone may make with your ideas.


I think we're saying the same thing but misunderstanding the words used by each other. Don't get hung up on my careless use of the word "win". Like I said elsewhere, I'm not trying to genocide competing ideas :)

The rest of this thread is just a reminder to me to avoid analogies like the (ahem) plague.


Heh, I notice now that I never actually said "replace" in the paper. I said, "take it out and think about the problem anew." That sounds like we're on the same page?

> ...we'll see over time whether coming up with the right abstractions is a sufficient approach

What other approaches are you considering? And sufficient for what purpose?

> it's not at all inevitable that the right abstractions will win out

I addressed this more thoroughly in my other wall of text, but I don't see why "winning" is a necessary objective. If you have an abstraction that works, it won't suddenly disappear on you. Or maybe I don't understand. "Win out" over what? And by what standard of success?

> We have to very carefully set the initial conditions to ensure the paths to them aren't prematurely discarded.

That's a slightly different consideration, trying to pick initial conditions that result in better abstractions. Honestly, it sounds like premature optimization and harder than the halting problem. In some ways though I think the general principles I mentioned are precisely intended to address this challenge. Basically, whenever you come to a design decision where you don't know what the right answer is, or if there might be more than one, don't hide the complexity but pass it on as flexibility to the user. The system stays correct and transparent without lying about how it works, and the user doesn't lose any options. This approach seems to satisfy your desire to not prematurely discard paths.

> The analogy with math is misleading here, because math doesn't have syscalls

My reference to math was not an analogy, but a description of an approach to abstractions. In Mathematics, abstractions are held to rigorous standards: they must actually be proven to behave as claimed, any exceptions must be included in the definition, and any application outside of the assumptions is invalid or at least highly suspect and must be justified.

> syscalls let us do fairly arbitrary things. Given this much power, "don't lie" is about as enforceable as it is with legislators.

It's not enforceable with mathematicians either; the best we can do is read eachother's work to check for such lies and avoid using flawed work. Such care is more important in mathematics where any flaws can ruin a proof, whereas in software a bug might only be reached in rare edge cases and even then we can turn it off and on again. That explains why the cost of failure is lower, and programmers don't apply the same effort to write flawless code. But what I'm proposing is not "don't let anyone lie" which sounds impossible, but "don't lie", which is a call for personal integrity. It's a design decision, in which integrity and transparency are chosen over comfort and simplicity. That decision is probably just as costly in software as it is in life, but hopefully proves just as rewarding.

> ...applying it becomes something outside of math. An externality.

That just sounds wrong to me, and needs a stronger argument. It may be a pain to write out all the preconditions and postconditions describing the whole state of the computer and environment (I certainly wouldn't recommend it), but that doesn't mean it is conceptually impossible and thus "outside math". However, thinking that way is mostly irrelevant anyway. Instead, I propose the simpler objective of not misrepresenting what could happen. "Not lying" is not the same thing as "telling the whole truth". Math uses pretty broad lower and upper bounds all the time; precise answers aren't always available, but we can still avoid claiming things we can't prove.

More