4 ms·

Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. And then that person leave

Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. And then that person leaves the company and no one else truly understands how it works or was meant to be used so it gets a series of hacks and patches applied to it which violate the original design which is known by no one at the company. For most projects this is not that big of a deal, the component gradually becomes less coherent and the original requirements change so much that one day someone will decide that the whole thing will be rewritten from scratch.

thumbuddy 3y ago
And this is why Go lang exists... The trade off is screw brilliant engineering just make it simple so other people can build on it easily. Not saying it's my favorite, but it has it's merits long term.
- AdieuToLogic 3y ago
  A semantically weak language does not reduce the inherent complexity of a system, as problem complexity is constant. What Go does is encode solution complexity implicitly throughout a code base. This is the same effect JavaScript often has.
  - whstl 3y ago
    Go isn't my favourite language, but I disagree with that: a language being being simple does wonders to reduce the possibilities of accidental complexity added by complicated features that are unnecessary for the business. But of course it's still possible to make a mess: I've seen someone who created an ad-hoc object model (with its own structs, plus multiple inheritance and all) on top of Golang and wrote a few apps in that style. But not having the features in the first place can help.
    - kaba0 3y ago
      Then why not assembly is the ideal program language? Ad absurdum, that’s the simplest, isn’t it? Each line does something completely trivial. Abstraction is the only tool we have to even hope to manage complexity. Unfortunately there is no way to force good abstractions, finding out the perfect abstraction is the deal of the art. Maybe I’m wrong on this, but I’m on the elitist view that the industry really shouldn’t try to replace a single senior developer with 10 juniors that monkey patch based on stackoverflow/chatgpt. I don’t even see how that makes financial sense, if one values product quality.
      - whstl 3y ago
        Because, obviously, too little abstraction is as bad as too much abstraction. The way to combat excess is not with more excess. There are no automated to enforce good abstractions, but languages and tools can serve as a way to shepherd programmers into avoiding or preferring certain patterns. This is an argument as old as the programming language field itself. For some people Golang strikes a good balance. I'm not one of those people, but I have learned to respect it.
      - thumbuddy 3y ago
        Assembly is a lot harder to write correctly/safely than go lang is. Comparing the two seems disingenuous. I do agree with you to some extent about not replacing senior engineers. But a "bad" senior engineer who is "too smart" for their own good can do more damage then juniors following a template. All things in balance for sure.
    - unconed 3y ago
      I find Go bizarre... 90% of the code written in it seems to consist of checking for errors and passing them around. And yet, every time I've had to interoperate with somebody's Go code, it falls apart immediately because of significant processing errors that it seems like somebody should've caught, like a null-pointer dereference, or a wrong lookup into a map, or a (de)serialization error. _Every time_ the programmer responsible seems blissfully unaware of the possibility of said error and I need to provide a test case for them to reproduce it. Their mental model of the code they think they wrote is wrong compared to the actual code. The culprit is usually something like an `interface{}`, granted, which people then excuse as being un-Go-like... but if all the language's supposed ease and robustness fails as soon as it encounters anything outside of its own ecosystem, then it's not worth much. All the busywork around errors starts to look like a cargo cult to make the juniors feel like they're accomplishing things when they're just glueing things together. No other language I've seen has it so bad. Rust is particularly good in this area, and seems to view it as its own responsibility to interoperate cleanly, providing sane and powerful ways to opt-in/out of Rust's semantics at the edges. Even TypeScript makes it easy to partially or gradually type when you need to, and this seems much safer in practice to me.
      - thumbuddy 3y ago
        I personally prefer rust over go as well. That said, some rust code is genuinely scary in a way where you do have to wonder if anyone else could maintain it without rewriting it themselves. There's a lot of complexity that although is visible in the syntax is too much for anyone to keep a mental model of - at a certain level of complexity. Kindly written rust is fine, same goes for a lot of languages. The issue is, sometimes really smart people have no interest in kindness. There are a lot of social factors that go into people writing monstrosities "gotta look smarter!" "Gotta have job security!" "Don't want anyone to call me out on this". I write dumb code 99 percent of the time. I'll never get promoted for it, but people know exactly what it's doing.
