DEV Community

What do you think about the idea that "there should be only one way of doing a thing" in programming languages?

Ben Halpern on June 21, 2019

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

There should be one-- and preferably only one --obvious way to do it.

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.

Dave Jacoby • Jun 22 '19

Snipe: if only they kept that philosophy to package management.

::ducks::

Ryland G • Jun 22 '19

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?

Shawn McElroy • Jun 22 '19

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.

Josh Pullen • Jun 22 '19 • Edited

Creating one obvious way to succeed sounds an awful lot like designing a Pit of Success:

I've often said that a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things.

Jeremy Grifski • Jun 22 '19

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.

Jason Huebel • Jun 22 '19

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.

Jeremy Grifski • Jun 22 '19

I’d definitely give C a pass! I feel like it’s a pretty straightforward language. You just have to do everything yourself. Haha

JavaScript Joel • Jun 21 '19

Part of the success of React is they didn't dictate how anything should be done. They made a few recommendations, like FLUX and instead the people chose Redux.

This flexibility, while being chaotic, allowed a survival-of-the-fittest design to grow naturally.

This is also the reason I abandoned Angular 1 for React.

Orlando Brown • Jun 24 '19

Hahaha it's not just me then!!
That said I'm always curious to see how Angular is progressed since I used Angular 1. But when I look, I get distracted by Vue's similar yet simpler API.

Stephen Belovarich • Jun 21 '19 • Edited

🤮

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.

Andrew Brooks 👨‍💻 • Jun 21 '19

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.

Dustin King • Jun 21 '19

I think there's a benefit to there being one obvious way to do something. However this can become restrictive, and programming languages should also support doing things a different way when you want to. Just like natural languages, programming languages are means of expression, and they do have conventions, but should also allow for a lot of flexibility in how ideas are expressed.

Jeremy Grifski • Jun 21 '19

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.

Scott Yeatts • Jun 22 '19

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!)

Jeremy Grifski • Jun 22 '19 • Edited

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.

Scott Yeatts • Jun 22 '19

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!

Jeremy Grifski • Jun 22 '19

Great stuff, Scott! Happy to chat with you.

Thibaud Ducasse • Jun 22 '19

