Slashdot Mirror
Practical Common Lisp
Unlike other good books about Lisp, which are focused on a specific domain, like AI (such as Paradigms of Artificial Intelligence Programming ) or basic computer science (for example Structure and Interpretation of Computer Programs for the Lisp-like language Scheme), this book focuses on solving real-world problems in Common Lisp, like web programming, testing etc., after introducing the language by examples in the first chapters. I started with Lisp half an year ago, and it has helped me a lot in learning it. But even if you already know Lisp, this book may be useful for you, because it has a fresh view on the language and the examples in the later chapters are usable in your day-to-day work as a programmer.
The first chapter tells you something about the author (he was a good Java programmer before starting with Lisp) and the history of Lisp and Lisp dialects like Scheme. The next chapters are a tour through all Lisp features, written in easy-to-understand steps, beginning with the installation of a Lisp system and an introduction to the interactive REPL. You don't need any experience in other languages to understand it.
The general concept throughout is to explain a feature first, then show an example of how to use it, with detailed discussion of what the example does and possible pitfalls. A nice example is the APPEND function, which does not copy the last argument:
The reason most list functions are written functionally is it allows them to return results that share cons cells with their arguments. To take a concrete example, the function APPEND takes any number of list arguments and returns a new list containing the elements of all its arguments. For instance:(append (list 1 2) (list 3 4)) ==> (1 2 3 4)From a functional point of view, APPEND's job is to return the list (1 2 3 4) without modifying any of the cons cells in the lists (1 2) and (3 4). One obvious way to achieve that goal is to create a completely new list consisting of four new cons cells. However, that's more work than is necessary. Instead, APPEND actually makes only two new cons cells to hold the values 1 and 2, linking them together and pointing the CDR of the second cons cell at the head of the last argument, the list (3 4). It then returns the cons cell containing the 1. None of the original cons cells has been modified, and the result is indeed the list (1 2 3 4). The only wrinkle is that the list returned by APPEND shares some cons cells with the list (3 4). The resulting structure looks like this:
In general, APPEND must copy all but its last argument, but it can always return a result that shares structure with the last argument.
In chapter 9, the first larger practical example is developed, a unit testing framework (like JUnit), which is easy to use and to enhance.
Certain Lisp implementation behaviors can be confusing, such as those for for building pathnames. The pathname concept in Lisp is very abstract, leading to different choices in different implementations. This is no problem if you use only one implementation, but chapter 15 develops a portable pathname library, which works on many implementations. By doing this, it shows you how to write portable Lisp code, using different code for different implementations with reader macros.
After an introduction to the Common Lisp Object System (CLOS) and a few practical FORMAT recipes (the printf for Lisp, but more powerful), chapter 19, "Beyond Exception Handling: Conditions and Restarts", is really useful. The exception handling in Lisp (called "condition system") is more general than other exeption systems: In Lisp you can define restarts where you generate an exception and the exeption handler can call these restarts to continue the program. After reading this chapter, you'll never again want to use the restricted version of Java or C++ exception handling.
Chapters 23 to 31 show real world examples: a spam filter, parsing binary files, an ID3 parser, Web programming with AllegroServe, an MP3 database, a Shoutcast server, an MP3 browser and an HTML generation library with interpreter and compiler. If you ever thought that Lisp is an old language, only used for AI research, these chapters prove you wrong: Especially the binary files parser shows you, how you can extend the language with macros for implementing binary file readers, which looks nearly as clear and compact as the plain text binary file description itself. I'm using some of the ideas for a Macromedia Flash SWF file reader/writer I'm currently writing. Take a look at my Web page for my currently published Lisp projects.
The Web programming chapters demonstrates how to use a dynamic approach for generating web pages. You just start a Web server in your Lisp environment; then you can publish static Web pages or define functions, which are called when the page is requested by a browser. The author demonstrates how to define dynamic pages with formulars in Lisp and Lisp HTML generators.
After reading Practical Common Lisp, you will know most of Common Lisp and how to write real-world programs with it. Some special features, like set-dispatch-macro-character, or using one of the non-standard GUI libraries, are not explained, but it is easy to learn the rest of Common Lisp and to use other Lisp libraries, with the knowledge gained from this book.
You can purchase Practical Common Lisp from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page
But since we're practicing it, Isn't that supposed to be lithp
Whenever I think of Lisp, I'm transported back in time to 1975 where I'm trying (unsuccessfully) to learn this as my 2nd programming language after Fortran IV (on a DECsystem-10, no less).
I never revisited Lisp. Perhaps now that I have the book, I'll give it a shot.
You can download a copy here if the main site is too busy.
~
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
I took a Programming Languages course up at Michigan Tech a couple years back. We wrote our own interpreter using nothing but Common LISP, and it blew my mind. It got me really interested in programming language design.
However, LISP can also be hard to learn. The function names don't make sense to most people who have been raised on higher-level (1980s+) languages. I mean, 'car' to grab the first element of a list, and 'cdr' to grab all the others? It can get downright confusing sometimes.
I am scientifically inaccurate.
Could someone proficient in LISP give me three cogent reasons to learn the language?
You can't talk about Wikipedia's flaws on Wikipedia
Subject says it all.
Sorry, had to be said.
Lisp is essentially the same as scheme. It's the hardest language to write for IMHO just cause it's out of ordinary.
There was a story of a hacker stole one of the A.I code from the government. The code turned out to be the last 100 pages of the program. It was all closing paranthesis. That should sum up how nasty the language is.
Good grief.
I think my favorite university course was a course focusing on "non-procedural programming." The course was half-Lisp and half-Prolog. Sure, I haven't ever actually used anything I learned in that course. But it was neat. Everytime I write code that involves parsing a text file, I always complain "I wish I were allowed to do this in Lisp." Webprogramming in Lisp would be, um, interesting. . . I've never considered that possibility before. I might buy the book just for help setting that up.
I've got a lisp!!! It's not though..... Sry, couldn't resist........ Someone else would have done it if I didn't.....
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
At one point you used 'for for' when you probably only meant to use one for!
Still I'll look forward to checking this book out, in the past I've done a lot of Emacs Lisp hacking but very little stand-alone lisp work, and now seems like as good a time as any to get more involved.
Once I got to grips with the way lisp programming worked it felt very natural and very powerful.
(if (or (= lisp practical) (= lisp common)) (monkeys-fly-out 'my-ass) (life-as-normal))
Where the hell have you been? It has better exception handling than most langauges (including java, read the book), and was one of the first languages to use garbage collection. In addition, you'll find all the normal data structures in all the other languages, threading, and so on that you're used to. CL of today is not CL of the past.
http://students.washington.edu/djwatson
Not that it's the same, but I currently am working with MIT Scheme, which has full garbage collection.
Dylan
seemed to have many of the benefits of Lisp without the prefix notation - macros, CLOS-based object system, multi-methods, multiple returns, optional type declarations, named parameters (I think), etc...
Dylan was started by Apple Research Cambridge in the late 80s, but was laid to rest (at least for Apple) after Jobs came back and the NeXT infusion.
At least Functional Objects opened up their stack and is now being incorporated by the above URL guys.
You are very confused. CommonLisp most certainly has exceptions, and generally speaking the implementations have much better GC than any Java you will come across.
Sheesh.
Lately there has been a lot of LISP hype mostly thanks to Paul Graham. I keep hearing "Macros are amazing", "totally different way of thinking about programming".
That's great and all but I can't find any concrete examples. I want to see a list of problems that are either difficult or nearly impossible with Java/C++ and see LISP's implementation.
Can anyone help me to get past the hype?
Now there's an oxymoron if I ever saw one!
Fly Fish? Participate in our forum
There IS a place for modern Lisp books!
but programs are made unnecessarily complex by the lack of exceptions and garbage collection -- available in the most current crop of languages (C#, Java).
What are you talking about? Common Lisp has both exceptions (conditions) and garbage collection.
Common Lisp is more concise, more expressive and MUCH FASTER than Perl, Python, PHP, Ruby and all those other "scripting" languages. It also has better reflection, exception handling and object orientation than Java or C#. I see no reason to use those languages over Lisp, really. Does anybody who know CL actually prefer one of those languages? Note: taking a course in college does not make you "know" a language.
indeed... lisp is a very powerful language, but practical is not what I'd use to describe it whatsoever.. i've seen it do wonders with clustering projects in which manipulate AI tasks.. that is if you're one of those crazy Patmos'ers
- Hi I'm Linus Torvalds and I pronounce Linux, Lih-nix..
When I think of functional (lisp), my head's twisted and then unwinded. When I think of contraint-based (prolog), my head feels like upside-down. When I think of object-oriented, I think of org-chart. When I think of procedural, I think of spagetti.
If you find LISP interesting, Haskell might also be of interest.
Recent interest in Haskell has exploded because of the implementation of Pugs in GHC. Pugs is a compiler / interpreter prototype for Perl 6, which is also a functional language, borrowing many concepts from LISP and smalltalk (as well as just about every other popular research or practical programming language).
I have a tutorial available that teaches lisp in comic-book form. It is geared to quickly ramp up a newbie to some very advanced lisp tool very quickly.
It uses a free online telnet lisp that lets you try Lisp with zero install required.
My biggest gripe with LISP is that there are so many fragmented implementations that if you're looking for an app that does something cool (Like dynamic web page generation) it typically won't be in the variant of Lisp that you're currently using. Every time I look at Lisp, I always end up impressed with how elegant and easy it is to use. Then I start actually trying to do stuff with it and run up against the fragmentation problem and the lack of standard libraries. At least Guile addresses the library issue -- there's a whole bunch of guile code available these days.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Oops- Here's the link: tutorial
... You will even find a book there. Try expressing some of of his macros as C++ with templates ;-)
(I doubt one can express a lisp macro in C/C++ WITHOUT templates, YMMV).
Paul B.
Sissy European lisp thingy!
Paul Graham's book, On Lisp, is the single best book on programming I have ever read. You can get it as a PDF from his website, for free.
You will also want to read his essay, Revenge of the Nerds, for some serious insight into why Lisp is just so darn good.
If you're just starting on Lisp, the best place to start is with GNU CLISP, although you will find yourself wanting to use Emacs with SLIME to interact with your Common Lisp environment. I use SBCL, but CMUCL and CLISP are also acceptable. On my Powerbook, I use SLIME with OpenMCL.
'car' and 'cdr' are supposed to be references to machine registers in some prehistoric implementations of LISP.
("Lots of Infuriating Single Parentheses").
Slashdot entertains. Windows pays the mortgage.
To wonder why there isn't a -99 "Suicidally Boring" option when you're moderating...
I predict this comment lasts 12 minutes before being modded down to -1. WHY DO THE MODERATORS HATE AMERICA?
Comon Lisp and Scheme are as different as programming languages can be.
Scheme can be said to be ontological attack against Lisp. It looks Lisp but is as far from Lispiness as you can and being still Lisplike.
Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
-- Nikodemus
Greenspun's Tenth Rule of Programming:
"Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."
Common Lisp people seem to behave in a way that is akin to the Borg: they study the various new things that people do with interest and then find that it was eminently doable in Common Lisp all along and that they can use these new techniques if they think they need them.
-- Erik Nagggum
More than anything else, I think it is the ability of Lisp programs to manipulate Lisp expressions that sets Lisp apart. And so no one who has not written a lot of macros is really in a position to compare Lisp to other languages. When I hear people complain about Lisp's parentheses, it sounds to my ears like someone saying:
"I tried one of those bananas, which you say are so delicious.
The white part was ok, but the yellow part was very tough and tasted awful."
-- Paul Graham
Lisp is about rising above implementation to saying something of lasting
value. -- Kent Pitman
Pascal is for building pyramids -- imposing, breathtaking, static structures
built by armies pushing heavy blocks into place. Lisp is for building
organisms -- imposing, breathtaking, dynamic structures built by squads
fitting fluctuating myriads of simpler organisms into place.
- Alan J. Perils
Puns are pricey to have in the language becuase they lead to ambiguity
but they are also a source of great expressional power, so we live
withthem. People who don't like them should probably seek out Scheme,
which tends to eschew puns, for better or worse.
-- Kent M Pitman @ comp.lang.lisp
Q: How can you tell when you've reached Lisp Enlightenment?
A: The parentheses disappear.
LISP has survived for 21 years because it is an approximate local
optimum in the space of programming languages.
-- John McCarthy (1980)
``Lisp has jokingly been called "the most intelligent way to misuse a
computer". I think that description is a great compliment because it
transmits the full flavor of liberation: it has assisted a number of our
most gifted fellow humans in thinking previously impossible thoughts.''
-- "The Humble Programmer", E. Dijkstra, CACM, vol. 15, n. 10, 1972
Lisp is like a ball of mud--you can throw anything you want into it, and
it's still Lisp".
Java was, as Gosling says in the first Java white paper,
designed for average programmers. It's a perfectly
legitimate goal to design a language for average
programmers. (Or for that matter for small children, like
Logo.) But is is also a legitimate, and very different, goal
to design a language for good programmers.
-- Paul Graham
> The continuing holier-than-thou attitude the average lisp programmer...
There are no average Lisp programmers. We are the Priesthood. Offerings
of incense or cash will do.
-- Kenny Tilton at c.l.l
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp
fueled by LSD. Java evokes a vision of a stereotypical nerd, with no
life or social skills.
In the Algol family, parentehses
signal pain. In the Lisp family, they signal comfort. Since most people are
highly emotional believers, even programmers, it is very hard for them to
relinquish their beliefs in their associations of parentheses with pain and
suffering. This has nothing to do with aesthetics, design rationales, ease
of u
Dyslexics have more fnu.
It's a pity, but lets face it: Lisp could never be adpoted for widespread use - there's only a finite number of parenthesis in the universe.
Oh, and by the way: Lisp Is Simply Perfect.
I think its a bit hardcore to refer to SICP as "basic" computer science. I read it after 10 years of industrial experience and found it an amazing but hard piece of work to get my head around -- constraint programming and a unification engine included with loads of other tough stuff.
Easily the best computing book I've ever read.
- C++ is more readable than assembler ...
- C# and Java are more readable than C++
- At the end of this list are functional programming languages.
If you can read source more easily, then maintainability will be better. Most projects maintain code, they write new code less often.
This article will tell you why you should be interested in functional programming languages (this link is about Lisp). If you're smart and open minded, you will be convinced.
The best functional languages are Haskell and Erlang (click "next" at the bottom of the page). But like the review and link indicate, there's actual value to learning Lisp.
However, the book review is much too in-depth and has jargon.
A simpler example: with Java you prevent bugs by static typing variables, example:
int numberOfTries = 3;
If you later try to fill "numberOfTries" with a string, the compiler will warn you of a bug and you'll have prevented it. The Java compiler makes it a rule that you have to give a type to your variable so your code quality will be higher (fewer bugs).
With Haskell, you don't have to type int. Haskell will figure out the type for you, you get the benefit of preventing bugs with the convenience of not having to type variables. There are other good features like that in functional programming languages.
You could say that every language puts restrictions on what the programmer can do. I mean writing the source code is bottlenecked by the rules of the language (every variable should have a type. You can't do this/that etc.) so that the resulting code AUTOMATICALLY has fewer bugs. Well the amount of source "laws" in functional languages is much lower than in C++ and Java. This means that there is less to remember for a programmer and there is less chance for rules to conflict/interact with each other (in Java you can't use certain variable types in static classes = another meta rule to remember).
Besides having less rules to remember and take into consideration. The functional languages have also chosen the best "laws" to follow. I mean that if you follow the source laws of Java, it's still relatively easy to produce buggy programs, with functional languages it's harder to produce implementation bugs (thinking bugs are always possible but that's your problem).
The only problems with functional programming languages is that the rules which govern source code are very good, but also very different from the rules in traditional programming languages. It might seem like thinking upside down/backwards for people already familiar with procedural languages. Another problem is that because of humans sticking to what they know, the libraries of the functional languages aren't as extensive as those of Java for example. This means that you'll have to program more parts of your program yourself instead of just using a ready made library which fits the task. This problem is limited by the fact that you can program 10 times faster than in Java and, as I said, maintenance takes up most of the time anyway.
The reason I chose Erlang is because with functional purely functional programming languages like Erlang, you can automatically multitask your program over several CPU's (or this will take minimal effort). Nice feature to have in the future because every CPU manufacturer is going multi-core chip now. The future is in multiprocessor machines, not higher clockspeeds (unless diamond wafers become viable) (Lisp is not purely functional by the way).
Also, you can easily make a server that never goes down with Erlang because your server is automatically clustered. Just plonk down a couple networked PC's and if one dies, the server cluster will just keep on going (a bit slower) until you replaced the power supply of the broken PC.
There are tons of other advantages but, as I said,
- -- Truth addict for life.
Well, Ruby doesn't warp your brain the way Lisp tends to, but "Why the Lucky Stiff's" Poignant Comic Book Guide to Ruby definitely will definitely umm, errr, it will, ahh, ahh shucks, see for yourself! Why's (Poignant) Guide to Ruby
LISP is as Practical and Common as the Holy Roman Empire was Holy, Roman, and an Empire.
I support the Center for Consumer Freedom
Note: The following are not necessarily unique to Lisp:
* Anonymous functions (why does a function used only once in your entire program need a name?)
* Programs that can modify themselves (think A.I. for games, genetic algorithms, etc.)
* Programs that can be modified at runtime. Think patching a critical program (server, kernel, whatever) without shutting it down.
* Ability to develop and then test individual functions/modules without writing extra code to do it (Lisp in interactive mode). I.E. write a function to parse input, then test it on the fly by calling the function from an interactive prompt. This is invaluable when you are writing only one part of a larger system.
* Makes it easier to create good functions/methods.
* Don't have a language feature you want and no one will build it for you? Write it yourself!
* Efficient garbage collection.
* Run in a VM, or compiled.
* Use OO or functional design.
Miles Teg
Can you give us a brief overview of how conditions (exceptions) are better-than scheme's call-cc?
FYI, the download-able files contain the book examples' source code. They do not contain the book itself.
As everyone else that's replied to you has pointed out you are talking out your ass. Lisp had exceptions and GC long before Java or C# were even an idea. GC in Common Lisp is far ahead of GC in Java and .Net, for just this reason. An industrial strength GC isn't made over night, it's made by having applications beat the hell out of the GC and the implementors spending huge amounts of time handling huge programs. This is exactly what's happened for Lisp over the last 20 years.
For example, Allegro CL hosts industrial applications the likes that have never even been dreamt of in Java or C#--programs that use GBs of memory and runs for months. Try that in Java or C#.
If you are still unconvinced, Orbitz wouldn't even be possible (according to the authors of the software that run the site) without Common Lisp.
CL sufferes from the ugly stepchild syndrome. Its so ugly that the only reason its still around is because it is faster than the nice looking alternative (think scheme). Also compare to ML vs. Haskell, C++ vs. Objective-C, etc.
It has been several years since I last programmed in Lisp. At the time there were few tools that would indicate how/where parenthesis balanced (and no integrated IDEs) making long lisp statements rather cumbersome to parse by hand. Writing Lisp programs in pico brings back some old memories.
Lisp does do some task rather elegantly, simplifying implementation and coding of some tasks. I still prefer other languages for most tasks.
Fly Fish? Participate in our forum
http://c2.com/cgi/wiki?GeneraOs
Lisp Machines
"It's a pity, but lets face it: Lisp could never be adpoted for widespread use - there's only a finite number of parenthesis in the universe."
I only have two things to say to that.
"<" and ">"
Have I been reading wrong books, or Lisp books are among the best books ever written about any programming language? I mean, both Graham books, this one and Norvig's Paradigms of AI include some of the best snippets I've ever encountered. Could it be that Lisp is indeed a good language?
(fuck (your grandfather) you (to your mom) (to your grandmother))
Reverse Polish Lisp.
Yes, it's real, as any HP-48 hacker can tell you.
I was highly tempted to get it. It made C-Lisp look like a fun language. Now I know it's online, so I might look at it again there....
Now that I've your attention, let me tell you what I really think. :-)
Lisp syntax and style is awesome. I first learned Lisp a couple decades ago and I've never seen a language that is as expressive and *general* as Lisp. Every program I write in Ruby or Perl I think to myself "man, if this were Lisp I could just..." then I sigh and continue banging out code.
When I saw this book I thought it was pretty cool. Actually, it *is* pretty cool. I bought a copy as soon as the dead tree version was available.
But Lisp has some serious problems that need to be overcome before you'll see it get popular. Every time I bring them up I get flamed by the smug lisp weenies (SLW). But here goes.
1) There needs to be only one Lisp implementation. Every time a programmer or a book author suggests Lisp, he gives a *list* of implementations. This is no good. I only want to devote brain cells to exactly one implementation.
2) This one implementation needs to come with an elegant Lisp-ish standard library, with threads, Unix integration, process handling, web development, etc. Take a look at Ruby: it comes with RSS libraries, a *complete web server*, XML parser, integration with Unix, a thread library..etc.. If your Lisp implementation doesn't *at least* these things "out of the box", you lose (or rather, you continue to lose). Don't flame me and tell me how on Debian, you only had to install X Y Z and W. I'm not going to switch OS just to play with a language that doesn't pay the bills.
3) Legacy stuff has to GO. ANSI Lisp is chock full of crap. At least remove the deprecated stuff already. Just *remove* car/cdr already (or at least pretend they aren't there). Any terminology that doesn't match Unix, change it. If Unix calls it a file, stream, or process, you do the same. Sad but true.
4) Package system. asdf or whatever it is sucks. I don't know how to use it. It doesn't work reliably. It doesn't make sense. When I asked I get flamed. When it breaks and I ask what the error message means, I get flamed. When I point out the correct code to do what I want is inelegant and hard to remember, I get flamed. The other day I tried to load a testing framework into CLISP. It gave an obtuse error message. I googled for the error message and the only hit was an IRC chat log where three SLW's were pulverizing a newbie because he dared ask for help. After I gave up, I tried to install SBCL. It segfaulted during install and wouldn't finish (I'm on gentoo). I gave up again and went back to Ruby.
5) Community. Look at the Ruby community. Friendly, enthusiastic people. The Lisp community is full of bitter old souls (like me, heh).
There is only one solution to all this: somebody like a Matz or a Guido need to come along and make their own "UniLisp" and break from the ranks. Make a *truly* practical Lisp. Push at the expense of all these other Lisps. Rise to the top. Please, the programming world needs it. Everytime I see somebody doing something in another language that is SOOO easy in Lisp, I cringe. I wish I could tell them to start using Lisp, but I know it's not worth the trouble for 95% of the programmers out there. That's sad, because Lisp is really the ultimate general language.
HAHAH PRACTICAL COMMON LISP ISN"T that a oxymoron??!??! haha it's neither practical nor common. I learned Lisp and I don't like it.
---
A simulated slashdot user.
That's probably not the right way to think about it. A cons cell is a data structure that holds a pair of items. The first is the car; the second is the cdr. The accessors for those parts of a cons cell also have the names car and cdr.
Linked lists are just one data structure that you can implement with cons cells. You can also implement a stack, queue, binary-tree, association-list, etc...
If your are using "cons cells" in your program, use car and cdr.
If you are using lists that are implemented via cons cells use first and rest.
If you are using a stack use push and pop.
And so on...
In other words:
CL-USER> (car (cons 1 2))
1
CL-USER> (cdr (cons 1 2))
2
CL-USER> (first (list 1 2 3))
1
CL-USER> (rest (list 1 2 3))
(2 3)
Justin Dubs
The initial vision of the GNU system - remember "GNU's not Unix" - was to combine a kernel written in C for performance reasons with a userland written largely in LISP. Emacs is the only remnant of that idea, isn't even LISP in its program core, and uses its own LISP dialect instead of CLISP or Scheme. [The climacs project, a CLISP reimplementation of Emacs, tries to fix that.]
Two years ago, I saw a practical demonstration of a Symbolics LISP Machine from 1987. It was like seeing the light of the holy hacker grail - the first system whose userland was superior to commandline Unix in every aspect [Plan9 has superior kernel design to Unix/BSD/Linux, but its mouse-centric userland sucks IMHO]. Everything was in one language, syntax and namespace. You could hack and debug the kernel (written in LISP, too) while it was running [!], the commandline userland hooked into every aspect of the system, and could be endlessly and seamlessly extended it just through custom LISP functions and eval-ing them.
Let's dream and hope that perhaps in one or two decades, when insight into the limitations of the Unix paradigm has become common sense, we will have a free Lisp OS as the next iteration of Free Software computing...
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
Does anyone remember the 'little LISPer'? That is what I learned on. One of the strangest, and perhaps most effective, CS books I ever owned.
s per/llisp.html/
http://www.cs.oberlin.edu/faculty/rms/htx_apps/li
When the little LISPer went into its fourth printing they renamed it, it is now 'The Little Schemer'.
I like lisp and would like to use it but I can't find any info on how to do os api interaction.
Pointers would be appreciated, thanks.
I hereby inform you that I have NOT been required to provide any decryption keys.
I hope you realize that you have been deprecated in favor of the smug_haskell_weenie.
- It will radically change the way you think about coding. With lisp, you program at something akin to the parse-tree level. There is (almost) no syntax to Lisp except what you make.
- It will show you to what higher order functions are canonically used for. Lisp heavily leverages anonymous functions as arguments to the core system calls. Languages with anonymous functions as first-class entities have remarkable properties that let you do amazing things with little effot.
- It will teach you about a relatively uncommon variant technique of bottom-up programming, in which you define every problem with a domain-specific language. It is a very powerful technique.
- Lisp has very, very powerful Object Oriented facilities. They are also very different from traditional OO features, so they should provide more perspective on the very difficult question, "What is Object Oriented Programming?" (If you think the answer to that question is easy, you need to learn Lisp).
Cheers.Slashdot. It's Not For Common Sense
It is such a shame that C-based languages took over the computer world in the 1980's. If we had followed the Lisp path instead things might be so much better. C++ with all of the template, RTTI, and STL grunge is such a half-assed imitation of powerful Lisp constructs that have been perfected for 15 years. I won't even go into Java, Python, C#, PHP. What a waste. I suggest you non-Lisp programmers grab a copy of SICP and start over.
an ill wind that blows no good
I went through Why's guide a few months back to learn enough to work my way through the scripts I run across these days. The only thing I came away from the tutorial was a deep sense of wondering why people find the language so great.
I suppose compared to C(++), Perl, VB, or whatever it's actually pretty nice. But compared to languages like OCaml, Oz, and Haskell it's... well... it tries hard -- and it's kind of cute. So I guess that's worth something.
-30-
I was amazed to find in an earlier /. thread that C++/C#/Java programmers actually think exception handling was a great new thing when their language came out. What they thought we did "in the old days" is beyond me. But then, C++ programmers have told me that the common template library is a great programming concept and not just a hack to get around the limitations of the language's terrible design.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Whenever I think of Lisp, I'm transported back in time to 1975 where I'm trying (unsuccessfully) to learn this as my 2nd programming language after Fortran IV (on a DECsystem-10, no less).
I've heard it said that someone just learning how to program can pick up Lisp in a day. If you happen to already know Fortran, it will take two days.
An unjust law is no law at all. - St. Augustine
use perl;
Why on earth was this modded down?
It must be true that Lisp programmers are smarter than the average programmer....you seem to have found a way to double your karma for free!
Enjoy and contribute..
I'm just getting started learning Lisp (mostly thanks to Paul), and I find myself asking repeatedly--why is it that there aren't good libraries with multiplatorm support? Is it a funding issue, where no one gets paid to so no one does it? I suspect that if it were a more popular language, it might find better support, but the catch-22 is that it needs more libraries (and thus support) to become more popular. Even then, popularity isn't the goal, so much as the byproduct of marrying a powerful language to equally useful libraries. Perhaps the word I'm looking for is more "developer-ready" than "popular".
In any case, does anyone think/know that it's possible to get Lisp to such a level or sophistication? Are major changes (*ahem* Arc) necessary to make it less "strange" without reducing power? Could the beginning programmer someday feasibly write a program in Visual Lisp, or can we not mix ease of development and powerful languages? If such a venture is possible, is anyone (even Paul) willing to support it? I suppose it retrospect it would have been fun to submit such an idea to Paul's VC setup, but I doubt it would have made it in light of the long-term nature of such development.
You are clueless.
Common Lisp is lexically scoped, in fact it has closures (unlike Java). 1984 it was standardized with a really powerful CLOS (CL object system), in comparison to the puny Java object system 10 years later.
Lisp also *invented* garbage collection! Without it you'd still be using FORTRAN, not Java.
And the AI comment is simply stupid. Any language can be used to do AI; Lisp is simply used for it, because it's way more powerful than Java and other crap.
At the time there were few tools that would indicate how/where parenthesis balanced (and no integrated IDEs)
.jar file are actual genius. I'm still waiting for someone to find a way to deliver lisp-based capabilities so cleanly.
I suspect that someone was pulling the wool over your eyes. Lisp has had fully featured IDE's almost since it was originally implemented.
A lisp shell environment is a true text-based IDE, with features that "modern" IDE's are still trying to catch up to. The editor, compiler, and debugger are all available exactly how and when you want them to be. As for the parens, I don't know how long emacs has done parenthesis matching and lisp autoformatting. Those features were there when I wrote my first lisp program in 1989, more than 16 years ago. I'm sure some of the more experienced lispers could give an authoritative answer as to when this happened (though I suspect that emacs has had these features since shortly after the appearance of elisp).
Now if you mean by "Integrated IDE", something that looks like eclipse or MS Dev Studio, well, yeah. Except for the UI builder, the complexity of those tools is there to help you deal with the fact that the language isn't helping you very much.
IMHO, the one thing that lisp really lacks and Java really has is effective packaging of deliverables. The combined ClassLoader concept and the
Regards,
Ross
I would like to thank my friend Dennis, who in addition to being a MAC crank is also a LISP zealot who motivated me to read at least part of an introductory LISP manual a few years ago.
Because of him I can understand this posters joke, and I am not even on any kind of drugs.
Dennis, thanks again for all of the free, high enthusiasm lectures on LISP.
If I could wave a magic wand I would the primary concern of the I.T. industry to be about doing things right which would result in a plethora of LISP programming jobs
All real-world Common Lisp implementations are bug-ridden, slow and generally implement about half of Common Lisp, plus sufficient ad-hoc informally-specified extensions to drag it into the modern era.
Lets not let him poison everything in the FOSS world. I think it's best to just tune ESR out then to react to anything he says. That way you don't conceed any power to him at all. LISP really is amazing. Especially as it was first written in ~1958 and basically solved all of modern computing in one fell swoop. All modern languages are striving to become LISP (ok, but learn some LISP and you'll see what I mean).
.NET, SmallTalk, C/++, Python, Perl, etc.).
If your a programmer than understanding LISP is something I can not recomend highly enough. You won't look at any language the same way again (Java,
Kind Regards
"A few great minds are enough to endow humanity with monstrous power, but a few great hearts are not enough to make us w
Comment removed based on user account deletion
Practical Common Lisp? LOL! Lisp is a language that's fairly impractical, definitely uncommon, and a lot of people pronounce it Lips :)
This seems to be a book about practical tasks in lisp but not necessarily practical lisp. For example, why would it be practical to do web programming in LISP instead of a platform like PHP, JSP, ASP.NET, or even Perl? All of these platforms have enormous community support for web development in terms of libraries and resources.
Am I wrong here? If not, for what tasks is LISP a practical aka appropriate, tool? From what I've seen, it's popular and presumably good for some AI work (although most of the younger AI guys I've known seem to use other tools) and it's also good for teaching students about functional programming and language theory. What else?
I have yet to find a lisp implementation that:
1-it is open sourced.
2-it has some GUI support (tk or gtk).
3-it is cross platform (including the GUI support).
4-it is estable, not in some estate of eternal beta.
5-it is embeddable in a web server (yes, I know Mod_lisp exists. But, yet it doesn't comply with 2 or 3)
If a young language, like Ruby or Python, can do this, why the hell Lisp, one of the oldest languages around, can't?!
Until I find something like that, I can't say Lisp is practical, no matter how theoretically cool it is.
Comment removed based on user account deletion
So, you know full well that your example is simple to impliment in dozens of languages, but you want to add a stupid restriction that doesn't actually make a difference in solving a problem, just to make it seem like lisp is special? I don't care if you want me to add a new keyword to my language, that doesn't solve a problem, and has no practical relevance. Present a real problem that is significantly easier to solve using lisp than it is in a typical dynamic language.
Whoop-de-doo. Macros don't evaluate their arguments. But you do realize that this is because call-by-value is ugly. Try a nice language like Haskell some time. And just how many special forms are in CL? Oh yeah, we'll just gloss over the fact that we've merely moved our choice of nastiness from syntax to library functions.
Go ... and wank ...
I can't help that I have a lithp, you inthenthitive clodth!!
Haskell has significant whitespace,
Optional significant whitespace, but everyone uses it. IM(anonymous)O it works a lot better in a functional language than imperitive.
Haskell syntax is really amazingly beautiful. Usually. Even if you don't find Lisp interesting, have look at Haskell.
Wrong. The entire text of the book is on-line.
Not quite. CAR = Contents of Address (part of) Register; CDR = Contents of Decrement (part of) Register (not Data). In those days, "register" just meant "memory location" - if you had, say, 8k of (36 bit wide) memory, you had 8k registers. Each of the CAR and CDR instructions accessed a piece of the 36 bit word.
CommonLisp has acquired lots of warts and problems over the last two decades. There is a lot of cumbersome stuff in it that isn't needed anymore (e.g., completely general floating point and character set support). There is a lot of stuff that is missing from the standard library: threads, sockets, a foreign function interface, etc. And then there is some stuff that is just poorly designed (e.g., function cells, arrays).
Unfortunately, CommonLisp is likely to be the last big Lisp standard for a long time, simply because the number of people who still bother is so smarll.
Paul Graham's Arc is the great hope (there's a lot of interest in it at least). If it is elegant as promised I think Lispers would take it up. But, it's pretty ambitious and he appears stuck for the time being; the most recent I've heard on the subject is this comment (2nd down) at lemonodor. He's said he intends it to be a hundred-year language and that he'll take his time, so, everyone'll have to make do with CL for the while.
Someday we'll all be negroes
OK. This goes WAY beyond trivia, but the original thesis had LITHP 1.5 on the cover sheet, but LISP 1.5 on the title page (and internally). I know because I took Introduction to Automatic Computation (a Freshman elective) from the McC himself in 1960 and saw his paper. Unfortunately, we only wrote in Meta-Lisp (curly braces, right arrows, etc.) and I never found out how to turn all that into incredible numbers of parentheses. This meant that everything we did (grouping of terms, symbolic differentiation, etc.) was desk-checked, not computer run. (sigh)
parl
"These are sort of cryptic names, but at least they have some relation to what they actually do, as opposed to "car" and "cdr"."
I find complaints about cryptic names ironic coming from a group that uses a Unix-lookalike OS.
"What they thought we did "in the old days" is beyond me."
Those who don't live history, are doomed to repeating it.
It was an IBM 704, which was the Scientific sibling to the IBM 1401, for Business and Accounting. The 704 was succeeded by the 709, 7040, 7090 and eventually the 7094 (uniting the 704 and 709 branches). The 360 was the union of the 7 and 14 branches, so as to provide for the full circle (360) of your applications. One model of the 360 actually had a switch where it (slowly) emulated a 1401. The County of Marin (CA) was lured away from IBM because Honeywell (?) promised to convert their 1401 programs to COBOL and free them from running their 360 in emulation mode.
parl
#define STMT(a) a;
:-( */
#define DECL(a,b) a b
#define RET(a) STMT(return a)
#define DEFUN(a,b,c,d) a b c { d }
#define LET(a,b) ((a)=(b))
#define ADD(a,b) ((a)+(b))
#define MUL(a,b) ((a)*(b))
#define PTR(x) x*
/* TODO: fill in the rest */
DEFUN (int, main, (DECL (int, argc), DECL (PTR (PTR (char)), argv)),
STMT (DECL (int, x))
STMT (printf ("%d\n", (LET (x, (MUL (ADD (1, 2), (ADD (3, 4))))))))
RET (0))
/* I feel dirty now.
Name one Common Lisp implementation which is bug-ridden, slow, or only implements half of Common Lisp! My guess: you've never even seen a Common Lisp implementation, and probably never even heard of the language until now.
I have had long debates with Lisp fans and FP fans. In the end I concluded:
1. FP simplifies bad practices. If you avoid certain poor programming practices of coupling things that shouldn't be coupled, then FP's advantages are only incrimental at best. My opponents kept saying, "See what I can do with FP!", and I kept countering, "But that is not a good design" or "I don't need that feature that often", which is the truth.
2. Lisp's uniformity of syntax makes it powerful, but also very difficult to read. Other languages have syntax that acts like landmarks. Lisp is like having every house be the same such that it's power comes from the arrangement of the houses, but other languages mix in houses, stores, trailers, etc. to give visual landmarks to lock onto. Lisp is just too damned monotonous. Somewhat ugly syntax is more memorable. I tried to get "into" Lisp, but just found it too hard to visually process.
Table-ized A.I.
Java has the distinct advantage of being available everywhere, largely because of the convenience that a .jar will run more or less the same on Windows, Mac, Solaris, and Linux. Lisp suffers from the variety of interpreters/compilers/"engines"/whatever-else that is available. You can't write code to SBCL and expect it to run on CLISP on Windows or OpenMCL on MacOS X. If that hurdle had been overcome by 1997, Lisp might very well have become the dominant platform instead of Java.
the general populace here, this has been one of the more informative discussions I think I've ever seen here. some of the practical points have been very informative.
thank you.
-- it's ridiculous how many people misspell ridiculous... (damn, damn, damn...)
"Several years"? Paren-matching IDEs for Lisp have been around since the early 1970s. And if you were writing Lisp in the 60s, I'm King of the Universe.
That is cool. Now I get it. Don't lose that example; it works.
I heard some vague talking up of macros before and I sort of understood the superficial impact of it, but I hadn't seen an example like that before that kind of hits home.
Now, having said that, I can easily come back with something like "yeah, but I can do the same thing in Java with a helper class that has a bunch of methods; then instead of using my mystical magical LISP macro thingy that no one will understand, I just call my methods when I need them". And that would be true. But I think the "magic" here in LISP is that by going at it with macros and using those to change the appearance of your programs, you're providing a sort of cognitive shift to the programmer where they can think about each category of problem in the system as a "mini-language". That renders a way for the programmer to feel like they're in control and like the solution feels more elegant, because it's less encumbered by syntactical baggage. Is that about right in your experience?
Well, between this and Ruby, I'll have my hands full for a while. Who knows, I may even do something useful with them someday. (Heck, it worked out that way when I went and learned Python on a lark.)
Thank you!
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
I learned LISP a long time ago, perhaps 25 years now.
I do not find it useful for my daily job due to the library issues and performance related concerns. I do still dust it off sometimes for personal projects.
However, I consider it the most elegant language that has ever been invented, and perhaps, that ever will be invented. It has a sort of mathematical purity that I have not seen in any other programming language, and I have seen many other programming languages.
I agree with the quote up above that LISP is the only programming language that is truely beautiful.
Don't drop the soap, Tommy!
...is a contradiction in itself ;-)
Ethics is what you say you do. Morals is what you actually do.
Yet another blogger begging for an audience.
I had a similar experience with Common Lisp a couple of years ago. Fortunately I found Scheme, which made the whole functional programming paradigm a whole lot more enjoyable.
http://www.plt-scheme.org/
I read it a few weeks ago so I would've noticed if only examples were online.
Linux is not Windows
I heard Lisp is USA and PROLOG is European.
-Tez
Haskell, the static-typed, lazy, polymorphic, programming language.
Common Lisp macros make debugging much easier because they reduce the amount of code that the original programmer has to write and that maintainers have to read. Patterns tend to exist in one and only one place instead of being scattered throughout as they are in Java and C++.
First off, let me say that I'm new to Haskell, and learning it, Python and (as of last night) Fortress at the same time, so I'm far from an expert.
"Lisp can generally be made faster than Haskell"
Certainly, and I'm not saying Haskell makes a good language for day-to-day coding. I'm just saying that it's a good place to learn functional programming.
"Haskell uses lazy evaluation. Lisp uses strict evaluation unless you explicitly ask for lazy evaluation."
For those who do not understand this point, it's worth going into. In C, when you say:
c = foo() + bar();
you call functioan foo and bar, add their results, and store that result in c. In Haskell a similar construct would store in c the information required to call foo and bar at a later time when/if you needed the value of c, but of course, if you just add c to another value, you just create a more complex result, you still don't invoke foo or bar.
This is a very powerful concept, but can also lead to surprising results if you are used to programming in non-lazy languages.
I am amazed nobody mentions the lack of static code checks in Lisp. There is this ongoing confusion about Lisp compilation: detractors say Lisp doesn't have compilation, then every pro-Lisper starts refuting that, "No, you moron, Lisp HAS compilation since ages".
Well, nobody really cares if it is interpreted, compiled, JITed, you name it, as long as it is fast. But most programmers (and most important, MANAGERS) care about compilation as a way to minimize run-time errors. Heck, they love it, they are obsessed with it. Look at the extremes people go with strong-typing, building strongly-typed collections wrappers over the standard collections classes in Java and C#.
While a code base with small incremental changes can do without static code verifications, lack of it makes team work so much harder. It feels absurd for modern programmers to use a language which cannot detect that a function is missing, unless you run the program. Or for which a string multiplication with a float is just fine.
Paul Graham tells you that bottom-up programming is the best. Well, in Lisp you only have bottom up programming, because every code fragment has to be tediously verified by running it, or you are going to mispel a symbol, miss some files not included in the project, or God knows what.
Add to that the extremely fragmented Lisp runtimes and development environments, and Lisp is disappearing.
Which is a terrible shame, since Lisp has so much power and potential. I love Lisp. I would dump C#, Java and C++ for a good Lisp any day now, because they lack any serious meta-programming capabilities. We have to repeat the same stupid work again and again, because you can't build truly reusable code in these braindead languages.
What we need for Lisp is a champion who would do for the Lisp concept what Java did for the C++ concept. Modernize it. Clean it. Implement it well and completely. Allow it to become the next-generation development system.
It is going to happen, sooner or later. The "Intentional Programming" meta-programming environment Microsoft Research was developing some time ago looks for all intent (pun intended) like Lisp. Like a poor's man Lisp in fact, because those guys never understood that they needed a true computation model (which Lisp has), they were just adding features by the bunch, like they did in Windows.
Don't hold your breath for this to happen.
http://www.call-replay.com
All the exciting stuff these days is happening in modern languages like Haskell. Lisp is old and tired - let it die its natural death, grieve for it but briefly, and then open your eyes to the possibilities of the 21st century.
I'm quite serious. Lisp has some very nice things about it. But dynamic code leads to unsafe code, and Lisp's very basic syntax leads to a tendency to rely too much on heterogenous lists as a solution to everything. Modern languages like Haskell make it trivial to build complex trees and graphs, and let you solve problems with just as little code and just as much reuse as Lisp - and yet it's also easy to prove that your code is correct!
Maybe they don't contain the book itself, but they do contain a copy of it.
Everything else is just now catching up. Evidence all the effort to fold in Lispy features into Python, Perl, Ruby, etc., etc.
Engineering is about making tradeoffs--something that the designers of Lisp did not understand. If you try to create a completely general language with completely general language constructs, you try to standardize it, and you try to also make it fast, something has to give. And the thing that gives is development time.
Python, Perl, and Ruby can afford to implement lots of Lispy things because they aren't also trying to create a language standard and efficient, natively compiled implementations. Java is also implementing lots of Lisp things, but it makes other tradeoffs (which result in it being more cumbersome in some ways).
While Lisp Just Works.
That's a stupid statement: nothing "just works" for everybody. And CommonLisp had lots of problems: scoping, naming, reflection, and code generation are all pretty shaky in CommonLisp. Its standard library also had lots of important omissions. If CommonLisp "just works" for you, consider yourself lucky. Frankly, I think the number of people for whom, say, Python "just works" is considerably larger than the number of people for whom CommonLisp "just works".
Based on his past record and interests, I wouldn't get my hopes up. Graham represents the attitudes and narrow focus that has turned off so many people from Lisp in the first place. And for a language designer to comment that he "intends it to be a hundred-year language" is just moronic and show a complete lack of long-term perspective.
The best attempt at a new Lisp I have seen is the Lisp Universal Shell (lush), which, despite the name, is actually a high-performance Lisp implementation.
Huh. I find haskell syntax really amazingly ugly: while I'm interested in FP, one of the main reasons I stick with lisp is because of its clear and simple syntax. I know one _can_ write clear (to my eyes) haskell - but all the idiomatic haskell code I see on the net is using haskell's obnoxious whitespace-sensitive 2D syntax, and, seeing as programming is 90-something % reading existing code, I just can't stand Haskell.
> Haskell has significant whitespace, like Python. Lisp doesn't.
Significant whitespace in Haskell is optional. If you miss out the braces, the compiler "inserts" them according to the whitespace. If you put them in in the first place, whitespace doesn't matter.
http://www.songworm.com/lyrics/songworm-parody/Ete rnalFlame.html
(There's an MP3 out there, but I can't find it)
Quite right, LISP's parentheses blow everybody's mind, including Paul Graham's.
From Graham's "On Lisp" errata site: ,(b `,c))) has an extra close paren.
p. 85. `(,a
(((I) (wonder) (why)))
;-)
--
Try the Nuggets mobile search engine in natural language - free across the UK
You'd have needed a supercomputer just to run a hello world program. Sorry to burst your bubble but C became big because it was fast, flexible and could code to the metal. WHen you're working with an 8 bit 4Mhz processor thats a *teensy* bit more important than having a design framework for your program that you could have impressed other fellow Ivory Tower inhabitants with when the wind wasn't blowing from the direction of Smalltalk Island. In fact if people still bothered to write efficient code as opposed to code that ticks all the design pattern boxes we might not need GHz processors to run a friggin word processor!
No doubt this will get modded down by some pimply faced moderator straight out of 00 101, but i does make me laugh when on the one hand people extoll the virtues of exceptions but on the other damning others who uses gotos. If they had a clue about programming paradigms they'd realise they're pretty much the same thing and can both lead to a type of sphagetti code where you cant easily follow the flow of control.
The notion of a hundred year language comes from the fact that some languages have been around for 50 years already, and there's little sign that they won't last another 50 (Fortran eg is still being written, and has a large code base as well). It's not hubris that makes him say his language will be around that long, there's a good chance of it. And since that's the length of time you're talking, it's worth a couple of years to get it right.
But, thanks for the link, I'll have to check that out.
Someday we'll all be negroes
That doesn't mean that I can't use some of its concepts, though. Our company's application server (running on Zope) makes heavy use of passing functions here and there ("report generator, make this data into a PDF, and use this dictionary of lambda functions to format the data in it and use this other function to generate the filename based on the results"). With Python, we have the option of using baby steps that my eventual replacement can understand, rather than having to find someone willing to jump directly into a Lisp codebase with no prior experience.
Is that the ideal? No, but it's certainly not awful, either.
Dewey, what part of this looks like authorities should be involved?
How specifically are function cells and arrays poorly designed?
If you are going to use Lisp for anything practical, you have to deal with the fact than any programming platform you choose is a combination of base language, libraries, dev tools, documentation, implementations (at several levels), other programmers, etc.
The Lisp aspect that Lisp lovers (like me) tend to like most is in the most fundamental notions of the "idea of Lisp". A very small toolbox of ideas that are combinable in an amazingly flexible way, allowing a layering of totally customizable abstractions. The power of such an approach is intoxicating, leading to a real love of the language for so many people.
The basic ideas aren't the problem. They are so pure and simple that they are almost timeless, like a branch of mathematics.
Lisp's problem is that those ideas don't exist in a vacuum. When you need to use Lisp for practical purposes, you have to deal with all the other aspects that come along with a platform, and those are stuck in a time warp.
While the fundamental ideas of Lisp are as fresh today as ever, fresher than the ideas of more mainstream languages as any Lisper will tell you (endlessly), the non-fundamental aspects of Lisp, such as the myriad design decisions in the Common Lisp version of Lisp, reflect design decisions optimized for the constraints of the computing industry of the Apollo Space Program era.
The fresh, powerful, timeless, amazing ideas of Lisp are inseparably intertwined with obsolete baggage (technical and marketing) that users of mainstream languages don't want to, and don't have to, deal with.
A New Lisp, where the timeless aspects are retained, but the other design and marketing decisions reflected today's circumstances could be terrific. Paul Graham has been talking about that for years now, essentially preempting anybody else by increasing their risk of irrelevance while refusing to deliver so much as an annual status report.
Any mention of a New Lisp to Common Lispers is like throwing water on a cat. They hiss and shriek that Common Lisp is so close to perfection that nothing needs to be changed beyond "a few libraries". It seems they have to convince themselves of that because there is so little life in the Lisp community that no one CAN produce a new Lisp. They're stuck with the old one, so they elevate it to almost the status of a religion. Those who require a more modern complete system leave Lisp (for inferior languages in superior systems), and only the True Believers remain to console one another and hiss at outsiders who ask the natural questions about the emperor's wardrobe.
What a mess....
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
for an example of something one can do in lisp that one cannot do in C++?
Common Lisp is the only industry language which has full-featured multimethods in its object system (CLOS).
Though it is still somehwat alpha, there is an implementation of multiple dispatch for Python which goes beyond CLOS by also providing predicate dispatch. Unfortunately there isn't much in the way of documentation yet, but try these links for starters:
Of course, your use of macros above is also known as polymorphism in the rest of the computer science world (which you don't need macros for).
How does Lisp tap into a dynamic link library written in an imperative language?
"Love heals scars love left." -- Henry Rollins
Sure programmers forgetting to close open streams is a real world problem. Its also a real world problem that can easily be solved in shitty old C++ just with a simple, ordinary class, nevermind dynamic languages. The only thing that sets your example apart is that you make up a nonsense restriction "add a keyword to the language" which has no effect on solving the actual problem. The problem is solved just fine without adding a keyword, and that's the only thing that makes the lisp solution different. That's not better, that's just different.
And yes, I don't fully understand lisp macros, that's the whole point. You are supposed to be explaining how lisp is so superior to everything else, for those of us who don't know it. Instead, you are being typical lisp weenie and claiming its better by making up bullshit reasons that don't matter, and saying "you don't understand" whenever anyone points out that your example is retarded.
Now, quit being a fucking moron and give a real world example of a problem that can be solved significantly easier in lisp than a typical dynamic language like python, ruby or pike.
You don't have to wait for vendors to do jack. YOU DO NOT NEED TO CHANGE THE LANGUAGE. Why is this so hard to grasp? You can simply make a class that handles this for you, and use that class. This is no more or less useful or easy than making a new keyword and using that.
This is the entire point I am making, that modifying the language's syntax is not needed to solve problems, and does not make things easier or simpler. This is the standard lisp misdirection, trying to claim that what lisp does is helpful because lisp does it. That doesn't prove anything, show me an actual, real problem that can be solved significantly easier in lisp than in a typical dynamic language.
Yet another blogger begging for an audience.
No offense, but it sounds like the teacher doesn't really understand recursion either. Proper recursion can always be rewritten as a loop, while improper recursion typically can/will eventually cause a stack overflow (or out of memory condition on stackless architectures).
While they're theoretically useful, improper recursions are of limited practical use, since they're only valid when the maximum depth is known in advance to be less than physical limit imposed by the architecture. For example, it's usually safe to do an improper recursion on a list of length 5, but it's rarely safe to use the same recursion on a list of length 5,000,000. (* Please spare me any "know your data" rebuttals.)
Fortunately, no. Doesn't need it, doesn't want it. Scheme only needs it because they brokenly puts function names and variable names in the same namespace.
You're just showing your ignorance. Lispers don't use recursion any more than C programmers, or any other language that "the majority of programmers" can supposedly understand.
BTW, it's spelled "Lisp", not "LISP"
What are you talking about? Hygiene or first class macros? CL could certainly benefit from hygienic macros. Heck there's quite a bit of discussion in On_Lisp on variable capture. (although I'm aware that Paul Graham isn't a fan).
-- I speak only for myself
Both. "Hygiene" is unnecessary and painful. "First class macros" would be pointless: macros run at compile time, so there's no need for them as first class data at run time.
Recursion is Lisp's natural computational mechanism; the primary programming activity is the creation of (potentially) recursive definitions.
You were saying?
Yet another blogger begging for an audience.
How did you arrive at this conclusion? In my previous comment I did little more than use the word recursion. I did not explain what it meant or provide an example. There is simply not enough information in my comment to determine whether or not I understand recursion.
Proper recursion can always be rewritten as a loop
Doing so will result in lengthier code. My comment was written in response to the statement that having less lines of code makes things easier to understand and maintain.
Yet another blogger begging for an audience.
I said Lispers don't use recursion any more than programmers in other languages. Which is true. If you have a source that says otherwise, your source is wrong.
Schemers use recursion a lot, but Scheme isn't Lisp.
(I checked your link: sure enough, it's a Scheme text)
Maybe you'd like to do some reading up on first class macros. Heck, even Arc apparently has first class macros.
Ok, technicalities aside (although in the Scheme world I think you'd say macros introduce new special forms), I'll modify my claim to, "you have to learn a bazillion 'special forms' and/or macros if you want to use CL effectively (and that makes it ugly)."
Lisp is mainly used for AI and other tasks that involve processing large, nested lists. Such tasks naturally lend themselves to recursion. Other proceedural and object oriented languages (C++, Java etc) are used for a much wider range of tasks (GUIs, TCP/IP communications, automation etc). Such tasks generally do not benefit from recursion as much as list processing does. Therefore it is safe to assume that recursion is used more often in Lisp than in these languages.
Incidentally, Lisp, in its original incarnation, did not even have iterative operators. Recursion was the only way to perform a loop.
Yet another blogger begging for an audience.
I doubt that.
Why do I have the sinking feeling that the next thing you're going to tell us is that you admire Perl's compact set of built-in functions and clean grammar?