It's a mistake to ignore the customer
Posted Dec 6, 2012 15:18 UTC (Thu) by david.a.wheeler
In reply to: It's a mistake to ignore the customer
Parent article: GNU Guile 2.0.7 released
First, a few quotes:
Paul Graham, a well-known Lisp advocate, admits that "Sometimes infix syntax is easier to read. This is especially true for math expressions. I've used Lisp my whole programming life and I still don't find prefix math expressions natural."
Paul Graham also said, "When you program, you spend more time reading code than writing it... a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor."
Paul Prescod remarked, “[Regarding] infix versus prefix... I have more faith that you could convince the world to use esperanto than prefix notation.”
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.
to post comments)