Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
To expand a little bit on this/slight counterpoint: We should all be pushing to make programming less elitist and more accepting (We have to... there aren't enough of us to go around). Also, I think Python is a great and flexible language, no hate from that end... I just feel the quote gets misused haha!
Insisting on one way, or writing a language/framework that only accepts one way to do something is harmful. It restricts expression at the cost of standardization, and increases the likelihood of bugs when someone doesn't have all the rules memorized. It also means it's harder to get that ONE answer in the sea of possible answers. All of these things prevent new engineers from succeeding.
Repetitive failure is demoralizing. Eventually you just give up. Programmers in the 70's and 80's weren't inherently smarter or better than today's programmers, they were just the last people standing after attrition took the ones that couldn't memorize all the commandments inherent in bare-metal and low-level instruction sets.
There's a reason we developed C++, then Java, then Python, then Node, then X. There's a reason the JavaScript frameworks keep changing. There's a reason that when you convert from Java 1.3 to 12 you remove a ton of code (I think that was what I was seeing in the GIF from that tweet today :D).
That reason for all this change is developer quality of life and accessibility for incoming users. When we start saying (or designing languages and frameworks to follow) "there should be only one way of doing a thing" we're stepping back, not forward.
Are there objectively "wrong" ways of doing something? Of course... but we need to make sure we have concrete reasons (code smells, side-effects, design patterns, common algorithms, Big-O etc) to explain it, or it's really just personal opinion.
When we start running teams with that expectation, or writing new languages that way, our opinionated product is now less accessible to the guy who just took his first programming course and just wants to solve problems using the magic mystery box running at his desk :D
(Additional disclaimer.... it IS also possible to go too far in the other direction... Andrew is right about that!)
I think everything you've mentioned is on point! That said, I would like to clarify exactly what I was imagining when Ben used the phrase: "there should be only one way of doing a thing."
In language design, we should try to avoid bloat whenever possible. When I think of bloated languages, I think of languages that have been around for awhile that never really deprecated anything (C++ comes to mind). As a result, these bloated languages have a certain amount of complexity that has to be reigned in by people—instead of by the languages. Setting up standards and whatnot take time, and it would be nice if the languages themselves stuck to a niche.
To your point, I wouldn't advocate for telling people in general that there's only one way to do things. That's textbook elitism. But from a language design standpoint, I think it makes sense to limit language complexity.
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
Absolutely! I actually think we're in complete agreement and just approaching it from two different angles. I just got inspired to throw my angle in there to keep discussion alive/offer a different perspective.
It started as a standalone post, but I saw you'd touched on it and figured it was better as a reply/part of a discussion than a standalone haha!
To expand a little bit on this/slight counterpoint: We should all be pushing to make programming less elitist and more accepting (We have to... there aren't enough of us to go around). Also, I think Python is a great and flexible language, no hate from that end... I just feel the quote gets misused haha!
Insisting on one way, or writing a language/framework that only accepts one way to do something is harmful. It restricts expression at the cost of standardization, and increases the likelihood of bugs when someone doesn't have all the rules memorized. It also means it's harder to get that ONE answer in the sea of possible answers. All of these things prevent new engineers from succeeding.
Repetitive failure is demoralizing. Eventually you just give up. Programmers in the 70's and 80's weren't inherently smarter or better than today's programmers, they were just the last people standing after attrition took the ones that couldn't memorize all the commandments inherent in bare-metal and low-level instruction sets.
There's a reason we developed C++, then Java, then Python, then Node, then X. There's a reason the JavaScript frameworks keep changing. There's a reason that when you convert from Java 1.3 to 12 you remove a ton of code (I think that was what I was seeing in the GIF from that tweet today :D).
That reason for all this change is developer quality of life and accessibility for incoming users. When we start saying (or designing languages and frameworks to follow) "there should be only one way of doing a thing" we're stepping back, not forward.
Are there objectively "wrong" ways of doing something? Of course... but we need to make sure we have concrete reasons (code smells, side-effects, design patterns, common algorithms, Big-O etc) to explain it, or it's really just personal opinion.
When we start running teams with that expectation, or writing new languages that way, our opinionated product is now less accessible to the guy who just took his first programming course and just wants to solve problems using the magic mystery box running at his desk :D
(Additional disclaimer.... it IS also possible to go too far in the other direction... Andrew is right about that!)
I think everything you've mentioned is on point! That said, I would like to clarify exactly what I was imagining when Ben used the phrase: "there should be only one way of doing a thing."
In language design, we should try to avoid bloat whenever possible. When I think of bloated languages, I think of languages that have been around for awhile that never really deprecated anything (C++ comes to mind). As a result, these bloated languages have a certain amount of complexity that has to be reigned in by people—instead of by the languages. Setting up standards and whatnot take time, and it would be nice if the languages themselves stuck to a niche.
To your point, I wouldn't advocate for telling people in general that there's only one way to do things. That's textbook elitism. But from a language design standpoint, I think it makes sense to limit language complexity.
Absolutely! I actually think we're in complete agreement and just approaching it from two different angles. I just got inspired to throw my angle in there to keep discussion alive/offer a different perspective.
It started as a standalone post, but I saw you'd touched on it and figured it was better as a reply/part of a discussion than a standalone haha!
Great stuff, Scott! Happy to chat with you.