Hacker News Reader

Comment by zokier | Hacker News Reader

Sure, but when applying "simple is robust" principle it is extremely important to understand also intrinsic complexity. Not handling edge-cases etc does not make for robust code, no matter how much simpler it is.

View on HN

This is where the advice in the article is excellent.

If you start with code that's easy to delete, it's often possible to alter your data representation or otherwise transform the problem in a way that simply eliminates the edge cases. With the result being a design that is simpler by virtue of being more robust.

If you start with code that's hard to delete, usually by the time you discover your edge and corner cases it's already too late and you're stuck solving the problem by adding epicycles.

Yes, but I definitely also see the opposite quite a bit: Somebody several layers down thought that something was an edge case, resolved it in a strange way, and now you have a chain of stuff above it dealing with the edge case because the bottom layer took a wrong turn.

The most common examples are empty collections: either disallowing them even though it would be possible to handle them, or making a strange choice like using vacuous falsity, i.e.

  all [] == False

(Just for illustration what I mean by "vacuous falsity", Python's all correctly returns True).

Now, every layer above has to special-case these as well, even if they would be a completely normal case otherwise.

Your example perfectly illustrates oversimplification: attempt to stuff categorical variable into another of lower order. If a language has absence of value available as an expressible concept (nullability), then a list is at least 3-way categorical variable: absence of value, empty list, non-empty list. Any attempts to stuff that into a binary truthy value will eventually leak one way or another.

Failing to account for this gives you Wayland (which at this time is more complex than X11)

Is it actually more complex?

I find it more understandable, it’s just that DEs need to write their own compositors.

X11 has plenty of warts, but Wayland has more.

Example: screenshot. X11: "please tell me the pixels in the root window". Wayland: "please tell me the extension number of the portals extension so I can open a portal to pipewire so I can get the pipewire connection string so I can connect to the pipewire server so I can ..."

Example: get window position on screen.

Example: set window title.

X11 is a protocol about managing windows on a screen. Wayland is a protocol about sending pixel buffers to an unspecified destination. All the screen-related stuff, which is integral to X11, is hard to do in Wayland with a pile of optional extensions and external protocol servers which do not interact.

X11 is also more standardized, de facto, because there are fewer server implementations, which is not just an accident but is by design.

X11 is far more inclined towards the idea of clean separation of policy and mechanism, which I think is becoming more and more evidently correct across the board of programming. When you start talking about libraries and layers, a policy/mechanism split is part of how to write layered code correctly:

base mechanisms that interpret the raw problem correctly (e.g. pixels on a screen, mouse position) -> some policy that is in some ways mechanism with slightly more abstraction (e.g. drawing shapes) -> some more policy-mechanism abstraction (e.g. windows) ...

until you get to your desired layer of abstraction to work at. This goes along with modularity, composition, code reuse. X11 itself has many design flaws, but Wayland's design is untenable.

X11's separation of policy and mechanism was a mistake. Maybe it made sense at the time - I don't know. GUIs were new at the time. Now that we know how they're supposed to work, the flag should really be called "I am a window manager" rather than "root window substructure redirect", and "I am a special window" (e.g. combobox drop-down) rather than "ignore substructure redirect" for example. (Even better, define some kind of window class flag so the window manager CAN see it and knows it's a combo box drop-down).

> and "I am a special window" (e.g. combobox drop-down) rather than "ignore substructure redirect" for example. (Even better, define some kind of window class flag so the window manager CAN see it and knows it's a combo box drop-down).

I think X11 has had that for a very long time. In the late 2000s when Beryl was still separate from Compiz, it was almost trivial to target things like dropdowns by a descriptive name and give them different effects than regular windows. Mine had an accordion effect while windows would burn up.

My point is that X is in the right direction more than Wayland is, in the spirit of its design, and major pain points of X are largely due to its specific design/implementation. Perhaps an outgrowth of having a lot of tiny policy-mechanism components is lack of standardization, which did strike X, but I think that's an orthogonal concern and not better served by overly large, inflexible components.

There will always be edge cases, and yes they will make the code more complicated, but what really helps is automatic testing to make sure those edge cases don't break when making changes.

Setting up automatic testing alone tends to add its own layer of complexity. At least it's worth it.

It doesn't have to be difficult, for example when developing user interfaces I have a secret key combo for triggering the latest test, and another for running all tests. And I make mock functions that will trigger user interaction automatically. I inline the tests so they are next to the code being tested. I also place them inside comments so I can regexp remove the tests for the release because I don't want my program to be more then two MB, but if you don't care about size you could just leave the tests there so that they can be triggered by users in a prod environment as well. The problem with modern development is that the frameworks makes everything more complicated. Just ditch the leaky abstractions and increase your productivity 100x

Reply on news.ycombinator.com