Erik Naggum <e...@naggum.no> writes: > | If you don't like the "dialect of X" terminology, then perhaps "member of > | the X family" would be better, but in my mind they mean the same thing.
> it seems to mean the same thing only when X = Lisp.
I think it most likely is the case that "dialect of Lisp", in its "traditional" Lisp-world usage, employs a nonstandard sense of "dialect". But that way of talking about Lisp-family languages is so common that we're going to have to live with it for some time to come.
Barry Margolin <bar...@bbnplanet.com> writes: > In article <3115018001706...@naggum.no>, Erik Naggum <e...@naggum.no> wrote: > >* Barry Margolin <bar...@bbnplanet.com> > >| Not that anyone likely cares, but Perl (Perl 5, in particular, since almost > >| everything is first-class) comes pretty close to being a dialect of Lisp, > >| IMHO.
> > that's pretty amusing, considering Larry Wall's explicit hatred for Lisp.
> I didn't know about that. What is it that he hates about it? Presumably > not the lack of type declarations, the automatic memory management, nor the > ability to execute code generated on the fly (Perl has "eval"). Maybe the > references-based semantics (i.e. object pointers are implicit), since the > major semantic difference between Perl 5 and Lisp is the need to use > special syntax to create references to first-class objects. Or maybe he > just doesn't like traditional Lisp syntax.
And what about python, pike, ici and ruby ?
> I think that the discovery that the Perl, Dylan, and Java folks hit on is > that if you can get around many people's irrational bias against Lisp's > heavily parenthesized syntax, they actually like most of the remaining > features, which just make programming easier. Garbage collection was > probably just one of the many language features that has simply been > waiting for machine speeds to catch up -- none of the current generation of > new programmers remember the days when Lisp would hang for a minute or more > in GC, so they're not biased against this and enjoy not having to call > free(). I recall that when C++ first started gaining popularity, one of > the most frequent Usenet posts in its newsgroup was "where can I get a > class that implements garbage collection?", and soon classes that implement > reference counting or conservative GC were popping up right and left. > Similarly, draft ANSI C++'s STL is in the spirit of Common Lisp's sequence > functions, but goes even further in providing higher level data structures > (stacks, queues, sorted tables, etc.).
On my machine, Emacs lisp does hang for several minutes, the swapping noise making the Wall s tremble.
* Jeff Dalton <j...@gairsay.aiai.ed.ac.uk> | You seem to be presupposing that Lisp, Scheme, and Common Lisp are | all on the same level.
it doesn't seem that way to me. why does it seem that way to you?
| (If they [Mandarin and Cantonese] are, indeed, considered dialects [of | Chinese] -- I have not checked this.)
they are not considered dialects of Chinese by the Chinese. Western non-linguists appear to find "Chinese" a useful abstraction. it's about as useful as "Germanic" about Western Hemisphere _spoken_ languages. (Chinese the writing-system is of course a different matter altogether.)
| Anyway, Saying that Lisp is a family of languages has a number of | advantages over talking of "dialects of Lisp", and members of a family | can be very different from each other.
indeed. however, membership in the family should ideally be testable by some reasonably simple means. I think the crucial element to membership is whether source code can be read and represented internally in the run-time environment as a standard data structure, and as a corollary, whether one can expect READ and WRITE to exist and do the obvious thing for all types that do not reflect "dynamic state" and without _undue_ complexity. that is, the old "code is data" argument. without that, I'd say it doesn't matter _what_ you do to look like any member of the Lisp family, and I'd have to remove Dylan and Perl 5 from the family.
| But I think it's a mistake to use "Lisp" in that way when it may be | misunderstood as referring to all of Lisp. This matters especially when | "Lisp" is being criticised, as it all too often is. It's fairly common | for people to say that "Lisp" is a too large a language, or makes it too | hard to deliver small applications, or has various other problems. But | often these claims are not true of Lisp in general (some Lisps are very | small languages, a Lisp could make it easy to deliver small applications, | and so on), but only of certain particular Lisps (maybe Common Lisp), or | only of certain implementations.
on this we agree. arguing _against_ Lisp has to be done on the essential elements of similiarity, not against incidental differences or qualities of implementations.
| Another case where I disagree is where someone seems to go further than | using "Lisp" as conveniently short for "Common Lisp" and say that Common | Lisp is the only Lisp, or that "Lisp" just *means* common Lisp (and hence | that there's either no Lisp family or else no other member).
this would depend on context. in some contexts, it is destructive and confusing to insist that "Lisp is not Common Lisp".
| For in fact other Lisps do exist, a number of them are still being used, | and Lisps can be significantly different from Common Lisp.
while still being used, I cannot but argue against learning them apart from the applications they are embedded in, such as Emacs' Lisp or AutoCAD's Lisp.
#:Erik -- ATTENTION, all abducting aliens! you DON'T need to RETURN them!
>> | If you don't like the "dialect of X" terminology, then perhaps "member of >> | the X family" would be better, but in my mind they mean the same thing.
>> it seems to mean the same thing only when X = Lisp.
>I think it most likely is the case that "dialect of Lisp", >in its "traditional" Lisp-world usage, employs a nonstandard >sense of "dialect". But that way of talking about Lisp-family >languages is so common that we're going to have to live with >it for some time to come.
I agree. Real world linguists presumably have terms for the various levels in the language taxonomy, but most of us aren't linguists and aren't familiar with the fine distinctions between the levels. To a linguist, "X family" and "dialects of X" are almost certainly very different, I'm happy to use them synonymously in reference to Lisp. I've also sometimes used "flavor of Lisp" -- this has the advantage that it doesn't try to reuse an existing linguistic term. Programming language people also often refer to the "Algol family", which includes languages like Algol, PL/I, Pascal, Ada, and C -- to me, what they have in common is similar uses of block structuring, structured data, and expression syntax.
Another thing that also can be used to determine language family membership is design history. This isn't something you can check by looking at a language specification. But it's well known that Dylan was designed by people very familiar with Lisp (many different dialects, and several of them were involved with the original and/or X3J13 design of CL); they took what they thought were all the good ideas from Lisp (call by object reference, dynamic memory management, much of CLOS), renamed them as they saw fit, added some other features (e.g. sealed classes), and eventually replaced the Lisp-like syntax with something more Pascal-like. But underneath that syntactic skin we all know there beats the heart of a Lisp. I think they started with the following goal: knowing what we know now and not having to worry about backward compatibility, redesign Lisp from scratch. Backward compatibility is the main reason why the Common Lisp designers couldn't do what the Dylan designers did -- CL was evolutionary, while Dylan could be revolutionary.
Perl5 is a real pastiche. It adopts many syntactic features from C, Unix shell, and sed/awk, and combines them with an underlying engine that's more like Lisp, IMHO. Given its mix-and-match origin, it's hard to say that it belongs to any particular family. But as a Lisp enthusiast, I don't feel uncomfortable using it, the way I do when using C.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
To me, more important than internal list processing is the fact that a Lisp language syntax is based fundamentally on the list structure.
The fact that ``any Lisp program is itself a list'' is what makes powerful macros like defpart possible, and for me this is the crucial feature which makes Lisp the language of choice for doing any kind of real work in this world.
* Barry Margolin wrote: > I didn't know about that. What is it that he hates about it? Presumably > not the lack of type declarations, the automatic memory management, nor the > ability to execute code generated on the fly (Perl has "eval"). Maybe the > references-based semantics (i.e. object pointers are implicit), since the > major semantic difference between Perl 5 and Lisp is the need to use > special syntax to create references to first-class objects. Or maybe he > just doesn't like traditional Lisp syntax.
I think he doesn't like the syntax.
> I think that the discovery that the Perl, Dylan, and Java folks hit on is > that if you can get around many people's irrational bias against Lisp's > heavily parenthesized syntax, they actually like most of the remaining > features, which just make programming easier.
I'm not convinced about this. I don't have an irrational bias against Lisp (my home computer is a 3630), and I certainly *do* have a bias against perl, whose syntax makes me feel quite ill. But Perl gives me important things that are hard to get in Lisp -- mostly string bashing with good performance. If I wrote Java I'd get at least the promise of feasible cross-platform GUI stuff. Those are both real immediate benefits which it is quite hard to get from Lisp systems. In the case of perl especially, I would (and have) write in lispy languages in preference, if I could do so without struggling because my scripts are so painfully slow.
(And before someone replies with `string processing in Lisp is easy, you're an idiot blah blah': it really isn't that easy if you want things to be fast, small and simple. I spent quite a long time doing stuff in scsh, and I now have a bunch of (very pretty) scripts which are really a pain in terms of performance compared to the obvious rewrite in Perl. I've done the same in elk, and CL, and it just isn't easy to get the kind of painless performance that perl has.)
Tim Bradshaw <t...@aiai.ed.ac.uk> wrote: >I'm not convinced about this. I don't have an irrational bias against >Lisp (my home computer is a 3630), and I certainly *do* have a bias >against perl, whose syntax makes me feel quite ill.
strange. i love both of them, as former c but now lisp addict. perl gives me all and 10x more what i could do in c plus most of the lisp'ish constructs (eg: map, hashes) i love. perl pleases my chaotic hacker mind and lisp my well-organized intellectual mind.
as with tim, I don't even try to do the string and database stuff in lisp what i do now in perl since with perl it is much easier to write and it runs faster. before the lisp has even initialized its image my perl script has finished processing the ~100 textfiles. and i still do like the one- or two-liners in perl, which would be six- liners in lisp. still kind of beautiful in lisp but unavailable art.
readability (i mean perl's so claimed "non-readability") is relative. yes, lisp is self-declarative, but i still can read and enhance my perl scripts i wrote years ago.
i just make more errors in perl than in lisp. in lisp it's almost impossible to make errors. in perl it's almost impossible to make no errors at the first writing, but the compiler makes wonderful suggestions. in c of course it's almost impossible to detect every single error.
>But Perl gives me >important things that are hard to get in Lisp -- mostly string bashing >with good performance. If I wrote Java I'd get at least the promise >of feasible cross-platform GUI stuff. Those are both real immediate >benefits which it is quite hard to get from Lisp systems. In the case >of perl especially, I would (and have) write in lispy languages in >preference, if I could do so without struggling because my scripts are >so painfully slow.
In article <ayyaf3xrjhw.fsf...@genworks1.i-have-a-misconfigured-system-so-shoot-me>, David J Cooper Jr <dcoop...@genworks.com> wrote:
>To me, more important than internal list processing is the fact that a >Lisp language syntax is based fundamentally on the list structure.
>The fact that ``any Lisp program is itself a list'' is what makes powerful >macros like defpart possible, and for me this is the crucial feature which >makes Lisp the language of choice for doing any kind of real work in this >world.
This would exclude McCarthy's original Lisp from the Lisp family! The fact that Lisp programs could be represented as lists was a revelation that came a few years later, when the EVAL function was written.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> (And before someone replies with `string processing in Lisp is easy, > you're an idiot blah blah': it really isn't that easy if you want > things to be fast, small and simple. I spent quite a long time doing > stuff in scsh, and I now have a bunch of (very pretty) scripts which > are really a pain in terms of performance compared to the obvious > rewrite in Perl. I've done the same in elk, and CL, and it just isn't > easy to get the kind of painless performance that perl has.)
> --tim
What are your tips and techniques for string processing in Lisp? Where (and why) does Lisp lose and Perl win?
DISCLAIMER: The opinions expressed are mine and do not necessarily represent Westinghouse Savannah River Co. or the United States Department of Energy.
* Barry Margolin <bar...@bbnplanet.com> | This would exclude McCarthy's original Lisp from the Lisp family! The | fact that Lisp programs could be represented as lists was a revelation | that came a few years later, when the EVAL function was written.
John McCarthy went on record in comp.emacs when somebody wanted to replace Lisp with Perl, saying, and I quote, hopefully sufficiently accurately from dejanews, despite their tendency to view articles and headers as subject to interpretation and layout control:
From: John McCarthy <j...@Steam.Stanford.EDU> Date: 08 Feb 1998 00:00:00 GMT Subject: Re: w3 and Re: perl embedded in emacs ("no zero-indexed char arrays") Newsgroups: comp.emacs, comp.emacs.xemacs Message-ID: <x4hk9b5p7hz....@Steam.Stanford.EDU>
One of the major characteristics of Lisp is that Lisp programs are Lisp data and one can compute with Lisp programs present in the machine without parsing. Scheme does this. Prolog does it to some extent. The original version of the late Dylan language did this.
To what extent is this facility used in XEmacs Lisp? Macros use it, and of course compilers do?
What about Perl? -- John McCarthy, Computer Science Department, Stanford, CA 94305 http://www-formal.stanford.edu/jmc/progress/ He who refuses to do arithmetic is doomed to talk nonsense.
#:Erik -- ATTENTION, all abducting aliens! you DON'T need to RETURN them!
>>> | If you don't like the "dialect of X" terminology, then perhaps "member of >>> | the X family" would be better, but in my mind they mean the same thing.
>>> it seems to mean the same thing only when X = Lisp.
>>I think it most likely is the case that "dialect of Lisp", >>in its "traditional" Lisp-world usage, employs a nonstandard >>sense of "dialect". But that way of talking about Lisp-family >>languages is so common that we're going to have to live with >>it for some time to come.
>I agree. Real world linguists presumably have terms for the various levels >in the language taxonomy, but most of us aren't linguists and aren't >familiar with the fine distinctions between the levels. To a linguist, "X >family" and "dialects of X" are almost certainly very different, I'm happy
To a linguist, "family" tends to imply more difference than "dialect". Nobody calls modern Italian, Spanish, or French dialects of some language. On the other hand, there is no real dividing line between two languages of one family and two dialects of one language. It's partly mutual intelligibility and partly politics. ("Mutual intelligibility" is also not well defined, nor can it be. There are places where one basic language is spoken, each group can talk to its neighbors, but the ends can't understand each other. This at least used to be the case with the German-speaking Swiss down the Rhine to the Netherlands.)
We're well in the mainstream here. We call various languages dialects of Lisp on the basis of mutual intelligibility, and we have political reasons to consider Scheme, Common Lisp, and ISLisp dialects of one language. The folks who like Wirth-designed languages seem to have political reasons for calling Modula-2 and Oberon different languages from Pascal. Over in comp.lang.c, the regulars are fiercely determined to call C and C++ two different languages, for reasons of their own (independence, I think - sort of like whether Ukrainian is a dialect of Russian).
So we don't need to feel guilty about misusing linguistic terms.
In article <3115135363710...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
>* Barry Margolin <bar...@bbnplanet.com> > What about Perl?
Perl has eval(). Perl is mainly a string-processing language, and Perl programs passed to eval() are themselves strings. Many of the things one needed eval() for in Perl4 have been replaced by explicit Perl5 operators (e.g. in Perl4 I would implemented nested data structures by storing variable names and evaling them, but Perl5 has references), but the capability is still there.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Randy Sims wrote: > What are your tips and techniques for string processing in Lisp? > Where (and why) does Lisp lose and Perl win?
String processing is, IMO, one of Lisp's weak points, but it's no worse than most other languages. There is one language that no one here has so far mentioned, and that is the string processing language Snobol4. When written well, it's more readable than Perl. It would be fairly straightforward to write a Snobol4 pattern matcher as a Lisp macro.
Incidentally, like Lisp and Perl, Snobol4 also has an eval which takes a piece of Snobol4 (a string) and executes it.
> randy.
-- Le Hibou (mo bheachd fhe/in: my own opinion) "it's just that in C++ and the like, you don't trust _anybody_, and in CLOS you basically trust everybody. the practical result is that thieves and bums use C++ and nice people use CLOS." -- Erik Naggum
* Donald Fisk <donald.f...@bt-sys.spamblock.bt.co.uk> | String processing is, IMO, one of Lisp's weak points, but it's no worse | than most other languages.
what is it that is so weak? I find it immensely useful that "string operations" in other languages actually work on _sequences_ in Common Lisp. on the other hand, that sometimes does make them harder to find when you look specifically for string operations, and perhaps more so when you need a few keyword arguments to get what you really want.
#:Erik -- ATTENTION, all abducting aliens! you DON'T need to RETURN them!
In article <3115371273457...@naggum.no>, Erik Naggum <cle...@naggum.no> wrote:
>* Donald Fisk <donald.f...@bt-sys.spamblock.bt.co.uk> >| String processing is, IMO, one of Lisp's weak points, but it's no worse >| than most other languages.
> what is it that is so weak?
When I think about the common string operations I do in Perl, many of them don't exist as Common Lisp (or most other Lisp) built-ins: pattern matching, substring replacement, inserting and deleting, splitting on delimiters, etc.
Of course, these can be written in CL, but in string-oriented languages you don't have to do that. There may be a library of them already, but the same would probably be true of other languages -- hence I agree with Donald Fisk's point that "it's not worse than most other languages."
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Erik Naggum <cle...@naggum.no> writes: > * Donald Fisk <donald.f...@bt-sys.spamblock.bt.co.uk> > | String processing is, IMO, one of Lisp's weak points, but it's no worse > | than most other languages.
> what is it that is so weak? I find it immensely useful that "string > operations" in other languages actually work on _sequences_ in Common > Lisp. on the other hand, that sometimes does make them harder to find > when you look specifically for string operations, and perhaps more so > when you need a few keyword arguments to get what you really want.
I'm gonna side with Donald on this one. The absence of regular expressions is a shame. Doing the equivalent with CL sequence operations has the same feel as doing without FORMAT in I/O. The language has the power even without FORMAT, but the packaging really makes it easier to do and to spot bugs and to maintain/extend.
I programmed for a while intensively in MOO (a programming language for certain text-based virtual realities) and it used regexps intensely and they were a ton of fun to use compared to the CL alternatives.
I think the absence of them in CL is mostly an accident of history because of when CL was coming together, not a willful rejection of a good idea. Regexps hadn't caught on clearly enough by 1988 when we froze the standard for there to be implementations which were sporting them.
On the other hand, I've heard there are contributed libraries that cover this gap. And given that, I can't feel too bad that what we have is not useful.
I do also sometimes wish for the LispM's string-search-set and string-search-not-set.
> > What are your tips and techniques for string processing in Lisp? > > Where (and why) does Lisp lose and Perl win?
> String processing is, IMO, one of Lisp's weak points, but it's no worse > than most other languages. has
Actually, i think Lisp is much better off than most other languages for these tasks, but perhaps I have a different view of what constitutes string processing. Lisp has an extensible syntax, so one can define specialized languages specific to a task that make it more useful and understandable than other languages, at least once you become comfortable with parenthesis.
There are a few pattern matching packages for lisp. Take a look at Olin Shivers package, it's quite good.
But if you take a broader view, you can simply do things easier and better by not viewing the problem as a pattern matching problem, but tackle it a different way. In particular, processing of HTML documents using twisted pattern matching is particularly horrific in my opinion. Instead, I tackle these tasks using an object oriented approach -- convert HTML into objects, and then process the objects, which is a much more general and MAINTAINABLE solution. And if your object system is fast, then it's not really slow, and in fact, compared to some highly compute intensive complex pattern matching solutions, it may even be more efficient as well.
-Kelly Murray
;; this downloads a directory, and returns all the files as urls (function url-directory (url) (loop with anchors = nil with html = (download-url url) with tags = (parse-html html) ;; TURN HTML INTO OBJECTS for tag in tags finally (return (nreverse anchors)) do (if (and (typep tag 'html-tag::A) (slot-boundp tag 'href)) then (push (merge-urls (slot-value tag 'href) url) anchors)) ))
* Kent M Pitman <pit...@world.std.com> | I'm gonna side with Donald on this one. The absence of regular | expressions is a shame.
a _shame_? I don't consider regular expressions _that_ much of a must. (I installed them in ACL 4.3, and it comes builtin with ACL 5.0, but I haven't had occasion to use it, quite unlike in Emacs Lisp, where I have to, and don't like the absence of everything that makes me have to.) on the contrary, since their presence seem to supplant better solutions, like parsers that convert strings into data structures you can work with more intelligently, I find them akin to the mythological sirens whose luring songs called ships into dangerous waters.
| I think the absence of them in CL is mostly an accident of history | because of when CL was coming together, not a willful rejection of a good | idea. Regexps hadn't caught on clearly enough by 1988 when we froze the | standard for there to be implementations which were sporting them.
would it be a workable solution if the vendors cooperated on the functional interface today? it doesn't appear to be for lack of fast and good implementations, at least not as far as strings are concerned.
| I do also sometimes wish for the LispM's string-search-set and | string-search-not-set.
hm. I found a veritable plethora of string functions in the Genera 7.2 manual set (which Michael Cracauer kindly sent me some time ago), most of them seeming to _scream_ for far more general solutions (not counting regexps as such a solution). it occurs to me that SEARCH should be sufficient with some moderately simple functions, as in
where SET and IN-SET-P could cooperate on optimizing performance, perhaps even at compile time. I just don't want to limit this to strings, only. likewise, regular expressions that worked on sequences of all kinds with any type of contents would be _much_ more attractive to me. regular expressions on strings is just that: a special case for _strings_, and the pattern matching languages involved should be far more generally applicable, in my opinion. it seems "un-Lispy" to me to make something work only for strings when there is wider applicability.
#:Erik -- ATTENTION, all abducting aliens! you DON'T need to RETURN them!
>>>>> "bm" == Barry Margolin <bar...@bbnplanet.com> writes: > In article <3115018001706...@naggum.no>, Erik Naggum <e...@naggum.no> wrote: >> [...] that's pretty amusing, considering Larry Wall's explicit >> hatred for Lisp. > I didn't know about that. What is it that he hates about it? [...]
"Explicit hatred for Lisp" is way over the top - Larry probably wouldn't deny that Perl owes quite a bit to Lisp.
The part that he probably has most problems with is the syntax. While I personally like Lisp's syntax a lot, I still find most of Larry's "linguistic" arguments quite compelling.
I didn't manage to dig up any references where he talks about Lisp syntax specifically (someone has a very old comp.lang.perl archive?). However, I recommend reading about his general approach to language design under:
* Randy Sims wrote: > Tim Bradshaw <t...@aiai.ed.ac.uk> writes:
>> (And before someone replies with `string processing in Lisp is easy, >> you're an idiot blah blah': it really isn't that easy if you want >> things to be fast, small and simple. I spent quite a long time doing >> stuff in scsh, and I now have a bunch of (very pretty) scripts which >> are really a pain in terms of performance compared to the obvious >> rewrite in Perl. I've done the same in elk, and CL, and it just isn't >> easy to get the kind of painless performance that perl has.)
>> --tim > What are your tips and techniques for string processing in Lisp? > Where (and why) does Lisp lose and Perl win?
I think it's tempting to say at this point `because there is no standard regexp/pattern-matching in Lisp'. But I think that is wrong actually. There is at least one system (scsh) which has good string-bashing stuff in there and some nice macrology on top of it which makes things easy to do (there is an `awk' macro). And there is an interesting proposal for lisp-style representations of regexps & so forth which has been posted recently (I think by the scsh people). And using a single-implementation system (like scsh or perl) is not a problem for me so long as I have a reasonable expectation of being able to port it to future machines.
I think the answer is actually poor I/O performance in many/all Lisps. Again, I know that it is often *possible* to get good I/O performance, but it usually isn't easy compared to things like perl.
In fact the particular case where I most recently got my fingers burnt was really not string-bashing at all. Our dump scripts are currently in scsh, and write a log file which is just a series of alists with information about what was dumped & so forth. I then have a little program which lets you ask various questions of this file, like `when was the last level zero dump of this partition'. The log file gets quite large (currently it's about 7000 records, or 0.5Mb), and there is a search through the file to find information (so it obviously won't scale for ever). The query program really just loops calling READ. It's so slow that I typically start up an emacs, edit the file and use search in emacs to find what I need to know. It takes minutes to run. It isn't particularly cleverly written, but it isn't *stupidly* written either. If I had written the log file in some format that perl/awk could hack easily, a naive script to search it would take fractions of a second. I suspect that I could implement READ *in perl* and it would still be much faster.
This kind of thing is really bad news, and I've run across very similar cases too many times. It's particularly bad news because being able to mash large amounts of data sitting in files like this is increasingly important to people. Of course, it's *possible* to do this in Lispy languages, but it's hard enough that people won't do it. When you have to think in terms of `I could link perl with my Lisp image, then do the I/O using perl and just pass data back to Lisp using some FFI' (I have thought this) you can be sure that Lisp will not be used for these applications.
* Simon Leinen <si...@limmat.switch.ch> | "Explicit hatred for Lisp" is way over the top - Larry probably | wouldn't deny that Perl owes quite a bit to Lisp.
Larry Wall has been explicit in his hatred for Lisp, and has denied every similarity between Perl and any Lisp. I have tried to communicate with him, but because of my involvement with Lisp and Emacs and the FSF, got an amazingly stupid flame back, not addressing anything of what I asked him, and this was _before_ I looked closely enough at Perl to think it's the worst disgrace of a language that has plagued this planet, not even beaten by C++. he continued to attack Lisp whenever he had a chance, but in all fairness, I haven't seen anything from him in a long time, so he might have improved for all I care.
#:Erik -- ATTENTION, all abducting aliens! you DON'T need to RETURN them!
>I think the answer is actually poor I/O performance in many/all >Lisps. Again, I know that it is often *possible* to get good I/O >performance, but it usually isn't easy compared to things like perl.
>In fact the particular case where I most recently got my fingers burnt >was really not string-bashing at all. Our dump scripts are currently >in scsh, and write a log file which is just a series of alists with >information about what was dumped & so forth. I then have a little >program which lets you ask various questions of this file, like `when >was the last level zero dump of this partition'. The log file gets >quite large (currently it's about 7000 records, or 0.5Mb), and there >is a search through the file to find information (so it obviously >won't scale for ever). The query program really just loops calling >READ. It's so slow that I typically start up an emacs, edit the file >and use search in emacs to find what I need to know. It takes minutes >to run. It isn't particularly cleverly written, but it isn't >*stupidly* written either. If I had written the log file in some >format that perl/awk could hack easily, a naive script to search it >would take fractions of a second. I suspect that I could implement >READ *in perl* and it would still be much faster.
maybe your problems arise because of using READ, which "interns" all symbols and variables in scsh (READ is really a scheme parser). This is really different from just finding strings in a text file by pattern matching.
Marc
-- --------------------------------------------------------------------------- --- email: marc dot hoffmann at users dot whh dot wau dot nl --------------------------------------------------------------------------- ---
Erik Naggum wrote: > what is it that is so weak? I find it immensely useful that "string > operations" in other languages actually work on _sequences_ in Common > Lisp.
What you want to do with strings is often different from what you want to do with lists, or vectors of numbers. Usually, some sort of lexical analysis is required. This is built into Snobol and Perl, but to do the same in Lisp would either require some extra programming, or worse, some degree of cleverness.
To choose a specific example, here is the Snobol which can separate a URL into a protocol, machine and path:
If this sort of thing comprises only a small part of your code, but is used in several programs (a likely scenario), you're still better off sticking to Lisp, after extending it with a macro which does Snobol pattern matching.
> #:Erik
-- Le Hibou (mo bheachd fhe/in: my own opinion) "it's just that in C++ and the like, you don't trust _anybody_, and in CLOS you basically trust everybody. the practical result is that thieves and bums use C++ and nice people use CLOS." -- Erik Naggum
> maybe your problems arise because of using READ, which "interns" all symbols > and variables in scsh (READ is really a scheme parser). This is really > different from just finding strings in a text file by pattern matching.
yes, I know that. But using READ gives you a lot of useful stuff -- specifically it gives you a simple extensible data format for which you don't have to write a parser (my specific example used essentially a property list, with functions to handle the values keyed of the property names and a default thing to handle unknown properties). It would be a nice property of lisps if this was actually usable in practice. The alternative is to go away and write a parser, which I might as well do in perl.