spondyl 3y ago
For anyone interested in a discussion about the concept of systems not being understood by newcomers, I can recommend Peter Naur's Programming as Theory Building: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
- mikmoila 3y ago
  Right to the spot, thanks for sharing this! I've always thought that having a decision log of justifying design/implementation choices which are somehow surprising would be healthy thing to do.
- kaba0 3y ago
  Just commented the exact same thing without checking if someone else also posted, because it is not that well known for some reason.
whstl 3y ago
That's often the rationalization for most "perfect" and "ultimately reusable" code I see, however what I've seen too many times is code that ended up turning into shit even when the creator remained the sole maintainer. Blame often gets passed upwards to some product manager or sales coming up with some outlandish business requirement, but honestly the real reason is that the code wasn't that flexible to begin with. Which is perfectly fine, not all code can be flexible and infinitely reusable. Perhaps we should stop forcing every single file to be.
quietbritishjim 3y ago
> Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. Very rarely is that good code, even if you actually do understand the design. Most of the time, when you come to extend it, it turns out to be in a slightly different way than the original author had expected. Now you've got the complexity of solving the original problem (inevitably) and the new problem (also inevitable) and also some other problem that might have needed solving but didn't after all (not inevitable). Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. That doesn't mean you can't create reusable abstractions - doing so often does make the code simpler even for just its current job. And that usually ends up aligning quite nicely with what turns out to be (almost) what is needed for other tasks anyway.
- The_Colonel 3y ago
  I agree wholeheartedly. Code which is "designed to be extensible towards future use cases" very often expects the wrong kinds of extensions and actually makes it more difficult to extend it because it's necessarily more complicated. > Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. Very much this.
  - K0balt 3y ago
    The exception here I think is the choice of data structure. If you know that code will be extended to accept additional fields it makes sense to be sure to use an extensible data structure or to ensure that side effects are contained correctly (a good idea anyway) and in a way that allows extensibility when they must be changed.
    - The_Colonel 3y ago
      > If you know that code will be extended to accept additional fields Well, you rarely know, more often "guess". There's an important distinction between public and private interfaces. With public interfaces, I contend that it does make sense to think about future use cases and put in some flexibility even at the cost of a small overhead.
deleted 3y ago
[deleted]
dingi 3y ago
This is true if you assume that the abstractions identified by the original author is correct and adequate for the life of that app. Usually, it's not the case. There are slight deviations that makes previous abstractions unusable for new requirements and the new dev has to start from the beginning

thumbuddy 3y ago

And this is why Go lang exists... The trade off is screw brilliant engineering just make it simple so other people can build on it easily. Not saying it's my favorite, but it has it's merits long term.

