[bigdubs]

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.

[arnehormann]

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.

[tieTYT]

"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." —Alan Perlis

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.

[bigdubs]

so what this is getting at more is that lambdas are a critical part of a language; the "genericness" they provide keeps you from having to write a sort method for each of your types.

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.