"Principle of least surprise" maps pretty well onto there should ideally only be one way to do something. If there isn't several ways of doing something it's not surprising :).
I was reading some ruby a while ago, and stumbled upon. array << element. It took some serious googling to figure that one out, and I'm sure there are several ways you can write that too.
It's fascinating to see how something like "principle of least surprise" can be interpreted and addressed so differently. The Ruby and Python solutions for this could not be more different.
"Principle of least surprise" maps pretty well onto there should ideally only be one way to do something. If there isn't several ways of doing something it's not surprising :).
I was reading some ruby a while ago, and stumbled upon.
array << element
. It took some serious googling to figure that one out, and I'm sure there are several ways you can write that too.I think the approach that ruby took is one of individuality. Imaging that the "one preferred way" of adding elements to arrays was
array << element
.You'd be surprised that something like
array.push
wasn't working, and even more surprised thatarray << element
even existed.Even though, in our hypothetical language, that's the only preferred way to push to arrays, it's still surprising.
If any of that made sense
It's fascinating to see how something like "principle of least surprise" can be interpreted and addressed so differently. The Ruby and Python solutions for this could not be more different.
It’s especially interesting because both languages (python 2.7 at least) are pretty similar from a high level technical point of view.
Both OOP style languages
Both interpreted (usually)
Both very high level
Both dynamic
Both are even heavily used in web development