5 ms·
With regard to the functional-style "map" function, is it really that much less typing than a simple for loop? output := make(output_type, len(input)) for
by cmccabe 13y ago
With regard to the functional-style "map" function, is it really that much less typing than a simple for loop?
output := make(output_type, len(input))
for idx, e := range(input) { output[idx] = convert(e) }
compared to:
output := map(input, func(in input_type) output_type {
return convert(in)
}
)
There are cases where functional programming can be a lot terser (for better and worse), but I don't think this is one of them. My guess is that the original poster is just adjusting to different ways of doing things between Golang and Ruby-- that's natural.
My biggest complaint about Go so far is that you have to use an external library to get an ordered tree structure. Maps suffice most of the time, but sometimes you need ordering.
[edit: fixed map example]
- comex 13y agoThe second example should be output := map(convert, input) After all, map generally handles fetching the element from the array.
- pcwalton 13y ago> There are cases where functional programming can be a lot terser (for better and worse), but I don't think this is one of them. That's only true in Go because Go doesn't have type inference for closures. In ML for example this would be: let output = map (fn i -> convert i) input or, more succinctly: let output = map convert input
- cmccabe 13y agoYes, that's true. I just wanted to address the specific suggestion that the original author made. Languages make a whole set of related design choices and typically none of them makes sense without considering the others. (Sometimes none of them makes sense AFTER considering the others, but that's another story.)
- jacques_chester 13y agoLoops impose, and guarantee, ordered traversal of a collection. Maps do not. This means that maps can sped up by dividing up the collection into smaller parts and mapping each of them in parallel. For a language that has concurrency as a central design motivation, it's an unfortunate omission. As we say in the database world: think in sets, not in arrays.
- cmccabe 13y agoIt's an imperative language, not a declarative one. The issue is not ordering (traversal over maps in golang is not ordered), but side effects. SQL is great. Not all languages have to be SQL.
- jacques_chester 13y agoAssembler is great too, but not all languages have to be assembler. The modern looping construct imposes order not by design, but by historical accident. Working with a collection of data in assembler works by proceeding through memory addresses in linear order and then jumping back to the top. That pattern got lifted into higher level languages via the DO loop in Fortran. It's an example of path dependency. Why do we assume that loops are the only natural way to deal with collections? Because that's just how the path of history unfolded. I think the die was cast when it turned out to be easier to build Turing machines than lambda calculators. Edit: I don't know who downvoted you, but I hope it was an accident.
- icebraining 13y agoIt's an imperative language with side-effects, unordered mapping would break expectations and produce buggy code. You can still achieve those speed ups, you just need to be explicit about the division (e.g., by creating a channel, launching goroutines and then collecting the results). https://sites.google.com/site/gopatterns/concurrency/parallel-for-loop https://sites.google.com/site/gopatterns/concurrency/paralle...
- jacques_chester 13y agoI'm not talking about what Go is; I'm more interested in what it might have been. There's nothing in the law that prevents mapping with side effects. If the side-effects don't require a particular order, why constrain them?
- icebraining 13y agoI'm not talking about what Go is; I'm more interested in what it might have been. Well yes, but there are certain core concepts that define Go, and being imperative with side-effects is one of them. If we drop that, then we're no longer discussing Go but some hypothetical language. There's nothing in the law that prevents mapping with side effects. If the side-effects don't require a particular order, why constrain them? But they aren't constrained, they just aren't built-in. Go has loops, not maps, but if one wants to make a mapping function, the link I posted shows there's no constraint in having it execute out of order.
- NateDad 13y agoI started writing this exact post before I saw yours. It boggles my mind that programmers complain about having to write four lines of code (if properly formatted, which yours is not... but I'm guessing the people that complain about not having a map function also complain about gofmt :)
- zeckalpha 13y agogofmt is the one feature that I think every language designer should steal from go.