In some languages (I'd say python), the most idiomatic way of doing things will also be the best for performance. And understanding the way the language expects you to write code is a big part of writing good code.

But sometimes, because they optimise the language for the most common 99% of the use cases, you end up having to write something else, more convoluted, but more performant.

I think it's not so much about having just one way, but more about teaching people that this should be the way unless you need X or Y.

Reminds of when eslint starts yelling at you but you add //eslint-disable to the line because "yes I know but in this case I need to".

Heiker • Jun 21 '19 • Edited

Is not a terrible idea.

In PHP you can append an item to an array in two ways

$arr = [];

// like this
array_push($arr, 1);

// or this
$arr[] = 2;

// PHP, why would you do that to yourself?

It certainly could help avoid meaningless discussions. Not so long ago the javascript twitterverse got mad because apparently reduce is like 500 times slower than a for loop, and of course the performance people was all over the place saying: stop using reduce, your killing your app. Think about the children!!

Might also lead to less bugs, because there are less "tricky parts." Consider this javascript object:

const shape = {
  radius: 10,
  diameter() {
    return this.radius * 2;
  },
  perimeter: () => 2 * Math.PI * this.radius
};

shape.diameter();
shape.perimeter();

Even though diameter and perimeter are "methods" one of them raises an error.

Aryamaan08 • Dec 21 '20

Apparently, they like to do things in 2 ways, because they have 2 ways of adding a single-line comment.

Prahlad Yeri • Jun 21 '19 • Edited

Its a good thing actually because it makes a coder's life easier. A hundred ways of defining a classes can easily drive you mad, the loathsome attitude of several JavaScript developers is the blessed proof of that!

But having said that, there could be some benefit in having two or more ways if they achieve some purpose like both targeting catering to different levels of coding expertise. You can use express.js for handling web requests, for instance, or you can do the whole thing purely in node.js by doing the hard work. But that's more like creating abstraction of an existing thing than creating another way of doing the same thing.

Sara °°° • Jun 21 '19

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.

AndyRosenberg • Jun 22 '19 • Edited

I understand why others might enjoy a highly opinionated language, but to me, this would suck all the joy and creativity out of programming.

My way of thinking about a problem may not be the same as yours. I should have the freedom of expression to carry out the implementation unique to my thought process, so long as it’s clean and understandable.

Kasey Speakman • Jun 22 '19

It intuitively seems like a good idea. But as time marches on, you realize that there are nuances to "doing a thing" that make a second (or 3rd or 4th) way preferable under certain circumstances. The real challenge is making it obvious which to use in the right circumstance.

Yechiel Kalmenson • Jun 21 '19

One of the things I loved most when I was learning Ruby was how many ways there are to solve each problem.

When I would complete labs at Flatiron my favorite thing to do was to go to look at other people's solutions. I would always learn new things!

Jaaki • Jun 21 '19

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.

Jonathan • Jun 21 '19

You could quit your job by saying "I quit", or you could say something a bit more lengthy and nuanced, like "All good things must come to an end. I feel like it's time for me to move on." They both basically say the same thing, but the second one carries a more information and conveys some depth and emotion.

In their expressive capacity I think programming languages are similar to human languages. That they are ways of expressing intent, not merely ways of getting the computer to do X or Y. For that expressiveness to be possible, it's necessary for there to be more than one way of doing something in a language.

Kirill Shestakov • Jun 22 '19

Disagree. Programming is expressing your creativity through a language. Nobody will solve the problem the same way.

If there are problems with obvious solutions, then those solutions can be automated. Once it's automated, your creative problem solving can apply at a higher level, but again, on this level, people will express their creativity differently.

Martín Emanuel • Jun 22 '19

I really appreciate when any technology takes that approach, even knowing that it might be controversial.

I don't want to think about a thousand ways to do the same thing, neither do I want to read thousands of lines of code that do the same in a different way.

I think that the more restricted is a technology you get more benefits: a team can work better, is easier to find solutions and it's harder to find corner cases that haven't been solved before.

I guess that explains why I really enjoy Angular over React/Vue, and in general convention over configuration.

Dinesh Pandiyan • Jun 22 '19 • Edited

Web wouldn't be where it is today now if someone didn't break that rule every now and then.

Now that doesn't mean you should go crazy and rebel all software dev principles. "Break rules responsibly" should be the goal.

David Daly • Jun 21 '19

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.

Daniel Coturel • Jun 21 '19

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.

Sendil Kumar • Jun 21 '19

Too many options are definitely a no go. It confuses everybody. But having only one way of doing a thing will not let you grow.

A better programming language should let you dream but at the same time, it will have to wake you up when you are abusing it with more options.

josephin • Jul 18 '19

amazing blog. thanks for sharing
java interview questions and answers/advanced java interview questions javatpoint/java interview questions for experienced/java interview questions quora/core java interview questions for 3 years experience/hr interview questions javatpoint/java interview questions quora/java interview questions videos/java interview questions 2019/java interview questions latest

protium • Jun 22 '19

I think flexibility is good for a solution to evolve in the most enhanced version of itself. But there should exist boundaries around it. Boundaries and flexibility is a good combination to get the best from both worlds (one way/undetermined way) and end up with something good.

I've refactored many code in my career. And I like to read solutions from years ago and refactor them. Can I get a better solution? Does this hypothetical better solution worth the effort?

I'm that guy in the team who is against to "this is the only way" but just because a team needs a guy like that. It worked so far.

Jake Varness • Jun 22 '19

If people have to "work around" your API because it's too concrete, it becomes difficult to consume.

If people have a hard time working around all the abstractions to get to what they finally want, it becomes difficult to consume and at times maintain.

Languages must have a healthy balance between customization and concrete design, and the user of that language has to be proficient enough with the language to know what's right for their use case.

Evan Oman • Jun 22 '19

I think it is generally a good principle to strive for, however devs shouldn't ignore the tradeoffs inherent in different approaches. For example, there are a bunch of different ways to write to a file in Java. Are all of them necessary? Probably not. However, each represents a unique set of tradeoffs, some of which may fit a certain application.

As with so many things, it all comes back to your objective function. What is most important in your given application? What negatives are you willing to accept?

Good engineers need to understand these tradeoffs in order to effectively solve problems. Good tools need to expose these different options for engineers to chose from.

johnfound • Jun 22 '19

Actually this is very bad idea that always kills the element of art in the programming. Of course, the real artist can draw a painting with one single brush. But if he has many different brushes his work will be much more comfortable.

For example, I can compare two MCU architectures: PIC and AVR. Both are risk harvard architectures, but PICs have so called orthogonal instruction set, with very small number of instructions and "only one way of doing things". AVR has extended non-orthogonal instruction set, where are many different ways to do things.

So, well, as a result, programming in assembly language with PIC is a pain. Programming in assembly language with AVR is a real pleasure.

Alex Lohr • Jun 22 '19

While there have been many attempts in different programming languages to create the syntax in a way that would lend itself to only one hopefully elegant solution for each problem, those have been doomed from the start by the fact that there are different paradigms (object orientation, functional programming) equally capable of solving problems in an elegant manner, thus the syntax becomes merely opinionated instead of obvious.

It's far more important to allow for consistency inside a single codebase than for uniformity of every code ever written in the language.

So, while a language and its libraries should provide simple and elegant solutions for everyday problems, striving for only one solution should be deemed unhealthy.

Ben Dowen • Jun 22 '19

If you think of what we didn't know yesterday, and then think about what we will know tomorrow. That "one way", may change and evolve over time.

To put it another way, it's difficult to determine if thing A really is the same as what you need, is it an identical use case? How well did it work out for others, or old you?

And what about room for innovation, maybe there is a more performance focused way to do A but with some compromises?

Summary: having an obvious way that is only deviated from for a good reason sounds sensible. Forsaking all possible alternatives upfront feels foolish.

Ben Dowen • Jun 22 '19

An example might be, using half, or or even quarter precision floating point maths for GPGPU powered ML.

This wasn't the first only obvious way, but it is the newer innovative way.

edA‑qa mort‑ora‑y • Jun 22 '19

As long as it's my way.

Anjaneyulu Aerrolla • Jul 1 '19

this quote is completely taken out of context , there is second line

There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

all it is saying is we should strive to do it better , and Dutch refers to Guido van Rossum as reveled by author of zen of python Tim Peters.
read more here softwareengineering.stackexchange....

Abdur Rehman Khalid • Jun 22 '19

Not Everyone Thinks the Same Way, and So there is no one way of solving the single problem, yes one solution can be better than other but it is not a good thing to say that there should be only one way of solving the same problem.