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

Comments

[Ryland G]

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]

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

::ducks::

[Ryland G]

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]

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]

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]

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]

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]

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]

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]

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]

🤮

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 👨‍💻]

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]

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]

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]

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]

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]

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]

Great stuff, Scott! Happy to chat with you.

[Thibaud Ducasse]

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]

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]

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

[Prahlad Yeri]

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 °°°]

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.