Re: The Weakness of Lisp
donal.k...@man.ac.uk
> The problem is that this easy extension is a reason why [Ruby] is one of
> the slowest script programming languages (only TCL is worse).
Do you have quantitative figures for that assertion, or is it based on
comparing with an ancient version like the 7.* series of interpreters
(which were indeed slow, but are also around 10 years old)? Or worse
still, are you just parrotting some random hearsay off "teh intarweb"?
If I introduce some actual information into this discussion
(http://shootout.alioth.debian.org/) we see that reality is much less
clear cut and everything depends on the specifics. On the other hand,
for the specific case of Tcl vs. Ruby,
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=tcl&lang2=ruby
indicates that Tcl usually smacks Ruby into the ground. :-)
[F'ups set; this isn't Lisp-related.]
Donal.
John Stoneham
Lothar is the developer of an IDE for Ruby, part of which required
custom rebuilding of the Ruby interpreter itself (if I remember
correctly), so I'd say he's very qualified to make such statements. The
Shootout is fun and all, but it hardly represents reality, much less
anything that is "clear cut".
Neil Madden
[...]
>
> Lothar is the developer of an IDE for Ruby, part of which required
> custom rebuilding of the Ruby interpreter itself (if I remember
> correctly), so I'd say he's very qualified to make such statements. The
> Shootout is fun and all, but it hardly represents reality, much less
> anything that is "clear cut".
Donal is one of the maintainers of Tcl and a member of the Tcl Core
Team, if you want to trade qualifications. But appeals to authority
don't make for great arguments. The shootout, while flawed, is at least
an attempt at providing empirical data. I think the point Donal was
making was not that Tcl is faster than Ruby (I wouldn't use either for
speed-critical tasks), but that it (Tcl) is not as slow as urban legend
would believe.
-- Neil
Donal K. Fellows
> I think the point Donal was
> making was not that Tcl is faster than Ruby (I wouldn't use either for
> speed-critical tasks), but that it (Tcl) is not as slow as urban legend
> would believe.
That was the point I started out to make, but I was surprised that Ruby
was slower for all shootout tasks except one that involved string
reversal (a known weak-point in Tcl's API[*]). That makes me suspect
that Ruby *might* be generally slower than Tcl.
Comparing with Perl, PHP and Python is also interesting. Of the three,
we're not that far off Perl and PHP (excepting things that require
string reversal) but Python is quite a bit faster on most of the
shootout measures. I wonder why that is?
Donal.
[* Should we do a [string reverse] operation? ]
Gerald W. Lester
> ...
> [* Should we do a [string reverse] operation? ]
While string reversal is a nice academic exercise, how often does one need
to do it in the real world?
In other words, does one really need to do it of then enough to justify
*any* effort to make that operation faster?
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Donal K. Fellows
> While string reversal is a nice academic exercise, how often does one need
> to do it in the real world?
Exactly, that's why we've not done [string reverse] yet. The only time
I've ever missed it has been when looking at our scores in the
shootout. :-) But I don't know that my code is representative, so this
is really a question for the community at large.
Donal.
Cameron Laird
Donal K. Fellows <donal.k...@manchester.ac.uk> wrote:
.
.
.
>Comparing with Perl, PHP and Python is also interesting. Of the three,
>we're not that far off Perl and PHP (excepting things that require
>string reversal) but Python is quite a bit faster on most of the
>shootout measures. I wonder why that is?
.
.
... while I generally regard Python as intrinsically *slower*
for many common operations. As Donal, Neil, and others well
know, there is a LOT of noise in this area.
suchenwi
Gerald W. Lester schrieb:
> While string reversal is a nice academic exercise, how often does one need
> to do it in the real world?
>
> In other words, does one really need to do it of then enough to justify
> *any* effort to make that operation faster?
>
I've used it for rendering Right-to-Left writings like Arab and Hebrew.
But with strings not longer than a line of text, Tcl's slowness never
disturbed me in those.
Darren New
> While string reversal is a nice academic exercise, how often does one
> need to do it in the real world?
The only time I used it was while sorting email addresses to try to
chunk them into domains, to make SMTP's life easier.
--
Darren New / San Diego, CA, USA (PST)
This octopus isn't tasty. Too many
tentacles, not enough chops.
Gerald W. Lester
> Gerald W. Lester wrote:
>> While string reversal is a nice academic exercise, how often does one
>> need to do it in the real world?
>
> The only time I used it was while sorting email addresses to try to
> chunk them into domains, to make SMTP's life easier.
Would you not be doing a list reversal in that case after spliting on @ then
spliting the end on "."?
Darren New
> Would you not be doing a list reversal in that case after spliting on @
> then spliting the end on "."?
At first I thoguht that was necessary, but it turned out not to be.
Reverse each address, sort the list, and reverse each again.
I didn't care if they went out in order. What I cared about is that many
AOL.com addresses ended up in the same transmission, so AOL would take
care of duplicating it for each mailbox instead of me.
Hence, it didn't really matter whether I sorted {COM AOL @ Fred} or
whether I sorted {MOC.LOA@DERF}.
The hackiness of that solution is the only reason it sticks out in my mind.
Larry Smith
> Comparing with Perl, PHP and Python is also interesting. Of the three,
> we're not that far off Perl and PHP (excepting things that require
> string reversal) but Python is quite a bit faster on most of the
> shootout measures. I wonder why that is?
Python's syntax permits a true compilation down to bytecodes.
It never needs to go back and recompile a string that may have
changed. That makes it much less flexible in terms of being
able to manipulate code as data, but it allows it to make some
assumptions about the program and run it much more quickly.
It's Lisp v. Fortran in the scripting language world.
--
.-. .-. .---. .---. .-..-.|Experts in Linux: www.WildOpenSource.com
| |__ / | \| |-< | |-< > / |"Making the bazaar more commonplace"
`----'`-^-'`-'`-'`-'`-' `-' |Check out my new novel: "Cloud Realm" at:
home:www.smith-house.org:8000|<-this url + /books/list.html
suchenwi
Larry Smith schrieb:
> Python's syntax permits a true compilation down to bytecodes.
> It never needs to go back and recompile a string that may have
> changed. That makes it much less flexible in terms of being
> able to manipulate code as data, but it allows it to make some
> assumptions about the program and run it much more quickly.
>
> It's Lisp v. Fortran in the scripting language world.
My nomination for QOTW! :)
Gerald W. Lester
> Gerald W. Lester wrote:
>> Would you not be doing a list reversal in that case after spliting on
>> @ then spliting the end on "."?
>
> At first I thoguht that was necessary, but it turned out not to be.
> Reverse each address, sort the list, and reverse each again.
>
> I didn't care if they went out in order. What I cared about is that many
> AOL.com addresses ended up in the same transmission, so AOL would take
> care of duplicating it for each mailbox instead of me.
>
> Hence, it didn't really matter whether I sorted {COM AOL @ Fred} or
> whether I sorted {MOC.LOA@DERF}.
>
> The hackiness of that solution is the only reason it sticks out in my mind.
>
I wonder if the following would not have been faster:
proc compareEmail {e1 e2} {
set e1 [lindex [split $e1 {@}] end]
set e2 [lindex [split $e2 {@}] end]
return [string compare $e1 $e2]}
}
set sortedEmailList [lsort -command compareEmail $unsortedEmailList]
Darren New
> I wonder if the following would not have been faster:
That would have made email to fr...@support.example.com wind up far away
from email to fr...@example.com, yes? Even though both would likely be
serviced by the same MX servers?
In any case, sorting the list was fast relative to actually delivering
the mail, looking up MX records to see if there were secondary hosts
that covered multiple domains, etc.
keithv
> [* Should we do a [string reverse] operation? ]
I'd rather have a list reverse function so I can invert keys and values
in a hash.
Keith
Donal K. Fellows
Now *there* is a good argument.
Donal.
Andreas Leitgeb
While the frequency might not be all that high, to me it appears
to be just one of the basic actions, that should just be there
regardless of usage-frequencies.
Also, "lreverse" for lists, qualifies as such, though I think that
list reversal may have even more practical use. (I vaguely
remember a couple of postings, where reverse list-iteration
was asked for, e.g. in the context of removing items from
listboxes by index.)
I'd opt for both, string and list reversal operations, unless they
were *really* complicated to implement. IOW, it *does* justify at
least some little effort, imo.
suchenwi
Andreas Leitgeb schrieb:
> I'd opt for both, string and list reversal operations, unless they
> were *really* complicated to implement. IOW, it *does* justify at
> least some little effort, imo.
String reversal may be slightly more complex because of varying width
of utf-8 characters. But given an efficient lreverse, it would be no
big deal to
join [lreverse [split $string ""]] ""
like we do in pure Tcl too... :)
Donal K. Fellows
> String reversal may be slightly more complex because of varying width
> of utf-8 characters.
Ah, but the real trick is that we shouldn't try to handle that case. :-D
Instead, we should just use Tcl's transparent string shimmering to get
rid of the difficult case.
Donal.
Donal K. Fellows
I've written a TIP on this; review/comment is welcome.
http://tip.tcl.tk/272.html
It proposes adding [lreverse] and [string reverse], using the obvious
semantics.
Donal.
Robert Hicks
> Also, "lreverse" for lists, qualifies as such, though I think that
> list reversal may have even more practical use. (I vaguely
> remember a couple of postings, where reverse list-iteration
> was asked for, e.g. in the context of removing items from
> listboxes by index.)
>
related to listboxes). : )
The reason I asked is that Tcl is the "string" language but had no
built in to do a reverse which other languages I have used did. I
thought it a strange omission.
I am glad a TIP was done.
Robert