11–20 of 28 posts
Earlier quoted context omitted.
The setup needs a little boilerplate, but it's definitely possible. And it can support different sort orders after writing the boilerplate once. For those wanting to test drive it: http://play.golang.org/p/I_Vu34hUoV
Interesting! Could you explain why []rune needs to be wrapped in a struct{Runes []rune}? Rather then just calling "type Runes []rune"?
Clickbait headline aside, I think Go threw some baby out with the bathwater in the march to simplicity. An example; try to sort a slice of runes.
The setup needs a little boilerplate, but it's definitely possible. And it can support different sort orders after writing the boilerplate once. For those wanting to test drive it: http://play.golang.org/p/I_Vu34hUoV
I don't think Go's concurrency model is as successful as others.
Earlier quoted context omitted.
Interesting! Could you explain why []rune needs to be wrapped in a struct{Runes []rune}? Rather then just calling "type Runes []rune"?
It doesn't need to. You could also write type Runes []rune but the struct variant has the advantage that you can get the array back without any conversions - it's pretty cheap. And you can embed it. That's an advantage if you e.g. don't define Less on Runes but define it on RunesAsc and RunesDesc. See http://golang.org/pkg/sort/ -> Examples (SortWrapper)
Earlier quoted context omitted.
The setup needs a little boilerplate, but it's definitely possible. And it can support different sort orders after writing the boilerplate once. For those wanting to test drive it: http://play.golang.org/p/I_Vu34hUoV
yep, so the point of that example was that there isn't a sort.Runes() convenience method, and you have to roll your own (like with any custom type). which is a mild problem to be certain, but there are lots of other little corner cases like this.
For me, next to everything from Microsoft is an example for a horrible api, the one from Javas standard library is rather meh and Go is pretty much the greatest thing since bread came sliced.
Earlier quoted context omitted.
Interesting! Could you explain why []rune needs to be wrapped in a struct{Runes []rune}? Rather then just calling "type Runes []rune"?
It doesn't need to. You could also write type Runes []rune but the struct variant has the advantage that you can get the array back without any conversions - it's pretty cheap. And you can embed it. That's an advantage if you e.g. don't define Less on Runes but define it on RunesAsc and RunesDesc. See http://golang.org/pkg/sort/ -> Examples (SortWrapper)
I don't think Go's concurrency model is as successful as others.
Earlier quoted context omitted.
yep, so the point of that example was that there isn't a sort.Runes() convenience method, and you have to roll your own (like with any custom type). which is a mild problem to be certain, but there are lots of other little corner cases like this.
I believe that's a good thing - I prefer a small api surface to a large one and I don't want to spend time digging through never ending functions to locate what I have to use. For me, next to everything from Microsoft is an example for a horrible api, the one from Javas standard library is rather meh and Go is pretty much the greatest thing since bread came sliced.
instead of three separate functions for len, swap and less, you'd just have one function
collection.sort(a => a.foo)
the swap and len functions are part of the collection type. the less function would be part of an interface on whatever type foo is.
it's not so much about api verbosity as not having to write the same functions over and over.
it's possible from a pure performance perspective that setting up the closures is bad but it's something i'd be willing to take for that much less code to write.
Earlier quoted context omitted.
yep, so the point of that example was that there isn't a sort.Runes() convenience method, and you have to roll your own (like with any custom type). which is a mild problem to be certain, but there are lots of other little corner cases like this.
I believe that's a good thing - I prefer a small api surface to a large one and I don't want to spend time digging through never ending functions to locate what I have to use. For me, next to everything from Microsoft is an example for a horrible api, the one from Javas standard library is rather meh and Go is pretty much the greatest thing since bread came sliced.
Note that I have no idea what a Rune is. But, you should check out Clojure's api. Here's a cheatsheet: http://clojure.org/cheatsheet
See also: http://stackoverflow.com/questions/6016271/why-is-it-better-...
BTW, I'd bet it takes longer to write a sort function than it does to search through api documentation and find one.
It has a mediocre type system, bad support for genericism, too much reliance on non-extensible language keywords (range, make, etc.). Want to range over a tree? Too bad. Or maybe wrap the tree with a chan and watch performance and simplicity go out the window.
I mean, come on, what modern language actually recommends casting to the top type? That would be like if idiomatic C++ involved casting things to void*, or if idiomatic java involved casting things to Object, just so you can write generic functions and types.