On Friday, September 16, 2011 14:24 bearophile wrote: > Jonathan M Davis: > > but is the overhead of creating a tuple to do that > > warranted in a systems programming language? > > This is an interesting point. My experience shows that while you write code > there are situations where you care for performance, even a lot. In such > situations a system language must give you ways to get the performance you > need. > > But there are many other situations where you know performance is not the > most important thing, because it's in a less critical path, because you > know you will sort only few items once in a while, or because you are > writing a 20 lines long script-line program. In such situations you want > to write less code (because less code often means less testing, less bugs, > less code to read and modify), you want higher level code (because this > makes the program simpler to understand and to think about). Such > situations are common, and in my opinion in them a good language has to > give you higher level ways to do what you need to do. This is multi-level > programming. > > A max function that takes an unary key function that returns a 2-tuple > built on the fly is probably not the most efficient code. But it's very > short (especially if your language gives a succint syntax for tuples and > lambdas), it's not bug-prone and it's quite handy and easy to to > understand and to think about. So I'd like it in Phobos. > > A system language has to give you ways to be efficient, and probably it > also has to offer ways to show and put in evidence where you are not doing > things efficiently (like a compiler switch that lists all heap allocations > of a module, or all its heap closures), but I don't want it to force me to > write low-level code where I don't want to do it. There are plenty of > situations where writing low-level code is not the best thing to do.
Indeed, there are a lot of cases where it's just nicer to have higher level code even if it's less efficient, but the difference between writing min!"a.length < b.length" and min!"a.length" is negligible, and it does have cost some overhead. Writing the comparator function instead of using a tuple with a unary key is certainly worse in terms of the amount of code, but the overhead is worse too. I really don't think that the benefit outweighs the cost. And while a particular call to min may not need to be all that efficient all of the little inefficiencies add up. I'm not opposed to there being a separate argmax function which takes a unary key, but in general, I think that taking a binary function is by far the superior solution, and I'd hate to see the default choice for anything to be a unary key. The small, incremental gain in shortness of code is outweighed by the cost in efficiency and expressivity IMHO. - Jonathan M Davis
