41–50 of 100 posts
Most of us spend 90% of our time reading other people’s code. So even though writing a concise and elegant formula in J might be a satisfying puzzle, I personally don’t want to deal with the cognitive burden of point-free style when sifting through my colleagues’ pull requests.
Earlier quoted context omitted.
Understandability is more important than conciseness in a team environment. In a team, you're not writing code for you - you're writing code to be reviewed by other people, integrated with other people's code, and maintained by other people in the future. In the example from this article, all developers I've ever worked with would understand what the "good old C" example is doing within seconds. Most would understand…
> J is even worse. I stared at the J code for a full minute without any comprehension of the language syntax or what was being accomplished. That code isn't readable or maintainable. It is bad code. But why does code need to be readable to someone who doesn't know the language? Yes, it's true that Python and some other languages are pretty readable even to people who haven't written any of that language, and that is…
It's obvious how to change the imperative code: `if (x[i] == 0) return 0;` What would this optimization look like in APL or J?
((+/) % #) &. ^. is the same as (+/ % #) &. ^. because adverb (/ in this case) binds with + before three verbs +/ , % and # are grouped into the fork. So some parentheses aren't necessary. It would be cleaner to show three expressions which share the common part as similar in letters as well.
Most of us spend 90% of our time reading other people’s code. So even though writing a concise and elegant formula in J might be a satisfying puzzle, I personally don’t want to deal with the cognitive burden of point-free style when sifting through my colleagues’ pull requests.
When it's appropriate, point free style doesn't increase cognitive burden. It's often inappropriate.
Earlier quoted context omitted.
Hi! I appreciate your honesty. Of course arriving at the Mathematical formula is the hard part, that's what it means to actually solve the problem. I consider the fact that you can't code your solution in this style until you have done so as a feature: you can't write code if you haven't really understood and solved the problem. (As opposed to imperative style which let's you implement a half done solution with hidde…
> Of course arriving at the Mathematical formula is the hard part, that's what it means to actually solve the problem. Most business problems can't be solved with a formula, or with a thousand formulas, or with a million formulas, especially if the problem is “our organization is an illogical clusterfuck” or “we don't even know what we should be doing”. > I consider the fact that you can't code your solution in this…
It can be helpful to look for generality and abstraction when solving problems. But it can be unhelpful to assume that general solutions and common abstractions must exist to an extent that makes a given solution more robust and efficient than a patchwork of partial solutions that explicitly handle corner cases.
A mathematician's definition of a sorted list is different to a programmer's at least in part because a mathematician is interested in a sorted list and a programmer is interested in sorting a list. This difference is intrinsically invariant of the programming paradigm (though not of the context).
This issue isn't so much that this post didn't convince me that there is an underlying, semantically relevant sense in which the APL approach is more mathematical, but that it didn't even seem to notice that this was a thing that needed to be argued.
Earlier quoted context omitted.
A good analogy would be music notation (pentagram) I could describe a piece of music in English prose, telling you were to put your fingers and for how long. The language itself would be easier to understand, but the efficiency of information transmission would be very low. Chinese looks complicated, unless you know Chinese. The ultimate criteria to judge a language should be how efficiently (concisely) it expresses…
> The ultimate criteria to judge a language should be how efficiently (concisely) it expresses the concepts of the subject matter. Some might say that the ultimate criteria to judge a language should be how quickly an inexperienced user starts to be fluent in it. I studied math (so the syntax isn't really an issue), but I think functional programming is completely inappropriate for general purpose programming tasks (…
Earlier quoted context omitted.
Understandability is more important than conciseness in a team environment. In a team, you're not writing code for you - you're writing code to be reviewed by other people, integrated with other people's code, and maintained by other people in the future. In the example from this article, all developers I've ever worked with would understand what the "good old C" example is doing within seconds. Most would understand…
> J is even worse. I stared at the J code for a full minute without any comprehension of the language syntax or what was being accomplished. That code isn't readable or maintainable. It is bad code. But why does code need to be readable to someone who doesn't know the language? Yes, it's true that Python and some other languages are pretty readable even to people who haven't written any of that language, and that is…
Writing terse readable code is great. Writing code that is so terse that it doesn't have variable names is an antipattern.