I’m not sure it’s unreadable to an experienced coder, someone learning the language though will be confused about the difference between = and => in the function argument definition.
Also the “arrow” is clearly pointing the wrong way, it should be “<=“.
His example of a function which is unreadable, is pretty typical. It still might be slower than a tight loop in C, but it’s only unreadable the first time you write something like that.
The thing is that usually basic algebra like this occurs somewhat seldomly in code. The rest of the function calls are readable, this is the (only) outlier to readability.
(1) yes my way is clearer, side by side this is very obvious. Certainly it is not worse.
(2) sure, but this doesn't change anything. Factoring a big ugly function out into two smaller easy functions is...fine, even if each is only used once. The name I picked wasn't to imply generalization, it was because I needed a name.
(3) yes.
But again the whole reason this is unreadable at all is because you've created an intentionally obtuse api. We're returning the row and column, so clearly either were able to index into this thing normally, or it's a temp we've created, in which case we can modify it's api and index into it normally.
Most math reads like very bad code to me: insufficiently commented, bad variable names, excessive (and wildly, ah, creative) operator overloading, no explicit types. Plus the debugging and analysis tools blow, forcing you to keep way too much in your head at any given time.
The documentation is extensive, but unfortunately too much of it takes the form of the same garbage code.
That code is pretty well messed up, but it is straightforward. For anyone that wants to read it just be aware that it uses old style parameter type declarations.
And a quick glance shows that the code isn't written in a terribly obvious and defensive manner. For example, just by skimming you can spot loads and loads of unchecked arithmetic. How can you know none of that can be exploited? The code doesn't do a lot to assure you of that.
The language they're using seems to pretty much be BASIC with slightly different syntax, it even lacks user-defined parameters for functions just like BASIC does.
it does nothing special or novel whatsoever - except maybe to set a quality bar for writing unmaintainable code.
the very first example given is simple, but demonstrates a thorough lack of understanding for what constitutes readable code. if i had to code review this from a junior i wouldn't let it go in without significant changes, and i'd make time to teach them some of the most basic concepts about producing maintainable and readable code... but only because its easier than firing them.
i am skeptical that the label 'transducer' has any solid value whatsoever here. i can understand the concept... its basically to encapsulate stages of algorithms neatly. the fact that it manifests one way in Clojure says nothing about the value of using exactly the same mechanism in C++ to achieve the same...
normal classes, normal functions, and not being rubbish at writing code combine to give a much better result for the same class of problems.
reply