Sorry, I should have addressed my last post to "puzzler".
On Friday, June 29, 2012 10:51:44 AM UTC-4, Warren Lynn wrote:
>
>
> 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
