"Occasionally surprise the novice, or you'll continually surprise the expert." | Hacker News Reader

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

nntp.perl.org

34 pointsakkartik19 comments

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.

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ñÁ®"

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.

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

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

That's ... an awesome mental image.

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.

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.

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?

I'm a Unix-type, and Perl still makes me want to cry.

Actually, a giraffe in a boolean context becomes bipedal, so that shouldn't be too bad.

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.

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.

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

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.

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

You shouldn't have gotten Toast&Eggs. You should have gotten (Toast&Eggs)*2 + (Toast^Eggs).

or ((Toast&Eggs)2&(Toast^Eggs))2+((Toast&Eggs)^(Toast^Eggs))

((Toast&Eggs)2&(Toast^Eggs))2+((Toast&Eggs)*2^(Toast^Eggs))

Reply on news.ycombinator.com