On Saturday, June 30, 2012 9:51:56 AM UTC-4, stuart....@gmail.com wrote: > > Having separate "peek" and "last", with documented performance > characteristics, makes it straightforward to reason about how code is > likely to perform, a point that Mark made earlier. > > As I said before, I strongly feel mixing abstraction and speed path is the wrong direction to take. Let me elaborate a little bit more:
1. What's the purpose of high level language and dynamic typing? To abstract so we can be more efficient in writing code (Note: code itself my not run fast) and the code is easier to read and maintain. Statically typed language has less abstraction power (although it still tries hard with things like C++ templates), but faster. Dynamic language has higher abstraction power but slower performance. So it is wrong to me to throw away the strength of abstraction of a dynamic language in pursuit of performance. Performance is of course important, but not at the expense of broken abstraction. Maybe that can be done on rare cases that may have a huge impact of performance on the whole system, but it seems wrong to do it as a "design choice". 2. The argument that if a function takes its pre-designated speed characteristics, even when its possible to be faster on a particular type, will encourage better code performance or performance analysis, is a very convoluted one. If you say: by making "last" slow on vectors, it will force people to use "peek", then why not make it even slower on vectors? (how about putting a "sleep" there for vectors?). If you say "no, no, sometimes people may still use "last" on vectors and we still want the best performance in that case", then why not make it as fast as we can? 3. Maybe we don't have one now, but we will have a profiler in the future if the language will be put into serious use. With a profiler you can see where the performance bottleneck is, and a programmer can reason "Ah, this part is slow because I used "last" on a large list", give we already documented that "last" will take linear time on lists. So he can choose the right data type instead of switching functions. If the abstraction is done right, switching a data type should not be difficult. It is a fundamental design principle of Clojure that, when given two > approaches, A and B, make primitive the one that could be used to build the > other. Clojure's "peek" and "last" might be useful to somebody building > the "last" that Warren wants. Warren's "last" is *useless* for building > the "peek" and "last" that Clojure already has. > > > Not arguing against having Warren's "last". Just saying that c.c/last > ain't broken, and is simpler. > > I don't understand the argument that because a higher level function cannot be used to build a lower level function, so it is not worth working on or fixing. We can build Clojure with Java but Clojure cannot be used to build Java, so we don't need to work on Clojure? Keeping both type specific low level functions and abstraction level function is less of a problem to me, but I would avoid it if possible. Stu > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
