12 ms·

There are a lot of comments in that thread, is there anything specific you think stands out? Some of Ian's initial comments were saying that they are being ver

by kyrra 12y ago

There are a lot of comments in that thread, is there anything specific you think stands out? Some of Ian's initial comments were saying that they are being very very careful about what gets added to the language. Also, at this point the language syntax itself is basically locked. And from everything I've seen, they are focusing more on the runtime and tooling before they make any serious changes to the code language.

exacube 12y ago
I think Ian (who works on Go) summed it up nicely. To paraphrase: yes map/reduce is useful but it's another built-in generic so it adds a lot of complexity and it's not worth the trade-off. This rounds back into Go's generics debate. If they give in with implementing map/reduce, they might as well start implementing some form on generics. I think Go is for people who are in-line with the golang crew's views on language design. For the rest, use any other strongly typed language that has sort form of type-abstraction/generics (which pretty much they all do).
- emmelaich 12y ago
  It's useful to know Ian's background too; he's the author of the gold linker (http://en.wikipedia.org/wiki/Gold_(linker) http://en.wikipedia.org/wiki/Gold_(linker) so would be intimate with the sort of problems that generics and map and reduce would introduce to the compilation pipeline. To a language user the benefits might be clear but the problems not. To a language implementor the problems will be much clearer.
- Rapzid 12y ago
  A thousand times this. If somebody were to go through the process of actually trying to implement a generic map function in the current Go they would get a good sense of just what the issues are. Unfortunately you need a good grasp of the type system and this just isn't something most of the commenters on this subject have; the Go community is much more qualified. I've done this and generics are the first road block but after consigning to working around that you run into a lot of Go implementation details around interface{} and type assertion so that what you end up with is actually quite verbose in practise and no more desirable than the alternative.. I decided that for me, for loops aren't so bad. So it does just come back around to generics but people are solving this with code generation, like gen which looks very interesting, and I imagine that is quite acceptable for the time being, for those who really want it.
alkonaut 12y ago
I'm thinking of the crowd that insists "map" is never more useful or readable than s straight for-loop. So not only don't they want it in go (which could be understandable in some situations), they genuinely seem to think it has no place in an imperative language. That blows my mind.
- jaekwon 12y ago
  I've written in both paradigms and I mostly agree with the Go team. That it blows your mind blows mine, and I suppose it's good that we have these choices so we don't have to agree. Could you show me a code snippet of maps and filters used that you believe is more readable than for loops? Maybe I'll get a laugh out of that. :)
  - alkonaut 12y ago
    A for loop is a general tool. It can be used for anything. Because of that, it conveys little or no information. As a reader I have to read the loop in detail to see that what it does is perform a mapping, and not something slightly different (the last item could be skipped, etc etc). The expressiveness of higher order functions comes not from terseness (only) but by expressing intent more clearly. E.g this expresses (in pseudo) A conversion followed by a filter. > odd_ints = strings.map(parseInt).select(odd) This was expressed in the forum, but there was no agreement that this was readable, so I fully expect you to also think the for loop to be more readable. I suspect there is a divide between those who prefer reading how something is done rather than what is intended, in order to understand it.
    - jaekwon 12y ago
      Ok, that's a good example. Your one-liner is pretty concise and the intent is clear. I think on a higher level with complex code, you definitely want better abstractions to convey intent, rather than say just having one large function that does everything. I think in many cases map/filter does in fact help with readability of intent, especially if you're not declaring the function body inline, and the functions are commonly available ones like parseInt. But generally this isn't the case, which diminishes the readability such that it's comparable to a for-loop anyways. I spend most of my time trying to figure out exactly that -- the higher level abstractions that aren't easily conveyed by "map" or "filter", that having map/filter generic functions isn't high on priority. I just want a simple language that I can spew out thoughts onto uncompilable code... tweak the code often as I see fit, and work on fixing type errors later and once I'm done with that it will probably run fine with few bugs. The nice thing about for-loops is that it exposes more control points e.g. breaking out early, using the index, inserting log lines -- that the flexibility helps me mutate the code quickly. So maybe it's more about coding style, rather than readability. Do you like to spec out your code completely before writing things down, or do you prefer to define the spec as you write and edit the code because it helps you get things done faster?

