Tamreen:
Thank you. Your posts really explained why it is so. I understand the
reasons now, but I can hardly agree those reasons are good ones (not
arguing with you, as you pointed out, the reasons are weak for this case).
As I pointed out before in my other post ("General subsequence function"),
mixing abstraction with speed path is really a bad idea, and might be a
classical example of what Rich called "complecting". In practice, it did
not achieve what it tries to achieve either (one of the big complaints I
read from the Web about Clojure is it is really hard to know the speed
performance). For speed, the classical solution is:
1. Put good documentations on the functions, and the programmer needs to
have some idea what data structure is fast/slow for what use. If the
programmer does not have a clue, why would making "last" artificially slow
on vectors help? Plus, whether one data structure is slower than the other
for certain operations can also be an implementation detail that may change.
2. Use a profiler, so you can keep optimizing on the current hot spots.
The above solution has no interference with abstraction.
On Thursday, June 28, 2012 11:08:35 PM UTC-4, puzzler wrote:
>
> On Thu, Jun 28, 2012 at 6:59 PM, Tamreen Khan <histor...@gmail.com> wrote:
>
>> Here's a somewhat old but still generally useful article on how Clojure
>> vectors are implemented:
>> http://blog.higher-order.net/2009/02/01/understanding-clojures-persistentvector-implementation/
>>
>>
>> Vectors are optimized for random access, whereas lists are optimized for
>> going through from the beginning to the end, which is exactly what the last
>> function does.
>>
>>
>>
> This doesn't really address the underlying question.
>
> nth is a good example of a function that is fast for vectors, strings, and
> arrays, and only for lists uses the slower sequential implementation.
>
> There's no technical reason that last couldn't do the same, dispatching on
> the underlying type to have a more efficient implementation for data types
> that support it.
>
> The real reason is this: With the glaring exception of nth, Clojure tends
> to eschew functions with a fast path and a slow path, because programmers
> shouldn't have to do deep semantic analysis of their code to figure out
> which will get chosen. In this case, however, we're talking about a
> function that is currently always slow. Surely it would be a win to make
> it have a faster path in a large number of cases, right? Well, the
> argument against that is eventually people would start to rely on it being
> fast for so many collection types, and then get burned when somehow their
> collection accidentally gets turned into a seq before last is called on
> it. The theory is that it's better to force people to use a different
> function call, namely peek, to retrieve the last element quickly from a
> vector.
>
> Honestly though, despite David Nolen's claim that this design decision
> will be obvious if you've coded enough Clojure, I've been programming in it
> for around 3-1/2 years, and I think the argument behind this design
> decision is a relatively weak one, so you are not making an unreasonable
> request. In fact, the more I code in Clojure, the more I see that there
> are a number of core functions that require significant semantic analysis
> of the surrounding context to know how they will behave. Either Clojure
> trusts that programmers can make determinations about the types of their
> collections or it doesn't. Which is it? Well, I'd argue there's a large
> body of evidence that under Clojure's current design, it's clear that you
> better know what you're doing. If that's the case, why not go ahead and
> make last fast when it can be fast?
>
> Nevertheless, I hope I've clarified the reasoning behind the current
> design. Early Clojure design decisions have a lot of inertia, so as David
> pointed out, this is very unlikely to change.
>
--
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
