Faith Club
Faith Club
- 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
- 2016.09.04, 12:13
- I am following some Scala lectures on Coursera right now, and I am growing annoyed how mathematically-academical it is. By that, I mean how the approach to problem solving is often "why don't we just explode the problem space exponentially, without regard for memory or running time, and see if it returns any result, don't care if it bombs out". It's often the exact opposite of real-world problem solving where you must carefully consider memory and CPU time constraints first, and the mathematical elegance of the solution as a distant second.
The other problem, naming. Somehow somebody decided that syntax like (_ + _) or (_ * _) makes sense. And you never see (_ - _) or (_ / _) ever discussed, because somehow only the + and * operands seem to come up, never - and / where position of operands actually would be important. I am growing annoyed of this handwaving and this "don't worry about it" sweep-it-under-the-rug" attitude of language designers.
(And constantly irritated how this makes code look like it's shitting on you.)
Then, something like list.foldRight(_ + _) and list.foldLeft(_ + _) makes appearance, and the method signature is foldRight(A, B) or foldLeft(A, B) without any thought given to providing a better name for the A and B arguments. Seriously, what does A stand for, and what does B act like? Are you absolutely, positively, unable to come up with a name that would make sense?
Why force me to recall whole application semantics for foldLeft and foldRight, can't you substitute some argument names giving me a hint of what is going to be happen. Say, foldRight( tailElement, elementBeforeIt ) and foldLeft( headElement, nextElement )?
(You will also see there is a bit of confusion if B is the single next element or the "rest" of the list, in Scala they define the result as placing the "op" between the elements of list - which is very, very easy to understand, and in other languages you would get some talk about "cons" or subtree or rest of list, any bullshit like that.)
-
0 rakstair doma