4 ms·

> A function gets less readable as you have to go context switch to more and more different functions to understand what it's doing. This is true. A function

by scubbo 2y ago

> A function gets less readable as you have to go context switch to more and more different functions to understand what it's doing. This is true. A function also gets less readable every time you have to mentally translate from low-level implementation code, to a high-/human-level description of "what is this actually doing?" (e.g. `val := a[len(a)-idx-1]` - "ohhh, ok, that's iterating in reverse"). Extracting out common patterns to methods with well-known names like `Filter` or `Map` or `ForEach` short-circuits that repeated parsing. > that doesn't save you from having to dive into each one. 99% of the time, it really does. If you can't trust something as basic and well-defined as `Map` to do what you expect it to do, you've chosen a poor library on which to take a dependency.

margalabargala 2y ago
> 99% of the time, it really does. If you can't trust something as basic and well-defined as `Map` to do what you expect it to do, you've chosen a poor library on which to take a dependency. The original comment said: it = slices.Map(it) I understand Map taking an array and a function, as in the article. I don't understand Map taking simply an array. Then I went to look it up, and turns out that slices.Map does not in fact exist. https://pkg.go.dev/slices https://pkg.go.dev/slices Personally I feel like this exchange is a vivid illustration of exactly my original point.
- scubbo 2y ago
  The facts that GoLang is missing such a fundamental tool from its standard library, and that it's easy to make typos when coding not in an IDE, hardly support your point. In fact, the very fact that you originally thought of the correct interpretation despite the fact that it had been misrepresented is a great example of why common shorthands are useful.
  - margalabargala 2y ago
    I suppose there are different sorts of programmers who prefer different levels of guardrails pre-made for them. Some people consider `Map` to be a fundamental tool. Like the original commenter mentioned, some people also prefer Typescript to Go. If I was interviewing someone for my (primarily golang) company and they mentioned that not having `Map` to be a downside of Go that hindered its readability, that would be a strong mark against them. I would not want to try to dig through the N levels of abstraction they would create in the codebase to hide what was happening with all its bugs. Other companies don't mind this, and use other languages, like Javascript or the latest versions of Python. Python in particular is great for what you mention, as nearly every slightly common programming idiom has its own keyword with its own special usage, so you can always use that instead of writing the fundamentals yourself. Personally I hate Python because I prefer not to have to learn a dozen new obscure tools and keywords with each minor language release. I dislike trying to read packages written in Python, because they use whatever 20% subset of the language the author was aware of. I like Go because I can look at the source code for nearly any function in nearly any library and understand it immediately. Nobody would import "leftpad" in Go. Different languages for different people.
    - scubbo 2y ago
      I really like how you've presented this (despite disagreeing as a point of personal preference on almost every point you make :) ). I'm baffled by the level of repetition and verbosity that Gophers seem to prefer - but I also can't deny that they've created some truly astonishing tools and projects, despite having to reimplement core concepts over and over again! Clearly, it works for them. As you say, different languages for different people. Best of luck to you, and thank you for an insightful and civil discussion :)

by scubbo 2y ago

margalabargala 2y ago

> 99% of the time, it really does. If you can't trust something as basic and well-defined as `Map` to do what you expect it to do, you've chosen a poor library on which to take a dependency. The original comment said: it = slices.Map(it) I understand Map taking an array and a function, as in the article. I don't understand Map taking simply an array. Then I went to look it up, and turns out that slices.Map does not in fact exist. https://pkg.go.dev/slices https://pkg.go.dev/slices Personally I feel like this exchange is a vivid illustration of exactly my original point.

scubbo 2y ago
The facts that GoLang is missing such a fundamental tool from its standard library, and that it's easy to make typos when coding not in an IDE, hardly support your point. In fact, the very fact that you originally thought of the correct interpretation despite the fact that it had been misrepresented is a great example of why common shorthands are useful.
- margalabargala 2y ago
  I suppose there are different sorts of programmers who prefer different levels of guardrails pre-made for them. Some people consider `Map` to be a fundamental tool. Like the original commenter mentioned, some people also prefer Typescript to Go. If I was interviewing someone for my (primarily golang) company and they mentioned that not having `Map` to be a downside of Go that hindered its readability, that would be a strong mark against them. I would not want to try to dig through the N levels of abstraction they would create in the codebase to hide what was happening with all its bugs. Other companies don't mind this, and use other languages, like Javascript or the latest versions of Python. Python in particular is great for what you mention, as nearly every slightly common programming idiom has its own keyword with its own special usage, so you can always use that instead of writing the fundamentals yourself. Personally I hate Python because I prefer not to have to learn a dozen new obscure tools and keywords with each minor language release. I dislike trying to read packages written in Python, because they use whatever 20% subset of the language the author was aware of. I like Go because I can look at the source code for nearly any function in nearly any library and understand it immediately. Nobody would import "leftpad" in Go. Different languages for different people.
  - scubbo 2y ago
    I really like how you've presented this (despite disagreeing as a point of personal preference on almost every point you make :) ). I'm baffled by the level of repetition and verbosity that Gophers seem to prefer - but I also can't deny that they've created some truly astonishing tools and projects, despite having to reimplement core concepts over and over again! Clearly, it works for them. As you say, different languages for different people. Best of luck to you, and thank you for an insightful and civil discussion :)