You're adding syntactical complexity. You keep referring to Python, which has a rule "There should be one--and preferably only one--obvious way to do it." It's not going to make it make it any easier to read existing code, nor access existing Scheme books or tutorials.
"There is a huge audience of people who will never consider Scheme seriously as long as it fails to support notation that 1K BASICs manage." is hard to take seriously. For one, where's my PEEKs and POKEs? For another, it's said so many times; if we just added this feature, everyone would jump all over our tool. Changing (+ 4 7) to {4 + 7} is not going change anything for most people.
If you really think that it will be useful to existing programmers, then perhaps it will be a useful feature, but it's tacking on additional duplicate syntax, not fundamentally fixing any problems.
Posted Dec 7, 2012 15:01 UTC (Fri) by david.a.wheeler (guest, #72896)
[Link]
Poster said:
You're adding syntactical complexity. You keep referring to Python, which has a rule "There should be one--and preferably only one--obvious way to do it."
Is 'x okay? After all, that's just a syntactic complexity for (quote x). I'm proposing another abbreviation for a common case.
Funny you should mention Python.
Python, of course, already has two representations for arithmetic operations, prefix and infix, if you want to create types that support infix operators. The Python infix operators are simply an abbreviation for the prefix operators, when you use them this way, e.g., infix "+" is an abbreviation for "__add__".
See the Python special names for more.
Many people are unaware that Python supports prefix notation in this case, because the infix notation is what users expect and want to use.
It's a mistake to ignore the customer
Posted Dec 7, 2012 19:52 UTC (Fri) by dvdeug (subscriber, #10998)
[Link]
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.
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]
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.