13 ms·
> One example of Go's lack of expressiveness is that loops are not abstracted away, e.g. you can't use higher level constructs like map and filter on collection
by sagichmal 7y ago
> One example of Go's lack of expressiveness is that loops are not abstracted away, e.g. you can't use higher level constructs like map and filter on collections.
This is (or was) deliberate, with the rationale being that it makes O(n) blocks of code trivial to identify in review.
Whether or not you buy that argument is a separate thing, of course.
- coldtea 7y ago>This is (or was) deliberate, with the rationale being that it makes O(n) blocks of code trivial to identify in review. Whereas, greping for .map(), .filter(), .reduce() wouldn't?
- azth 7y ago> This is (or was) deliberate, with the rationale being that it makes O(n) blocks of code trivial to identify in review. Like how for (int i = 0; i < strlen(str); i++) { ... } is O(n)?
- coldtea 7y agoLet's give them the benefit of the doubt, and consider that they meant that: for (int i = 0; i < strlen(str); i++) { ... } could be grepped and easily discerned from: for (int i = 0; i < str_length; i++) { ... } and generally, that every looping point could be easily identified. After all, if you call functions inside the body, all bets are off as to what complexity the loop means anyway...
- h_r 7y agoCan you explain why you think it makes O(n) blocks trivial to identify? How is such identification made easier by manually writing out a `for` loop applying a function foo to each element rather than writing `map foo myCollection`?
- tfha 7y agoThe way many people read code, it's much easier to overlook three characters than it is to overlook three lines with indentation.
- h_r 7y agoThat's quite an interesting, if frightening, take on it. Assuming a developer knows what `map` does, then I wouldn't have very much confidence in their reading comprehension if they somehow mentally skipped over the main higher order function being called on a three word line of code. Would anyone expect such a developer to read and parse several more lines of code more reliably, in order to understand the algorithmic complexity? Seems unwarranted to me...
- tfha 7y agoHumans make mistakes. People code review after exhausting days or late at night. Or sometimes they skim more than they intended to. You want to make problems in the code obvious everywhere that you can. In programming, if you miss an important detail the repercussions can be high. In a million line codebase every idiom that's slightly more complex than it needs to be is going to result in dozens of additional bugs, sheerly because of the increased surface area for making mistakes with that idiom.
- h_r 7y agoI agree with everything you've said here but being mentally exhausted doesn't make it more likely that you can read even more lines of code in a more reliable fashion. I think the clue to your thinking, for me, is in your description of the `map` HOF as "slightly more complex". Having years of experience with both paradigms, I've found that grokking a call to one of these fundamental building blocks (map, filter, reduce, fold, etc) is nearly instantaneous. We've all experienced reading prose where the author was excessively verbose when the same point could have been made succinctly. It feels the same way reading for loops once you get over the learning curve of these very basic functional constructs. You have to keep repeating that boilerplate endlessly and it's very tedious to keep writing and reading it.
- temac 7y agoSo how does it work exactly? Are functions forbidden?
- sagichmal 7y agoFunctions (and methods) are the only way to "hide" computation and allocation in Go. That rubric makes reading Go code to build mechanical sympathy relatively straightforward.