6 ms·

I'd say that the only reason that software seems too complex, rather than as complex as it needs to be, is because every programmer thinks he can rewrite it in

I'd say that the only reason that software seems too complex, rather than as complex as it needs to be, is because every programmer thinks he can rewrite it in a simpler way, but when he's done, it's as complex that which he has rewritten. I've seen it happen so many times, and I've done it. It's the very same principle that leads to almost every construction project running behind schedule — a man simply underestimates the complexity of nigh every task he endeavors to complete.

nchelluri 6y ago
I see your points, and I see the merit of "rewrite syndrome", and lean strongly towards automated-test backed refactoring, and all in all I disagree with your thesis. Sometimes, software patches and new features get tacked on and tacked on and the system loses all semblance of cohesion or integrity. Thinking of the system as a whole, iterating with the confidence brought by tests of some sort, one can begin to detangle all the unncessary intermixing and duplicate work and begin to make the system sensible.
Aeolun 6y ago
Depends. If you can re-evaluate the requirements when you start your rewrite, you can likely consolidate a lot of the features. If the requirements stay exactly the same, then yeah, there’s no point.
- Blikkentrekker 6y ago
  Well, when Wayland started they went in on the assumption that they could cast away quite a bit that “no one was using” or that “wasn't necessary”. And then they had to include more of what they cast away because they underestimated the number of consumers of things they personally weren't using. libinput originally actually did not have a way to disable and configure pointer acceleration I believe because the developed thought there was no reason to ever turn it off. He was not a gamer and was largely ignorant of how essential being able to disable it is for the level of accuracy required for video games.
  - SulfurHexaFluri 6y ago
    Now days Wayland compatible DEs seems to support everything the average user needs while supporting quite a few modern features that were apparently too difficult to support in X11 like monitors with different DPI scales.
    - Blikkentrekker 6y ago
      That you think that would suggest you have a similar lack of appreciation of what users that aren't you need that the developers that went into it had. At this point Wine is still at the point of not considering a Wayland port until some severe changes happen at all — it cannot even begin to map the WinAPI to Wayland as it could to X11 at this point because too many features they need are missing that the developers didn't consider would be necessary for many things that Windows simply exposes. https://bugs.winehq.org/show_bug.cgi?id=42284#c1 https://bugs.winehq.org/show_bug.cgi?id=42284#c1 It's from 2017 but it details some of the features that they would need which Wayland does not consider to support.
      - SulfurHexaFluri 6y ago
        The wine situation is kind of unique. Programs should not be able to force their locations, the wayland devs are correct here. The unique issue is trying to map windows apis to wayland. The wine devs are pushing to have wayland implement all of the mistakes in the windows API while the wayland devs want the best possible solution without being chained to the windows api. I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues. In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications.
        Blikkentrekker 6y ago
        > The wine situation is kind of unique. Programs should not be able to force their locations, the wayland devs are correct here. Absolutely not. This is needed for many things, and that you think it can simply be stripped shows your lack of appreciation of the needs of many other users and software. How will you without this for instance make: - a notification daemon that creates a notification bubble at some part of the screen - a toolbar of some sorts that sits at a specific place on the screen and is summoned on command - a collapsible terminal application that summons itself on a certain global hotkey and otherwise lays hidden - any such application that summons itself - a program that rearranges other windows for any particular purpose such as tiling them in a specific way that the user wants All these things obviously exist as of this moment, and are used by many users, and can't be made to work on Wayland because the developers were “correct” according to you in their assumption that none might ever need this. > I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues. Your conviction would be wrong; I've been in the same situation and talked to the Wayland developers and it is they who refuse to implement various features that are highly requæsted based on principle. > In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications. Yes, if it would be only Wine, perhaps, but it's not only Wine — and that you think it's only Wine shows either having never researched the mountain of issues, or willfully ignoring them because these concerns are immediately encountered when researching the issue of developers of many an application who are not pleased that their application fundamentally can't work on Wayland because it endeavored to not include basic functionality that every other display protocol has. These were not “mistakes” — the reason everything from Windows, to X11, to Quartz has these features is because users need them for what they wish to do. And this is only about programs choosing the positions of their own windows. A simple, trivial other thing is every time a new Hearthstone expansion comes out and I buy about 80 new packs with in-game currency that I game insists that I sit through the animations of opening them which bores me. I refuse and rather simply minimize the Hearthstone window and even though it doesn't have focus rapidly send it endless spacebar key events with a trivial xdotool command which then does this in about 15 minutes without needing my attention — such a simple thing cannot be done in Wayland at the moment and most likely never will because “users should not be able to simulate key events” as far as the Wayland developers are concerned, which is obviously a function with many use cases. “Users should not be able to ...” was the mantra of the Wayland developers when they started, and in many cases they have relented and allowed them because they realized they severely underestimated for how many things users do need to do that.
- nradov 6y ago
  That doesn't work in reality because for any large, complex piece of software it's impossible to rediscover all of the requirements. There are always hidden requirements which were never properly documented but somehow ended up as code in the legacy system.
RivieraKid 6y ago
Depends. In my experience, I've never regretted a rewrite and always ended up with a better and simpler code. It can be very frustrating to modify low quality and ugly code so I feel much better after a rewrite.
convolvatron 6y ago
I completely disagree. certainly the chances that a rewrite in a standard software organization are pretty good that the new version will be just as broken, but in a new and different way than the last. but I've taken several projects in the 100s of k-lines and translated them into projects with equivalent functionality and spanning between 1-2 decimal orders of magnitude less source code. that's not an argument for rewriting in all circumstances - I just think at least half of most mature software is just 'junk dna' - useless boilerplate, unused paths, poor abstractions, etc

