4 ms·

I agree. But hindsight is a very cushy position to look back from. Making said decision at any given point in time during the development is harder. Should I ad

I agree. But hindsight is a very cushy position to look back from. Making said decision at any given point in time during the development is harder. Should I add a simple support for functions because I need to express something the DSL doesn’t support or should I replace everything and replace it with a complete new solution and added complexity. I mean these decisions tend to become very clear a few month/years down the line. The dangerous path of not doing a needed refactor early is that with added time, it can become more and more difficult to do the refactor at a later point. Could be because of sheer size, or because there are no test specs or because the feature is public facing.

lifthrasiir 3y ago
I totally agree that you can't decide whether a refactoring is required or not for quite a long time. But this language has been around for more than 2 decades, and documented since 2001 [1]. Moreover all main issues were already present at that point and even more options and features were added since then (e.g. `%:sanitizer()` should have been added after sanitizers themselves, i.e. 2012). I think 21 years are long enough to do something about it. [1] https://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC18 https://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC18
- larusso 3y ago
  Again no argument there. Don’t want to imply the intend of the parent comment but I hear it quite often at work that new people come into projects etc and declare statements backed by virtue of looking at all the facts long after all decisions had been made. I think with projects like GCC any decision should be waited for the long game. In commercial software the pesky labor and maintenance cost also become a factor :(
  - lifthrasiir 3y ago
    That's indeed a good point, as I too have been both culprit and victim of this issue. My general sentiment was that this is mostly about management, i.e. how to manage complexity, and this apparent failure can make a good counterexample, but I was not careful enough to put a disclaimer that GCC may have a totally good reason to leave it as is (if it's the case, the reason is probably that only a small number of people will ever work with this language). Thank you for explicitly voicing that concern.

lifthrasiir 3y ago

I totally agree that you can't decide whether a refactoring is required or not for quite a long time. But this language has been around for more than 2 decades, and documented since 2001 [1]. Moreover all main issues were already present at that point and even more options and features were added since then (e.g. `%:sanitizer()` should have been added after sanitizers themselves, i.e. 2012). I think 21 years are long enough to do something about it. [1] https://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC18 https://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC18

larusso 3y ago
Again no argument there. Don’t want to imply the intend of the parent comment but I hear it quite often at work that new people come into projects etc and declare statements backed by virtue of looking at all the facts long after all decisions had been made. I think with projects like GCC any decision should be waited for the long game. In commercial software the pesky labor and maintenance cost also become a factor :(
- lifthrasiir 3y ago
  That's indeed a good point, as I too have been both culprit and victim of this issue. My general sentiment was that this is mostly about management, i.e. how to manage complexity, and this apparent failure can make a good counterexample, but I was not careful enough to put a disclaimer that GCC may have a totally good reason to leave it as is (if it's the case, the reason is probably that only a small number of people will ever work with this language). Thank you for explicitly voicing that concern.