1. 20
  1.  

  2. 12

    On the topic of languages, I think Scheme refutes this point. It’s a simple language, that has a (or multiple) standards, yet it’s the simplicity (or the limits this simplicity implies) that forces implementations to create their own extensions, whereby the standard is again subverted. On the other hand Common Lisp is expansive, but manages to be one of the most portable languages known – over time and over systems – although nobody would call a language of it’s complexity simple.

    So it seems there’s more to it, at least if the point is generalized.

    1. 9

      It seems like we’re stuck between a rock and a hard place. Make your standard simple, and people will build extensions because the standard doesn’t have enough features, “ruining” the standard, adding complexity, and leading to a monoploy situation.

      Make your standard complex, and there will only be one or two implementations to start with, leading to a monopoly situation.

      So we have some good examples of standards that are going wrong. Where are the good examples that have managed to survive the test of time existing between this rock and hard place?

      The only successful simple standards I can think of are standards that only hardcore nerds use exclusively. The nerds who appreciate a lack of features. It seems like the core of the issue is not “simple vs complex”, but rather use case. It’s a cultural issue.

      Edit: A very relevant article, one of my favorites: The Danger of Simplicity

      1. 7

        This is pretty disingenuous to Matrix. The reason that Matrix has relatively few server implementations isn’t because the standard is particularly complex, but because we didn’t stabilise the server-server API until Matrix exited beta in June 2019.

        Meanwhile, even though the Dendrite implementation technically began in 2017, we consciously put it on life-support for 2 years until we exited beta given there was zero point in burning effort on multiple implementations whilst the goalposts were changing. We then funded people to work fulltime on Dendrite again starting Dec 2019, and as a result Dendrite’s about to enter beta and as of today has >70% test compliance for Federation (i.e. all the important bits work fine).

        As an excellent counterpoint, an entirely independent server (Conduit) has exploded out of nowhere in the last few months, and has almost full client API coverage and is rapidly putting federation together (they got room joins working this week, and are busy building out state resolution over at https://github.com/ruma/state-res.

        And even despite Matrix being unstable prior to 2019, folks still implemented working federation in servers - e.g. Construct, mxhsd, etc (even if the developers got Very Very Frustrated with the fact that the spec was beta and buggy at that point).

        So, TL;DR: it’s a nice easy trope to say “Matrix is too complicated, that’s why there’s only one usable server implementation”, but it turns out that the reality is a lot more interesting (and positive, thankfully).

        1. 2

          heh, I’d missed that the author also claims “Element is the only usable client implementation”. I must be hallucinating when I use weechat-matrix, gomuks, mirage etc as a daily driver. Yay for hyperbole on the internet :|

          1. 1

            I want to agree with you, but if I put on my end user hat wanting a single thing - a graphical, cross-platform matrix client - it looks bleak. I’ve spent quite a few hours looking at, compiling, and testing Spectral, Fractal, Quaternion, nheko-reborn (am I missing one?) and they all don’t nearly come close to being daily usable, so there is exactly element Desktop (and that’s why I’m still using the web app in a browser). So ‘cross-platform, usable, stable’, there really is element and nothing else. If I forego cross-platform, some of them are actually usable, but still not real contenders.

        2. 4

          re: matrix

          The problems matrix is trying to solve are complex. A simpler solution (e.g. IRC) would not be able to compete with proprietary alternatives (like Slack, WhatsApp) because of missing features.

          Is HTML not open? What about TLS? I’m sure there are more and better examples.

          1. 4

            Yes. Openness and making your project subject to collaboration requires active work to explain things and “open them up”. Simplicity makes that effort much cheaper, maybe even implicit. Totally reminds me of Moxie’s point on why Signal is not decentralized: Making it open/federated also makes it hard to move forward. He summarized this point in the title of his 36c3 talk “the ecosystem is moving”.

            I personally disagree. Some openness can be achieved when stuff is complicated. When you open up, you need to have a strategy. But it’s coming at a cost. You can’t just tell folks to RTFM or read the existing code. You need conscious, enduring effort to talk, reach out, seek feedback and explain. This is hard. There was a study done by colleagues at Mozilla a couple of years ago that tried to explain and categorize “openness”. A catching example would be “open by design” versus “open by accident”. The study was called open source archetypes.

            1. 2

              Interesting read and I completely agree. I mentioned this issue yesterday about Rust and the ongoing discussion might’ve sparked this submission.

              Still, the conflict between simplicity (leading to many extensions, like with Haskell) and broadness (leading to complex standards, like with Matrix) seems to be a tough balance to make.