by kyrra 12y ago

exacube 12y ago

I think Ian (who works on Go) summed it up nicely. To paraphrase: yes map/reduce is useful but it's another built-in generic so it adds a lot of complexity and it's not worth the trade-off. This rounds back into Go's generics debate. If they give in with implementing map/reduce, they might as well start implementing some form on generics. I think Go is for people who are in-line with the golang crew's views on language design. For the rest, use any other strongly typed language that has sort form of type-abstraction/generics (which pretty much they all do).

emmelaich 12y ago
It's useful to know Ian's background too; he's the author of the gold linker (http://en.wikipedia.org/wiki/Gold_(linker) http://en.wikipedia.org/wiki/Gold_(linker) so would be intimate with the sort of problems that generics and map and reduce would introduce to the compilation pipeline. To a language user the benefits might be clear but the problems not. To a language implementor the problems will be much clearer.
Rapzid 12y ago
A thousand times this. If somebody were to go through the process of actually trying to implement a generic map function in the current Go they would get a good sense of just what the issues are. Unfortunately you need a good grasp of the type system and this just isn't something most of the commenters on this subject have; the Go community is much more qualified. I've done this and generics are the first road block but after consigning to working around that you run into a lot of Go implementation details around interface{} and type assertion so that what you end up with is actually quite verbose in practise and no more desirable than the alternative.. I decided that for me, for loops aren't so bad. So it does just come back around to generics but people are solving this with code generation, like gen which looks very interesting, and I imagine that is quite acceptable for the time being, for those who really want it.

alkonaut 12y ago

I'm thinking of the crowd that insists "map" is never more useful or readable than s straight for-loop. So not only don't they want it in go (which could be understandable in some situations), they genuinely seem to think it has no place in an imperative language. That blows my mind.

jaekwon 12y ago
I've written in both paradigms and I mostly agree with the Go team. That it blows your mind blows mine, and I suppose it's good that we have these choices so we don't have to agree. Could you show me a code snippet of maps and filters used that you believe is more readable than for loops? Maybe I'll get a laugh out of that. :)
- alkonaut 12y ago
  A for loop is a general tool. It can be used for anything. Because of that, it conveys little or no information. As a reader I have to read the loop in detail to see that what it does is perform a mapping, and not something slightly different (the last item could be skipped, etc etc). The expressiveness of higher order functions comes not from terseness (only) but by expressing intent more clearly. E.g this expresses (in pseudo) A conversion followed by a filter. > odd_ints = strings.map(parseInt).select(odd) This was expressed in the forum, but there was no agreement that this was readable, so I fully expect you to also think the for loop to be more readable. I suspect there is a divide between those who prefer reading how something is done rather than what is intended, in order to understand it.
  - jaekwon 12y ago
    Ok, that's a good example. Your one-liner is pretty concise and the intent is clear. I think on a higher level with complex code, you definitely want better abstractions to convey intent, rather than say just having one large function that does everything. I think in many cases map/filter does in fact help with readability of intent, especially if you're not declaring the function body inline, and the functions are commonly available ones like parseInt. But generally this isn't the case, which diminishes the readability such that it's comparable to a for-loop anyways. I spend most of my time trying to figure out exactly that -- the higher level abstractions that aren't easily conveyed by "map" or "filter", that having map/filter generic functions isn't high on priority. I just want a simple language that I can spew out thoughts onto uncompilable code... tweak the code often as I see fit, and work on fixing type errors later and once I'm done with that it will probably run fine with few bugs. The nice thing about for-loops is that it exposes more control points e.g. breaking out early, using the index, inserting log lines -- that the flexibility helps me mutate the code quickly. So maybe it's more about coding style, rather than readability. Do you like to spec out your code completely before writing things down, or do you prefer to define the spec as you write and edit the code because it helps you get things done faster?