What do you think about the idea that "there should be only one way of doing a thing" in programming languages?
For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (60)
Gotta go against this.
I like a balance. Too many options makes it hard to define best practices but too few doesn't allow breathing room for edge cases.
🤮
The “way of working” is whatever a team decides is the way to work (well-informed or not). A programming language is usually flexible enough to allow for multiple ways of working. It doesn’t have to dictate solely how we work.
Personally, I love it. Ever since I picked up Python, I've been thankful for this idea since it makes the language so much easier to work with. After all, once you know the idioms, solutions to common problems start to feel obvious.
Of course, idioms can act as a barrier to entry, and some people can leverage that fact as a form of gatekeeping. In addition, I think the lack of flexibility can work to the languages detriment in some cases.
That said, in a language like C++, the lack of "there should only be one way of doing a thing" makes the language ridiculously complex. If you asked two people to solve the same problem, you can end up with wildly different solutions. To me, that's a problem because there's no unity in problem solving. In other words, good luck getting help from your favorite search engine.
In addition, without a "one way to do it" mindset, people are free to mix and match syntax which I find to be error prone. Of course, some people prefer the flexibility, and that may pay off from an optimization point of view.
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.
If there is only one way of doing something and it's the right way to do something, then it's "problem solved" and you can move on to the next issue.
Like when you learn to walk, once you've mastered it, you've got it forever right. Then you can move on to running or jumping etc.
So I supposed when standards are formed, your tool-sets or ides etc. can also take advantage of the fact that it's a proven solution.
I think it depends - if there was only one way to do everything in programming, it would kill innovation and fun, but I see where it would be useful.
If you are trying to do something mission critical and very important (think encryption, security, etc...) there should only be one way that is adopted. This would mean that there would be less need to try and implement custom security code that probably won't be as secure as the "adopted standard" if there was only one way.
For anything else, I think its fine to have more than one way to do things. I think its situational, and there is room for both in programming.
That's the reason that i'm using Go 👨💻
The idea of "one way to do things" originated from the Zen of Python. This quote has been taken out of context and distorted, here is the original
I think the rule makes sense as it was originally stated. Strive for one way, make it obvious, don't beat yourself up if it's not possible.
Creating one obvious way to succeed sounds an awful lot like designing a Pit of Success:
What a great link! I had never heard of a pit of success before, but I’m on board. In terms of pits of despair, C++ was the exact language that came to mind when I jumped in on this thread.
I personally would give C/C++ a pass. It's a foundational/architectural language, so it should be flexible and shouldn't hold the programmer's hand. I don't think C++ is a language that needs to be fixed. But I do think it's a language that not just anyone should use.
But for higher-level languages like Python, Ruby, PHP and the .NET variants, I would agree that having one obvious way to do things is the best policy.
I’d definitely give C a pass! I feel like it’s a pretty straightforward language. You just have to do everything yourself. Haha
Snipe: if only they kept that philosophy to package management.
::ducks::
That shit is a disaster. I don’t really use python and that’s definitely a contributing factor. Why should I have to use venv?
Totally agree. I love python and is often my goto. But its been so bad for so long. It IS getting better. pyenv/pipenv make it way better for one. pipenv still isn't what you need if you are publishing libraries on pypi, but I think its a good start in the right direction.
The packaging should be built in. To me, Rust/Cargo so far has some of the best packaging around.
Programming is about solving problems, people solve problems based on the way they think and the way their minds operate, and people minds operate differently.
So the "one way" is not so preferable for me in programming.
As long as the problem is solved, and functioning well; then i think we will be good.
But in the case of a team, some broad line should be followed just to make sure everyone are on the same page.
For me i find a great pleasure when checking different solutions for one problem, it's so fascinating, and that what makes programming fun.
Maybe I don't understand the concept. But I think there are few problems to solve where there is only one right approach to the solution. Maybe the exact same problem, with the exact same context, can be approached with an only way of solving it.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.