AdieuToLogic 3y ago
A semantically weak language does not reduce the inherent complexity of a system, as problem complexity is constant. What Go does is encode solution complexity implicitly throughout a code base. This is the same effect JavaScript often has.
- whstl 3y ago
  Go isn't my favourite language, but I disagree with that: a language being being simple does wonders to reduce the possibilities of accidental complexity added by complicated features that are unnecessary for the business. But of course it's still possible to make a mess: I've seen someone who created an ad-hoc object model (with its own structs, plus multiple inheritance and all) on top of Golang and wrote a few apps in that style. But not having the features in the first place can help.
  - kaba0 3y ago
    Then why not assembly is the ideal program language? Ad absurdum, that’s the simplest, isn’t it? Each line does something completely trivial. Abstraction is the only tool we have to even hope to manage complexity. Unfortunately there is no way to force good abstractions, finding out the perfect abstraction is the deal of the art. Maybe I’m wrong on this, but I’m on the elitist view that the industry really shouldn’t try to replace a single senior developer with 10 juniors that monkey patch based on stackoverflow/chatgpt. I don’t even see how that makes financial sense, if one values product quality.
    - whstl 3y ago
      Because, obviously, too little abstraction is as bad as too much abstraction. The way to combat excess is not with more excess. There are no automated to enforce good abstractions, but languages and tools can serve as a way to shepherd programmers into avoiding or preferring certain patterns. This is an argument as old as the programming language field itself. For some people Golang strikes a good balance. I'm not one of those people, but I have learned to respect it.
    - thumbuddy 3y ago
      Assembly is a lot harder to write correctly/safely than go lang is. Comparing the two seems disingenuous. I do agree with you to some extent about not replacing senior engineers. But a "bad" senior engineer who is "too smart" for their own good can do more damage then juniors following a template. All things in balance for sure.
  - unconed 3y ago
    I find Go bizarre... 90% of the code written in it seems to consist of checking for errors and passing them around. And yet, every time I've had to interoperate with somebody's Go code, it falls apart immediately because of significant processing errors that it seems like somebody should've caught, like a null-pointer dereference, or a wrong lookup into a map, or a (de)serialization error. _Every time_ the programmer responsible seems blissfully unaware of the possibility of said error and I need to provide a test case for them to reproduce it. Their mental model of the code they think they wrote is wrong compared to the actual code. The culprit is usually something like an `interface{}`, granted, which people then excuse as being un-Go-like... but if all the language's supposed ease and robustness fails as soon as it encounters anything outside of its own ecosystem, then it's not worth much. All the busywork around errors starts to look like a cargo cult to make the juniors feel like they're accomplishing things when they're just glueing things together. No other language I've seen has it so bad. Rust is particularly good in this area, and seems to view it as its own responsibility to interoperate cleanly, providing sane and powerful ways to opt-in/out of Rust's semantics at the edges. Even TypeScript makes it easy to partially or gradually type when you need to, and this seems much safer in practice to me.
    - thumbuddy 3y ago
      I personally prefer rust over go as well. That said, some rust code is genuinely scary in a way where you do have to wonder if anyone else could maintain it without rewriting it themselves. There's a lot of complexity that although is visible in the syntax is too much for anyone to keep a mental model of - at a certain level of complexity. Kindly written rust is fine, same goes for a lot of languages. The issue is, sometimes really smart people have no interest in kindness. There are a lot of social factors that go into people writing monstrosities "gotta look smarter!" "Gotta have job security!" "Don't want anyone to call me out on this". I write dumb code 99 percent of the time. I'll never get promoted for it, but people know exactly what it's doing.

spondyl 3y ago

For anyone interested in a discussion about the concept of systems not being understood by newcomers, I can recommend Peter Naur's Programming as Theory Building: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf

mikmoila 3y ago
Right to the spot, thanks for sharing this! I've always thought that having a decision log of justifying design/implementation choices which are somehow surprising would be healthy thing to do.
kaba0 3y ago
Just commented the exact same thing without checking if someone else also posted, because it is not that well known for some reason.

whstl 3y ago

That's often the rationalization for most "perfect" and "ultimately reusable" code I see, however what I've seen too many times is code that ended up turning into shit even when the creator remained the sole maintainer. Blame often gets passed upwards to some product manager or sales coming up with some outlandish business requirement, but honestly the real reason is that the code wasn't that flexible to begin with. Which is perfectly fine, not all code can be flexible and infinitely reusable. Perhaps we should stop forcing every single file to be.

quietbritishjim 3y ago

> Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. Very rarely is that good code, even if you actually do understand the design. Most of the time, when you come to extend it, it turns out to be in a slightly different way than the original author had expected. Now you've got the complexity of solving the original problem (inevitably) and the new problem (also inevitable) and also some other problem that might have needed solving but didn't after all (not inevitable). Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. That doesn't mean you can't create reusable abstractions - doing so often does make the code simpler even for just its current job. And that usually ends up aligning quite nicely with what turns out to be (almost) what is needed for other tasks anyway.

The_Colonel 3y ago
I agree wholeheartedly. Code which is "designed to be extensible towards future use cases" very often expects the wrong kinds of extensions and actually makes it more difficult to extend it because it's necessarily more complicated. > Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. Very much this.
- K0balt 3y ago
  The exception here I think is the choice of data structure. If you know that code will be extended to accept additional fields it makes sense to be sure to use an extensible data structure or to ensure that side effects are contained correctly (a good idea anyway) and in a way that allows extensibility when they must be changed.
  - The_Colonel 3y ago
    > If you know that code will be extended to accept additional fields Well, you rarely know, more often "guess". There's an important distinction between public and private interfaces. With public interfaces, I contend that it does make sense to think about future use cases and put in some flexibility even at the cost of a small overhead.

deleted 3y ago

[deleted]

dingi 3y ago

This is true if you assume that the abstractions identified by the original author is correct and adequate for the life of that app. Usually, it's not the case. There are slight deviations that makes previous abstractions unusable for new requirements and the new dev has to start from the beginning