nchelluri 6y ago

I see your points, and I see the merit of "rewrite syndrome", and lean strongly towards automated-test backed refactoring, and all in all I disagree with your thesis. Sometimes, software patches and new features get tacked on and tacked on and the system loses all semblance of cohesion or integrity. Thinking of the system as a whole, iterating with the confidence brought by tests of some sort, one can begin to detangle all the unncessary intermixing and duplicate work and begin to make the system sensible.

Aeolun 6y ago

Depends. If you can re-evaluate the requirements when you start your rewrite, you can likely consolidate a lot of the features. If the requirements stay exactly the same, then yeah, there’s no point.

Blikkentrekker 6y ago
Well, when Wayland started they went in on the assumption that they could cast away quite a bit that “no one was using” or that “wasn't necessary”. And then they had to include more of what they cast away because they underestimated the number of consumers of things they personally weren't using. libinput originally actually did not have a way to disable and configure pointer acceleration I believe because the developed thought there was no reason to ever turn it off. He was not a gamer and was largely ignorant of how essential being able to disable it is for the level of accuracy required for video games.
- SulfurHexaFluri 6y ago
  Now days Wayland compatible DEs seems to support everything the average user needs while supporting quite a few modern features that were apparently too difficult to support in X11 like monitors with different DPI scales.
  - Blikkentrekker 6y ago
    That you think that would suggest you have a similar lack of appreciation of what users that aren't you need that the developers that went into it had. At this point Wine is still at the point of not considering a Wayland port until some severe changes happen at all — it cannot even begin to map the WinAPI to Wayland as it could to X11 at this point because too many features they need are missing that the developers didn't consider would be necessary for many things that Windows simply exposes. https://bugs.winehq.org/show_bug.cgi?id=42284#c1 https://bugs.winehq.org/show_bug.cgi?id=42284#c1 It's from 2017 but it details some of the features that they would need which Wayland does not consider to support.
    - SulfurHexaFluri 6y ago
      The wine situation is kind of unique. Programs should not be able to force their locations, the wayland devs are correct here. The unique issue is trying to map windows apis to wayland. The wine devs are pushing to have wayland implement all of the mistakes in the windows API while the wayland devs want the best possible solution without being chained to the windows api. I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues. In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications.
      - Blikkentrekker 6y ago
        > The wine situation is kind of unique. Programs should not be able to force their locations, the wayland devs are correct here. Absolutely not. This is needed for many things, and that you think it can simply be stripped shows your lack of appreciation of the needs of many other users and software. How will you without this for instance make: - a notification daemon that creates a notification bubble at some part of the screen - a toolbar of some sorts that sits at a specific place on the screen and is summoned on command - a collapsible terminal application that summons itself on a certain global hotkey and otherwise lays hidden - any such application that summons itself - a program that rearranges other windows for any particular purpose such as tiling them in a specific way that the user wants All these things obviously exist as of this moment, and are used by many users, and can't be made to work on Wayland because the developers were “correct” according to you in their assumption that none might ever need this. > I'm also not convinced there is _nothing_ the wine devs could do to resolve this. They already suggested some ways to deal with the lack of APIs but they refuse to implement them more on principal rather than practical issues. Your conviction would be wrong; I've been in the same situation and talked to the Wayland developers and it is they who refuse to implement various features that are highly requæsted based on principle. > In the end, if only Wine is using xwayland, thats not a particularly bad position to be in and Wayland seems to work well for native linux applications. Yes, if it would be only Wine, perhaps, but it's not only Wine — and that you think it's only Wine shows either having never researched the mountain of issues, or willfully ignoring them because these concerns are immediately encountered when researching the issue of developers of many an application who are not pleased that their application fundamentally can't work on Wayland because it endeavored to not include basic functionality that every other display protocol has. These were not “mistakes” — the reason everything from Windows, to X11, to Quartz has these features is because users need them for what they wish to do. And this is only about programs choosing the positions of their own windows. A simple, trivial other thing is every time a new Hearthstone expansion comes out and I buy about 80 new packs with in-game currency that I game insists that I sit through the animations of opening them which bores me. I refuse and rather simply minimize the Hearthstone window and even though it doesn't have focus rapidly send it endless spacebar key events with a trivial xdotool command which then does this in about 15 minutes without needing my attention — such a simple thing cannot be done in Wayland at the moment and most likely never will because “users should not be able to simulate key events” as far as the Wayland developers are concerned, which is obviously a function with many use cases. “Users should not be able to ...” was the mantra of the Wayland developers when they started, and in many cases they have relented and allowed them because they realized they severely underestimated for how many things users do need to do that.
nradov 6y ago
That doesn't work in reality because for any large, complex piece of software it's impossible to rediscover all of the requirements. There are always hidden requirements which were never properly documented but somehow ended up as code in the legacy system.

RivieraKid 6y ago

Depends. In my experience, I've never regretted a rewrite and always ended up with a better and simpler code. It can be very frustrating to modify low quality and ugly code so I feel much better after a rewrite.

convolvatron 6y ago

I completely disagree. certainly the chances that a rewrite in a standard software organization are pretty good that the new version will be just as broken, but in a new and different way than the last. but I've taken several projects in the 100s of k-lines and translated them into projects with equivalent functionality and spanning between 1-2 decimal orders of magnitude less source code. that's not an argument for rewriting in all circumstances - I just think at least half of most mature software is just 'junk dna' - useless boilerplate, unused paths, poor abstractions, etc