| |||||||||||||
It's a mistake to ignore the customerIt's a mistake to ignore the customerPosted Dec 6, 2012 0:28 UTC (Thu) 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
I don't understand the problem this is trying to fix. Is there really a huge audience of people who would wrap their minds around Scheme if only it supported an infix notation? The illusion that this is an infix language is going to disappear the instant you have to look at anyone else's code, even the most trivial. If you have to look up something in a manual, any non-trivial example will force you to figure out the original syntax.
The Bourne shell code uses the C preprocessor to look like Algol 68. I don't believe anyone who had to maintain it was amused.
I don't know that most developers care about superficial syntax when they're looking for a practical language. (And if so, you're completely misusing brackets there, as they aren't being used like in C.)
(Log in to post comments)
It's a mistake to ignore the customer Posted Dec 6, 2012 15:18 UTC (Thu) by david.a.wheeler (guest, #72896) [Link] First, a few quotes:
Now a few replies...
The illusion that this is an infix language is going to disappear the instant you have to look at anyone else's code, even the most trivial. There is no such thing as an "infix language". There are simply programming languages, nearly all of which allow the use of infix notation. Internally many language implementations store constructs in some sort of abstract syntax tree; does that make them "abstract syntax tree languages"? Is there really a huge audience of people who would wrap their minds around Scheme if only it supported an infix notation? I would argue the other way. 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. And it's not just for "outsiders"; as noted above, some current LISPers want to use infix too.
If you have to look up something in a manual, any non-trivial example will force you to figure out the original syntax. There is no "figuring out"; I expect developers to learn the underlying traditional Lisp notation, and then learn that there's a new abbreviation for some common cases. Scheme developers already need to know other abbreviations to be effective. For example, 'x means (quote x). Are you suggesting that developers cannot follow code in a manual if it says (quote x)? Curly-infix is just another abbreviation. Python developers actually have to learn many more abbreviations, by the way; there's no evidence that this short ruleset causes any hardship. I don't know that most developers care about superficial syntax when they're looking for a practical language. I think you're wrong on this point. I think most developers do care about surface syntax. Surface syntax matters, because you have to read a lot of code when developing. If the code is hard to read, you won't want to do it. Python has caught on in many places precisely because it has good "superficial" syntax. By the way, "superficial" is misleading; it's actually tricky to create really good surface syntax. If you didn't care about superficial syntax, why are you complaining about curly-infix? It is, fundamentally, a surface syntax. Lisp fails many users and potential users because its syntax ossified in the late 1950s / early 1960s. Even its original developer (McCarthy) thought Lisp notation had many problems as a programming notation. It's been over 50 years... it's time to fix its most well-known problems.
It's a mistake to ignore the customer Posted Dec 6, 2012 19:39 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
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.
It's a mistake to ignore the customer 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]
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.
More quotes showing that readable syntax matters Posted Dec 6, 2012 16:05 UTC (Thu) by david.a.wheeler (guest, #72896) [Link] Here are some more relevant quotes showing that surface syntax matters to developers:
|
|||||||||||||