Talk:Lisp (programming language)/Archive 2
This is an archive of past discussions about Lisp (programming language). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 |
Which dialects should be mentioned at the top?
Most Lispers will tell you that there are only 3 major dialects of Lisp now: CL, Scheme, and Emacs Lisp. The former two are standards and the third merits mention because it is ubiquitous.
NEWLISP is NOT a major dialect. It is neither a standard nor ubiquitous. To me, its addition is possibly a marketing effort. If it is to be included, then many other, more important dialects should also be included, such as librep.
It is already mentioned under minor dialects.
I removed it but left it in the rest of the article.
--gamba
FWIW, Scheme isn't really Lisp, either! Tacitus Prime 07:13, 18 September 2007 (UTC)
- Of course it is.--MarSch 09:52, 18 September 2007 (UTC)
- It really isn't. The defining feature of Lisp - or at least, one of the defining features (no-one expects the Spanish Inquisition!) is that source code is parsed into the internal data format (lists, etc.), and the evaluator/compiler works on that. Scheme, however, is defined on the external (text) representation (whether or not any given implementation actually uses
read
to parse source code is immaterial; as is being able to read the source as data — prior to R5RS, Scheme didn't even haveeval
) that has important implications wrt to "EQ
ness" that make it not Lisp (e.g., the possibility ofquote
making copies). Scheme is a language that looks like Lisp, and certainly has Lisp heritage, but it is not an instance of Lisp, IMNSHO. There's no reason to interpret "Scheme is not Lisp" as some sort of slight against Scheme. —Tacitus Prime 11:03, 18 September 2007 (UTC)
- It really isn't. The defining feature of Lisp - or at least, one of the defining features (no-one expects the Spanish Inquisition!) is that source code is parsed into the internal data format (lists, etc.), and the evaluator/compiler works on that. Scheme, however, is defined on the external (text) representation (whether or not any given implementation actually uses
You are confused. Scheme has a defined syntax. That makes it possible to use non-read-based source processing. Still READ will be and can be used. Scheme is a dialect of Lisp. —Preceding unsigned comment added by 85.176.9.180 (talk) 01:14, 9 November 2007 (UTC)
- Your arguments are implementation details and (non)-existence of some specific function??? Consider me unimpressed. IMANSHO a mostly S-expression based syntax (with the implication of simple powerful meta-programming) is all that is needed to be a Lisp. --MarSch 11:21, 18 September 2007 (UTC)
- It's not merely an implementation detail; it has a vital effect on the semantics of the language (and absolutely nothing to do with the existence of any function). See the long "Why is Scheme not a Lisp?" thread on comp.lang.lisp in early 2002 on this subject. —Preceding unsigned comment added by Tacitus Prime (talk • contribs) 11:46, 18 September 2007 (UTC)
- I do not see any reason to demand any similarity to the semantics of LISP to be considered a Lisp. Also if want to point to online discussion to back you up, you would do well to mention an URL. --MarSch 11:51, 18 September 2007 (UTC)
- It's probably better to ask Google yourself, but if you like: [a link] —Tacitus Prime 12:03, 18 September 2007 (UTC)
- I do not see any reason to demand any similarity to the semantics of LISP to be considered a Lisp. Also if want to point to online discussion to back you up, you would do well to mention an URL. --MarSch 11:51, 18 September 2007 (UTC)
I personally thing Clojure deserves a mention. DiscipleRaynes (talk) 05:56, 28 January 2009 (UTC)
Clojure may be mentioned as a dialect of Lisp (it is) but how come it got included into "Historically significant dialects" together with arc? — Preceding unsigned comment added by 190.173.209.209 (talk) 14:46, 18 September 2009 (UTC)
I suggest that "historically significant" should imply that there is substantial and enduring third-party writing (that is, not just promotional writing) about some application that is implemented in the dialect or about some later independently written dialect that credits it as an influence. In this, I would count standards because they are by definition enduring and because they are consensus writings of the whole community (and hence are not just promotional). The creation of a standard at all is a milestone of significance. Things that spawn hardware implementations are also important. For example, in no particular order: Lisp 1.5 influenced many later dialects. MACLISP (and arguably Franz Lisp) were significant because MACSYMA (something about which a lot of writing has been done) was written in it (them). PSL is significant because REDUCE (another historically well-known symbolic algebra system) was written in it. INTERLISP is significant because various important AI systems were written in it or influenced by it AND because the Xerox D-machines were intended to run it. Common Lisp and ISLISP clearly belong because they are standards. Zetalisp belong because it spawned the Lisp Machine family of processors. IEEE Scheme is a standard and that qualifies it. Revised Report Scheme has a lot of textbooks written around it, so that should probably qualify it. Dylan (especially early Apple-based Lispy-syntax Dylan, around the time it was code-named Ralph) seems to me to have been historically significant in that it produced an industry collaboration on the later dialect of Dylan, which I'm not sure was really historically significant in the grand scheme of things. But the basic design of Dylan has been influential on later thinking about Lisp and Scheme. Lisps on various hardware platforms like the VAX, Apollo, and even IBM and CDC mainframes influenced Common Lisp, which may be seen as significant; I'll leave it to others to say which ones. Constraints of Gold Hill Lisp made a material affect on the design of Common Lisp, so probably should be included. I'd like to think that the T dialect of Scheme was historically significant but since I worked on it, I have a conflict of interest in saying so; someone else can make the case for that if they care to, or can argue against. I don't have a strong stake. I don't know enough about ACL2 to know why it would qualify under any of these criteria, though that could be my own ignorance. If one is going to remove Arc and Clojure, my intuition is that ACL2 should also be removed. By the way, I agree with removing Arc and Clojure even though I personally have a lot of hope that Clojure will grow to eventually become a historically significant dialect; I just agree it should be disqualified for merely because it's too early to say it's yet enduring. --Netsettler (talk) 15:50, 18 September 2009 (UTC)
Applications
Myself, I've been involved with many commercial successes for 20 years. Where are the references to these? Emacs, for instance. I've added ICAD which is a wonderful example of an extreme form of End-user computing. jmswtlk 16:21, 29 December 2005 (UTC)
I changed "little languages" to "Domain-specific languages" because many of the interesting, major applications for Lisp are implemented as DSLs on top of a Lisp system, so the term "little languages" (a term I usually associate with things like commandline syntaxes for Unix programs) seems to understate the case. Something like Common Lisp Music, for example, is hardly "little". Dzlk (talk) 15:13, 5 May 2008 (UTC)
Logo and turtle graphics
I restored the link to turtle graphics in the description of Logo as it is the best known feature of the language and it's not mentioned elsewhere in the article. --Tony Sidaway|Talk 20:23, 14 January 2006 (UTC)
.NET programming language?
Why is there a category ".NET programming languages"? Shouldn't the correct place for this category be only in article L Sharp .NET programming language? --lauri 07:08, 26 January 2006 (UTC)
- Quite right! Gone now. --FOo 07:16, 26 January 2006 (UTC)
Raymond's influence removed?
CYD just removed the note that "Many new Lisp programmers describe the writings of Paul Graham and Eric S. Raymond as influential in their decision to pursue", replacing it with the text that "Many new Lisp programmers were influenced by Lisp 'evangelists' such as Paul Graham in picking up"; his edit comment was that "Raymond never did any Lisp evangelism". I think this edit discounts the writing that some people do cite as influential in their decision. I believe that the evangelism in question is from How To Become A Hacker. Specifically, esr speaks of "the profound enlightenment experience you will have when you finally get it", and "that experience will make you a better programmer for the rest of your days". A quick search in the Road to Lisp surveys linked to from the article (in that paragraph) will show multiple hits saying that this influenced their decision to learn Lisp. So I think that this edit should be reverted, but wanted to see if I could get consensus before doing so. - Piquan 22:48, 2 February 2006 (UTC)
- I've certainly seen positive comments by ESR on Lisp, so it's inaccurate to say that he "never did any Lisp evangelism", except insofar as the word evangelism is misapplied. That said, it probably isn't too important for the article's phrasing to name everyone who's said something good about Lisp. --FOo 05:46, 3 February 2006 (UTC)
- I think he belongs in the list. Much of the Linux and other free software community would be unaware of Paul Graham, but very aware of ESR. His occasional words about Lisp (such as it being one of the two languages GNU will have and his comment cited above in How to Become a Hacker) are not as strongly influential as Graham's extensive writings, but he has a much larger audience so the aggregate influence is comparable if not greater. Ari 06:11, 3 February 2006 (UTC)
- I think you'll find that ESR doesn't have much to do with GNU ... it was rather RMS who said Lisp was going to be one of GNU's two system programming languages, waaay back in the original announcement of the project.
- It's actually one of the few goals of GNU that didn't get fulfilled in modern GNU/Linux systems ... others being a versioning filesystem and a release-quality HURD. (Yes, there are high-quality free Lisp systems for GNU/Linux ... but as with the kernel, that's one place other contributors got well ahead of the actual GNU folks.) --FOo 06:26, 3 February 2006 (UTC)
- Fair enough. I was mistaken, and it's hard for me to envision why ESR would be mentioned. Ari 03:18, 5 February 2006 (UTC)
- Instead of depending on the weaselly "many new Lisp programmers", why not use a quote from an actual new Lisp programmer who cites ESR influence in his/her own words? I'm a little skeptical that any exist, but a verifiable direct quote would prove otherwise. Stan 14:10, 3 February 2006 (UTC)
- Check the references! The footnotes on that section take you to the "Road to Lisp Survey", a section of another wiki site where new Lisp programmers relate their experiences. --FOo 07:57, 5 February 2006 (UTC)
- While in general, I agree that verifiable quotes are preferable in general, whom do we use? New Lisp programmers are not generally people whose quotes are noteworthy for an article on Lisp. Besides, the fact that one particular person said that esr influenced their decision is not the point: the fact that several did is. So including one quote instead of the "many" phrase isn't really getting the same point across. Other than that, I'll expand on what FOo said. The Road to Lisp pages (which are a reference in that same paragraph) are easily checked: there's a search function, and even a wiki category for Road to Lisp stories from people who feel that esr was influenced them (I believe it's RtLRaymond, but you can find it easily enough yourself). --Piquan 11:01, 5 February 2006 (UTC)
- Ok, I'm not really sure if we have consensus here or not. Any second opinions? --Piquan 03:42, 10 February 2006 (UTC)
List processing operations
I recently wrote a (stubby) article on append
, and was trying to find logical places to cover that material and link to it. I ended up adding a section on list operations to this article. I'm afraid it's probably woefully inadequate; I'm still learning functional programming, and I have more experience in Scheme than Lisp, but I'm hoping it's a start.
To some extent, the material seems a bit more specific than I might want in the general "Lisp programming language" article. I certainly wouldn't object to it being moved to a subarticle, but there doesn't seem to be an appropriate one existing yet. I don't know whether it might be appropriate to have a separate article on "List data structures in LISP-like languages", or something like that. -- Creidieki 21:57, 9 March 2006 (UTC)
- I think that producing material about this sort of Lisp-specific information is a great idea. I'm not sure that Wikipedia is the right place, though; as you mentioned, it does seem out of place here. However, Wikibooks may be just the right place for your Lisp articles. --Piquan 10:08, 10 March 2006 (UTC)
- Yes, if you write an article about list processing for Common Lisp Wikibook taht would be cool. You can also start Scheme Wikibook, which is not developed at all. Grue 10:27, 10 March 2006 (UTC)
Functional Language?
I don't know if Lisp can be considered a functional programming language. It indeed has functional support, but it also supports other features that can break the functional paradigm. The preceding unsigned comment was added by 24.84.195.200 (talk contribs) 02:41, 27 March 2006 (UTC1)
- Lisp was not invented to advance any particular ideology about programming. It antedates by several years terms such as "functional programming", "object-oriented programming", and so forth. It was invented a decade before anyone thought it would be a good idea to make languages artificially more restrictive in order to constrain programmers to specific favored practices.
- (Lisp -- 1958. "Go to statement considered harmful" -- 1967. Pascal, the first language designed to restrict -- 1970.)
- When the first Lisp dialects were developed, the problems of the day were making languages more expressive (particularly, more like mathematics) and more reflexive (because it was thought this would aid AI). Constructs such as upward and downward funargs (the ability to pass functions as arguments, and return them as values) had to be invented before anyone could come up with the claim that all programming should be done functionally. They were invented in Lisp.
- Lisp as it is practiced today (in either Scheme or Common Lisp) is more akin to functional programming style than the original LISP was. This is largely because we have learned to gloss over or hide some of the innards the original systems exposed: we have languages more like mathematics and less like machine code. We also have optimizations which make functional style efficient enough to be practical -- tail-call optimization; dynamic compilation; type inference. These were developed for Lisp.
- Of course Lisp does not enforce a functional style, for the same reasons it does not enforce an object-oriented style. It supports these styles, just as it supports structured programming and even imperative kludging with GOTO if you really want it. Nonetheless, it's correct to say that Lisp is broadly in the camp of functional programming because Lisp is where the ideas of functional programming, and the tools needed to do it well, were developed. --FOo 05:16, 27 March 2006 (UTC)
- It can be quite hard for us to state the obvious, without citing, but I know a guy whose primary job description is Lisp Programmer. If you do a little research you will find that lisp is a functional language applicable in commercial industry. Yet, I will admit it is in a limited sense.
- Ähumm!! Of course LISP (note the all-caps!) is a functional language. It's the functional language. The distinguishing feature of functional languages is that the function is a kind of data. Since LISP was built on lambda calculus, and lambda calculus regards the function as a kind of data, LISP is by definition functional. One may do the following in a functional language:
int fun (int n) { return do_something (n); } typedef int iifun(int); int main (void) { iifun *fptr = fun; int R;
R = fptr(997); /* and the function fun is called */ }
- The above C code actually works, so by accident (or by intention), C "inherited" being a functional language from it's main inspiration Algol 68. Said: Rursus ☺ ★ 19:41, 16 July 2007 (UTC)
- C isn't functional because a C function does not return its last statement (need an explicit "return"). -- Jerome Baum —Preceding unsigned comment added by 77.176.69.76 (talk) 23:19, 27 January 2009 (UTC)
I disagree with those saying Lisp is a functional language. First, Lisp is a language family, not a particular language. Some Lisp languages are more heavily functional than others. Many modern commercial programs in Common Lisp rely heavily on state and side-effect; this is an intended aspect of languages like Common Lisp. I think it varies heavily from language to language within this family how true it is that Lisp is a functional language. It promotes huge misconceptions to say that all of them are. --Netsettler (talk) 16:46, 24 August 2009 (UTC)
Another comment on functional style
While it is true that CL is multiparadigm, I think that the following paragraph is far too strong. Functional programming is far more widespread an ideal in CL than is indicated. I propose that it be toned down a bit. It implies that CL is much more imperative than it is culturally.
The style preferred by many Common Lisp programmers may seem more familiar to programmers used to structured languages such as C, while that preferred by Schemers more closely resembles pure-functional languages such as Haskell.
I propose:
Common Lisp is multiparadigmatic, and it supports an imperative style, familiar to users of languages such as C. However, functional programming is culturally well regarded and most experienced Lisp programmers use it when possible. This preference is stronger in Scheme, which more closely resembles pure functional languages such as Haskell.
--gamba
- Experienced functional programmers may use Lisp frequently, but that's more a statement about their preferences than about the language. Common Lisp offers almost nothing beyond simple closures that actually helps with functional programming, and a number of features (
DEFSETF
,UNWIND-PROTECT
,LOOP DO
, the entire I/O system...) that can only be used imperatively. Scheme's tail call guarantee and mutator naming convention are only small steps towards languages like Haskell. - Erik Seaberg 04:24, 30 June 2007 (UTC)
Edit war about polish notation and AutoCAD?
I am somewhat baffled by the repeated reverting of what seemed to me perfectly valid edits. Could the reverters please explain why they do not this article to link to AutoCAD and polish notation? —Tobias Bergemann 08:30, 1 April 2006 (UTC)
- I have not a clue as to the issues with AutoCAD.
- But one author has confused a list prefix notaton with polish notation. Polish notation doesn't use (or need) parentheses because the arity of an operator does the job, list notations use parentheses to handle the arity and can therefore handle N-ary operators.
- For example, the traditional notation
(a*b)+(c*d)+(e*f)
- could be written in a list notation as something like
('+ ('* a b) ('* c d) ('* e f))
- but in a polish notation you have fixed operator arity (binary in this case) and you would have to pick either
+ + * a b * c d * e f [corresponding to ((a*b) + (c*d)) + (e*f) ]
- or
+ * a b + * c d * e f [corresponding to (a*b) + ((c*d) + (e*f)) ]
- The notations are obviously related (they both put the operator first), but not the same at all.
- The list notation is a lot more flexable, and can handle things needed in an AI language such as operators that take operators as arguments. Nahaj 13:58, 1 April 2006 (UTC)
- It isn't really an edit war. The two editors that were reverted were both Sockpuppets of banned user Zephram Stark. His edits are reverted without regard to their merit. So if you think some of the changes were appropriate, them you can make the edits and they won't be reverted. --JW1805 (Talk) 14:54, 1 April 2006 (UTC)
- I ReiniUrban have some clue about AutoCAD. I deleted SageCLOS from Object systems, as of the 22:12, 1 December 2005 edit by 68.219.238.110. SageCLOS is a simple CLOS for AutoLISP, but is no seperate new and distinct Object system for LISP, as flavors, CLOS or KR truly are. SageCLOS tries to fill in for CLOS, without having the possibility to use macros and some syntactic sugar, a real lisp has. ReiniUrban 09:05, 10 September 2006 (UTC)
Lisp Criticism
why isnt there any section for criticism of lisp? no one did one? :) - --Cyprus2k1 12:04, 22 May 2006 (UTC)
- Because LISP is without flaw of course! Begone heretic, lest you wish to smell burning faggots. :) --DV8 2XL 12:16, 22 May 2006 (UTC)
- Apart from the joking braggadocio of DV8 2XL, I feel rather strongly myself that there should not be a criticism section in this article. There is a very distorted misreading of "balance" that seems to arise among editors of many topics, but especially technical topics. They come to believe that NPOV mandates that whenever some topic is discussed, a collection of negative comments about that topic need to be recruited out of "balance". But such sections almost always read as very unencyclopedic, and ultimately rarely very informative. I've fought off the same misconception at Python programming language and Functional programming. Unfortunately, I recently noticed that Object-oriented programming has an overly long and unprofessional looking "criticism" section.
- What an article on something technical like a programming language or programming paradigm should do is present all of what it discusses in a sufficiently neutral fashion that there is nothing to be counter-balanced in the first place. So don't write that "Lisp does blah because that is the most powerful technique". Either just write "Lisp does blah" and leave it at the plain fact... or quote some specific source that claims blah is "the most powerful technique". As long as the entirety of the article avoids advocacy, some separate section for criticism is superfluous. LotLEtalk 18:10, 1 June 2006 (UTC)
- I have been a Lisp user since 1970, and I am very fond of it. However, I think it makes perfectly good sense to incorporate criticism both in specific sections (e.g. "Jones has criticized this design decision because xxx[biblioref]") and perhaps in a separate section if there is in fact relevant serious literature, like Kernighan's "Why Pascal is Not My Favorite Programming Language" and Hoare's "The Emperor's Old Clothes" -- though I disagree with many of Hoare's arguments, it should certainly be referenced in the Ada article, which it is not currently. There must also be serious articles about Scheme vs. Common Lisp. --Macrakis 19:19, 1 June 2006 (UTC)
- I entirely agree on the "inline" criticism when some specific feature are fact is discussed. Certainly if we report that "Lisp does blah" it is reasonable to also mention that "Jones criticizes the choice of blah". The thing I don't like is a whole section devoted to "criticism", since it almost always turns into a semi-random collection of negative remarks w/o any helpful structure (in every technical article where I've ever seen such a thing). LotLEtalk 19:26, 1 June 2006 (UTC)
- I think that's fine, as long as "Jones" is notable and we verifiably cite where that criticism was made. This helps keep WP from becoming a collection of original research/analysis and user reviews. --Ds13 19:56, 1 June 2006 (UTC)
- a few common lisp criticism include, the irritating parenthesis , the code gets too confusing if the algorithm is more complex, speed issues, its easy to program inefficient solutions but harder to program efficient solutions, the language itself is too large , in java and python its organized in objects which makes it easier to remember and use, the majority of university students who use it, hate it and never want to even heard of it again.
- im not sure if its true but according to this lisp doesn't define threads or GUI.
- anyway, knowing the pros and cons of a language is a usefull information when choosing one. and therefore should be present in wikipedia articles, as long as it stays NPOV - --Cyprus2k1 11:17, 9 June 2006 (UTC)
- People may or may not like various attributes of Lisp, but the only criticisms that belong in an encyclopedic article are those written by competant scholars. What undergraduates think of it after brief study is not terribly interesting and certainly not encyclopedic. --Eipi 13:40, 9 June 2006 (UTC)
To reiterate Eipi's point: While everyone is qualified to complain about something they don't like, not every complaint is noteworthy criticism. For instance, I would suggest that Ron Garret's "How Common Lisp Sucks" is far more noteworthy than some freshman's complaint that he doesn't like being assigned to learn Scheme when he'd rather learn C++ so he can get a job as a code monkey. Garret (n Erann Gat) has been working with Lisp for many years, and has a refined understanding of the ways in which it sucks, whereas the freshman does not. --FOo 04:51, 10 June 2006 (UTC)
If people do think its worthwhile adding a criticisms section then they should not repeat what is elsewhere in Wikipedia. For example, criticisms due to Lisps nature as an impurely function language should refer to other pages on that subject rather than repeating it. The problem with many of the criticisms in other language entries is that they rehash issues mentioned elsewhere in wikipedia, and do so badly. - --Jrthorpe 14:38, 26 July 2006 (UTC)
- So much rudeness here. Why assume the critics are freshmen? As far as I know, there is NO university program that uses LISP, because it is a pathetic language. Scheme, there are a few that come to mind. In any case, there are very few companies that use LISP, because it is a lousy language misdesigned from the get-go. C/C++, Java, Perl, .net, python, maybe even ruby here and there, some COBOL, some Fortran, but NO ONE uses LISP. It's hard to imagine someone using it since '70. I say, bring on the criticism section. And spare the "unencyclopedic" preachiness. As if the current level of detail about a programming language is something that belongs in an encyclopedia. Igottalisp 00:20, 21 October 2006 (UTC)
- Geez, got some serious fanboyism here. LISP is dynamically scoped, which all computer scientists that don't use LISP agree is absolutely retarded, leading to unpredictable code and poor efficiency. This is a valid criticism but the fanboys keep removing it. Igottalisp 01:14, 22 October 2006 (UTC)
- All computer scientists agree that Lisp is absolutely retarded? That's pretty serious claim. Care to provide a source? Grue 11:17, 22 October 2006 (UTC)
- Geez, got some serious fanboyism here. LISP is dynamically scoped, which all computer scientists that don't use LISP agree is absolutely retarded, leading to unpredictable code and poor efficiency. This is a valid criticism but the fanboys keep removing it. Igottalisp 01:14, 22 October 2006 (UTC)
- They think dynamic scoping -- LISPs form of scoping -- is retarded. NOBODY uses it and NOBODY likes it. It is less efficient and is confusing. It's impossible to find anything proving they all dislike it, but there are plenty of individuals who've said so. Dynamic scoping is not used in any language with any significant mindshare (Perl has it in the "local" construct for holdouts, but it rarely used). Here's one site: [1] History has taught that static scoping is far preferable to dynamic scoping....Upshot: if you have to implement a language, use static scoping. Igottalisp 03:25, 24 October 2006 (UTC)
- You're right that NOBODY uses dynamic scoping, indeed. In fact, modern Lisp systems don't even use it. Scheme doesn't, Common Lisp doesn't, Arc doesn't ... basically the only folks who still use it are the Emacs people. --FOo 05:14, 24 October 2006 (UTC)
- Not quite. Dynamic scoping is used in Common Lisp for special variables. It makes a lot of sense for global variables and similar stuff. And it's not confusing because programmer usually puts asterisks before and after variable name so it stands out. So, I use dynamic scoping, and I like it. Grue 15:28, 24 October 2006 (UTC)
- Yes, yes. Don't be tedious. The newbie's implication was that Lisp used dynamic scoping only or by default, which is thoroughly wrong. --FOo 17:56, 24 October 2006 (UTC)
- The old school hanger on speaks out to (personal-attack someone (who (disagrees-with him)) . So what if some dialect of LISPs were shamed into modernity by other languages -- it only proves how lame LISP was to begin with, and it leaves other dialects using the outdated dynamic scoping....and decades worth of legacy code unusable on "modern" LISP systems. It is still a criticism of LISP that has been and is still used. Just cause fanboys don't like to admit when their favorite toy has blemishes doesn't change the fact, so give up on the "removed POV" edit summaries. Igottalisp 04:36, 25 October 2006 (UTC)
- Whoa, I get the shivers when I read this! Although I am not an unreserved fan of either Lisp or dynamic scoping, I must say you must obviously be a Wikipedia-troll of the most abysmally dumb kind. Thank you. 0ffh
- Wow! Such a lot of heat and light. However, that doesn't settle it. We do need a criticism section. LISP has several known weaknesses which have precluded its use in the commercial world. Examples are its non-intuitive syntax which is designed for being easier for the computer to parse than for a human to read (a similar conundrum destroyed FORTH), its obscure terminology and keywords that have been kept on (eg: 't' for true while 'nil' for false), idiosyncratic type-systems (sometimes so flexible that bypassing them is easier than in BCPL -- which had none to start with), requirement of a substantially complex runtime to host even the simplest of programs (the reason why LispMs lost the performance race with UNIX workstations very soon) while requiring great amounts of computer resources for any medium to large ones (not a problem in AI research labs funded by the Generals, but a great problem everywhere else), failure to embrace object-oriented programming soon enough (i.e., soon enough for LispMs to have maintained their performance crown), flaky support of modularity in large programs (lack of the compile-link-go cycle that made greatly complex programs impossible to run on machines that weren't suitable for developing them) -- particularly the non-feature-rich system linkers in many systems, etc, etc, etc. The single greatest reason for resurgence of LISP since the 2000s is the availability (finally) of computer systems powerful enough, cheap enough, and in large enough numbers to support full LISP systems. LISP may have a bright future yet, but it will not be due to AI labs. Also, the systems which can support LISP with high performance can also support Java Virtual Machines with equally high performance, and extraordinarily more complex now-traditional C and even modern C++ (i.e., C++2003) programs. The most important contribution of LISP to Computer Science is not that it is a particularly useful programming language, but that it has enabled a generation of programmers to grasp that many more things are possible in a computer language than conventional wisdom states. As for Emacs LISP, I have no positive comments whatever, for I consider it to be the greatest cause of the infamy that now surrounds LISP. If I had my way, Emacs LISP would not even be allowed to have `LISP' in its name. Merely by copying the syntax and some idioms of the LISP language it does not become a LISP system. It is basically a macro language for a text editor, and is no more to be considered a programming language than Visual Basic for Applications in Microsoft Weird. —The preceding unsigned comment was added by 221.134.161.90 (talk) 14:47, 11 April 2007 (UTC).
One thing I know for certain is that anyone who calls it "LISP", in all-caps, certainly doesn't know enough to be worth listening to... :) Tacitus Prime 06:13, 18 September 2007 (UTC)
- (Ad hominems aren't going to move things forward.) There is some useful stuff in there amid the other stuff, and I'd like to see them sorted out. Regarding "We do need a criticism section." (a couple paragraphs above), I went to C++ to see if it had a criticism section and it does. I think creating a place for that means people don't have to inject it elsewhere, and people who want to read about such issues can read it. I actually like the "Controversies" super-heading in that article more than the "Criticism" section, not just because "Criticism" is not upbeat but mostly because it's not specific. Any section that has a title like "Criticisms" needs specific subheadings on specific topics so that there's room for exposition and rebuttal, or else it's just a place to drop attacks and be done because there's no real syntactic room for reply. But properly managed with subheads, it's a good way for the community to organize summaries of the standing issues of confusion and concern.
- Returning again to the same paragraph where it says "LISP has several known weaknesses which have precluded its use in the commercial world.", that's something that I think is trickier because the reasons people don't do things are legion and except where there is a documented process for decision-making that includes all of the factors, I think it's divisive to make this a per se goal for the same reason as Userboxes are forbidden to say what people don't like. Most people spend most of their time not doing most things. It's more constructive to focus on the reasons people do things, since there's so much less of that going on. Who cares why some people don't read the works of novelist Stephen King? People don't read things for a variety of reasons. Maybe Stephen King could sell more if he wrote less scary stuff (and yes, I know all his work isn't scary--it's just an example). A section on why he isn't more popular seems like something Wikipedia ought not be involved in since it's inherently speculation about counterfactuals. What's interesting to an encyclopedia is that he is popular, and that people may document why. It's also fine to discuss objective questions that may influence popularity, like writing style, plot structure, and genre, since those are somewhat objective measures. Likewise for programming languages, it makes sense to talk about reasons people like Lisp, and the objectively observable properties of Lisp. But talking about why it's not used more in business, without serious documentation, seems out of the realm of Wikipedia.
Application Order
"Evaluation is performed in applicative order."
I don't think that this is strictly true. In most Lisps, it is, but, in R5RS Scheme, for example, I'm pretty sure that the order is unspecified and may even vary within an implementation (depending upon what optizimations are made) and maybe even between different executions of the same expression. --69.61.168.145 02:49, 22 August 2006 (UTC)
- I think the order of evaluation of function arguments is independend of the evalutaion order mentioned here. Applicative order means that all arguments to functions are immediately evaluated in contrast to for example normal order evaluation as employed by lazy languages like Haskell. --MarSch 15:18, 18 September 2007 (UTC)
- According to the applicative order article, that phrase means the same as leftmost innermost. I think you mean strict/eager evaluation as opposed to non-strict/lazy evaluation. Making it a separate paragraph. Boemanneke (talk) 17:41, 5 December 2007 (UTC)
Missing stuff
The Smalltalk#Image-based persistence article mentions this in one section:
- "Other languages that model application code as a form of data, such as Lisp, often use image-based persistence as well."
(Where it's talking about persistent System images.)
I vaguely remember hearing about something similar for Lisp machines, with "worlds". Could we maybe add a section on that? -- Gwern (contribs) 20:29, 23 September 2006 (UTC)
It might indeed be worth mentioning. But though such a feature was available on Lispms and is in most Common Lisps, I think, it wasn't used in the way it suggests. Random data that could go into a section on this topic, since I don't have time to write it: A lot of Lisps load up "fasl files" (fast loading, i.e., compiled files) and then have a suspend or dump command that dumps things back out as an executable image in its entirety for delivery purposes. (Note that this is often not for the purpose of sustaining development work from day to day--that is stored in files. I think that cross-reference in the Smalltalk article is really wrong to cross-index Lisp in the way it does; I suspect it should refer to using a similar technique for different end-purposes. That is, in Lisp, it is an optimization sometimes (but infrequently) used to load up work. That is, the normal way to load work is to start a lisp, then load your code, and sometimes you can dump a lisp with that code loaded and start from there, but most commonly the reason for dumping an image in lisp is not development but the deployment of finished applications. It's a common confusion with newbies that they work interactively and then expect to save their work and are surprised that this is not the recommended way of doing things. This is not what I understand Smalltalk to do, though I have not used Smalltalk.) It's possible that Interlisp had the model of actually saving out an entire image for the purpose of continuity of development work, though even there I am not sure (I just suggest it as something someone should research). Incidentally, the MOO language has image-based persistence as described in the Smalltalk article. Btw, it's probably no coincidence that Smalltalk, Interlisp, and MOO all come out of Xerox PARC. I suspect that there is a design preference there that is reinforced by personal associations and organizational preference/experience (which is not to say it's bad--just that it's not random coincidence). --Netsettler 07:22, 9 November 2007 (UTC)
Name
I'm not all that happy with the current article name, parenthesized or no: it suggests Lisp is a single language, when the very intro takes pains to emphasize that it's a family of languages with quite a bit of diversity in it. Perhaps we should move it to Lisp programming language family or something more accurate at least? --Gwern (contribs) 15:28, 9 October 2006 (UTC)
- Not a bad idea. --MarSch 15:19, 18 September 2007 (UTC)
- I agree with Gwern's suggestion and rationale, and add the following comments by way of underscoring the importance:
- This issue is confusingly presented and the use of "language family", "language", and "dialect" is not consistent throughout this article. There is considerable disagreement about whether it is appropriately described as a "language family" (with "languages" as the component pieces) or as a "language" (with "dialects" as the component pieces). To some, this is simple normalization of usage without real-world implication, and may be reasonably done editorially, while to others these terms carry objective implications through their mere use and may not be used editorially. I was pleased to see that Wikipedia's Dialect entry, which was probably written to describe natural language, is suitably general in its analysis to sum up some of these issues. An attempt to integrate the work already done in those areas would be productive.
- I would endorse moving the present discussion from Lisp programming language to Lisp programming langauge family, and leaving Lisp programming language as an ambiguity page in the style of Whole number or Billion, telling people who click through to it that they really want to be looking at either the article on the language family (to find out the history of the individual dialects, to find comparative information, etc.) or at some specific dialect (to find out specific semantics).
- The fact that there is even an attempt to talk about "syntax and semantics" of Lisp in the Lisp page (rather than in individual pages) is suspect and flirts with the divisive that Wikipedia seems to want to avoid. It's fine to refer to elements that are common, and to cite lists of dialects that endorse it. But to say, as happens in the top of the Syntax and semantics section, “Note: This article's examples are written in Common Lisp (though most are also valid Scheme).” is effectively to admit that a language class cannot have a semantics, and to weaken the notion of what it is to have a semantics. (I'm quite on the liberal end of what it is to be a semantics, and don't require a formal semantics, but I do suggest that a semantics should, at minimum, be a decision procedure intended to answer the question "can I do this?" and no such question can be meaningfully answered about a language family as broad as this one. As an example, I've studied the matter in detail and believe there is no operator whatsoever in the language family that occurs in all dialects with the same syntax and semantics!)
- To some extent, the history of Lisp has been an exercise in branding, both in the positive sense of wanting to associate oneself with its perceived strengths and in the negative sense of wanting to distance oneself from its perceived weaknesses. But, as such, leaning too heavily on it as a "defining characteristic" and not outright acknowledging the arbitrary and even sometimes Machiavellian nature of the union that defines this term is likely to lead to trouble. They say that if you're playing poker and you don't know who the fool is at the table, it's you. If someone comes to Wikipedia asking "what's this Lisp thing?", the biggest service Wikipedia can do is to say "before you get the answer, you'd better understand which question is being asked". It can then proceed to document the various answers to the various questions that might be asked, but at least the naive reader will understand that the landscape of the question might matter, just as no matter how one falls on the abortion debate, knowing that the term Life is now politically charged and no longer objectively definable in a canonical way is essential to navigating the space.
- Sorry for the long comment. I worked for a long time trying to get my thoughts into a space even this small. But it's a complex topic. --Netsettler 05:43, 9 November 2007 (UTC)
Cleaning up
I've done some cleaning up also involving removing a lot of stuff that is not particularly relevant to Lisp. This article is not about Common Lisp after all. I'd also like for most of the explicit syntax use to go away. No need to duplicate Common Lisp.--MarSch 17:40, 9 February 2007 (UTC) Furthermore I've now moved the extremely stripped down Genealogy section up into the ``History`` section. This needs some major reworking and especially the lists should be killed. I also think that for the major Lisps, Common Lisp and Scheme there should be a separate section. --MarSch 19:07, 9 February 2007 (UTC)
Why were all the minor dialects removed?
It seems rather strange to me that as a result of a large series of edits to the Lisp page on Feb 9, 2006, by MarSch there is now a page on newLISP that goes into great detail about newLISP, but is not linked to from this primary page on Lisp. The same is true for many of the other "minor dialects" listed on this version of the Lisp page. References to those other dialects were removed from the main page. Personally, I think that these should be listed somewhere on this page so that people interested in Lisp can go and find out about some of the other Lisp dialects out there. Was this intentional? Or just an omission during a large editing cycle?
Given that there has been so much discussion and debate in this page's history - and I have not been part of that, I'll not go and put them back in myself, but I would suggest to those of you maintaining this page that they should be included again. What do others think? - Dyork 18:25, 12 February 2007 (UTC)
- All I did was remove the __list __ of minor dialects. If you want something like that you should use a category or create a list article. If you can write some __prose__ on the minor dialects that would be fine here. --MarSch 11:00, 13 February 2007 (UTC)
- In text in another section, you (please note that that was someone else MarSch 12:25, 9 November 2007 (UTC)) remarked about "It is neither a standard nor ubiquitous. To me, its addition is possibly a marketing effort." and I almost replied there, but there seemed more breathing room for discussion here, so I'm attaching my comment here. I agree with the desire not to have Wikipedia be a marketing forum. And if "ubiquitous" and "standard" are just some of several qualifications, I think that's going in the right direction. But I might suggest that "substantial" is the right concept, and that if Wikipedia doesn't have a general criterion for establishing substantiality in some sort of quasi-objective way, it should. Examples (not intended to be either mutually exclusive or exhaustive) of criteria any one of which would establish it for me might be:
- "formally standardized by a recognized standards group whether or not used" (ANSI Common Lisp, ISO ISLISP, IEEE Scheme)
- "implemented by more than one vendor/supplier" (CLTL, CLTL2, Zetalisp, Emacs Lisp, EuLisp and early Dylan--which was much more Lispy than later Dylan)
- "the subject of multiple independently written books" (AutoLisp)
- "expressly cited by standards or peer-reviewed scholarly works as influential" (Lisp 1.5, Interlisp, MACLISP, Franz Lisp, PSL)
- --Netsettler 06:32, 9 November 2007 (UTC)
On the heels of my remarks above, someone just edited out a bunch of Dialects from the list in the infobox at the top. It surprises and frustrates me that removing information is permitted at all from someone who has not identified themselves. I see just an IP address and have no one to respond to. I don't want to undo another's decision, even a decision I disagree with, without discussion. And yet, how am I to discuss this? The label does not say "Major Active Dialects" nor "Featured Dialects", it just says "Dialects". So I had added several dialects for which there are Wikipedia entries. I don't mind them being removed, but I mind the label giving the misleading sense that these are the dialects. Moreover, I would like to understand what "Obsolete" (it was spelled "Absolete" in the history) means, given that some of these dialects continue to be available today. I suspect EuLisp is, for example. And I know that it is possible to get PDP-10 emulators and to try MACLISP. I don't mind a clear criterion, and I have no specific agenda to get a specific list on there or not, but I'd like it to be obvious what's listed. For example, ISLISP recently came out with a standard; by the accounts of some, a standard at all, and especially a recent one, should be enough. Others have suggested to me that ISLISP has a tiny user community, though I have no way of gauging that. And even if I could, how could I know if it was "tiny and growing" or "tiny and shrinking"? How am I to understand the removal of MACLISP, which might have once had (and might even today) more users than ISLISP, and which might have more historical programs written in it, from that list? Even I would not contest NIL not being there if the criterion is major/minor, but where is such a criterion documented? In the change notes of an anonymous IP address? NIL is documented as a dialect by Wikipedia and it seemed an error not to include it in a list of dialects given that there were no guidelines to suggest otherwise. When someone asks (and inevitably they will) whether Zetalisp belongs there, what will be the objective criterion for deciding, since surely there are users still today using that. What about Autolisp? Will whoever made this change please make themselves known? --Netsettler 10:17, 9 November 2007 (UTC)
Lisp has such a rich history, that a bit concentration is needed to remove complexity from the article. In the top box I would only list relevant dialects. Dialects that are in use for software development or are significant as a reference to documentation or code. There are possibly hundreds of dialects and we should concentrate there on the obvious ones. Available are lots of dialects. The Internet has lots of archives for obsolete stuff. But at the top we should link to things that are in use and not to dead cities. We should list dead cities below somewhere, but most important is to point the reader to active communities. Compare that to the presentation of a country here in Wikipedia. At the top we find the capital, the current government and all important uptodate information. Then somewhere in the article you will find a reference to older governments and to the history of the country. We should present Lisp like a country or a continent - with information what is relevant today at the top. Then I would list minor dialects that are somehow active. Not every hobby project that is abandoned after the Lisp showed a prompt should be listed. Minor dialects would be some which only run on some platform or have a small user base. Then I would list dialects that are dead, abandoned, no longer used for software development, but which are interesting. Dialects like Lisp 1.5, 3-Lisp, Lisp Machine Lisp, InterLisp, InterLisp-D, Standard Lisp, Portable Standard Lisp, MacLisp, Prefix Dylan, StarLisp, Paralation Lisp, Connection Machine Lisp, QLisp. Plus lots of others. But as a general rule, I would really like to see the main article on Lisp (the language family) to be more focused and a starting point for more articles (History, Standardization, Interesting Dialects, Interesting Books, Interesting Publications, ...). -- RJ —Preceding unsigned comment added by 85.176.7.139 (talk) 14:24, 19 November 2007 (UTC)
Gentle Intro for Links Section?
Hi. I'm interested in learning Lisp. Is this recommended for the External Links section?
Common Lisp: A Gentle Introduction to Symbolic Computation by David S. Touretzky
Thanks Dhammapal 04:35, 21 March 2007 (UTC)
- There are many Lispen. Look at Common Lisp and Scheme for more info. --MarSch 10:03, 21 March 2007 (UTC)
The meaning of the abbreviation "cdr"
When I studied Computing/Computer Science (Informatica) at the Eindhoven University of Technology (in Eindhoven, The Netherlands), the well-respected professor that taught LISP (Prof.dr. F.E.J. Kruseman Aretz) told us that "car" (indeed) stood for "Contents of Address Register", but that "cdr" stood for "Contents of Data Register". I have to admit that "Contents of Decrement Register" makes more sense from the point of view of a "list processing" language, but, at the same time, "Content of Data Register" makes more sense on the much lower level of the CPU's native/assembly language. So which one is correct? Does John McCarthy say what "cdr" means? If so, I'd like to see a reference to that in this article. wjmt 01:22, 8 June 2007 (UTC)
- Decrement has nothing to do with list processing and everything to do with the IBM 7090's architecture. See [2] or IBM 7090: "The basic instruction format was a 3-bit prefix, 15-bit decrement, 3-bit tag, and 15-bit address." --Macrakis 02:12, 8 June 2007 (UTC)
LISP not Lisp
LISP is an abbreviation for LISt Processing - therefore the article name should be LISP, not Lisp (programming language). I've actually never seen Lisp elsewhere than on Wikipedia! Said: Rursus ☺ ★ 19:46, 16 July 2007 (UTC)
- just look at the first reference, http://lispers.org/ and you will see we are not the only one. As I understand it LISP is the name of the first incarnations of Lisp. --MarSch 11:12, 17 July 2007 (UTC)
For a similar case, see Fortran. These languages were known by all-caps names back when most computers only used capital letters. Recent writers use the mixed-case names. --FOo 21:41, 17 July 2007 (UTC)
Rursus, I take it you don't read comp.lang.lisp often. ;) Grue 09:07, 18 July 2007 (UTC)
- It's not relevant how the users of the language spell it, but rather how the producers of the language spell it. McCarthy originally spelled it "LISP", in all caps, and it was most definitely an acronym. Most variants of the language continued to spell it "LISP" (e.g., Common LISP [3], CLIST, et al) well into the 90s. The spelling "Lisp" (or even "lisp") would appear to be of fairly recent origin. As such, it might be more correct from a historical standpoint of saying that this is a renaming of the language. — Loadmaster (talk) 15:10, 13 June 2008 (UTC)
- Well, Steele consistently spells it "Common Lisp", not "Common LISP", in his book you referenced above. The issue is somewhat muddled as historically the names of programming languages where set in small caps. — Tobias Bergemann (talk) 08:23, 14 June 2008 (UTC)
- Common Lisp is spelt like that according to its ANSI specification. Grue 08:42, 17 June 2008 (UTC)
- As I said, it might be useful to determine when the majority of users switched from calling it "LISP" to calling it "Lisp". I suspect it was some time in the 80s, roughly the time Common Lisp came out. A similar issue exists for UNIX/Unix. — Loadmaster (talk) 23:48, 17 June 2008 (UTC)
- From browsing the Google usenet archives of net.lang.lisp (renamed to comp.lang.lisp in 1986) it appears that as early as 1982 both "LISP" and "Lisp" were in use.[4] Apparently, some contributors specifically used "LISP" to refer to the language family and "Lisp" when referring to specific members of that family. And apparently, it always was "Franz Lisp", never "Franz LISP", which may have been a factor in the adoption of "Lisp" vs. the older "LISP". However, I cannot tell when the majority of users switched from "LISP" to "Lisp". As you wrote, probably some time in the 1980s. — Tobias Bergemann (talk) 07:03, 18 June 2008 (UTC)
- Just FYI, since I just reverted a broken blanket find/replace of "Lisp" with "LISP" on the article - John McCarthy himself uses both "Lisp" and "LISP," but seems to consistently use "LISP" to refer only to early versions/implementations, and "Lisp" otherwise. (Hence "This was the original paper on LISP," vs. "some Lisp programs for algebraic computation.") He also refers to "Common Lisp" and "Emacs Lisp" as such. krimpet✽ 04:04, 18 January 2009 (UTC)
Threshold of relevance?
I note that my link to the recent xkcd comic on LISP has been removed. I don't feel strongly that it was essential to this article but it was on topic and highlights an important cultural aspect of LISP, namely the semi-jocular mythology that LISP is fundamental to the structure of the universe.
As a novice editor I am eager to better understand how I may make contributions which are considered worth keeping. Is there a good Wikipedia principle I could have applied to recognize that my contribution would fall below some threshold of acceptability? Piggy@baqaqi.chi.il.us 18:45, 11 October 2007 (UTC)
- I think you are looking for WP:BOLD :-) The rule of thumb here is to edit if you think you can improve the article. Boemanneke (talk) 19:18, 5 December 2007 (UTC)
Quotations
I think that this should be added to the quotations: Lisp is not dead, it just smells funny —Edi Weitz ;) —Preceding unsigned comment added by 91.148.97.222 (talk) 18:25, 25 October 2007 (UTC)
Orphan article "Lisp renaissance"
I only just now noticed the article Lisp renaissance. I first thought it might have been a part of Lisp (programming language) that was moved to its own page, but from a casual look at the page history of Lisp (programming language) this seems not to be the case. The article was created on 5 August 2007 as the only contribution of User:Moonbuggies, with only editorial changes after that, and with no other pages in article space linking to it. Its contents are apparently fully referenced. However, I am not sure what to make out of it. Should it be kept as a separate page, integrated with the rest of wikipedia, deleted, or what? What do the other wikipedians think? —Tobias Bergemann 14:07, 29 October 2007 (UTC)
A bit of googling suggests that the Lisp renaissance is a quiet phenomenon which has been growing for a few years. The citations in the article appear to be quite sound, but none of them specifically refer to the renaissance the article documents. This synthesis of existing data sounds a bit like original research to me. It's very interesting research deserving of publication. I'm not sure it could make it into a referred journal. It feels like an interesting news snippet similar to the brief summaries near the start of each issue of CACM. It probably doesn't belong in wikipedia at this point. Piggy@baqaqi.chi.il.us 23:38, 11 November 2007 (UTC)
I integrated that pseudo-article's information into this article and redirected it here. The citations aren't that great - they're mostly mediocre primary sources instead of reliable secondary sources - and I'm not sure they actually back up those assertations, but well, good enough for now. Dreamyshade (talk) 02:58, 5 March 2008 (UTC)
Logo
Ref. Image:Lisplogo_alien_256.png. It's cute and all, but shouldn't the logo be a little more official if one is to be used at all? Doesn't it seem a little amateurish to have this logo on this page? --Kvaks (talk) 03:56, 28 November 2007 (UTC)
- There is not, and cannot be, an "official" logo for Lisp, since there is nobody with authority to declare one "official". It's like having a logo for arithmetic or democracy or the internal combustion engine: you can invent one (like a bunch of arithmetic operators, or some people standing in a circle, or a little diagram of an engine), but it's just yours; it doesn't belong to the concept.
- The alien logo is a recent invention (it's only a few years old) that seems to be used by a number of Lisp programmers on the Web; the intent of it, I believe, was for people to put it on Web apps that are programmed in Lisp in order to attract attention to this fact, analogous to the logos people use to show their site was done in Perl, or PHP, or Ruby on Rails. --FOo (talk) 06:53, 28 November 2007 (UTC)
Request for the ciation of the validation report on
ISO/IEC 13816:2007 - Information technology -- Programming languages, their environments and system software interfaces -- Programming language ISLISP
if it is not a rule-based standard —Preceding unsigned comment added by 64.62.138.95 (talk) 08:32, 24 February 2008 (UTC)
This is an archive of past discussions about Lisp (programming language). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 |