4 ms·
COBOL has a SEP field on it (and for good reasons - it is someone else's problem), but when discussing APL, I've often reached for it as an example that everyth
by beagle3 6y ago
COBOL has a SEP field on it (and for good reasons - it is someone else's problem), but when discussing APL, I've often reached for it as an example that everything is just preference.
When I show an APL or K gem such as "|/0(0|+)\" (which is a complete and rather efficient implementation of the maximum-subarray-sum problem), people usually complain that "it's unreadable".
But then "ADD ONE TO X GIVING X" compared to "++x" or "x=x+1" shows that explicit is only better than implicit when you're not familiar with the notation.
Readability is all about your expectation and familiarity.
- nextaccountic 6y ago> COBOL has a SEP field on it (and for good reasons - it is someone else's problem), What do you mean by SEP field? (I can't find it in the article either). Is this a programming construct like a field of a record?
- QuesnayJr 6y agoSomebody Else's Problem field. It's a joke from Hitchhiker's Guide to the Galaxy. Instead of an invisibility field, where you can't see something, you use an SEP field, which makes you look at something, subconsciously think "that's somebody else's problem", and then you look away.
- teataster 6y agoI found out most people confound familiarity and "intuitiveness" when trying to teach Emacs. They would say it was not intuitive because common key shortcuts were not default. I would try to explain, to no avail I must say, that it is rather intuitive since, once you understand the basics, everything follows quite logically and key bindings are customizable.
- BlueTemplar 6y agoOne of rules of design is that there is no such thing as intuitive, only familiar.
- cinntaile 6y agoWhile I get your point, your example seems to only be partially valid. Programming languages are moving away from the ++ operator due to its ambiguity in favor of x=x+1. Exactly to make sure that what you expect to happen actually happens.
- beagle3 6y agoMoving away from? Ambiguity? Maybe from "x++", and even that is not clear. There is no ambiguity, "++x" is as strong as ever in the C family including C, C++, C#, Java, JavaScript. Python added "x+=1" which is as ambiguous as "++x" and did so (relatively) recently, even though it had "x=x+1". I'm not sure why you think "programming languages are moving away from the ++ operator". Care to elaborate?
- ivanhoe 6y agoNot that I ever had problem with it, but ambiguity with ++ lies in prefix/postfix version of the operator. I don't see how x+=1 is ambiguous in any way, it's just a shorter way to write it, but there's no side-effects like with x++?
- beagle3 6y agoThere is no ambiguity. Prefix is increment pre (increment before getting the value). Postfix is increment post (increment after getting the value). Both have side effects as does x+=1. consider the call f(x+=1,x+=1) when x=5; what is the call? f(6,7) or f(7,6)? Iirc even f(6,6) and f(7,7) were valid behavior in the past.
- ptx 6y ago"x += 1" in Python is a statement, not an expression, so that's a SyntaxError. But I suppose you would run into this kind of ambiguity with the walrus operator, i.e. >>> x = 5 >>> f = lambda a, b: (a, b) >>> print(f(x := x + 1, x := x + 1)) (6, 7) PEP 572 appears[1] to specify that the evaluation order should always be left to right. [1] https://www.python.org/dev/peps/pep-0572/#change-to-evaluation-order https://www.python.org/dev/peps/pep-0572/#change-to-evaluati...