Re: Linked lists (was osascript - path to me)
Re: Linked lists (was osascript - path to me)
- Subject: Re: Linked lists (was osascript - path to me)
- From: email@hidden (Michael Sullivan)
- Date: Mon, 20 May 2002 15:02:07 -0400
- Organization: Society for the Incurably Pompous
email@hidden (Christopher Nebel) writes:
>
Here's my thinking:
>
1. Linked lists aren't documented anywhere aside from the 1.1 release
>
notes.
>
2. They're essentially useless right now, because the only operations
>
for which they're more efficient than vectors (i.e., insertion and
>
deletion) don't work. Of course, we plan to fix that, at least for
>
vectors.
>
3. They're not entirely supported as it is -- they don't support a bunch
>
of the properties vectors do.
>
4. They're not functionally equivalent to vectors -- "set" has radically
>
different behaviors in some cases, and it's not always easy to predict
>
where or why. (This is not a bug -- it's inherent in the data
>
structures. We could perhaps make linked lists act like vectors, but it
>
would tend to destroy the performance advantages.) This means that you
>
can't just flip your script from one to the other without looking at it
>
very carefully.
>
5. Having an extra class increases the implementation and documentation
>
work accordingly.
>
6. I'm uncomfortable philosophically with asking scripters to make a
>
decision between two subtly different data structures purely for
>
performance reasons. AppleScript is supposed to be useful to people who
>
don't know Computer Science and don't particularly want to know. I want
>
to reduce the number of data types scripters have to deal with, not
>
increase it.
In general I agree with your thinking. I tend to like being able to
make certain kinds of specifications when necessary because it's hard to
predict what will happen when you get the code out into the real world.
But I agree that a scripter shouldn't typically have to think about how
a structure is implemented. On modern hardware, only very large
problems should have a major problem with occasional O(n) behavior, as
long as it's at the compiled level.
The big question is: how scalable do you want applescript to be? If
the 5-10 year vision includes people being able to write workflows in
applescript on terabytes of data run on clusters of mac servers (the way
that Perl and Python are going on other platforms), then you're probably
going to need to support all of the fundamental data structures and
their combinations (ll, dll, btree, generic tree, vector, htable)
(either that or support pointers and casts :)).
If you're willing to limit your vision of applescript to creating small
scale programs, or driving scriptable programs that can handle the giant
data sets (which is perfectly reasonable, IMO -- if I want to drive big
iron, I would normally write in a compiled language anyway), then having
nothing but vectors and hash tables with all the standard functions
implemented efficiently at the compiled level is plenty good enough.
>
As for the lengths people will go to to find the most efficient way to
>
script something, I have a theory: I suspect the only reason it's such a
>
popular "sport" is that AppleScript is so ^#@!ing slow. If we could
>
remove the performance drags and support real object model operations so
>
scripters didn't have to write hand-coded loops and copy list data back
>
and forth all the time, people would be comfortable writing their
>
scripts the way the founders intended. Or do people spend time on this
>
just because they think it's fun?
Well... It can be kinda fun, but if applescript weren't so slow at some
things, I'd find other problems to work on that would also be fun, and
I'd end up getting a lot more accomplished. So yes, I agree.
If the two existing data structures were implemented a bit more flexibly
and efficiently, such that all the basic O(n) and worse operations on
them were written at the compiled level as part of the native language
-- then I wouldn't care what data structure or algorithms were used
internally to implement them.
As it is, I can only guess at how records and lists are implemented now.
What I know about them is their performance characteristics. And, well,
in some cases they just aren't good enough, or they can only be made to
be good enough by a lot of creative programming.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT email@hidden
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.