It's a mistake to ignore the customer [LWN.net]

It's a mistake to ignore the customer

Posted Dec 7, 2012 19:52 UTC (Fri) by dvdeug (subscriber, #10998)
In reply to: It's a mistake to ignore the customer by david.a.wheeler
Parent article: GNU Guile 2.0.7 released

And personally I think it's an inelegance that quote exists at all.

I think you're misstating the cause; the people who are unaware that Python supports prefix notation in this case are unaware because it's obscure and rarely used outside operator overloading, which is in part because __add__ is seriously more clunky then +. If the notation were + (a, b) and a __add__ b then people would use the prefix notation more. Moreover, people being unaware of the prefix notation means there's for most purposes only one notation, with __add__ and friends existing solely for operator overloading. (It would have been more elegant to extend the characters available for function names.) You're setting up two competing syntaxes, and the arguably more friendly one is not the one used for 35 years in Scheme and since the dawn of time in Lisp. Either the new one will see little to no use, or both will be used.

(Log in to post comments)

It's a mistake to ignore the customer

Posted Dec 10, 2012 2:22 UTC (Mon) by david.a.wheeler (guest, #72896) [Link]

Poster said:

personally I think it's an inelegance that quote exists at all.

I think that is an extremely small minority position. I think most people are happy to have abbreviations for common situations.

If the notation were + (a, b) and a __add__ b then people would use the prefix notation more.

Actually, I think people just wouldn't use the language at all, if those were your only options. I believe that for many developers, infix using symbols like "+" is a "bare minimum" requirement for a programming language. It matters how code looks, it really does.

You're setting up two competing syntaxes, and the arguably more friendly one is not the one used for 35 years in Scheme and since the dawn of time in Lisp. Either the new one will see little to no use, or both will be used.

If a notation is more friendly, why should people object to it? My hope is that both will be used, and that isn't a problem. People see (quote x) and 'x all the time, it hasn't hurt them.

It's a mistake to ignore the customer

Posted Dec 12, 2012 13:09 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> If the notation were + (a, b) and a __add__ b then people would use the prefix notation more.
Bollocks. In Haskell, you can use (+) a b instead of a + b, but nobody actually does that. The only reason the (+) syntax exists is to make it possible to pass + to a higher-order function.

It's a mistake to ignore the customer

Posted Dec 13, 2012 1:19 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Right, but it's closer to the question: Given:

> (+) a b

and

> a `add` b

as the "only" options, which would be more popular?

It's a mistake to ignore the customer

Posted Dec 13, 2012 1:29 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

I'd go for option (c) Find the person who is requiring me to use this language clearly designed by either a parodist or a malicious idiot, and require them to explain to me in less than 150 syllables why I have to put up with it.

It's a mistake to ignore the customer

Posted Dec 13, 2012 1:36 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Ah, yes. I forgot that option :) . That's how I feel with the class/method names people tend to use in Java… Biggest thing it's missing is a "typedef" equivalent, IMO.

It's a mistake to ignore the customer

Posted Dec 13, 2012 21:17 UTC (Thu) by mirabilos (subscriber, #84359) [Link]

Urgh. U+0060 should never be used. It should really have been a combining character, but ASCII doesn’t really have them. See also: http://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html

It's a mistake to ignore the customer

Posted Dec 12, 2012 13:56 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

If the notation were + (a, b) and a __add__ b then people would use the prefix notation more.

Fortunately, programming languages seldom (INTERCAL doesn't count, being a parody) display such high levels of overt malice in their design, and such an arrangement could not (at least in our world where infix notation arithmetic is the norm) plausibly be the product of mere stupidity or laziness.