- 2016.09.25, 09:56
- I must agree - Java's decision to not support custom operators, and force folks to use method names for whatever obscure operations they want to implement (and side stepping the whole dumb issue about operator precedence, binding rules and order of evaluation) was genius. (Annoyed as I am how useless is "==" operator that does pointer comparison on 2 objects, forcing you to call "Objects.equals( obj1, obj2 )" is very readable, and also makes you recognize the fact that deep-comparison will be performed on 2 objects to establish their equivalence.)
And on other hand, by example of Scala we easily can see how the operators support will get abused, devolving the language into yet-another write-only Perl clone by unscrupulous practitioners. Complete with _ underscore magic, folks manage to reduce their code into unreadable line-noise garbage, all while mumbling about "conciseness" and maybe "expressivity" of their code.
Take just the standard operators - ::, #::, ++, :+, +: - it's remarkable how they make code difficult to read for a novice, because their semantics are completely disconnected from appearance.
Allowing language users to define new operators using entirely symbolic characters is a mistake. Language users now are attempting to use some unicode arrow characters to make their code look like mathematic notation. (Speaking of maths, I really dislike all the greek letters and single-char identifiers with subscripts and prime ', markers and what else. Yeah mathematicians will say once all notation is internalized, then some maths will simply "look right" or "look wrong" at glance, and individual is able to "see" a solution without having to consciously derive it. Well screw that, programming does not work like this. You should be able to read a program like piece of literature.)
The unreadability of Scala stack-traces is another downfall. Because the language encourages the creating anonymous functions (closures, whatever), then chaining the methods together with lazy evaluation, when finally the method blows up you have no way to trace it back to original line of source that introduced the issue.
It's laughable how ScalaUnit is unable to navigate back to original "assert" line in code which triggered the test failure. - 0 rakstair doma
autortiesība
pīkstulis
ateja birkas
ienākt iedirst