> pla...@nospam-cs.wisc.edu writes: >> In comp.arch Duane Rettig <du...@franz.com> wrote: >> > pla...@nospam-cs.wisc.edu writes: >> >> Out of curiosity: what kinds of large commercial >> >> applications use LISP? Do they use it as an embedded >> >> scripting engine, or to write the application proper?
>> > Both are possible, as well as using lisp as glue to hold >> > together systems with subsystems written in different languages. >> > However, the applications I refer to, which _must_ use lisp for >> > its ability to handle large problem sets, tend to be largely >> > written in lisp.
>> I guess I'm trying to figure out why LISP is unique >> in its ability to handle these large problem sets. >> What is it about these data sets that prevents use >> of C or C++, and *requires* LISP? > nothing *requires* Lisp, per se, as you can always write a common-lisp > in, for example, C and C++.
[ snipped lots of good stuff about LISP ]
Oh sure, I agree. But I'm curious as to what exactly the original poster meant while writing "applications [...] which _must_ use lisp for its ability to handle large problem sets".
What is it about LISP that enables handling large data sets? Is it just the fact that objects can be easily serialized to storage and back (as you described earlier)? Or the garbage collection? Or the uniformity and simplicity of the data model (everything is a list)?
I guess it would be good if the original poster described the applications in question and explained how LISP helped in their implementation.
As you've suggested, most of the operation of Usenet can probably (and almost certainly will, evolutionaly) change to these sorts of servers, as the admins of current news servers learn about them. I doubt that NNTP-client users ever need to know about these changes.
Erik Naggum <e...@naggum.net> writes: > [interesting things about news]
While I don't think it does really what you propose, the leafnode and leafnode+ news systems are perhaps moves in the right direction. They fetch groups on demand from upstream servers (the first time you ask you see a little fake article saying it will be here in a minute, if you stop reading a group then it stops fetching it after a bit), so they're pretty good for small leaf sites. If, like me, you read a small number of groups then you can also set the expiry times for stuff that is fetched to be huge -- I think I cache comp.risks for a year and c.l.l for several months.
> I think this actually supports my point, since arrays of length 6 > are more space-efficient than lists of length 6. (With some quibbles > about implementation techniques for adjustable vs non-adjustable arrays.) > I agree it wouldn't make that much difference either way for short lists.
Are they really? Remember you need both adjustability *and* displacability (adjustability so you can do push &c, and displacability so you can share tails, both of which are significantly important features).
> One might also use data structures differently in an array language. > The classic example is a matrix, which is more efficiently represented > using a single vector in row-major order, rather than a nested vector > of vectors. Another example is using two arrays to represent a tree.
Of course a matrix *would* be represented as a single entity in row-major order in Lisp -- not a vector, as it knows its dimensions, but the storage is the same, and indeed there is an accessor -- ROW-MAJOR-AREF which just treats arrays as vectors. Remember Lisp *is* an array language.
> What is it about LISP that enables handling > large data sets? Is it just the fact that objects can be > easily serialized to storage and back (as you described > earlier)? Or the garbage collection? Or the uniformity > and simplicity of the data model (everything is a list)?
Everything is *not* a list. It was in 1956 but we've moved on since then.
pla...@nospam-cs.wisc.edu writes: > In comp.arch Johan Kullstam <kulls...@ne.mediaone.net> wrote: > > pla...@nospam-cs.wisc.edu writes: > >> In comp.arch Duane Rettig <du...@franz.com> wrote: > >> > pla...@nospam-cs.wisc.edu writes: > >> >> Out of curiosity: what kinds of large commercial > >> >> applications use LISP? Do they use it as an embedded > >> >> scripting engine, or to write the application proper?
> >> > Both are possible, as well as using lisp as glue to hold > >> > together systems with subsystems written in different languages. > >> > However, the applications I refer to, which _must_ use lisp for > >> > its ability to handle large problem sets, tend to be largely > >> > written in lisp.
> >> I guess I'm trying to figure out why LISP is unique > >> in its ability to handle these large problem sets. > >> What is it about these data sets that prevents use > >> of C or C++, and *requires* LISP? > > nothing *requires* Lisp, per se, as you can always write a common-lisp > > in, for example, C and C++.
> [ snipped lots of good stuff about LISP ]
> Oh sure, I agree. But I'm curious as to what exactly > the original poster meant while writing "applications [...] > which _must_ use lisp for its ability to handle large > problem sets".
I guess that would be me. Please recall that in that same article I said:
You can also check out our website (below) under "Success Stories", and also http://www.lisp.org, for more info.
I suppose that due to fear of entering into "advertising" mode, I was not as clear as I should be. So I'll be more direct: Go to http://www.franz.com, click on "Success Stories", and find out why some of our customers themselves say that they could not have built their apps without Lisp.
> What is it about LISP that enables handling > large data sets? Is it just the fact that objects can be > easily serialized to storage and back (as you described > earlier)? Or the garbage collection? Or the uniformity > and simplicity of the data model (everything is a list)?
Many of these are true, though everything is not a list, and the data model is not any simpler than other languages. However, I would characterize Lisp, and especially Common Lisp, as a language that scales well because it is both general purpose _and_ is not brittle.
That is, you can make changes dynamically to functions and classes (yes, you can redefine classes on the fly, and the CLOS system lazily updates the new class usage!). When errors in your program inevitably occur, debug interactions allow you to find and fix your bug _and_ retry portions of what has been done already (no need to start from the beginning). You can compile and load files, but there is no "link edit" phase, because of the dynamicity of lisp functions, so you can define a function on the fly and run it interpreted if you wish, or you can compile the function and it is immediately available for efficient running, while you are in the middle of running your application. Lisp also has introspection; you can see as much or as little of the internal structure of your program as you wish, depending on how you set it up; while debugging your app, you are not left wondering what some string of bits really represent, because the inspector tells you what they are.
> I guess it would be good if the original poster > described the applications in question and explained > how LISP helped in their implementation.
Once again, it is our customers that describe these things, some of whose descriptions you can read for yourself.
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
pla...@nospam-cs.wisc.edu writes: > In comp.arch Johan Kullstam <kulls...@ne.mediaone.net> wrote: > > pla...@nospam-cs.wisc.edu writes: > >> In comp.arch Duane Rettig <du...@franz.com> wrote: > >> > pla...@nospam-cs.wisc.edu writes: > >> >> Out of curiosity: what kinds of large commercial > >> >> applications use LISP? Do they use it as an embedded > >> >> scripting engine, or to write the application proper?
> >> > Both are possible, as well as using lisp as glue to hold > >> > together systems with subsystems written in different languages. > >> > However, the applications I refer to, which _must_ use lisp for > >> > its ability to handle large problem sets, tend to be largely > >> > written in lisp.
> >> I guess I'm trying to figure out why LISP is unique > >> in its ability to handle these large problem sets. > >> What is it about these data sets that prevents use > >> of C or C++, and *requires* LISP? > > nothing *requires* Lisp, per se, as you can always write a common-lisp > > in, for example, C and C++.
> [ snipped lots of good stuff about LISP ]
> Oh sure, I agree. But I'm curious as to what exactly > the original poster meant while writing "applications [...] > which _must_ use lisp for its ability to handle large > problem sets".
> What is it about LISP that enables handling > large data sets? Is it just the fact that objects can be > easily serialized to storage and back (as you described > earlier)? Or the garbage collection? Or the uniformity > and simplicity of the data model (everything is a list)?
everything is not a list. there are a number of simple types such as number or character. other aggregate types such as array and hashtable exist in common-lisp.
> I guess it would be good if the original poster > described the applications in question and explained > how LISP helped in their implementation.
agreed.
-- J o h a n K u l l s t a m [kulls...@ne.mediaone.net] Don't Fear the Penguin!
* Tim Bradshaw <t...@tfeb.org> | While I don't think it does really what you propose, the leafnode and | leafnode+ news systems are perhaps moves in the right direction.
They don't do anything close to what I propose. I use leafnode myself, and while it goes to fetch news for every once in a while, it is even harder than it usually is to fetch an article by message-id because someone thinks cross-posting is a good way to "move" discussions.
#:Erik -- The United States of America, soon a Bush league world power. Yeee-haw!
* pla...@nospam-cs.wisc.edu | Or the uniformity and simplicity of the data model (everything is a list)?
It would be helpful if you could explain why you believe this "everything is a list" part to be true and how you came to believe it. (Hint: It has actually _never_ been true, and it mystifies Lisp people that so many people who come to Lisp hold this myth. If we could only track it down and find ways to replace it with something less false...)
#:Erik -- The United States of America, soon a Bush league world power. Yeee-haw!
In comp.arch Duane Rettig <du...@franz.com> wrote:
> chu...@best.com (Chuck Fry) writes: >> And with 64 bits to play with, who's to say we can't spare a couple for >> CDR-coding? > Let's not make this mistake again. When IBM (and Amdahl) created their XA > architectures for the 370 compatibles (extending the address range from 24 > bits to 32 bits), several programs suddenly broke. These programs, which > used the upper 8 bits of address words for tags and flags, assumed (correctly, > but without foresight) that these bits were available for use.
This mistake hit several architectures based on the Motorola 680x0 also. 32bit address registers, but only 24 physical address lines on the 68000 and 68EC020 so the top 8 bits were ignored. Enter the 68030, and a lot of software broke. It was especially bad on the Macintosh, which made Apple add a "24bit compatibility mode" by using the MMU.
I don't think I should promote more discussion on this subject here in comp.lang.lisp/comp.arch; my original point was on topic, but now we're a bit too far removed from that, unless there are some valuable lessons to be learned in computer architecture or with Lisp from this topic.
(I _do_ find your points interesting -- which is why I question them -- and I'd like to know if you've done any formal research on this, published or not -- this is exactly the kind of thing I'm writing about in my thesis, although there are many things I don't know yet and still need to learn.)
My apologies to comp.arch and comp.lang.lisp for yet another off-topic thread drift.
-- In the beginning was the Bit, and the Bit was Zero. Then Someone said, Let there be One, and there was One. And Someone blessed them, and Someone said unto them, Be fruitful, and multiply, and replenish the Word and subdue it: and have dominion over every thing that is.
On 15 Dec 2000 11:52:39 +0000, Erik Naggum <e...@naggum.net> wrote:
>* pla...@nospam-cs.wisc.edu >| Or the uniformity and simplicity of the data model (everything is a list)?
> It would be helpful if you could explain why you believe this "everything > is a list" part to be true and how you came to believe it. (Hint: It has > actually _never_ been true, and it mystifies Lisp people that so many > people who come to Lisp hold this myth. If we could only track it down > and find ways to replace it with something less false...)
A few months ago in an interview about emacs (at freshmeat or slashdot, I'm not sure), RMS himself said that "in Lisp everything is a list", that why it's so flexible and bla, bla, bla... I guess this sort of thing helps. ;-)
//----------------------------------------------- // Fernando Rodriguez Romero // // frr at mindless dot com //------------------------------------------------
Tim Bradshaw <t...@tfeb.org> writes: > Are they really? Remember you need both adjustability *and* > displacability (adjustability so you can do push &c, and > displacability so you can share tails, both of which are > significantly important features).
You need displacability is you are doing straight-forward re-implementation of list code to use arrays instead. But, otherwise no, sharing tails is not a significantly important features, not enough so that you want to include a displacement in every array, or even every adjustable array. If you are using displaced arrays as a replacement for cdr-ing down a list you're almost certainly doing something wrong.
Note I am not talking running existing Lisp code or even necessaily using the (a) Lisp language, but about solving Lisp-style problems using a language based on arrays instead of lists.
If you have a language with type inheritance, it is useful to have at least three array implementations: (1) Constant arrays. Simple and compact. The equivalent of the Lisp reader and the "list" function should return these, as should "arrays comprehensions" (from a user's, not implementor's, point of view). (2) Adjustable arrays. (3) Slice arrays: arrays that are displaced to a sub-sequence of another array, perhaps with a stride.
A fourth type: (4) Fixed-size arrays with mutable elements. - is useful for library implementors but most programs should have little use for it. (I'm assuming a "mostly functional" language.)
> Of course a matrix *would* be represented as a single entity in > row-major order in Lisp -- not a vector, as it knows its dimensions, > but the storage is the same, and indeed there is an accessor -- > ROW-MAJOR-AREF which just treats arrays as vectors. Remember Lisp > *is* an array language.
Agreed. My point is that you have a data structure implemented as a nested list, alternative data structures may be appropriate. I used matrix as an example that is already available in Common Lisp. -- --Per Bothner p...@bothner.com http://www.bothner.com/~per/
> * pla...@nospam-cs.wisc.edu > | Or the uniformity and simplicity of the data model (everything is a list)?
> It would be helpful if you could explain why you believe this "everything > is a list" part to be true and how you came to believe it. (Hint: It has > actually _never_ been true, and it mystifies Lisp people that so many > people who come to Lisp hold this myth. If we could only track it down > and find ways to replace it with something less false...)
It's because, to a level zero - or 10,000 foot approximation, everything in Lisp *is* a list. That's what they taught in the first week of my lisp/Algol class. Arrays weren't even mentioned for several weeks. Naturally, when my friends asked me what was so strange about the language, I'd say "Lisp stands for LISt Processor. Everything is a list". Since my friends were only interested in the summary, this answer was correct.
Mechanical engineers aren't taught Einstienian mechanics - they're taught Newtonian mechanics. Newtonian mechanics isn't wrong - it's just less accurate. When the book says to over design by a factor of six, what difference does it make?
Perhaps Lisp needs a better executive summary.
Why do people use Perl and Java instead of Lisp and Forth?
> Finally, we come to the design criterion which set our choice; it > is array access efficiency. The majority of simple arrays in any > lisp are either strings or else they contain elements of the same > size as a Natural Word. Now, all array accesses (e.g., AREF, SVREF, > and their inverses) contain an offset component, to compensate for the > tag and array header, and a shift component to compensate for the > difference between the width of the array element and the "width" > of the fixnum index, as established by the number of bits in its tag. > If the width of the array element matches the "width" of the fixnum, > then no shift is necessary, and the access is faster. In fact, tight > loops of array access operations are within 20% of C speed, and in > special cases where atomic array loops (i.e. with no chance of a gc > moving the array) where the tag offset is precalculated, the access > can be 20% faster than C. These loops tend to only differ by only > one instruction.
Interesting.
You mean 20% faster than - A: for (i = 0; i < ARRAYSIZE; i++) { array[i]++;
}
or 20% faster than - B: for (i = 0; i < ARRAYSIZE * sizeof(typeOfArray); i += sizeof(typeOfArray)) { array[i]++;
}
or 20% faster than - C: for (p = array; p < array + ARRAYSIZE; p++) { (*p)++;
}
In practice, the relative timing of each of the above differs from architecture to architecture - possibly from compiler to compiler. For some architectures and compilers, it makes a big difference if "array" is bound to a static address. A good C compiler could convert A to B or C, if it notes that "i" is only used to index into "array". Does gcc?
There is value in making the simple syntax for common tasks run efficiently. I've actually heard C programmers complain about the infinite oportunities that the language presents to the programmer for optimization. They are a distraction.
When I learned Lisp, the system required some 35K words (about 150 KB, since a word was 36 bits) - thus a resource hog. And, it was considered "slow" - since it was "interpreted". These days, I'd never use it - except that my text editor has it built in, and I need to customize it from time to time. And, instead of sharing a 0.2 MIPS & 700 KB RAM system with 35 other users, I have multiple 100+ MIPS & 128 MB RAM systems to myself. Of course, even this is entirely consumed by my screen saver - which requires over 13 MB RAM and must periodically connect to the internet to get more data. Golly.
I used to think that Lisp was hard to read. But now that I use Perl, Lisp is no big deal.
In comp.arch Johan Kullstam <kulls...@ne.mediaone.net> wrote:
> pla...@nospam-cs.wisc.edu writes: >> and simplicity of the data model (everything is a list)?
> everything is not a list. there are a number of simple types such as > number or character. other aggregate types such as array and > hashtable exist in common-lisp.
Mea culpa. Apologies to all the LISP fans out there. I've never programmed in LISP myself, only read a bit about it.
Erik Naggum <e...@naggum.net> writes: > * Per Bothner <p...@bothner.com> > | (It would be needed there anyway if memory management code needs to > | scan memory consequtively.)
> Really? I thought memory management code followed pointers and chains > from a root set if it were any smart. Randomly walking over memory it > has no idea what contains just seems like a recipe for major disaster.
No, not at all. There are many reasons why a collector might scan memory sequentially. And if it's not a conservative collector, it does know the layout of the objects. The most important sequential technique is the Cheney scan <URL:http://www.xanalys.com/software_too ls/mm/glossary/c.html#cheney.scan>, which most copying collectors use: scanning over the newly copied objects eliminates the need for a scanning stack. Non-moving collectors often scan over memory in the reclaim phase to build the new freelist.
> If you keep the size of a vector in a well-known structure with the > pointer to the data array, there is only one way to get at that data > array, anyway.
As long as the array code is not interrupted by GC, leaving a pointer to the data array on the stack/registers. Furthermore, having a data array that the collector cannot parse without making reference to an array header makes some barrier techniques harder, for example those based on VM page protection. I wouldn't recommend it. -- Pekka P. Pirinen, Adaptive Memory Management Group, Harlequin Limited Hell is other posters. - Nancy Lebovitz (nancyL_universe.digex.net)
Per Bothner <p...@bothner.com> writes: > You need displacability is you are doing straight-forward > re-implementation of list code to use arrays instead. But, otherwise > no, sharing tails is not a significantly important features, not > enough so that you want to include a displacement in every array, or > even every adjustable array. If you are using displaced arrays as a > replacement for cdr-ing down a list you're almost certainly doing > something wrong.
Sharing substructure is unfortunately completely crucial to a lot of the code I'm talking about. Without it space requirements would be hideous, and equality tests would change from something which is almsot always a check for pointer equality to something which could walk half the tree.
Indeed, if I was doing it in a language other than Lisp which didn't have a huge array bias like, say, fortran, I'd use the same technique I used in the Lisp code before I optimized it -- objects (in the sense of things defined with DEFSTRUCT or DEFCLASS rather than in the better Lisp sense of `everything is an object') with a couple or three of slots. I definitely wouldn't use arrays.
What I'm trying to get at is that you seem to be assuming that lists (really, conses, Lisp doesn't actually have lists as a distinct representational type) are used as a kind of crap array substitute. That was perhaps once true and might still be true in badly written Lisp code (there is a lot of this). It *isn't* true in well-written code.
But I don't think this argument is going anywhere unfortunately, so I'll avoid wasting further bandwidth.
In article <41yvayoph....@beta.franz.com>, Duane Rettig <du...@franz.com> wrote: > I suppose that due to fear of entering into "advertising" mode, > I was not as clear as I should be. So I'll be more direct: Go > to http://www.franz.com, click on "Success Stories", and find out > why some of our customers themselves say that they could not have > built their apps without Lisp.
> > What is it about LISP that enables handling > > large data sets? Is it just the fact that objects can be > > easily serialized to storage and back (as you described > > earlier)? Or the garbage collection? Or the uniformity > > and simplicity of the data model (everything is a list)?
> Many of these are true, though everything is not a list, and the > data model is not any simpler than other languages. However, I > would characterize Lisp, and especially Common Lisp, as a language > that scales well because it is both general purpose _and_ is not > brittle.
> That is, you can make changes dynamically to functions and classes > (yes, you can redefine classes on the fly, and the CLOS system > lazily updates the new class usage!). When errors in your program > inevitably occur, debug interactions allow you to find and fix > your bug _and_ retry portions of what has been done already (no > need to start from the beginning). You can compile and load files, > but there is no "link edit" phase, because of the dynamicity of lisp > functions, so you can define a function on the fly and run it > interpreted if you wish, or you can compile the function and it is > immediately available for efficient running, while you are in the > middle of running your application. Lisp also has introspection; > you can see as much or as little of the internal structure of your > program as you wish, depending on how you set it up; while debugging > your app, you are not left wondering what some string of bits really > represent, because the inspector tells you what they are.
> > I guess it would be good if the original poster > > described the applications in question and explained > > how LISP helped in their implementation.
> Once again, it is our customers that describe these things, some of > whose descriptions you can read for yourself.
I don't want to mean about this, and I know pretty much nothing about Lisp, so have no opinion, but the thing such lists never mention is the customers who used Lisp and found it to be a terrible mistake for their project. From a world with which I am more familiar, I have spoken to various friends (not C bigots, people who've used many languages) involved in projects with Java where they believe the use of Java was a terrible mistake, that the resultant apps were horrendously slow memory hogs---but I strongly suspect you want see any mention of them at a Sun web site.
>>> And with 64 bits to play with, who's to say we can't spare a couple for >>> CDR-coding?
>> Let's not make this mistake again. When IBM (and Amdahl) created their XA >> architectures for the 370 compatibles (extending the address range from 24 >> bits to 32 bits), several programs suddenly broke. These programs, which >> used the upper 8 bits of address words for tags and flags, assumed (correctly, >> but without foresight) that these bits were available for use.
>This mistake hit several architectures based on the Motorola 680x0 also. >32bit address registers, but only 24 physical address lines on the 68000 >and 68EC020 so the top 8 bits were ignored. Enter the 68030, and a lot >of software broke. It was especially bad on the Macintosh, which made Apple >add a "24bit compatibility mode" by using the MMU.
but there is a fundamental difference here: the examples you cite started with entities (24 bit addresses) that were not big enough to fill the space they were stored in. when those entities grew to fill the available space they collided with situations where this space was used for other purposes. in our case you deal with a conscious decision to use a coarser granularity, which is not likely to change (i really cannot imagine a memory subsystem allocating single bits or bytes)
> As long as the array code is not interrupted by GC, leaving a pointer > to the data array on the stack/registers. Furthermore, having a data > array that the collector cannot parse without making reference to an > array header makes some barrier techniques harder, for example those > based on VM page protection. I wouldn't recommend it.
for the port of apl/360 to cms/apl ... this was one of the problems that we had run into. going from essentially a swapping 32kbyte-64kbyte workspace environment to a demand paging 16mbyte workspace environment ... the original apl had the propensity that every assignment allocated new space (and prior location ignored). when end of workspace was reached, garbage collection would compact all allocated space and the process started over.
one of the other projects at csc was vs/repack ... which included page reference monitoring and drawing "pictures" with special TN train of the operation. At times the halls of 4th floor, 545 tech. sq were papered with these reference pictures. basically five foot long section on reversed green-bar paper with storage accesses along the length and time along the width. A whole series of these were taped to the wall (length running vertical) giving several seconds of program execution as you moved down the hall.
The bottom of the wall tended to be solid pattern of use ... but there was a very strong sawtooth pattern where pages were touched, used for very short periods and then storage allocation moved up until it reached top of storage ... and then there was a solid line as all allocated data was compacted back down to low storage. In virtual memory environment, this tended to result in an application using maximum amount (all) of available virtual memory regardless of the application size or complexity ... with bimodel reference pattern ... partially LRU and partially MRU (i.e. the least recently used page wasn't likely to be used again for awhile).
Part of the less obvious things that we had to do in the '71 time-frame for the port of apl/360 to cms/apl was a dynamically adaptive memory collector.
"Stephen Uitti" <sui...@ford.com> writes: > "Erik Naggum" <e...@naggum.net> wrote in message > news:3185869959483668@naggum.net... > > * pla...@nospam-cs.wisc.edu > > | Or the uniformity and simplicity of the data model (everything is a > list)?
> > It would be helpful if you could explain why you believe this > "everything > > is a list" part to be true and how you came to believe it. (Hint: It > has > > actually _never_ been true, and it mystifies Lisp people that so many > > people who come to Lisp hold this myth. If we could only track it down > > and find ways to replace it with something less false...)
> It's because, to a level zero - or 10,000 foot approximation, everything > in Lisp *is* a list. That's what they taught in the first week of my > lisp/Algol class. Arrays weren't even mentioned for several weeks.
==^^^^^^^^^^
This should have given you a clue as to how bad the class would be. Your professor either didn't know lisp, or didn't care to really teach it. And spouting such inaccuracies in classes propagates misinformation throuout the industry.
In fact, if we look at a lisp object count, there tends to be more bytes of arrays than conses (list elements), although there are more conses in number - Note the table in the middle of this output:
cl-user(1): (room t) area area address(bytes) cons other bytes # type 8 bytes each (free:used) (free:used) Top #x3063a000 New #x30534000(1073152) 95:3981 714976:273680 New #x3042e000(1073152) ----- ----- 0 Old #x30000cc8(4379448) 369:76056 2100512:1659240 Root pages: 30 Lisp heap: #x30000000 pos: #x3063a000 resrve: 17842176 C heap: #x54000000 pos: #x54006000 resrve: 1024000
total bytes = 2529640 aclmalloc arena: max size free bytes used bytes total 112 3472 112 3584 496 3968 0 3968 1008 4032 0 4032 2032 4064 0 4064 4080 0 8160 8160 total bytes: 15536 8272 23808 cl-user(2):
> Naturally, when > my friends asked me what was so strange about the language, I'd say > "Lisp stands for LISt Processor. Everything is a list". Since my friends > were only interested in the summary, this answer was correct.
I disagree; the second part of your answer was incorrect, and you then succeeded in propagating the inaccuracy to your friends.
Another "executive summary" (as you say) that is totally incorrect but which often gets propagated is "lisp is slow because it is interpreted". Here's my theory on why these inaccurate "executive summaries" get taught and propagated:
All languages have common aspects, and they have aspects that are unique. A Venn diagram of all languages would be fairly messy, and there would be very few one-color areas in such a diagram, because most languages must have at least enough functionality to be useful, either in teaching or in the industry, or both. Lisp is a hard language to describe, because it is so general-purpose, and has so many features that other languages have. So to teach Lisp, many will teach other languages first, and then teach only the differences between Lisp and those first languages. This inevitably leads to the kind of teaching you received, especially if your professors were themselves taught this way. For example, Why teach arrays in lisp; they are effectively the same as in the other languages we taught! Or, Lisp is good at recursion, so let's teach the recursion concept in lisp (this tends to lead one to the assumption that lisp is only good at recusrion, and can't iterate). Or, Other languages are compiled; let's show the students a Lisp interpreter (the fact that Lisp code can be interpreted does not preclude extremely efficient compilation, but teaching about interpreters in lisp can lead one to incorrectly conclude that lisp is only interpreted; incorrect for over 20 years).
> Mechanical engineers aren't taught Einstienian mechanics - they're taught > Newtonian mechanics. Newtonian mechanics isn't wrong - it's just > less accurate. When the book says to over design by a factor of six, > what difference does it make?
Don't know mechanics, but perhaps better design accuracy would lead to higher profits. It would seem like a useful difference to me.
> Perhaps Lisp needs a better executive summary.
Yes, it does. You shouldn't use the one you are currently using.
> Why do people use Perl and Java instead of Lisp and Forth?
At the face of it, your question is incorrect, because people do use Lisp (Forth, too, presumably, but I won't comment on that). I assume, though, that your question was really meant to be qualitative, as to why _more_ people use the former languages than the latter. If that is really the question, then I really have no idea. However, you should put some perspective on the question - the question used to be "Why do so many more people use C++ than Lisp?", but we hardly ever hear this question anymore. Any guesses as to the name of the next fad language to be replaced in the beginning of this eternal question?
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
handl...@ricochet.net (Maynard Handley) writes: > In article <41yvayoph....@beta.franz.com>, Duane Rettig <du...@franz.com> wrote: > > > I guess it would be good if the original poster > > > described the applications in question and explained > > > how LISP helped in their implementation.
> > Once again, it is our customers that describe these things, some of > > whose descriptions you can read for yourself.
> I don't want to mean about this, and I know pretty much nothing about > Lisp, so have no opinion, but the thing such lists never mention is the > customers who used Lisp and found it to be a terrible mistake for their > project.
Of course not. Why would we want to do that? :-)
Actually, the reason why I directed the original poster to our website was because the original question was why people felt they _must_ use lisp. Because the question was a directed question, and not of the form "what are the pros and cons ...", I felt justified in pointing there, even though it is one-sided...
> From a world with which I am more familiar, I have spoken to various > friends (not C bigots, people who've used many languages) involved in > projects with Java where they believe the use of Java was a terrible > mistake, that the resultant apps were horrendously slow memory hogs---but > I strongly suspect you want see any mention of them at a Sun web site.
Yes, we get customers who come from both C++ and Java shops to replace, either all or in part, their applications that either took too long to finish or were not very maintainable.
The major reason why people moved away from Lisp is historical:
Lisp was always very general-purpose, but was especially good at Artificial Intelligence, and was for a long time very closely associated with AI. The Lisp companies rode the great AI wave in the early 80's, when large corporations poured billions of dollars into the AI hype that promised thinking machines in 10 years. When the promises turned out to be harder than originally thought, the AI wave crashed, and lisp crashed with it because of its association with AI. We refer to it as the AI Winter. Some high-level managers who were burned by the AI hype actually kill any project with either the name AI or Lisp in it (that's why you don't even see or hear the term AI much anymore; most of the more successful branches of AI (e.g. speech recognition, expert systems) have distanced themselves from the name. And many distanced themselves from Lisp as well, trying to make a go of their projects in C, C++, or Java. Some have succeeded. Others, not. Some have come back to Lisp, and not told anyone, for the twofold reason that it might be a negative in their marketing strategy to mention the L word, and also because it became a competitive advantage to not mention how their time-to-market is so quick.
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Tim Bradshaw <t...@tfeb.org> writes: > What I'm trying to get at is that you seem to be assuming that lists > (really, conses, Lisp doesn't actually have lists as a distinct > representational type) are used as a kind of crap array substitute. > That was perhaps once true and might still be true in badly written > Lisp code (there is a lot of this). It *isn't* true in well-written > code.
Beeing able to use pointer equality is certainly valuable. Being able to use pointer equality for tails of lists certainly seem less obvious - and I suspect rarely useful. You may be right, but I am unconvinced The only way to decide something like this is to examine the problems where you say you need to be able to share list tails, and consider alternative solutions. That is probably more time than either of us want to spend. Might be a valueable paper in it, though. -- --Per Bothner p...@bothner.com http://www.bothner.com/~per/
>>>>> "Duane" == Duane Rettig <du...@franz.com> writes: > L word, and also because it became a competitive advantage to not > mention how their time-to-market is so quick.
I'd be surprised if it took their competitors more than a few minutes to figure out what compiler was used to build the application.
