4 ms·

I'm not sure why you think that quoting random HN users proves anything except personal opinions of specific people? These are fine, but other people have other

I'm not sure why you think that quoting random HN users proves anything except personal opinions of specific people? These are fine, but other people have other opinions. I don't oppose the "principles" you've quoted, but they would just as easily apply to e.g. Haskell (maybe except for the "there's only one way to do it" which however has never been true of any language, including Python). I feel like you missed my larger point. It's not terribly difficult to write code that you can understand line by line. It's incredibly hard to write a huge code base in a way that you can reason about many code paths simultaneously, however. That's where the abstractions start to make sense. I don't understand why people think that those facilities were created just to piss people off? People were facing real problems. Yes, sometimes the cure is worse than the disease. Use abstractions judiciously and by employing common sense. That doesn't mean you should never use them. I've seen over- and underabstracted code (as well as just plain wrongly abstracted code). Both of these situations really suck. Honestly, what annoys me a bit here is your smugness. It seems as if you feel you've figured out how to write good code, and all the other idiots who use Ruby, Java, etc. haven't. But I don't believe you. Nobody in this industry knows how to write "good" code. I don't even think we know what "good" code is. The most we can do is try our best, learn about better ways to do things, discuss approaches and use our judgment.

bborud 3y ago
> I'm not sure why you think that quoting random HN users proves anything Does it have to? How do you prove that what someone expresses is something other than opinion when it comes to programming practices? This isn't a field that is easy to quantify or distill into unquestionable truth. To approach anything nearing proof we'd need data from which clear conclusions can be drawn. A look at scientific publishing on a lot of these topics suggests that "proof" is going to be hard to come by for a lot of the things discussed here. > but other people have other opinions. Not all opinions count equally to all people. In fact, most people's opinions don't matter. However we do tend to value the opinions of people who are able to properly articulate reasonable arguments based on demonstrable results or experience.
- Tainnor 3y ago
  I'm not looking for rigorous proof, but these are just cherry-picked example quotes instead of a coherent argument. You could just as well quote people who have experience dealing with code that is "not clever enough", e.g. 1000 line files without any internal structure. What does that show? Writing code is about tradeoffs and not about pithy truisms lime "code should be obvious".
  - bborud 3y ago
    So if it isn't about trying to make things obvious, what do you think the goal is?
    - Tainnor 3y ago
      Huge code bases are never gonna be "obvious". It's all about optimising for a balance of tradeoffs.
      - bborud 3y ago
        So you claim that beyond some magic size limit a codebase cannot be easy to understand. Well, quantify it. At what number of lines of code does a codebase pass from the domain where it is possible to easily understand it to where it is impossible? I suspect you didn't pay any attention to what I wrote about how people go about ensuring that large codebases maintain readability. That saddens me a bit because it means you probably aren't interested in learning anything.
        Tainnor 3y ago
        This is just an incredibly bad faith reply, and an insulting one at that. I don't know why you felt the need to cross into personal territory, but I will make a mental note not to engage with you again. PS, please check my comment history before claiming that "I'm not interested in learning anything".
        3y ago
Mawr 3y ago
> I'm not sure why you think that quoting random HN users proves anything except personal opinions of specific people? These are fine, but other people have other opinions. They support my argument so I included them. I don't see a practical difference between a "random HN user" and a random blog post or anything else. A good idea is a good idea, regardless of the medium. --- > I don't oppose the "principles" you've quoted, but they would just as easily apply to e.g. Haskell Possibly, I threw it together pretty quickly, so it's not very thought-out. I'm also not familiar enough with Haskell to know what you mean. --- > (maybe except for the "there's only one way to do it" which however has never been true of any language, including Python). It's not binary, but a spectrum. No language has just literally one way to express each concept. However, Python is definitely further towards the "one way to do it" end of the scale. Perhaps not as much these days as it used to, but still far more than for example Ruby or Perl. --- > I feel like you missed my larger point. It's not terribly difficult to write code that you can understand line by line. It's incredibly hard to write a huge code base in a way that you can reason about many code paths simultaneously, however. That's where the abstractions start to make sense. I thought I adressed that; everything I mentioned - explicit error returns, pure functions, no global state, and no metaprogramming - all show their true worth in large and/or unfamiliar codebases. --- > I don't understand why people think that those facilities were created just to piss people off? People were facing real problems. Yes, sometimes the cure is worse than the disease. Use abstractions judiciously and by employing common sense. That doesn't mean you should never use them. I'm not sure what exactly you mean by abstractions, so this is hard to respond to. --- > I've seen over- and underabstracted code (as well as just plain wrongly abstracted code). Both of these situations really suck. Both suck, but as far as I can tell, erring on the side of underabstracting is better. Some random references (not HN comments ;>): [1] [2]. > Honestly, what annoys me a bit here is your smugness. ;) I can either post something quick but smug or spend hours polishing it until it's as bland as can be. I prefer the quick and authentic approach. --- > It seems as if you feel you've figured out how to write good code, Not even close. --- > and all the other idiots who use Ruby, Java, etc. haven't. I'm definitely not calling people who program in <x> language idiots. There are far too many factors at play to be able to make such a broad judgement. --- > Nobody in this industry knows how to write "good" code. I don't even think we know what "good" code is. I'd certainly hope that in the last half a century of programming we have at least learned something! A video (and book) you may enjoy: [3]. --- > The most we can do is try our best, learn about better ways to do things, discuss approaches and use our judgment. I thought that's what we were doing. --- [1] https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction [2] https://programmingisterrible.com/post/176657481103/repeat-yourself-do-more-than-one-thing-and https://programmingisterrible.com/post/176657481103/repeat-y... [3] https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY

