An Optometrist and a Language Designer Walk Into a Bar....

| 8 Comments

(or, stop me if you've heard this one before)

A good friend of mine first wore glasses in college. He hadn't realized that the world had been blurry for 20 years until his doctor demonstrated exactly how clear the world can be.

If you visit the optometrist and get fitted for corrective lenses, the doctor will put a viewfinder over your face and fiddle with dials, asking "Better or worse". Your task is to squint and squirm and try to read the optical equivalent of lorem ipsum until everything becomes clear and you no longer have to worry about your focal depth. If you get it wrong, you'll have slight headaches for a year until you correct things again. If you get it right—well, that's a matter of preference.

After all, no one can decide your own tolerance for clarity.

Some people believe that Perl has too many operators and they ask questions like why are there separate comparison operators for strings and numbers, for example.

Better or worse?

$x eq $y
$x.to_str == $y.to_str
(String)$x == (String)$y

Granted, the underlying mechanism in a virtual machine might perform the same operations:

get_string %SREG(0), $x
get_string %SREG(1), $y
compare %SREG(0), %SREG(1)

... but people like me write lots of code so you don't have to write code like that, or even know how that code works.

Suppose the optometrist knows all about Hindley-Milner, and over a second round of delicious beverages, he asks the programming language designer about typeclasses and inference:

$x == $y

Better or worse than the previous examples?

Of course, your optometrist probably isn't even an amateur programming language designer, so it's easy to counter the argument:

  • Does this operator compare container equivalence or value equivalence?
  • If value equivalence, must the values be the same or equivalent?
  • If container equivalence, how deep is the container equivalence?
  • Must the inferred types be the same, or can they be contra/covariant?
  • If deep container equivalence, how does this comparison interact with laziness or infinite data structures?
  • If value equivalence, are coercions allowable between potentially comparable representations?
  • What happens if someone overloads this comparison operator for one type or another?

Better or worse?

$x == $y
$x.CONTAINER == $y.CONTAINER
$x.VALUE == $y.VALUE
typeof $x == typeof $y
<contravariant_type>$x == <contravariant_type>$y
LAZY($x == $y)

... and so on.

Over a third round of drinks, the programming language designer might get the optometrist to admit that the reason some languages have so many operators is because there are so many possible operations. The question, as always, is "What's the most clear to read and to understand?"

8 Comments

In one post you referece, "ank" wrote:

Operators are akin to prepositions and should be kept to a minimum, in my very humble opinion.

I can see why you chose someone with such a strong opinion to use as a foil to this post, but honestly, isn't picking on someone who views operators as prepositions kind of like shooting fish in a barrel?

This aside, I wonder how Java handles this?

    if ( string1.equals(string2) )                   { ... }
    if ( string1.equalsIgnoreCase(string2) )         { ... }
    if ( string1.compareTo(string2) == 0 )           { ... }
    if ( string1.compareToIgnoreCase(string2) == 0 ) { ... }
    if ( string1.contentEquals(stringBuffer) )       { ... }
    if ( string1 == string2 )                        { ... }

And those are just for strings! Every single one of those has a different meaning and is needed (though you could easily shrink this list if Java wasn't so broken).

As you already know, and as I'm sure many readers of this blog are already aware, operators are effectively a shorthand for certain common methods (except that Java doesn't let you overload operators outside of '+' for the String class). Regardless of what one thinks about Java, they had a reason for providing all of those different comparison operators, er, methods. And even then, let's look at how some of them compare to Perl 6:

Equality:

    if ( string1.compareTo(string2) == 0 ) { ... }
    if $string1 eq $string2                { ... }


Less than:

    if ( string1.compareTo(string2) < 0 ) { ... }
    if $string1 lt $string2               { ... }

Greater than:

    if ( string1.compareTo(string2) > 0 ) { ... }
    if $string1 gt $string2               { ... }

Needless to say, I find the Perl 6 far easier to read than the Java, but Java's constrained because of its poor operator handling.

At the end of the day, most people will not need the extra Perl 6 operators, but when they do need them, they'll be thankful they're there.

As noted in a Perl-IL and Python-IL post I've made, Python can sometimes throw an exception if you do a "==" comparison:

shlomi:~$ python
Python 2.6.2 (r262:71600, Jul 11 2009, 07:37:11) 
[GCC 4.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [0,1,2]
>>> x[0] = x
>>> y = [0,1,2]
>>> y[0] = y
>>> x
[[...], 1, 2]
>>> y
[[...], 1, 2]
>>> x == y
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded in cmp
>>> 

Python also has an "is" operator, but it only checks if the values are the same referent.

Ah, nice. So in something like:

print @array+0;

+ is obviously the verb, then?

-- Andres N. Kievky (aka ank - no need to double quote my name)

The plus operator is obviously a verb, yes. So is print. Read it aloud in execution order in English: evaluate the array named "array" in scalar context, add zero, and print the result.

The plus operator is obviously a verb, yes. So is print. Read it aloud in execution order in English: evaluate the array named "array" in scalar context, add zero, and print the result.

Ah yes. And now we get to the heart of the matter. Traditionally, operators have meant just that - operate (apply this particular operation) to these items. That's not quite fitting today - and it's especially not fitting for perl.

Take, for example - print @array+0. Most programmers will read that as "print the size of this array". The verb? print. The subject? an array. Since when has "the size of" been a verb? Moreso with perl - operators like => more and more "introduce" bits of that to be processed by the overall line.

Now, please tell me how => is a verb. Thanks.

Do you have references for your "Traditionally"? How about your "Most programmers"?

Are the latter primarily Perl programmers? If not, who cares what they think? If so, are they aware of addition? How about evaluation order? Expressions?

Would you expect a first grader to diagram sentences correctly without receiving instruction in syntax and grammar? Why then a programmer without an understanding of syntax and grammar?

You make a good point about the comma operators, however. They indeed act more like prepositions with their (parse time) sequencing and potential autoquoting.

Now that you've found a modicum of humility, please make a post in use.perl stating that:

  1. you misread my original comment (i never said oeprators ARE prepositions, I said they are AKIN TO prepositions;)
  2. you were wrong in that "operators are verbs", and
  3. given this new information, you will review the operators that exist in perl 6, in light of its sheer complexity.

I think not.

With regard to point one, I never claimed otherwise. Metaphors are, in part, lies.

With regard to point two, I'd be guilty of a hasty generalization (From the comma? The metaphor that it is an operator rather than punctuation is, in part, also a lie. Yet we also discuss quoting and quote-like operators, despite their effects on the parsing of programs. As for the fat comma in Perl 6, as an infix operator it is a constructor for Pair objects. Note also the lack of the comma in the list of Perl 6 operators in Synopsis 3.) were I to do so. My previous post discussed both comma forms in the context of Perl 5; clearly a confusing mistake on my part.

With regard to point three, you are more than welcome to post to p6l or discuss your ideas for the improvement of Perl 6 in #perl6, especially with the reference from Mr. Grune to which you have alluded repeatedly. (If it's his August 1993 SIGPLAN paper, you have a very curious reading of it. See also some of the published literature about teaching APL to high school students; I know Adin Falkoff had some interesting experiences there. You might also look at the work of Howard Peele -- this approach changes the discussion from the world of natural language to one of very symbolic computation, much more that of the mathemeticians.)

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

affiliated with ModernPerl.net

Categories

Pages

About this Entry

This page contains a single entry by chromatic published on June 9, 2010 2:09 PM.

Punctilious and Parsimonious Primitives was the previous entry in this blog.

The Importance of a Number is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Sponsored by Blender Recipe Reviews and the Trendshare how to invest guide

Powered by the Perl programming language

what is programming?