Jonathan Blow posted this on Twitter:
"I kind of don't understand what's the big deal with these 'modern' "display servers" like Wayland / Mir / etc. it ought to be kind of simple actually, because we now have all this experience with drawing graphics and we know how it should go. So I wonder if it's just being made more complicated than it really needs to be, the same way GUI libraries always are. GUI libraries are generally terrible, but this is self-perpetuating as people making new GUI libs absorb bad assumptions from the old ones. There's an interview up with a Mir developer who mentions Mir is structured as communication via a protocol over sockets. And, like, I have literally NO IDEA why you would build a window system like that in 2014. It makes no sense to me at all. (But if you do decide that's how things should go, things become a lot more complicated, so that's at least part of the problem.)
A major reason computers are so unreliable and un-fun to use is because software is now a massive pile of overcomplication. When it comes to a core thing like a window system, that many programs will interface with, simplicity should be a high design priority. Because every bit of complication that goes into the window system propagates. EVERY SINGLE PROGRAM becomes more complicated. Every piece of software becomes harder to develop. The toll in man-years becomes HUGE very quickly. Yet for some reason people don't learn. I think there is some Stockholm Syndrome happening: programmers can't even imagine how much more they would get done if the underlying systems were as simple, reasonable and solid as they should be."
Is this the same Jonathan Blow who said "Braid physically cannot be ported to Linux, the sound APIs simply can't handle it"? :P (Braid was later ported to Linux by a third party and runs fine, IIRC)
Regardless, the answer is "everything is simple when you imagine a single use-case", which as far as I know is what he is doing. I would suggest that people with experience building multi-use-case display servers would know best, those building single-use-case display servers second best, and everybody else is essentially working on guesswork and imagination.
That said, if he wants to go ahead and prove us all wrong by writing a small, elegant display server which fulfils everybody's needs without compromise, I wish him luck and can't wait to start using it :)
Jon Blow is a smart guy, but this sounds like he just hasn't looked at the problem long enough and deep enough to understand it.
I'm sure almost everyone here has at some point looked at a task an said 'Oh that's easy, I'll do it in a week!', and then realised that it's a rabbit warren of peculiar instances, customer needs, and unique problems.
It's like people who think Time is easy, but they forgot timezones, and then they write timezones but they forgot half hour timezones, or quarter hour timezones, or daylight savings time, or leap years, or different calendars, or the fact that calendars change over time, over place, that timezones change, are adapted, etc.
I mean, it's a server. It's a singleton process, which many other processes much communicate with. What other widely supported ICP technique do you think is better for this job, and would make it simpler to develop against?
> Mir is structured as communication via a protocol over sockets
It's important to note that there's a big distinction between Wayland and Mir here. Mir provides an ABI; a protocol over sockets is an implementation detail.
OTOH, Wayland is defined as a protocol that runs over a socket.
So, the way to make peace between the camps is to write an implementation of the Mir API that (optionally) uses the Wayland protocol?
Back to the interview: is there actually an answer there to "what is is that Mir does, that Wayland doesn't?". Apart from the protocol versus API thing, and a claim that protocols cannot be versioned easily (PDF files seem a counterexample to me), I can't find it.
He's generally right about over-complication, but he either lacks the understanding of just how much X hits his bullet points for bad software; or he wants to stick with the current ball of mud rather than add the complexity of migrating to something that will eventually be simpler (hopefully).
I assume the former, but the later is an arguable position I happen to disagree with.
FWIW I liked MGR [1] You just wrote special control codes to stdout in order to create windows and such like. Very simple, no libs required, dead easy to use from programs.
My opinion is that it's very, very hard to avoid this.
I would say that in all the software I have ever written, some part of it sucked. It's actually quite upsetting if I think too hard about it, I wish it wasn't that way. This is mainly because of four reasons (in no particular order):
1. I didn't have time to really finish it
2. I didn't test it thoroughly enough
3. There was some part of the underlying language or framework that I was unaware of that behaves unexpectedly (e.g. the framework encodes output, the int in the language can only handle up to 16384, or you can add a general error catcher, but if you invoke a web method in a particular way, the framework 'helpfully' circumvents the error handler, leading to weird bug that you never hear about)
4. I was using a new language/framework that I didn't know quite how to use. It's not just inexperience, quite often the examples for new frameworks/languages turn out to be bad practices or inefficient ways of doing things in the long run.
Even if you're a good programmer and try and plan ahead, quite often you're writing something you don't quite understand until you actually write it and as you go you make, in hindsight, a couple of poor decisions. It's often a big job to go back and change those poor decisions, and even if you did it might not completely fix the problem. Some remnants of the old design stick around like a bad smell.
And there's also bad design decisions that don't come out until the program is out in the wild, you might have thought the purpose of your wheel was to make bicycles, but in fact only a couple of neckbeards make bicycles, everyone else is making cars out of them and they're completely the wrong design.
And worse, only the neckbeards are on the mailing list so you get a disproportionate amount of feedback from a vocal minority and don't even realise it's not really suitable.
And on top of that, some software suffers from the first mover advantage though it's badly written and then gets almost, but not quite, abandoned, so no-one ever moves to the much better alternatives.
And then all those little warts and mistakes, as you say, propagate.
I have screamed at my screen in rage at how stupid some programmer has been while designing a program that almost does what I want but quite spectacularly (or worse silently) fails at some key part. But they probably tried hard to make it good.
In truth, writing excellent software is still the domain of a very elite few, the rest of us write ok, but very brittle, software.
A major reason computers are so unreliable and un-fun to use is because software is now a massive pile of overcomplication. When it comes to a core thing like a window system, that many programs will interface with, simplicity should be a high design priority. Because every bit of complication that goes into the window system propagates. EVERY SINGLE PROGRAM becomes more complicated. Every piece of software becomes harder to develop. The toll in man-years becomes HUGE very quickly. Yet for some reason people don't learn. I think there is some Stockholm Syndrome happening: programmers can't even imagine how much more they would get done if the underlying systems were as simple, reasonable and solid as they should be."
I'm curious about HN's opinion on this.