| |||||||||||||
It's a mistake to ignore the customerIt's a mistake to ignore the customerPosted Dec 6, 2012 20:37 UTC (Thu) by neilbrown (subscriber, #359)In reply to: It's a mistake to ignore the customer by etienne Parent article: GNU Guile 2.0.7 released
> Just to add that the main disadvantage of infix is that you have to introduce operator precedence
I was thinking exactly the reverse - a significant *advantage* of infix is that it allows the use of precedence to reduce bracket-noise.
Some care is needed in choose the precedence levels of course but it isn't hard if you apply care.
I really do not want to try to write (let along read)
if a + 2 < b*3+1 and c & 4 == 4
in anything but precedence-aware infix notation.
(Log in to post comments)
It's a mistake to ignore the customer Posted Dec 6, 2012 22:08 UTC (Thu) by dakas (guest, #88146) [Link] I really do not want to try to write (let along read)Thanks for proving how problematic infix can be. That example does not look like you are aware that == has higher precedence than &. So you are arguing for something beyond your capabilities. How would it look in Scheme as presumably intended?if a + 2 < b*3+1 and c & 4 == 4in anything but precedence-aware infix notation.
(if (and (< (+ a 2)
(+ (* b 3) 1))
(= (logand c 4) 4))
...)
It's a mistake to ignore the customer Posted Dec 6, 2012 22:22 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Thanks for pointing out stupidity of prefix syntax with your wonderful example of a one-liner turning into 5-liner.
It's a mistake to ignore the customer Posted Dec 6, 2012 22:48 UTC (Thu) by dakas (guest, #88146) [Link]
It is a 4-liner, and the material corresponding to the one-liner takes 3 lines. If mathematicians preferred minimal line count above readable grouping, why would they use fractions rather than in-line divisions?
It's a mistake to ignore the customer Posted Dec 6, 2012 23:09 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Because paper is a bit different medium and by using vertical layout it's possible to present information more efficiently?
It's a mistake to ignore the customer Posted Dec 6, 2012 23:54 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> (if (and (< (+ a 2) (+ (* b 3) 1)) (= (logand c 4) 4)) ...)
> if (a + 2 < b * 3 + 1 && (c & 4) == 4) {...}
At 56 characters, not counting the ellipsis, the Scheme example fits easily into one line. Personally, I would probably have split it across two lines in either language, but to each his own. Granted, the corrected C version is only 42 characters, but that is offset by the need to remember the precedence of each operator, and you just demonstrated how difficult that can be. The fully parenthesized C version
> if (((a + 2) < ((b * 3) + 1)) && ((c & 4) == 4)) {...}
is 52 characters, which isn't much shorter (or more readable) than the Scheme code.
It's a mistake to ignore the customer Posted Dec 7, 2012 0:08 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Nobody writes 2*3+1 as (2*3)+1 - everybody remembers THAT precedence rule.
So we realistically have: "if ((a+2 < b*3+1) && ((c&4) == 4)))" or 27 non-whitespace symbols. That's more compact and easier to understand.
And most people remember precedence rules of logical operators, so we have: "if (a+2 < b*3+1 && (c&4) == 4)" or 23 symbols.
Also, infix order has nice feature - it allows me to group relevant operations with whitespaces, with little "graphical" overhead.
It's a mistake to ignore the customer Posted Dec 8, 2012 9:57 UTC (Sat) by nix (subscriber, #2304) [Link] everybody remembers THAT precedence ruleI have fixed multiple bugs over the years caused by people thinking that + had higher precedence than *, or that C was strict left- or even right-associative. Yes, anyone with half a clue knows otherwise: but not every developer, alas, has half a clue to spare.
It's a mistake to ignore the customer Posted Dec 8, 2012 13:51 UTC (Sat) by paulj (subscriber, #341) [Link]
Also, clue level can vary significantly, even with a fixed, given programmer. E.g. regular diurnal patterns (pre-coffee, post-lunch, pre-knocking-off-time), when extremely tired at the end of a too-long hacking session, or even programming while drunk. :)
It's a mistake to ignore the customer Posted Dec 12, 2012 13:45 UTC (Wed) by HelloWorld (guest, #56129) [Link]
The solution to that isn't dumbing down the language but firing people who don't have half a clue.
It's a mistake to ignore the customer Posted Dec 13, 2012 11:39 UTC (Thu) by dakas (guest, #88146) [Link] The solution to that isn't dumbing down the language but firing people who don't have half a clue.Scheme is the ultimately dumbed-down language for the computer, to the degree that it does not require a parser for interpreting, just an expression reader and an evaluator. It is similarly dumbed-down to the human reader as commerce/Pidgin English is, meaning that it takes practice and control to consistently dumb down in the right manner. The purpose is having a common language for talking about programs shared between human and computer. Using infix in Scheme is like Yodish Pidgin English. Sort of defeats the original purpose of human and computer sharing a language for talking about code rather than humans expressing themselves to one another.
It's a mistake to ignore the customer Posted Dec 13, 2012 11:55 UTC (Thu) by mpr22 (subscriber, #60784) [Link] What a wonderful instance of "Humans can do the work, so machines have time to think."
It's a mistake to ignore the customer Posted Dec 13, 2012 17:26 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> Scheme is the ultimately dumbed-down language for the computer,
No, it's not. As you were told multiple times by now, Scheme already has syntactic sugar for multiple constructs. 'x is (quote x), and (quote x) is (quote . (x . ())).
> Using infix in Scheme is like Yodish Pidgin English. Sort of defeats the original purpose of human and computer sharing a language for talking about code rather than humans expressing themselves to one another.
It's a mistake to ignore the customer Posted Dec 13, 2012 18:38 UTC (Thu) by viro (subscriber, #7872) [Link]
Not quite. The problem, in a sense, is that the structure chosen for representing program makes sense for optimizing interpreter a bit, at the cost of being very unnatural. Subtrees are not subexpressions. Sure, that way you avoid digging in to find the node where you'll be doing reduction, but that doesn't come for free. As the matter of fact (and you damn well know that, seeing that you seem to be familiar with e.g. Haskell), the things can be done the other way round - with APPLY being the fundamental primitive and CONS expressed via it. The same "easily represent program in the language's primary data structure" thing holds for a lot more than just LISP, e.g. when the primary data structure *is* partially evaluated expression. That's not what makes LISP LISP; neither is the syntax, of course.
It's a mistake to ignore the customer Posted Dec 7, 2012 0:22 UTC (Fri) by neilbrown (subscriber, #359) [Link]
> That example does not look like you are aware that == has higher precedence than &.
Sorry, but what language did you think I was using? Given that I used "and" and did not include () around the condition of the 'if', it certainly wasn't C. (It is missing a ':' at the end - sorry about that).
Much as I like C, it clearly got some precedence issues wrong. More modern languages do a much better job.
It's a mistake to ignore the customer Posted Dec 7, 2012 7:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
To be fair, there is a define for 'and' to '&&' in commonly included C headers (I forget which exactly). And since there's LISP floating around, parentheses sort of fade into the background after enough programming in it, so the error(s) made aren't completely obvious. The colon probably would have helped :) .
C alternative tokens Posted Dec 7, 2012 16:42 UTC (Fri) by dtlin (✭ supporter ✭, #36537) [Link] #include <iso646.h>defines macros for C. They're in C++ by default.
|
|||||||||||||