> 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
[2] https://programmingisterrible.com/post/176657481103/repeat-y...
[3] https://www.youtube.com/watch?v=bmSAYlu0NcY
