4 ms·

Sure, but when applying "simple is robust" principle it is extremely important to understand also intrinsic complexity. Not handling edge-cases etc does not mak

by zokier 2y ago

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.

z3t4 2y ago
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.
- Vampiero 2y ago
  Setting up automatic testing alone tends to add its own layer of complexity. At least it's worth it.
  - z3t4 2y ago
    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
immibis 2y ago
Failing to account for this gives you Wayland (which at this time is more complex than X11)
- dartos 2y ago
  Is it actually more complex? I find it more understandable, it’s just that DEs need to write their own compositors.
  - immibis 2y ago
    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.
    - vacuity 2y ago
      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.
      - immibis 2y ago
        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).
bunderbunder 2y ago
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.
Skeime 2y ago
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.
- friendzis 2y ago
  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.

by zokier 2y ago

z3t4 2y ago

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.

Vampiero 2y ago
Setting up automatic testing alone tends to add its own layer of complexity. At least it's worth it.
- z3t4 2y ago
  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

immibis 2y ago

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

dartos 2y ago
Is it actually more complex? I find it more understandable, it’s just that DEs need to write their own compositors.
- immibis 2y ago
  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.
  - vacuity 2y ago
    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.
    - immibis 2y ago
      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).

bunderbunder 2y ago

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.

Skeime 2y ago

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.

friendzis 2y ago
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.