bborud 3y ago

> I'm not sure why you think that quoting random HN users proves anything Does it have to? How do you prove that what someone expresses is something other than opinion when it comes to programming practices? This isn't a field that is easy to quantify or distill into unquestionable truth. To approach anything nearing proof we'd need data from which clear conclusions can be drawn. A look at scientific publishing on a lot of these topics suggests that "proof" is going to be hard to come by for a lot of the things discussed here. > but other people have other opinions. Not all opinions count equally to all people. In fact, most people's opinions don't matter. However we do tend to value the opinions of people who are able to properly articulate reasonable arguments based on demonstrable results or experience.

Tainnor 3y ago
I'm not looking for rigorous proof, but these are just cherry-picked example quotes instead of a coherent argument. You could just as well quote people who have experience dealing with code that is "not clever enough", e.g. 1000 line files without any internal structure. What does that show? Writing code is about tradeoffs and not about pithy truisms lime "code should be obvious".
- bborud 3y ago
  So if it isn't about trying to make things obvious, what do you think the goal is?
  - Tainnor 3y ago
    Huge code bases are never gonna be "obvious". It's all about optimising for a balance of tradeoffs.
    - bborud 3y ago
      So you claim that beyond some magic size limit a codebase cannot be easy to understand. Well, quantify it. At what number of lines of code does a codebase pass from the domain where it is possible to easily understand it to where it is impossible? I suspect you didn't pay any attention to what I wrote about how people go about ensuring that large codebases maintain readability. That saddens me a bit because it means you probably aren't interested in learning anything.
      - Tainnor 3y ago
        This is just an incredibly bad faith reply, and an insulting one at that. I don't know why you felt the need to cross into personal territory, but I will make a mental note not to engage with you again. PS, please check my comment history before claiming that "I'm not interested in learning anything".
        3y ago

Mawr 3y ago

> I'm not sure why you think that quoting random HN users proves anything except personal opinions of specific people? These are fine, but other people have other opinions. They support my argument so I included them. I don't see a practical difference between a "random HN user" and a random blog post or anything else. A good idea is a good idea, regardless of the medium. --- > I don't oppose the "principles" you've quoted, but they would just as easily apply to e.g. Haskell Possibly, I threw it together pretty quickly, so it's not very thought-out. I'm also not familiar enough with Haskell to know what you mean. --- > (maybe except for the "there's only one way to do it" which however has never been true of any language, including Python). It's not binary, but a spectrum. No language has just literally one way to express each concept. However, Python is definitely further towards the "one way to do it" end of the scale. Perhaps not as much these days as it used to, but still far more than for example Ruby or Perl. --- > I feel like you missed my larger point. It's not terribly difficult to write code that you can understand line by line. It's incredibly hard to write a huge code base in a way that you can reason about many code paths simultaneously, however. That's where the abstractions start to make sense. I thought I adressed that; everything I mentioned - explicit error returns, pure functions, no global state, and no metaprogramming - all show their true worth in large and/or unfamiliar codebases. --- > I don't understand why people think that those facilities were created just to piss people off? People were facing real problems. Yes, sometimes the cure is worse than the disease. Use abstractions judiciously and by employing common sense. That doesn't mean you should never use them. I'm not sure what exactly you mean by abstractions, so this is hard to respond to. --- > I've seen over- and underabstracted code (as well as just plain wrongly abstracted code). Both of these situations really suck. Both suck, but as far as I can tell, erring on the side of underabstracting is better. Some random references (not HN comments ;>): [1] [2]. > Honestly, what annoys me a bit here is your smugness. ;) I can either post something quick but smug or spend hours polishing it until it's as bland as can be. I prefer the quick and authentic approach. --- > It seems as if you feel you've figured out how to write good code, Not even close. --- > and all the other idiots who use Ruby, Java, etc. haven't. I'm definitely not calling people who program in <x> language idiots. There are far too many factors at play to be able to make such a broad judgement. --- > Nobody in this industry knows how to write "good" code. I don't even think we know what "good" code is. I'd certainly hope that in the last half a century of programming we have at least learned something! A video (and book) you may enjoy: [3]. --- > The most we can do is try our best, learn about better ways to do things, discuss approaches and use our judgment. I thought that's what we were doing. --- [1] https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction [2] https://programmingisterrible.com/post/176657481103/repeat-yourself-do-more-than-one-thing-and https://programmingisterrible.com/post/176657481103/repeat-y... [3] https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY