5 ms·

"Occasionally surprise the novice, or you'll continually surprise the expert."

34 points by akkartik 17y ago

wanderr 17y ago
I agree with Larry Wall on this particular point, but I'd love to see further examples illustrating the principle here.
- francoisdevlin 17y ago
  Take a look at anything in Clojure. Sexps, homoiconic language, immutability & macros don't seem like good choices at first. Once you have some experience writing code, you'll see that they're killer features.
jergosh 17y ago
Advocating principle of least astonishment for Perl is like a giraffe trying to breakdance.
- chronomex 17y ago
  That's ... an awesome mental image.
  - stcredzero 17y ago
    There must be something clever we could say about moment of inertia. Also, isn't it instructive that the "novice" here is someone who's already a programmer in another language? Why are the arbitrary conventions of the Unix shell sacred? They are not some ultimate good. They are merely good because they are the result of cooperation and collaboration over many years. They are by no means perfect.
- pmccool 17y ago
  I disagree. perl made a point of adopting a lot of idioms from well-known languages. Some of it's more inscrutably named internal variables came from awk, for example. Whatever perl's vices, indifference to least astonishment isn't among them. Admittedly, it's target audience was UNIX types. I can well imagine a good deal of astonishment, along with some other emotions, from those not in the target audience.
  - jergosh 17y ago
    I agree that many constructs (s///, tr//, ``) will be familiar to someone with Unix background, but I'm not sure if they would qualify as a novice (many CS first years are unfamiliar, and in fields like bioinformatics -- where Perl happens to be the most commonly used language -- it's a rarity). But anyway, what about $_ and a host of other special variables? Pulling arguments to functions out of nowhere? Using regexps for simple string operations? Strings not being array? Using a special comparison operator for strings (without complaints when == is used)? length() not working on arrays (again, no warning) and $# returning index of last element rather than length? 'if' not being able to take a single statement? 'Last' instead of 'break', 'next' instead of 'continue', 'continue' doing something else?
  - alextingle 17y ago
    I'm a Unix-type, and Perl still makes me want to cry.
- lsb 17y ago
  Actually, a giraffe in a boolean context becomes bipedal, so that shouldn't be too bad.
RyanMcGreal 17y ago
Here's how another popular scripting language handles this: >>> a, b = 123, 456 >>> a + b 579 >>> c, d = '123', '456' >>> c + d '123456' >>> b + c Traceback (most recent call last): File "<pyshell#4>", line 1, in <module> b + c TypeError: unsupported operand type(s) for +: 'int' and 'str' I must confess that none of these behaviours surprised me when I first encountered them.
- cperciva 17y ago
  TypeError: unsupported operand type(s) for +: 'int' and 'str' What a silly error. Obviously "123" + 1 is "23", "123" + 2 is "3", "123" + 3 is "", and "123" + 456 is "ùÏÚ0óÊÌ°qÛ=æPªuök6~;;\ðÚÕKµM¦OñÁ®"
- csbrooks 17y ago
  Python is one of my favorite languages, but every time I use + to concatenate strings I get a kind of gross feeling. I think one reason is that python encourages the use of duck typing, and as a result when you look at a piece of code you can't really be positive what kinds of values the variables hold. So if you're writing some code that works as long as the arguments passed in support "+", it's jarring thinking that it might run on strings, but surely won't do what you expect.
plesn 17y ago
Addition and concatenation have different properties: concatenation is not commutative. So the problem is not the types, strings vs int, but different operations. In a language that puts an emphasis on principles like haskell, I find "++" a elegent syntax for concatenation, but otherwise I find that Python's approach of using "+" and throwing a type error is good enough.
- Zak 17y ago
  I see the overloading of operators to do fundamentally different sorts of operations as a mistake in all cases. That's not to imply that (in a language with infix syntax) operator overloading is bad, but that it should be used to add the same kind of operation to a new situation. Overloading + to work with a fixed-point math library makes sense. Overloading + to do concatenation does not.
j_baker 17y ago
I think that Wall misunderstands the policy of least surprise and I even think Matz might agree with the principle of the quoted statement (although he probably wouldn't agree with the overall point Wall is making). From an interview: "I wanted to minimize my frustration during programming, so I want to minimize my effort in programming. That was my primary goal in designing Ruby. I want to have fun in programming myself. After releasing Ruby and many people around the world got to know Ruby, they said they feel the way I feel. They came up with the phrase the principle of least surprise. But actually, it's often misunderstood. ... Everyone has an individual background. Someone may come from Python, someone else may come from Perl, and they may be surprised by different aspects of the language. Then they come up to me and say, "I was surprised by this feature of the language, so therefore Ruby violates the principle of least surprise." Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well. For example, I was a C++ programmer before I started designing Ruby. I programmed in C++ exclusively for two or three years. And after two years of C++ programming, it still surprised me." http://www.artima.com/intv/ruby4.html http://www.artima.com/intv/ruby4.html
jaekwon 17y ago
I Added some Eggs to my Toast today, and all I got was Toast&Eggs. Nothing Exceptional.
- cperciva 17y ago
  You shouldn't have gotten Toast&Eggs. You should have gotten (Toast&Eggs)*2 + (Toast^Eggs).
  - jaekwon 17y ago
    or ((Toast&Eggs)2&(Toast^Eggs))2+((Toast&Eggs)^(Toast^Eggs))
    - jaekwon 17y ago
      ((Toast&Eggs)2&(Toast^Eggs))2+((Toast&Eggs)*2^(Toast^Eggs))

34 points by akkartik 17y ago

wanderr 17y ago

I agree with Larry Wall on this particular point, but I'd love to see further examples illustrating the principle here.

francoisdevlin 17y ago
Take a look at anything in Clojure. Sexps, homoiconic language, immutability & macros don't seem like good choices at first. Once you have some experience writing code, you'll see that they're killer features.

jergosh 17y ago

Advocating principle of least astonishment for Perl is like a giraffe trying to breakdance.

chronomex 17y ago
That's ... an awesome mental image.
- stcredzero 17y ago
  There must be something clever we could say about moment of inertia. Also, isn't it instructive that the "novice" here is someone who's already a programmer in another language? Why are the arbitrary conventions of the Unix shell sacred? They are not some ultimate good. They are merely good because they are the result of cooperation and collaboration over many years. They are by no means perfect.
pmccool 17y ago
I disagree. perl made a point of adopting a lot of idioms from well-known languages. Some of it's more inscrutably named internal variables came from awk, for example. Whatever perl's vices, indifference to least astonishment isn't among them. Admittedly, it's target audience was UNIX types. I can well imagine a good deal of astonishment, along with some other emotions, from those not in the target audience.
- jergosh 17y ago
  I agree that many constructs (s///, tr//, ``) will be familiar to someone with Unix background, but I'm not sure if they would qualify as a novice (many CS first years are unfamiliar, and in fields like bioinformatics -- where Perl happens to be the most commonly used language -- it's a rarity). But anyway, what about $_ and a host of other special variables? Pulling arguments to functions out of nowhere? Using regexps for simple string operations? Strings not being array? Using a special comparison operator for strings (without complaints when == is used)? length() not working on arrays (again, no warning) and $# returning index of last element rather than length? 'if' not being able to take a single statement? 'Last' instead of 'break', 'next' instead of 'continue', 'continue' doing something else?
- alextingle 17y ago
  I'm a Unix-type, and Perl still makes me want to cry.
lsb 17y ago
Actually, a giraffe in a boolean context becomes bipedal, so that shouldn't be too bad.

RyanMcGreal 17y ago

Here's how another popular scripting language handles this: >>> a, b = 123, 456 >>> a + b 579 >>> c, d = '123', '456' >>> c + d '123456' >>> b + c Traceback (most recent call last): File "<pyshell#4>", line 1, in <module> b + c TypeError: unsupported operand type(s) for +: 'int' and 'str' I must confess that none of these behaviours surprised me when I first encountered them.

cperciva 17y ago
TypeError: unsupported operand type(s) for +: 'int' and 'str' What a silly error. Obviously "123" + 1 is "23", "123" + 2 is "3", "123" + 3 is "", and "123" + 456 is "ùÏÚ0óÊÌ°qÛ=æPªuök6~;;\ðÚÕKµM¦OñÁ®"
csbrooks 17y ago
Python is one of my favorite languages, but every time I use + to concatenate strings I get a kind of gross feeling. I think one reason is that python encourages the use of duck typing, and as a result when you look at a piece of code you can't really be positive what kinds of values the variables hold. So if you're writing some code that works as long as the arguments passed in support "+", it's jarring thinking that it might run on strings, but surely won't do what you expect.

plesn 17y ago

Addition and concatenation have different properties: concatenation is not commutative. So the problem is not the types, strings vs int, but different operations. In a language that puts an emphasis on principles like haskell, I find "++" a elegent syntax for concatenation, but otherwise I find that Python's approach of using "+" and throwing a type error is good enough.

Zak 17y ago
I see the overloading of operators to do fundamentally different sorts of operations as a mistake in all cases. That's not to imply that (in a language with infix syntax) operator overloading is bad, but that it should be used to add the same kind of operation to a new situation. Overloading + to work with a fixed-point math library makes sense. Overloading + to do concatenation does not.

j_baker 17y ago

I think that Wall misunderstands the policy of least surprise and I even think Matz might agree with the principle of the quoted statement (although he probably wouldn't agree with the overall point Wall is making). From an interview: "I wanted to minimize my frustration during programming, so I want to minimize my effort in programming. That was my primary goal in designing Ruby. I want to have fun in programming myself. After releasing Ruby and many people around the world got to know Ruby, they said they feel the way I feel. They came up with the phrase the principle of least surprise. But actually, it's often misunderstood. ... Everyone has an individual background. Someone may come from Python, someone else may come from Perl, and they may be surprised by different aspects of the language. Then they come up to me and say, "I was surprised by this feature of the language, so therefore Ruby violates the principle of least surprise." Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well. For example, I was a C++ programmer before I started designing Ruby. I programmed in C++ exclusively for two or three years. And after two years of C++ programming, it still surprised me." http://www.artima.com/intv/ruby4.html http://www.artima.com/intv/ruby4.html

jaekwon 17y ago

I Added some Eggs to my Toast today, and all I got was Toast&Eggs. Nothing Exceptional.

cperciva 17y ago
You shouldn't have gotten Toast&Eggs. You should have gotten (Toast&Eggs)*2 + (Toast^Eggs).
- jaekwon 17y ago
  or ((Toast&Eggs)2&(Toast^Eggs))2+((Toast&Eggs)^(Toast^Eggs))
  - jaekwon 17y ago
    ((Toast&Eggs)2&(Toast^Eggs))2+((Toast&Eggs)*2^(Toast^Eggs))