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

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.

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.

🤮

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.

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.

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.

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.

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".

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.

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.

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.

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.

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.

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!

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.

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.