Slashdot Mirror
Using Lisp to beat your Competition.
kovi writes "Paul Graham, the guy who developed what finally became Yahoo!Stores (and made him $50 million richer) wrote
an article that explains how he used Lisp (the infamous programming language) as a competitive advantage against the competition. As a bonus: thoughts on startup experience." Its in pdf, but its actually worth a read. Very nifty.
Hey, what do you know. He knows exactly what you mean, and you're too stupid to grasp his point. Now who's the moron?
Whoever told you ACL is _extremely fast_ was lying through their teeth. Probably either an Allegro rep or else one of these academics who use ACL to "prove" their postulate that LISP can be fast. Maybe compared to interpreted LISP, ACL *is* extremely fast! But the compiler we have written in ACL is extremely slow, and we have spent quite a lot of effort optimizing it. Effort we could have easily spent elsewhere if we had just written the damned compiler in C++.
ACL is certainly powerful, and it is possible to make code run almost as fast as C code - but "possible" in this case means augmenting your source code with reams and reams of auxiliary information. We once tried to optimize a simple function in the compiler, and it took about 4 hours, and the size of the function grew by a factor of 3. Apply this to any large-scale project and you've suddenly shown that ACL is not a viable platform if speed is an issue.
Sorry dude but this misinformation about ACL has got to be trashed. It takes a while [longer than I've got] to explain to newbies why LISP is such an inherently slow language, and I do appreciate that Allegro have made a compiler which is almost workable for small-scale projects. ACL contains many, many extremely clever features. I admire the programmers for making LISP even vaguely workable in speed terms. But to say that they've succeeded in making LISP a viable alternative to C/C++ is at best an exaggeration and at worst an outright lie.
CLOS is a piece of shit too, but that's a different post.
Just a little note. You seem to still be thinking in LISP/some other language, or you haven't learned new-style C++. If you want a pipe of some sort which calls a function to get a new element, you write an iterator. So, *x would give you the last thing read from the pipe and ++x would read one more thing from the pipe. Then you can use all the fun STL algorithms with it, like any other input iterator.
Take a look at the istream_iterator and ostream_iterator (one site is SGI's). If you don't know the STL look at the introduction and http://www.sgi.com/tech/stl/Iterators.html and http://www.sgi.com/tech/stl/InputIterator.html (sorry, too lazy to make them links, they're all on the site above)
The author of the paper missed this little point. You not only don't understand cool features, you also can't use the language well because you're using the wrong paradigm.
Bravo! Bravo!
Except that a cataloging and shopping cart system like Yahoo Store is not exactly one of the most inscrutable problems in computer science out there. It was a good idea, but never Rocket Science. In fact, the only difficult bits are the implementation issues. And if Lisp is the determining factor there, I have no idea why it would need to be rewritten, except as you pathetically argue, people aren't "brillant" enough.
And while they did this pioneering work, they didn't leave much Lisp legacy on the web development community. (Apparently, it was such a good idea, it had to remain secret for 6 years.) Otherwise, there might be more than one major project to show for it. Too bad, considering the current Java/NET hype steamrollers. And they might have found it easier to hire maintenence programmers.
Forth is an interesting dual to Lisp. Lisp programming encourages building the language, and hence the computer, up to the problem. Moore wants to dispell the levels of abstraction, but interestingly enough his language works by building up phrase books of words to map your problem onto the machine. He emphasizes keeping the phrase books as simple as possible, but in a way so does Graham in On Lisp.
A relevant USENET quote I cannot attribute: In Lisp, code is data. In Forth, data is code.
For Common Lisp, at least, this is not true. One can specify the type of objects.
Lisp is so great not because of some magic quality visible only to devotees but because it is simply the most powerful language available. If you agree with this, try REBOL. REBOL also appears as a weird AI language, with a bizarre syntax full of parentheres (replace with brackets for REBOL) and is a very high level language. The difference is that REBOL as built-in support for CGI, so you can also use it for the back-end. Dolmen.
It's been done, of course. IBM did it and called it skij. - Rob
Try www.ocaml.org for the English version.
Here is a list of online books and references which I found useful:
The CLIM perspective, user's guide, and specification.
A Link so everyone can read it and know, yes it is.
Historical note: LisP is an implementation of the *lambda calculus* (just as SQL is an implementation of the relational calculus). Lambda calculus is a wierd reverse-Polish notation function language that I think mathematicians may have invented before they even had decent computers to run it on. I think lambda calculus was one of the original 'paradigms for computation' that was shown to be equivalent to Turing machines and Finite State Machines by the "Church-Turing hypothesis". There is lisp-optimized, lisp-based processing hardware out there -- powerful stuff. Personally I think any algorithm involving recursion, parsing, and composing is more straightforward in lisp than pretty much any other language. But there's a learning curve--all those parenthesis are intimidating and I think this is the single biggest reason lisp isn't a more dominant language today. I think someone else here compared the moment of nirvana when they suddenly understood lisp to that scene in the Matrix where Neo suddenly sees the Matrix underlying everything. There is indeed something semi-mystical about how much more clearly I saw algorithmic programming after I'd done it in LisP. And it's a fun language to program in.
It is much easier and more efficient to write the first implementation in Lisp and then translate to C++ when the Lisp implementation is pretty much frozen, when compared to designing and writing the final product in C++ from the start.
Read Graham's books to understand the real reason why, but one of his more potent analogies is sculpture. When you want to make a sculpture in bronze, you first make one in clay which is an extremely flexible and responsive medium for sculpture, and then you use that clay model to create a mold in which the final bronze sculpture is then cast.
You *cannot* start in bronze. It is far too inflexible.
It's the same thing with Lisp. If you are trying to solve a problem that is ill-defined and incompletely specified, like most problems are, you need the flexibility of Lisp to solve the problem efficiently. Then, when you understand the problem well enough to have written the Lisp program, then the Lisp program is sufficient as a specification for a C++ implementation.
With C++, for example, you need to develop a rigid set of classes before you can do anything. Changing that set of classes on the fly is tremendously painful.
In Lisp, you can pause the program execution, REDEFINE a class, and CONTINUE EXECUTION, providing a method to AUTOMATICALLY TRANSLATE the instances of the old class into instances of the REDEFINED class as they are encountered. That's object oriented power. No half-hour recompile, no restarting the program, if it needs to be changed you change it. While you are paused, you can write as much Lisp code as you want, interactively testing your implementation to make sure it does what you want.
You C++ guys have no clue what you are missing. Luckily, Paul Graham wrote two books to clue you in: "ANSI Common Lisp" and "On Lisp." Read them, and you'll never want to go back.
People have actually done some experiments at moving Emacs to a more modern lisp, but it would be a hell of a lot work for relatively little tangible gain. I believe RMS has a long-term plan to move Emacs on top of GUILE Scheme.
Modern commercial lisp systems come with their own IDEs and integrated editors. Modern free lisp systems are typically used as subprocesses behind Emacs, which is surprisingly comfortable in itself, and with the ILISP emacs package actually resembles very much an IDE.
Your final comment about converting Emacs Lisp to modern lisp is not far out at all -- people have done that. The problem is converting the reams of C code and libraries that Emacs uses, and which are closely tied to the internals of Emacs lisp the language. Besides, most of the packages available for Emacs lisp make many limiting assumptions that thwart the advantages of changing only the underlying lisp systems -- for example, no one has paid any attention to thread safety since Emacs lisp can only run single threaded.
--han
Two words: tail recursion. Just as you wouldn't write the above code in C due to inefficiency, LISP programmers learn how to ensure that a function will be properly tail-recursive, and thus execute without chewing up a bazillion stack frames.
The fact that he took notice of Perl- and Python-using competitors is significant. He views those languages as being nearly as powerful as Lisp; their main deficiency is that their syntax isn't ``easily extensible.'' Both possess means of extending syntax, but the revealed expressive power is handicapped by the languages' definitions.
Lisp macros work directly on Lisp objects, which exist after parsing but before compilation. Perl mostly lacks that middle ground (or rather it has 12004782 different middle grounds, depending on how you look at it), and Python's AST system is terribly difficult to use (and somewhat non-portable). Both of those languages treat syntax extensions as black magic; Lisp makes them everyday tools.
Lisp does have its problems. The package system is slightly obtuse, and the inheritance scheme in standard CLOS is completely busted. And it's only as portable as its implementations. The free Common Lisp implementations that run on many platforms are interpreters. The compilers run on a very restricted number of platforms. And there's no equivalent to CPAN. But it's still worth a look.
VB is just Fortran with GUI callbacks.
WRT to aD TCL, you've in some ways demonstrated precisely the author's point: he's suggesting that using technology your competitors don't understand is a win. Your competitors don't understand that a good data model and a simple, quick programming language (TCL) with a good library is more important that using tredy Java crapware.
Your competitors don't understand that; they point and laugh and make fun of you for using TCL. They struggle with bloated, trendy middleware. You make your clients happy. You win.
Actually, the most famous LISP app is probably AutoCAD, which many people outside of Unixy circles have heard of. Not only that, but AutoCAD's use of a LISP dialect for macros has proably resulted in more people becoming LISP programmers than anything else - all those drafters, engineers and whatnot who don't realise LISP is supposed to be hard and obscure and only for academics.
Another program that uses a Lisp like language (actually Scheme IIRC) is the Gimp. Maybe you've heard of it? :)
Functional languages have some useful properties that can make some things really easy and fast (recursive list processing algorithms for instance).
Unfortunatly, most functional programming languages are toys that sometimes get used in big projects. Before anyone flames me to a crisp, I'd like to point out how bad the I/O is in Lisp, and how hard it is to properly handle the myriad possible errors a program has to handle gracefully when working with humans. Also, most lisp engines I've seen are interpreted (save for things like the Lisp Machine). Now this doesn't prevent you from doing very powerful very high level things with Lisp, but for the most part you can do them easier and faster with C, also it's nigh impossible to do very low level things with Lisp (At least from with what's available). Lisp is truely the language of the theoretical math major.
Please hold on until I finish donning my asbestos underwear, thank you.
Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
I read the internet for the articles.
Lisp has powerful features like macros and lambda operators that many other langues don't have. So admitting that LISP is über-cool, even though I get bored of the parenthesises after a while...
What do YOU think of other langauges, are there any other languages that you feel are even more powerful and flexible than LISP, allowing you to write better software in shorter time?
(define better-tool 'emacs)
(use (better-tool))
Computers are great for counting parentheses. That sort of 'have the machine take care of it' thinking is the point of high-level languages...
Remember that what's inside of you doesn't matter because nobody can see it.
Smalltalk completely exposes as much of its implementation as you need to do all of this. It's not all built in, because that's not what Smalltalk is about -- it's philosophically more like a Scheme that actually does useful things. But that doesn't mean its less powerful -- as I said, I disagree that features is the best way to judge a language, and though Smalltalk has less features it has a more powerful metaphor and cohesive core.
Ummm... maybe you missed what he was talking about. This is an application for making online stores -- not a store itself (though I suppose it is that too). This is in line with WikiWiki, or some of the homepage builders that have come about. It's not a shopping cart application.
The real reason Lisp and AI go together is because Lisp is a very high level language, and as such is very good for prototyping and experimentation. In AI research this is very important, while the ease of deployment is very unimportant. Lisp scales into complexity well, and you can fit pieces together well. Lisp is just a good language.
The reasons it is good for AI are all the reasons that it is good for server-side web development. That said, I think there's other languages that are just as high-level (or higher). Smalltalk, in particular, is just as high level as Lisp if not higher. I say this not because of the features that Smalltalk has compared to Common Lisp -- in fact, Smalltalk as a language has only a handful of features, and CL has very thick books worth of features. I think the author was wrong to say that languages are good just because of features. But Smalltalk does everything CL does without features, and if that doesn't make it higher level, it at least makes it wiser.
I really like Python, but I can't claim it's on that level.
Our plan was to write software that would let end users build online stores. What was novel about this software, at the time, was that it ran on our server, using ordinary Web pages as the interface. (...) as far as I know, Viaweb was the first Web-based application.
I think in that context, his statement seems much more reasonable. The Xerox map server is not nearly as interactive, or as stateful, as what he was doing. There was a novelty to it.
In a funny sort of way, while Scheme isn't used for many large projects, it's nearly as alive as Common Lisp -- which is to say, not very alive. Scheme is more popular in Academia at this point, in large part due to the book Structure and Interpretation of Computer Programs, by Abelson and Sussman, which is a great book for learning to think differently about programming. It's the standard introductory text for programming at MIT.
Common Lisp is far more practical than Scheme. It has every feature you would want to use, and many features that you would never want to use (e.g., dynamic scoping). It was designed by committee by smushing a bunch of previous Lisps together, and it shows. But it actually has a lot of useful code for it, and a lot of useful features.
Scheme is designed by a committee of mathematicians posing as computer scientists, and that shows too. Common Lisp has an ANSI standard, Scheme has a strong standard that is only endorsed by convention and the academic credentials of the committe. It's an interesting difference.
Common Lisp is also interesting in part because of its rather novel object system, CLOS. It implements what's called a Meta-Object Protocol, and is supposed to be very Deep (though I haven't used it myself). It uses a style of generic programming, as opposed to object methods -- it looks reminiscent of C++ function overloading, but is somewhat more general (arguably more general than methods). There are comparible object systems (e.g., TinyCLOS) available for Scheme, but not generally built into the language.
Common Lisp has been used more in AI, where Scheme is a more important foundation for language design.
Whatever. I was building web apps full-time in early 95, at which point CGI app development was common knowledge. The Xerox map server was running in '93, and it was more technically interesting than any web store.
So Yoda was a Lisp Master!
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
When I was in school the scheme class was about the hardest class you would get as a CS undergrad, and it was what you got *FIRST*. They figured if you could do that class you probably could do the entire CS major. And if not best to find out now so you can go major in something else while you still have time.
Erlang Developer and podcaster
You know the strange thing, now almost 10 years latter this morning I hit a problem and my first thought was that the Ableson & Sussman book from that class would probably be the right book to have handy, To bad my copy is at home. And yes Brandeis was a bit heavy on theory. But they did teach me rather well. In both CS and Physics.
Erlang Developer and podcaster
I think every programer should learn lisp or scheme. It is very different from the Perl/C/Java that we spend most of our time working with. Since it is so different while programing in scheme you tend to come up with very different ways to solve problems. Once you know how to solve problems like that you can if needed take those ideas and move them back to Perl/C/java or whatever.
But learning to think differently is something that is definitly worth it!
Erlang Developer and podcaster
This is a common misconception- as far as I know, there is no purely functional Lisp. Common Lisp allows to write programs in any style. So if you want functional, write functional. If you prefer procedural, you can use setf. If you want OO, then use CLOS. Scheme is closer to a true functional language and many users tend to write scheme in a functional style, but it does have set! and its simple to hack your own object system if the implementation you are using doesn't come with one. (One if the weaknesses of Scheme, is that it doesn't have a standardized object or module system).
On the other hand, CL's huge library makes it an enormous project to implement, whereas Scheme can be implemented in a weekend.
Someday someone will write a good CL library in Scheme, and we'll all be happy, except for the people who want to know the truth value of the empty list.
Yes, in the last 30 years, the C language family has finally gotten as slow and large as the Lisp family has been all along, and now processor speed and memory size have gotten up to the level needed to do things usefully in Lisp.
You have to respect a language which is so much ahead of its time that it can compete with languages developed decades later, even if it was too slow for most applications on most hardware in the intervening time.
Wow. Thanks for the link. =)
SDL version of Abuse! Woohoo, my life is complete! I thought my world ended when I gave my old machine to my mother and this graphics card was no longer supported by SVGALIB (no way I would have used the 8bpp-only Abuse binary). Now I again have one way of letting out the steam =)
Thanks for the additional info.
;-)
I realized after I hit "Submit" that I prolly should have written a more thorough description of functional programming and it's benefits.
Topher
Well, Lisp isn't really based of anything, at least, not off of any other programming langauges. It is based on the concept of the Lambda Calculus, which is something of a way to describe programs in a mathematical way. Or, something like that. <g> Honestly, I've never gotten a great definition of lambda calculus, but I'm content that Lisp is cool. ;-)
Now, as to why you haven't heard of it before, my guess is because you are either not a University Computer Science graduate, or you haven't branched into functional programming. Most universities will cover it at least very briefly in some sort of programming languages class, though rarely do they do it justice.
As for functional programming, it's a programming paradigm, like imperative or object oriented programming. It tends to be very powerful, often makes use of constructs which are terse (fewer lines of code to do the the same thing than required in other langauges) and generally makes extensive use of recursion.
Lisp is very interesting, however. Even though it is usually thought of as a functional language, it actually provides excellent support for functional, imperative, and object oriented programming. In fact, many people think the Common Lisp Object System (CLOS) is one of the best Object Oriented Programming implementations available. It was also the first object oriented langauge that was standardized (by ANSI or ISO, I don't remember for sure which one).
It's also been around for a while. In fact, Lisp is one of the oldest programming langauges still in somewhat common use today. (The only older language being Fortran, which predates it by about 5 years, as I recall.)
If you've never had any experience with functional programming, I strongly encourage you to investigate and study[1] it a little, even if you never really use it, because you will learn a great deal about programming in general for your time invested.
Now, as for what applications have been written in it, the canonical example is GNU Emacs. At it's core, Emacs is basically a lisp interpreter, and most of the editor is then written in Lisp.
While applications that are written entirely in Lisp are perhaps not as well known, one of the most common places to find Lisp is as an extension language for other programs. Here are a handfull that make impressive use of Lisp:
The GIMP uses Scheme, a dialect of Lisp for it's Script-Fu, which can be used to programatically execute anything that can be done by hand.
Autodesk, the makers of the industry leading CAD software AutoCAD use their own dialect of Lisp, called AutoLISP, for programming and customising the AutoCAD software.
Siag Office is a free small, Open Source, and very impressive, Office Suite making extensive use of Scheme. (SIAG == Scheme In A Grid). It includes a very cool Spreadsheet program, as well as others, and is highly customisable.
GnuCash makes use of the Guile library to provide Scheme as an extension and scripting language for the application.
Speaking of Guile, Guile is the official extension language library of the GNU project. Using Guile to provide Scheme scripting, you can add support for scripting and extensibility to any application. Guile is used in many applications including GnuCash (mentioned above), the SCWM Window Manager, the TeXmacs editor (integrating Tex support into an Emacs like editor), and many others.
One last example is the Sawfish Window Manager, which seems to be among the most popular Window Managers around these days. It makes use of an Emacs-ish philosophy, having a very small core program, including a lisp interpreter, and implementing most of its feature set on top of that with lisp.
This is, of course, not an exhaustive list of applications written in, or making use of, Lisp, however I think everyone here will prolly recognise a few names there. ;-)
[1] If you're interested in learning more about Lisp, I strong suggest you take a look the book Structure and Interpretation of Computer Programs. The full text is available online at the link here, and it is one of the best books ever written about Computer Science. It's also used as an early CS text book at MIT.
Topher
>LISP is a programming language. XML is a syntax.
More specifically, XML is a Markup Language (the "ML" in "XML"). That's why, when people call it a programming language, I tell them, "if it was a programming language, it would be called XPL!"
Bob DuCharme - see http://www.snee.com/bob/xsltquickly for
info on upcoming "XSLT Quickly" from Manning Publications.
One thing that's interesting about the relationship of LISP and XML is that XSLT, the W3C standard for transforming XML in which stylesheets are expressed as specialized XML documents, is a great-grandchild of LISP. It's derived from DSSSL, an ISO standard for transforming and formatting SGML that no one used because of all the Silly Parentheses, and DSSSL was based Scheme. People have taken to XSLT more easily than to DSSSL because it's easier to read: when I see "" it's very clear to me exactly which structures are ending, even if I'm reading a hard copy of it, but when I see "))))" it's not always easy to tell which "(" goes with which ")" at a glance.
Bob DuCharme
See http://www.snee.com/bob/xsltquickly for info on upcoming "XSLT Quickly" from Manning Publications.
Son, you need Emacs.....
...richie - It is a good day to code.
The turn-off for me was his statement that high-level languages are inherently "more powerful" than low-level languages. I guess that he's using a definition of "powerful" that varies substantially from the standard CompSci meaning. Lisp, C++, Assembler, and Perl are all Turing-complete. End of story. If you can implement something in one, it can be done in any of the others. One may be easier to manage than another for a specific project, but that is completely different than saying that it is "more powerful".
The author could use a little more CompSci theory before making such grandiose claims. I, for one, had difficulty reading further into the article once I had read that misstatement and realized that he did, in fact, mean exactly what I originally thought he said.
Dewey, what part of this looks like authorities should be involved?
On a different note, CmdrTaco said, "Its in pdf, but its actually worth a read." I have two problems. First, the two instances of "its" should be "it's," because the words are contractions for "it is," not the possessive pronoun. Second, why the implication that PDFs are not, in general, worth the read? Because they look identical on multiple platforms and allow the author to get exactly the result they want? Oh, the horror...
Yes, I'm still a junky. Are you still a bitch?
Why wait for Google to find it, just so you can read the essay in plain text? Don't! Here it is already. And since the Web server seemed a bit sluggish, perhaps in anticipation of the /. Effect, here's a mirror of the PDF original. Enjoy.
Why should I learn English as a whole when I can just learn American English and spelling?
Sarcasm aside...
Scheme is a very reduced subset of LISP, designed for teaching functional language programming. I'm probably wrong, but I don't believe there are any 'real' programs written in Scheme, outside of teaching examples and such.
This space for rent. Call 1-800-STEAK4U
Huh? Not liking LISP because of the parens is like saying I don't like you because you have too many freckles....
But seriously - use an editor that matches your grouping structures (parens, braces, etc). EMACS does this, as does Vim and a whole crapload of editors.
LISP is confusing. Most definitely. However, C++ and Perl were confusing to me when I first saw them, too. LISP is completely bass-ackward from every otehr language you've seen before. Where as in C and Perl, you have all these nifty notations for denoting objects and references and such, you have none of them in LISP. Why? Because LISP programming _is_ programming with objects, as opposed to programming in C or Perl, where you can program in an OO way, but OO is not inherent in the language or the syntax of the language.
My first year of college was Scheme and LISP, then another semester my senior year when I took an AI course and programmed my computer to play Mancala (my computer beat me about 1 out of 10 times, and I wrote the gamespace interpreter). When I started, I said the same thing - (What's (up (with (all (these (parens))))))! But after I started formatting my code in a way that was understandable to me, I could 'see' the program just like Neo 'saw' the Matrix and Perl Hackers 'see' JAPH's.
That being said, I would disagree with the thought that you should use LISP because it's the most powerful language out there. In fact, it's not for something like graphics programming. However, if the application you are working on can be broken down into a number of objects, and actions on said objects, then there's a 90% chance that LISP would be an excellent choice for your programming language.
This space for rent. Call 1-800-STEAK4U
Why should I learn Common Lisp rather than Scheme? Or why Scheme rather than Common Lisp?
-- Ed Avis ed@membled.com
What does LISP have that Python doesn't?
Macros?
Is a macro similar to Python's exec() or eval() statements? Is 'macro' just another name for dynamic execution of LISP code?
-ec
What next? A decent application for Forth? Ada? Eiffel? C++? Oops. What that out loud?
Dearly loved among OLD theoretical computer scientists. Among students, hated. Perhaps the days of lisp, scheme, etc are finally over. I really hope so. People are better equipped to deal with implimentation these days. Consider the lack of experience among the people who created lisp, and you begin to see the why's of languages like C.
lisp was great. now, lisp is not so great. Move on.
Why doesn't someone start another Lisp-based OS? I mean, Unix has been reimplemented so many times... If Lisp is so appropriate for rapid development, why hasn't a Lisp OS ever resurfaced?
I think it would be wonderful.
Cadence's popular chip CAD software is glued together by a lisp based language "SKILL".
t ml#skill
NEdit syntax highlighting patterns available here:
http://www.nedit.org/download/contrib-patterns.sh
They even provide a console window into which SKILL commands can (and frequently are) typed directly.
There are also few high quality implementations (as in "generates extremely fast native code" and "has commercial support options") out there ... Also, try to find good Haskell programmers in your area. I'm having trouble even finding a Perl expert ...
"I love my job, but I hate talking to people like you" (Freddie Mercury)
In the interest of completeness (and Six Degrees Of GLS)....I feel compelled to mention that the above-named Guy Steele Jr. is one of the two creators of the Scheme programming language, which is a stripped-down, not to mention nifty and useful, Lisp variant.
spawn_of_yog_sothoth
"[...] After the storm of negative publicity that followed this blunder [the Great Worm], Morris's username on ITS was hacked from RTM to RTFM."
My
Anyone out there with a licence plate that says
'CDR CAR'?
If tits were wings it'd be flying around.
A large number of messages in this list have been marked funny. Is the age of a language proportional to the number of jokes that people have invented about it?
If tits were wings it'd be flying around.
What can I say?
:-]) C, C++, COBOL, Forth, Fortran, HTML (& XML, XLST,) Java, JavaScript, Lisp, Pascal, Perl, php3 & 4, PL/I, Prolog, SetL and since 1987, I have used Smalltalk almost exclusively because in terms of reflexivity, productivity and expressiveness, Smalltalk RULEZ D00DZ.
There is nothing you can write in Smalltalk that can't be written in a hundred other languages and about a hundred times more slowly.
I've written code in Ada, Basic (yes, I was young once and developped payroll systems for municipalities in Quebec on Wang 2200 minis [What's an OS?
Its NOT perfect, contained objects don't know about their containers unless you make the reference explicit and the it doesn't understand squat about instantiation in context (using a schema,) but its light years ahead of the rest.
Uber Smalltalkerz hack the VM and code BELOW the metal.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Also, most lisp engines I've seen are interpreted (save for things like the Lisp Machine).
Not just untrue for decades now, but a persistent myth/slur.
I'm curious; how do you know it's untrue that most of the lisp engines HE'S SEEN are interpreted, and how is it a persistent myth that he's seen them?
-
Also, aeons ago, AutoCad used to be Lisp-based. I have no idea if it still is.
You seem to be using an older dialect of Lisp. I think you meant
(lisp (taught (me (to (count (parenthesis))))))
or maybe
(taught
(me)
(lisp)
(to
(count parenthesis)))
First off let me say that I don't like lisp. The main thing I don't like about it is the bizarre syntax. All those parenthesis are hard to keep straight and even.
Having said that, though, I'd like to hear a lisp zealot's view of how maintainable lisp code is. Obviously there is good lisp and bad lisp, but it seems to me that it would not be easy just by looking at lisp code to determine what exactly it does for the purposes of debugging and adding features.
What do you all think?
Ben
Unfortunately the author comes across as almost a "Lisp apologist" which may turn people off from looking at Lisp.
Would anyone know if his co-author Robert Morris is the same Robert Morris (or his father) of the infamous Morris internet worm from the late 80's?
Trolling is a art,
Whenever I need to do more in the shell than loop through a few files, I write it in Lisp (I've written 5-line programs to leech an entire Web page's MP3 archive).
:) :
:).
Hmm.
Well, I can seldom resist a challenge
#!/usr/bin/perl
$source = `lynx -source $ARGV[1]`;
$ARGV[1] =~ m/(\S+\/)[^\/]*/; $base = $1;
while ($source =~ m/([\w_-]+\.mp3)(.*)/is) {
$fname = $1; $source = $2;
$dummy = `lynx -dump $base/$fname > $fname`; }
Probably made a few typos in there, but oh well
It's fun when words loose their meaning, isn't it?
What is "Lisp" based off of? Is it a C++ style code or something else, and why have I not heard of it before?
Lisp is a functional programming language. Since you haven't heard of it, I'm betting you that didn't major in CS at a University. Lisp (along with ML and Scheme) is dearly loved by theoretical computer scientists.
To find sample Lisp code, just do a Google search. It is very different than procedural languages lilke C, Java, etc.
Prolly the most famous application using Lisp is Emacs. In fact, some people refer to Emacs as nothing more than a Lisp interpreter that includes some macros that are really good for text editing. Most people I know outside of academia that program Lisp do it to customize Emacs.
"The Structure And Interpretation Of Computer Programs," Abelson, Sussman and Sussman.
(jfb)
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Same way at Chicago when I was there. Taught out of SICP, and man, was it tough.
Peace,
(jfb)
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Any time you have an interpretation environment, you have the potential for programs that write parts of themselves. It happens in Perl all the time. In environments such as Hypercard, you can even have GUIs that write GUIs (click a button that creates new pages, populates them with scripted buttons or other controls, and presents them to the user). How's that for a kick in the head? I wonder if anyone has programmed a VM system to programmatically generate custom VMs to run new jobs on... wouldn't that be fun? David Boyes, are you listening? ;-)
Okay, first of all, I'm glad to see someone pushing Lisp, even though I don't know it very well myself. I get really annoyed at the endless announcements for Yet Another Scripting Language ("It's just like Perl, except without that annoying flexibility!"). If I'm going to take the trouble to learn something new, I'd like it to be really new, and Lisp is high on my list (even if I am over 25).
But I think his premises are severely flawed:
See, if you'd just said PIASACNASAK, instead of writing the whole thing out, you'd have illustrated my point perfectly. Thank you.
So, what the hell is Y? If you're a Java zealot, you might say that it's strong typing and bytecode portability. Of course, a C nazi would want to tear his hair out because of how "limiting" all that strong typing is, and how infernally slow the produced code is. Meanwhile, Python geeks will sing the praises of syntactically signifigant source-code formatting, ML nuts will talk about how nifty it is to have your whole program look like it's written in EBNF, and Perl monks will spout off huge strings of acronyms which all serve to hilight the Swiss Army knife nature of their language.
In other words, by failing to take a stand on what makes some languages better than others (other than the bland assessment that the addition of lexical closures in Perl 5 was a good thing), he succeeds in avoiding offense, but utterly fails to say anything useful. "Power" becomes a catch-all abstraction, like a D&D stat, and nobody gets to argue about what features they actually want in a hypothetical uber-language, because that might get someone's panties in a bunch.
And now I'm grumpy because I stopped to write this out instead of studying for my Distributed Object Programming final tonight. Feh.
For those interested, here are some more links about Deep Space 1 and Lisp:
SOFTWARE FOR FIRST NEW MILLENNIUM MISSION CLOSEST YET TO "HAL 9000"
The Intelligent Execution Systems Project Home Page
Back to the Future: Is Worse (Still) Better?
... um, becase ... ?
That last paper is Richard Gabriel's follow-up to his original Is Worse Better?/i> paper. A cool quote from the "Back to the Future" paper:
Last year, this Common Lisp code was selected by a NASA panel for NASA's software of the year award. Despite this and despite the fact that the software works well in space, one of the high officials at NASA blocked the award and declared that it would not be given unless the system were re-coded in C, in which language it would be obviously better because
cpeterso
Many "modern" functional languages, like ML and Haskell, have strong-yet-polymorphic typing and all of the functional abilities of Lisp. Of course, these languages suffer from a derth of libraries, too.
Of course, this is a COM interface for Haskell called Haskell Direct, allowing your Haskell program to call COM and ActiveX controls. This work was done by someone in Microsoft Research and wrote a paper about it humorously titled "Calling Hell From Heaven And Heaven From Hell."
cpeterso
the paper stated that if a startup follows the common ground of implemeting their system in a popular language such as C, C++, or Java then the startup is no better than the 'average' startup that uses the same technology is funny and wrong.
its not about whether use LISP or Java or whatever. But the idea and the way it is implemented counts. And yes, if the application being used can't be maintained because the technology of choice is not very common then that would work against the technology selection itself.
> How do you find GUILE?
"Works for me; YMMV."
I've really liked it so far, and I seem to like it better as I get more familiar with it.
> how easy is to create and access objects from the other language?
Supposedly pretty easy, though I haven't tried that yet. You might want to google SWIG and see what it will do for you.
Also, I haven't tried GUILE with C++, but I think I've seen messages about that on their mailing list, so I would ass-u-me that it works OK.
> Know what the compiled code size of GUILE is?
Sorry, no. FWIW, it looks like libguile.a is about 3/4 Mb and libguile.so is about 1/2 Mb.
> How does it do garbage collection?
I hear the technical term for the kind of GC they do now and then, but I haven't had time to read up on it, so it doesn't mean anything to me and I haven't bothered trying to remember it. I think it's supposed to be pretty aggressive, but still shy of precise. (Don't quote me on that.)
From the above, it should be obvious that I'm nothing near an expert. You might want to subscribe to their mailing list and post your questions there.
--
Sheesh, evil *and* a jerk. -- Jade
> What is "Lisp" based off of? Is it a C++ style code or something else, and why have I not heard of it before?
Actually, it's one of the oldest computer languages still in (semi-)common use. Vintage 1958, IIRC.
> What are some other "famous" applications that are using Lisp?
Lisp.
--
Sheesh, evil *and* a jerk. -- Jade
> Lisp (along with ML and Scheme) is dearly loved by theoretical computer scientists.
Theoreticians do love functional languages, but Lisp is primarily popular among AI researchers.
--
Sheesh, evil *and* a jerk. -- Jade
> Now that XML is around and the world is saying it?s the greatest thing since sliced bread - I have an analogy.
FWIW...
I have an as-yet unreleased OSS project that I tinker with when time allows. Last summer I implemented an XML system for storing external data. My thoughts upon reviewing it: Ugh-ly!
Since then I have ripped out all the XML and replaced it with GUILE [= Scheme = a dialect of Lisp = on topic], and I find that it's much cleaner, more readable/maintainable, and incredibly easy to parse. As a free bonus, now that I've started on the user-level scripting part of the application, I can load Scheme code directly from my config files and use all the pattern matching / symbol substitution / code writing stuff that Lisp and its ilk are so good at.
YMMV, but it sure as heck works for me -- as a data language, a data-description metalanguage, and a scripting language.
As a side note, interested parties might want to investigate the use of a Lisp-style language by Xconq for specifing game variants.
--
Sheesh, evil *and* a jerk. -- Jade
It was a good idea for Graham to write the system in Lisp - Yahoo! bought his company and made him a rich man. Sounds like Yahoo!'s IT is in a pretty wretched state if it can't maintain a system in which they invested millions of dollars.
Incidentally, the last compiler I worked on had an intermediate language after parsing that looked amazingly close to lisp.
This is my signature. There are many signatures like it but this one is mine..
Also, it's not functional like someone tried to point out. You can use it like a functional language but generally it isn't.
It's good stuff, you can't say your a real CS guy until you've done a fair amount of lisp.
This is my signature. There are many signatures like it but this one is mine..
I program in LISP (CAD systems) and find it a useful language, but this article, and the essay fail to list any technical detail on just what the advantage was. The essay claims how they could do functions that their competition couldn't, but declines to state what those functions were. It also gives no detail on what it was that their competition did, that they were able to re-create so rapidly. In fact, it dangles the carrot of "it's basically macros", but then dismisses it along the lines of "but it's too complicated to explain". Bah. File under "unsubstantiated".
The problem is not that Common Lisp programs are slow, the problem is that in CL it is possible to do 'exploratory' programming to an extend that is impossible in other languages. So while you chip at the problem one function at a time and you get closer and closer to the solution you might solve the problem, but you'll do it in a non-optimal way. The good Lisp programmers have then placed abstraction layers at the places that mattered and can then profile the program and find and elimitate the bottle-neck. I did this with a program of mine and I elimitated 99% of memory-use and 90% of run-time by re-writing one function. Then the real problem of Lisp shows up: managers. They don't see an almost-solved-problem that requires a bit more of work, they see a solution and want to get it into production NOW! I've seen the results of 15 years of that too: a slow, buggy program.
But in all horrors of Lisp programs I've seen it isn't the fault of Lisp that it is slow, it is due to Lisp the program exists! The fact that it is slow is only because nobody has the time to invest into making it fast.
You don't need to recode your problem in C++, you need a Lisp expert!
Peter Van Eynde
(1) Yeah, but how do you find good Lisp programmers? Java programmers are a dime a dozen.
(2) There's no support for Lisp. None of the app servers support Lisp. Databases don't support Lisp. Etc.
I know a bit of Lisp -- I love Emacs and wanted to be able to customize it more, so I played around with Lisp. I learned enough to do some pretty cool things, and learning Lisp has taught me a lot about programming in general...
But I'm not convinced that Lisp is the "highest level language of all high-level languages" or "the most powerful of all high-level languages". In a sense that is probably VB. It is the one that removes the programmer from the actual workings of the CPU the most. Unfortunately it's also a language that's horribly designed in a lot of ways. I think Lisp has some very powerful features like macros that other languages lack, but it loses out in other areas.
Lisp code is hard to read for most programmers, one big reason for this is that the condition in a conditional statement can be 10 lines long, and 5 parentheses deep. Because of this, finding a bug in a Lisp program could take longer than finding on in a procedural program. Secondly not many people speak Lisp. Like Esperanto, something can be wonderfully designed but if it isn't widely used it's not going to be too useful.
I think the main reason their software was so successful was that Paul Graham et al. were extremely good coders developing in a high level language they knew very well, that was well suited to what they were trying to do. This story isn't about Lisp being used for a kick-ass user interface or a 3d engine because (IMHO) Lisp isn't as well suited to those things.
As has been said many a time before -- "Use the appropriate tool for the task at hand".
Anyhow, having said all that, could someone who knows Lisp better than me explain what it is about Lisp that makes it so good for AI? I've always heard that but being pretty far removed from that field I've never seen any cool Lisp AI code.
I think you misunderstood what I was saying. Obviously in this case things worked out in this case, I'm talking about the more general cases.
The main problems I see with Lisp aren't problems with the language, they're with how widely it's used. This affects 2 areas most:
If I went up to my boss and suggested we do our core products in Lisp he'd almost certainly reject the idea. Even if we had a few programmers who knew Lisp really well, if someone quit or we needed to expand, finding people who knew Lisp well enough to join the team would be really tough. Plus we do a lot of things in languages with huge libraries of useful code. It sounds like these guys avoided this problem by not having to hire new people and by concentrating on an area where they didn't need many external libraries.
If I'm going to write a tool to use on my own I'll do it in whatever I feel like using. Perl for text manipulation, C for speed, Java for cross platform stuff, PHP for web stuff... As soon as the project becomes big enough I have to worry about whether other people around me know enough of the language I'm using to contribute. And if I'm going to write a client-side GUI program I'm going to do all I can to avoid using low-level GUI API calls if I can just use a wrapper library.
Something doesn't have to be very popular to be good (i.e. Linux), but for certain things popularity is important (i.e. availability of Linux games).
And I admit I can read procedural code in nearly any language (not Perl) easier than I can read Lisp. A big part of that is due to my having more experience with procedural languages, but I think some of it is just the nature of the language. I think most people would find that it's much easier to keep track of the level of indentation than the depth of parentheses (but hey, maybe that's just me).
You're an evil, evil man.
--
You're a suburbanite.
The choice of programming language makes at most a 10% difference in results. And that is being generous. Its probably closer to 1%. The talent and experience of the programmer is all that matters, to a first approximation. A Master of Assembly Language will beat a drone in LISP any day.
The conclusion is that you should hire the best people, and use whatever kinky language turns them on.
What I think killed LISP is that many LISP programmers had the attitude that they wouldn't stoop to mere application programming, much of which has little technical thrill. What impresses me most about Viaweb is a bunch of LISP hackers willing to get their hands dirty and deliver value to the masses. Maybe those Founder's Shares helped.
Anyway it is heartening to see LISP succeed for whatever reason. It really is the best programming language. God is written in LISP.
If it ain't broken, don't fix it.
(besides, Haskell's "pure functional, yet we have the I/O monad" dualism makes my head hurt, among other things.)
If a recursive function call comes at the *end* of a function, then it's called 'tail recursion', and it dosn't need any stack space, it just jumps back to the begining of the function
ReadThe ReflectionEngine, a cyberpunk style n
Ok, Java might not have Scheme support, but writing scheme interpreters in java is pretty easy, and lots of people have done it. But what's cool about the way java works is that It's very easy to call objects in java dynamically using the reflection API. So, in theory (and in most cases practice as well), you could write a scheme interpreter that runs on the Java virtual machine, and can use the whole of the Java Runtime environment.
ReadThe ReflectionEngine, a cyberpunk style n
But ML turned out to be great! It functions like Lisp, but has some additional interesting features:
- Strong type checking: Most of my Lisp errors were type errors. ML is the most strongly typed language I have heard of (its often used by language theoriticians). When you run the program it is first fully type checked, very few runtime errors are even possible. What makes it different from C is that type checking is implicit (although you can specify types if you want). The compiler/interpreter will figure out which types a function can accept, so you can have a function that accepts many different types for some argument, yet you get the safety of full type checking.
- Its simpler than Lisp. Lisp has too much crap thrown in. ML is more understandable (like Scheme).
- Few parenthesis. Although your programs are structured similar to Lisp, most parenthesis are not needed, which IMO really helps readability and makes it easier to change (no more counting parenthesis when you add something).
- More powerful functions. When you call a function the arguements are actually matched against a pattern in the function declaration. The function with that name which has a pattern that matches the closest is used. You can write interesting recursive functions where one version of the function gets called normally, and another gets called when the argument is a 1, for example. This only scratches the surface of how powerful this feature is.
- There is even an object oriented version: Caml
It is available from Bell labscool. Another convert! :) How do you find GUILE? The main issues with ingregrating LISP heavily into another applications are :
- garbage collection
- type information integration with C++ (how easy is to create and access objects from the other language?)
I remember briefly looking at GUILE, but I was afraid that it was a little too big for many of the applications I had in mind. Know what the compiled code size of GUILE is? How does it do garbage collection?
-- Virtual Windows Project
LISP is a programming language. XML is a syntax.
Lisp programs are not programs in the interpreter. They are data. You can call (eval) on the data, but it's still just data that conforms to a standard. That is what makes lisp cool is that data=code. You can do the same with XML - that is create a stand where XML data can be evalulated. For example :
In lisp this would be :
(print (+ 4 5))
After the parser has gone through both cases the data structures are basically the same. LISP can be used as a programming language and compiled to executable format, but it can also be used as a data-definition language. A lisp parser doesn't need the LISP execution environment - i.e. garbage collection and predefined functions. But, by allowing predefined functions such as defclass you can do everything you can do in XML in LISP.
-- Virtual Windows Project
slashdot doesn't like XML... try again with ( replacing
XML:
(print)(plus arg1=4 arg2=5/)(/print)
-- Virtual Windows Project
Some points well made, I don't have time to write back right now - but just wanted acknowdege your comments were read. :)
-- Virtual Windows Project
Reminds me of one math class where our home work was to find the first and last digits of some huge exponent and prove that was right. No one's calculator could handle a number that big so the teacher figured everyone would have to get us to figure out a pattern. But, I just typed in one line of code into clisp under linux and let it run for a few minutes. I printed out the result to prove I was right (the number was something like 8 pages of tiny text long)! The teacher wasn't too happy that I spoiled his logic proof.
-- Virtual Windows Project
Check out Abuse (link below), even though the game came out more than 6 years ago the community is still going and active on a daily basis. I attribute this largely to the addition of LISP which made the game very expandable.
http://abuse2.com
Recently Jermey Scott made a Win32 port of Abuse and converted the IPX code to DirectPlay so you can play multi-player over the net. That can be found here:
http://www.uidaho.edu/~scot4875/
-- Virtual Windows Project
I've been a big fan of Lisp since I first learned it, but I've always had trouble articulating why it is so useful. Now that XML is around and the world is saying it's the greatest thing since sliced bread - I have an analogy.
/. Say
Lisp and XML both support
- Arbitrarily complex data can easily represented in text.
- Parsing of data in an easy fashion.
However, I think LISP has some advantages over XML:
- XML standard is becoming too complex, LISP data format is about as simple as you can get. You can write a LISP parser in 100 lines of code. This makes LISP ideal for tiny "fun" applications, to the larger enterprise applications.
- XML is much more verbose to write - making it easier to read by humans, but also making it something you don't want to write by hand - witness all the tools that have been writing to assist XML writing.
- LISP allows for execution and interface with code. Sometimes data can't be stored and loaded in a 100% static format. It's very useful to be able to embed calls to your program to generate data on the fly. And it's very easy to mix and match data and code.
To see LISP in work in the real world, download some of my programs:
Abuse - a side scroller action game published by Electronic Arts. Almost all the data loaded by the game is specified externally in LISP files. All but the main character's AI functions are written externally in LISP. Source code for this is available.
EZIP - This program shows my new HTML-like dialog layout library. I encourage you to look at the LISP code that generates the dialog boxes. 3 very nice dialog boxes specified in 100 lines of code. LISP is easier to write than HTML because with an editor that does paren matching you can see opening and closing of rows, tables, and columns. Here is an excerpt of the LISP code from ezip:
(well
"Lameness filter encountered. Post aborted.
Reason: Junk character post.") when I post the code... oh well
(This looks better in an editor). What is cool is that changes to variable names such as "filename" and "outname" are automatically applied . If this were an Active-X control with IE showing HTML then I'd have to have a "Submit" button which sent the results of the form, and then parsed the changes I wanted by hand.
This dialog software uses the same algorithm as IE to layout dialog boxes so when I open I dialog I don't need to specify any sizes in the code. The layout algorithm automatically determines optimal size for tables, cols, and rows. This allows it to calculate a size for the tab control, and a size for the window itself. Language translations just work regardless of how long the German word is for "duck" It's a huge advantage over conventional dialog layout methods like GUI editors.
Golgotha -A 3d action game that used external LISP files to specify data for the game. This allowed artist to add new models and textures to the game. They may not know lisp but they can copy a line of code and change file names like there is no tomorrow. Source for this is available.
I'm not going to say that people should go out and programmer entire apps in LISP - but I think it's an excellent way to represent data extern to your program - perhaps better than XML because of the flexibility it can allow you.
-- Virtual Windows Project
... until the monstrosity called Common Lisp was created. More features does not make a better language. Also, it has many silly compromises because of differences between Xerox and Symbolics Lisp machines. Anybody remember those?
Among other famous LISP programs (Emacs, ABUSE, all the Sierra games (king's quest, etc...)), and some other good stuff, a decent portion of AliasWavefront is written in LISP.
---
Play Six Pack Man. I
Apparently it didn't teach you to count them *well*. =P
----
Dave
MicrosoftME®? No, Microsoft YOU, buddy! - my boss
- Dave
Common Lisp is a standard. "Open" is just an invitation to change the standard.
CMUCL, SBCL, and CLISP and all reasonably close to ANSI. CMUCL is probably one of the highest quility compilers on Earth.
This is more a matter of taste than most people care to admit. If you really want laziness, you can build it, as in Scheme.
Sometimes that is the effect, but often it isn't; I don't consider IO monads easier to understand than s/foo/Foo/, for example. It doesn't really matter anyway, since you can write purely functional programs in Lisp.
I've never liked monads; frankly, they seem like a hack, and they spoil the conceptual simplicity. You can get the same effects through, e.g., uniqeness typing, without so much syntactic and sematnic baggage. Variable functions are even better, but you probably wouldn't like the "impurity".
Currying is spiffy, and imagine it will eventually make it into a major Lisp. I believe I've actually seen curried Scheme, somewhere (and, actually, I starting writing one, once). And I like parenthesis.
Static vs dynamic typing is a matter of taste. Some people like the extra checking, some people don't, and some people don't need it (oddly enough, these tend to Lisp and Smalltalk hackers). The only type errors I can recall making in Lisp recently involve putting the wrong number of d's in cad*r. I'm not having trouble, so why should I throw extra code at a problem that doesn't exist?
Mixed prefix and infix notation is not simple, consistent, or pure.
So, I ask my question: Why fear new and better things? Why do people keep ranting about the virtues of an outdated programming language, when there are better alternative standard functional programming languages?
Ah, I see, you're a troll. Well, bye then.
I'm not convinced that there are actually standard, portable socket, GUI, even regexp, libraries for C. There are certainly some that are portable across Unices, or from Unix to Windows, but I wouldn't call those standard (nor working, in most cases).
While the ANSI CommonLisp standard is one of the larger standards around, it is amazingly deficient in nailing implementations down enough to let programmers write efficient, portable, robust code.
Of course, many people believe that vagueness is a strength, allowing vendors to innovate some in their implementations.
I want a simple language definition, low-cost implementations, interoperable multi-vendor implementations, reasonable performance, runtime safety, interactive development, and a large set of libraries.
CL gives you half the items on the list, and I would argue Java is missing interactive development and that mutli-vendor anything is still a big problem.
We have a standard, and implementations try as hard as they can to follow it. The standard doesn't need evolutions; it's already ahead of any other ANSI language standard I know of, and certainly better than following Sun's whims.
CMU CommonLisp finally gets released with multithreading
AFAIK, the x86 port has threading.
the language is brought into the 00's
Meaning...? You seem to have caught a serious case of Java-itis: symptoms include conflating languages, libraries, and implementations, and believing that everything in the universe should be included in one of the three.
include regular expressions
I don't see why this should be in the standard. In a language like Perl, where text manipulation is the norm, it makes sense. Everywhere else it's just bloat.
XML
Ditto. XML parsing is an application of a language, not a part of a language. If you really want to play with XML, use XSL; otherwise, write your own library and keep the language small.
sockets
I would really like to see sockets as well, but I would rather have generalized streams (across sockets, FIFO's, pigeons, whatever). You also face the problem of defining sockets; e.g., would you include local (Unix-domainish) datagram sockets, which may not be available on some systems?
HTML parsing
This is a non-issue. HTML parsing doesn't belong in any language not defined by W3C, and in any case HTML is supposed to be dead in a few years, when XHTML replaces it.
Internet protocols
graphics
No, absolutely not.
binary I/O
Have it, or as much as I want.
other common features
Sorry? Since when are XML, regexps, sockets, and graphics "common" feature in language specs? My copy of the C standard must be missing some headers....
Then, perhaps, the fact that it runs about 10x faster than common scripting languages might start attracting users again.
I'd rather Lisp hang on the edge of oblivion than come back as a scripting language.
I think his main point was that functional languages are sorely lacking when it comes to the representation of concepts beyond those found the lamba-calculi. For example, the common objects-passing-messages idea is a far better suited, conceptually, to some problems than the lambda calculus; similarly, lambda is better for many things than OOP. Imperative languages are more natural in some cases than declarative, and vice versa. It's true that you could implement anything in anything, but it's easier to think about some things in certain ways (e.g., it's easier to think about the world as composed of objects than to use quantum mechanics when your trying to make breakfast). Lisp provides almost every paradigm you could imagine, and in this regard I think it's ahead of functional languages.
How about closures, then? Recursion was just an example. As an aside, how does C optimise tail recursion?
I'm hoping you actually got the point, though, amusing as you were.
LISP is also famous to engineers as the macro language used in AutoCAD.
Well, PDF is a lot more useful than ps in a few different ways. Acroread is a lot easier to get functioning properly on some platforms than ghostview is (not to mention the possible size redux and clarity). If I can have Acrobat Reader on AIX, with bookmarks, the ability to copy text out of a document, and know that anyone on just about every platform will have a reader for it... well, it just makes sense. #(WinPCs with Acroread) >> #(WinPCs with ps viewers). Add that to the fact that Acrobat Reader easily nests in Netscrape/Mozilla and IE, and it comes in pretty handy for most people. I avoid .ps on AIX, Linux and Windows as much as possible.
And, as the other posters already mentioned, Google caching those pdfs is really handy...
--
"It's tough to be bilingual when you get hit in the head."
Back in undergrad, when we had a course that made use of LISP, we came up with quite a few backronyms... the file is at home, I'll have to grab that later, but one of my favorites was:
Lots of Insidious, Superfluous Parentheses.
Llamas from India, Syria, and Pakistan didn't seem quite right... wrong continent and all...
--
"It's tough to be bilingual when you get hit in the head."
>Acrobat 4.05, the latest version, put random characters in the text and a space before every comma.
Hmmm, didn't have that problem... on windows or AIX...
--
"It's tough to be bilingual when you get hit in the head."
>He could have written it in Sanscrit if he wanted to,
... Here's Latin, that's the best I can do."
"You're majoring in a 4000 year old dead language?
--
"It's tough to be bilingual when you get hit in the head."
>any web browser (with the exception of a few really weird ones, whose names I can't remember) can show html.
;-)
That would have to be '>wget | less'
I agree that pdf can be overkill for a small (in this case, 8-page) text document, especially when you don't make any use of real typesetting. HTML is well appropriate for these sort of things (though copy and paste from a text-based pdf still works better than from a web browser, due to the copy inserting unnatural carriage returns when grabbed from a web browser). For any real document (papers, not just trite commentary) that has any type of formulas, graphics or real format to it, pdf is superior to html, since you design it to be WYSIWEG (what everyone gets), and HTML isn't well suited for publishing complex things (tables, frames, etc aren't nearly as nice as the ouput from Pagemaker or [insert your favorite desktop publishing program here]). Printing a given document is likewise simplified...
Plus, you can easily take a pdf with you, and not have to worry about grabbing all of the associated graphics and/or having a good connection every time you want to look at it (laptops, corporate firewalls)... an html-based document isn't as easy to pull down for complex docs. Plus, the indexing (bookmarks, thumbnails) and other navigation for pdfs far surpasses a side frame on a website, especially with responsiveness. resizing, zooming in... those are nice features, too.
For short, text-only documentation, html is fine, but complex material (even longer, sectioned text-only material) pdf can provide a lot of nice add-ons.
The original complaints seemed to stem from ps vs pdf, rather than pdf/ps vs html... which is what I was responding to...
--
"It's tough to be bilingual when you get hit in the head."
That's because Google recently started indexing PDF files in addition to HTML.
--
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
lack of compilation to native code for Python source code
FALSE
You can compile python code under at least windows and Mac os, (don't know about Linux yet)
I like being able to do this. it make python a real programming language being both interperted and compiled.
Elephant: a mouse built to government specs
As opposed to, say, a competitive advantage against...?
Best Slashdot Co
.. that their entire competitive edge was a programming language.
There are other factors too, like sales and reputation.
But Lisp? The reasons why given are vague.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
I'm old enough to remember when discussions on Slashdot were well informed.
LISP has had highly sophisticated I/O for many decades. This is why it's so widely used in parsers, text processors, editors and so on. The (Common LISP) I/O specification is here.
in fact, of course, LISP has a condition handling system at least as sophisticated as any other language. The specification is here.
Originally LISP was a compiled language. However it is extremely easy to write a LISP interpreter in LISP, so most LISP systems area able to execute both interpreted source and compiled code. Furthermore, interpreted code can call compiled code and vice-versa. Documentation on the Common LISP compiler is here.
Only a few toy LISP systems lack a compiler.
You really never have used the language, have you? If a programming problem can be solved easier by a good C programmer in C than it can by a good LISP programmer in LISP, it wasn't a problem in the first place. For example, I wrote a CASE tool for expert system design in LISP by myself in three months; it took a team of four programmers two years to produce the production C version of the same program.
I'm old enough to remember when discussions on Slashdot were well informed.
Great article. Now I actually want to learn lisp.
But I don't expect to convince anyone (over 25) to go out and learn Lisp.
Good thing I have about two weeks before I turn 26. I will have to learn quickly!
But that's nothing new. The best C implementations are also commercial. gcc may run everywhere, but it typically doesn't compete too well in terms of performance with a vendor's compiler. Similarly, I guess, for almost all other languages other than those (like perl or Python) defined by a single implementation.
First, I just want to agree with your point about right-tool-for-the-right-job. Disturbingly few people understand that. Anyhow:
Lisp code is hard to read for most programmers, one big reason for this is that the condition in a conditional statement can be 10 lines long, and 5 parentheses deep. Because of this, finding a bug in a Lisp program could take longer than finding on in a procedural program.
Like the quote goes, "You can write FORTRAN in any language." Don't blame bad programming style or bad design on the language. You say it would take longer to find a bug than it would in a procedural language, but that's only because you know procedural programming better than Lisp hacking. Be fair.
Secondly not many people speak Lisp. Like Esperanto, something can be wonderfully designed but if it isn't widely used
So it has to be popular to be good? I know that's not what you really meant (hopefully), but that's a dangerous trap to fall into for a programmer. You just became one of those competitors in the article.
it's not going to be too useful.
If it makes me $20 million, I'd call it useful.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
um -- that depends on the quality of those hundred other programmers. If you have separable packages, OK. I'm guessing that a package one or 5 people would consider tackling does not read like that, so you suffer communication problems, and the lack of skill so often displayed by the average programmer. Interoperability becomes a problem too -- someone has to glue all that junk together.
My advice is to choose the supporting libraries *very* carefully.
the implementation model of elisp is simpler than CL, and is missing a number of really useful features, while retaining one really bad feature.
elisp is derived from LISP 1.5 and MACLISP, IIRC.
The ugly feature is dynamic scope -- all variables in all functions on the stack are visible for modification. *shudder*.
The present in CL that are missing in elisp are almost too numerous to mention, but some simple elements of syntax like do and loop, and lexical scope, come to mind.
ROFL -- you have never groked LISP, have you?
LISP is so flexible that the rewrites you talk about improve the program over time rather than making things works, provided that the programmer thinks rather than just slinging code. There is a moment when you look at the code, thinking about implementing some new feature, and your head explodes -- you suddenly realize that you can discard several hundred lines in various places with a new abstraction -- a macro or maybe a just a new function....
I write C++ most of the time to work with an existing code base, but I use LISP every chance i get.
and don't forget that the LISP compiler is likely to rewirite your code using tail-recursion elimination, making the recursive calls into a loop, along with some obvious variable transformations, leading to code which is obvious and correct and also effecient.
well yes, but they were looking for a particular type of other person to work with -- and that type of person either knows lisp, or wants to learn lisp. LISP has the hacker nature -- that quality that leads to being 100 times more productive than the average VB programmer.
I challenge you to write an effecient planning package in Haskell. While I love functional purity, monads do not come close to providing the conceptual utility of Classes or some similarly clear representation of concepts, unless things have changed a *lot* in the last 5 years (since I last studied Haskell....)
:)
Yes I know about the newer compilers. You will soon hit the wall
are you certain of that? I seem to recall some clever transformations that will result in the exactly the rewrite you suggest. Scheme compilers wont to do the rewrite, IIRC, but i;m nearly certain that Lucid Common LISP would do the transform with a high enough optimization level.
On the other hand, that was at *least* 7 years ago, and those brain cells may already be demented -heh
That's pretty funny.
OTOH, the substitution is not perfect. As cool as perl modules are, they do not give you new syntax, while lisp macros can. Splicing, backquote, reader macros are enough to totally transform the language to an entirely different thing.
Actually having used LISP and C++ (along with many other languages) in my career, I can speak with *some* authority on the differences. I'm frequently astonished with people who express opinions about some language with out first learning something about it. People seem to learn only some small corner of a language and assume the rest of the language is like that chunk, or worse, latch on to some half formed opinion expressed by some other person, and claim that to be the final word on the language.
The saddest reality is that there is a 100:1 productivity ratio among programmers, and there are many more at the low end than at the high end. I have noticed that the best programmers all know LISP. They grok LISP. As a result, they *really* understand computation deeply enough for that understanding to translate to any other language, though it still takes time to grok the core idea of that other language (C++ comes to mind as a devilishly complex language to truely master).
Every language has a core quality that the programmer must grasp to use the language effectively. If you can't learn that core idea, the game is over.
So -- when you say that the code is being rewritten in C++ because your shop can't maintain it, what you are saying is that you can't understand the elegant design, so you will replace it with something simpler (you hope), and will ultimately find that the resulting program is far more brittle, and harder to maintain.
You are also saying that you don't have any of those programmers who truely grok computation.
As support for my position: I developed software for engineering automation in the 80's and 90's, then moved to control systems when my company was sold and destroyed by poor management. Technically, the product (written in CommonLISP) was a screaming success. We just could not make good sales/management/investment decisions. I now write control system software in C++. LISP would work better, but I needed to be compatable with an existing code base. I consider myself to be expert or at least competent in both languages.
LISP is not that hard to learn, by the way. The syntax is *really* simple, the language uniform. What *really* stalls people is not the parens or the effeciency, or loose typing (as is often reported), the core problem people choke on is the abstraction. If your mind is not well enough trained to understand the idea of mapping a function over a domain and expressing that directly, rather than say as a looping procedure, or if you can't grasp recursion, you can't really pick up speed, and when you read code that uses those ideas, you will be lost entirely.
We could all stand to learn much more. Study LISP -- it will improve your programming skills hugely, I promise you.
wow, C++ came out in the early 60's. Then when did C come out?
I thought that C++ was a product of the 80's?
While I agree that LISP is cool, they did'nt:
1: do the whole thing in LISP,
2: are killer programmers so any language would have probably worked.
Could it be possible that they actually built an extensible product and had a small enough team that they were able to implement functionality quickly and easily, it's probably just that they like LISP and decided to use that.
It is sad that he doesn't explain why he needs C for other parts of the system.
I'm sure that he's only trying to make a point in that people over 25 won't learn new languages but I'm wondering if that also applies to him?
Naughty Dog's 'Crash Bandicoot' for the Playstation uses a variant of LISP, too.
Tim Hickey was a great teacher wasn't he Zach? While I missed the application specific parts of CS, our theory-heavy department at Brandeis did a great job of making us into great programmers in any arena, provided we had the time to learn the language.
I had no idea what scheme was, having only learned C up to that point. Boy was I in for a surprise, but that language really grew on me, and I ended up using Lisp heavily in AI applications throughout college.
I'm very glad we got Scheme first. I would hope that most people entering CS programs these days begin with a fairly solid grasp of a more conventional language like C++.
The nice thing about the LISP/scheme dynamically typed system is that it is pretty much complete (given the existence of macros). One can add object orientation, lazy evaluation, complex numbers, matrix types, even type inference, without changing the basic language. Wheras strongly typed languages always are in need of extensions. C++ isn't so bad, but then it isn't really strongly typed (the definition is that one can never encounter a run-time type error).
I'm a Kaskell fan, but I can't agree with a lot of this. Haskell's syntax is a convoluted mess, as is its module system. Monads are theoretically very nice, but they intrdouce horrible maintainence issues. The best Haskell compiles to slower code than the best LISP compilers, possibly *much* slower. It is very hard to predict performance with a lazy evaluating language, so it is not suitable for writing an OS in.
Lazy evaluation, currying, type inference and pattern matching are all attractive features, but I think Haskell has some fair way to go, and, with the exception of currying, all of these can be introduced as extensions to LISP or Scheme.
A defense contractor once had the source code to a sensitive data analysis package broken because they transmitted an encrypted version of it across a public network. The attackers broke it because the file name ended in .l, so they assumed it was a LISP application and that the last 64 characters were closing parentheses (or 62 parentheses followed by a CRLF). They made a known-plaintext attack against the last block, extracted the key and used it to decode the remaining blocks.
--
This is not my sandwich.
one thing that sucks about LISP is, it uses dynamic scoping, meaning that if you define a procedure, it uses the "calling" environment, and not the environment that exists when the procedure was defined..........
Snorp
The whole point of macros is they are key for
"fast, efficient development of an application like the Yahoo store builder"
They make programmers FASTER and MORE EFFICIENT, by allowing them to EXTEND the language to meet the problem definition, until the problem can be solved with a one-page program. Then, you're done.
If you are writing Lisp, and you find yourself repeating code, then you write a macro that repeats the code for you. It is the ultimate labor-saving device.
Competent programmers know how to pick the tool that will let them solve the problem most efficiently. For most problems, that is Lisp. The fact that there are few programmers using Lisp is a clue as to how few competent programmers there actually are.
No serious Lisp programmer uses a Lisp interpreter. All the major Common Lisp implementations in use today are compiled.
They are, however, interactive. When you type in your code, function by function, you can compile each function as you complete it, and test it out by calling it by hand with arguments, or writing another routine that calls it with test cases.
Try
(defun f (x y z)
"Routine to frobnicate X with Y, with Z degrees of freedom"
(let ((result1 (- (g y) 2))
(result2 (h (/ z 2) x)))
(* 2.6 result1 result2)))
Notice how much more compact the Lisp code is. I use "let" all the time for this kind of mathematical stuff, and also more ordinary common-expression elimination.
The "let" is just syntax, that most compilers will compile as efficiently as the version that doesn't state intermediate results.
Want speed? Use "declare" I'm not totally sure I have the syntax right, as my Lisp implementation is in the shop,...
(defun f (x y z)
"Routine to frobnicate X with Y, with Z degrees of freedom"
(declare (double-float x y z))
(let ((result1 (- (g y) 2))
(result2 (h (/ z 2) x)))
(* 2.6 result1 result2)))
If g, h are properly defined with declarations, a good Lisp compiler will infer that the results of the computations are also doubles, and will omit type checking when optimization for speed is turned up and for safety is turned down. Chances are, you will get close to the same code as C.
What do you mean by vanilla Lisp? Scheme? Emacs Lisp? Common Lisp includes CLOS ("Common Lisp Object System") by definition. Since most industrial-strength Lisp implemenations are Common Lisp, they also include CLOS.
"C++ is more challenging to use than Lisp"
:: syntax) from Common Lisp. Templates? Get real. Lisp macros do more, and do it better, without the gross syntax and without the code bloat. Object orientation? CLOS is objects with all the power of C++ and more.
Walking around with your eyes closed is more challenging than walking with your eyes open. It doesn't mean you are smarter when you do so.
What "features" of C++ exist to facilitate larger programs? Packages? Stolen (including the
Perhaps an example will illuminate things.
It is possible (see Graham's books) to ignore the object-oriented features (CLOS) that come with Lisp, and define your own object-oriented dialect of Lisp in about 100 lines of ordinary Lisp, using macros. And once you've done so, there is essentially no way to tell that your dialect was not part of Lisp to start with.
To do the same thing in C, Stroustrup had to write cfront. Which is substantially more than 100 lines, and is far from transparent.
"new fancy features" == standardized in 1994. And, unlike some standards, existed before it was standardized.
You are assuming that the typical (i.e. popular) process of choosing a language in which to program weighs both the difficulty of learning and benefits of both C++ and Lisp. I think that assumption is false.
I believe rather that most programmers *fail* to recognize how difficult C++ is to use well, and in fact don't use C++ well, whether they know it or not. Most programmers have never attempted to learn to use Lisp well (I'm not talking about Scheme, and I'm not talking about the "Lisp is interpreted and has only one data structure" 1950's view of the language), so they have no way of measuring the difficulty anyhow.
My view is that most C++ programmers have accepted the challenge of C++ without knowing about, much less rationally considering, Common Lisp as an alternative. That is why I depict them as having their eyes closed.
Oh, come on. Lisp has practically *no* syntax. What it has is so logical and uniform that it gives huge power to macros, and allows editors to sensibly indent programs to reveal their semantic structure.
Common Lisp lets you totally redefine the language's syntax anyway, if you don't like it. Want to write your math expressions using infix notation? Download the infix package, that lets you write #I'sin(x)+y^2' if you don't like
(+ (sin x) (expt y 2))
The very logic that you supposedly find appealing in Lisp drives inevitably toward the syntax that Lisp uses: code and list data have the same representation, so that the same operators that you use manipulate lists also lets you manipulate programs!!! That is the essence of macros.
C++ is an example of a language that misses that great chance. How do you manipulate programs in C++? You either use the C-style preprocessor, which is so limited that it is deprecated in favor of things like inline functions, or you use templates, which introduce a whole new meta-language and a corresponding layer of complexity, and is living is such an over-syntaxified environment that you must remember to leave that extra space in << or the parser will barf on you.
Arguments about syntax are going to favor Lisp over C++. Consider trigraphs, for God's sake.
I find it hard to believe that anyone would prefer the syntax of C++ templates, for instance, over CLOS.
Things I love about lisp.
- Macros. Because the syntax is so regular and the whole lisp system
is available during macro expansion, you can extend the language in
very powerful ways with macros. *THIS* is a killer feature in lisp.
- Generic Functions. This is a generalization of virtual functions
where a function can dispatch based on more than one parameter. Anyone who
has used the visitor pattern in C++ knows implementing multi-dispatch in
C++ comes with tradeoffs.
- Method Combination. Before/After, Around methods.
- Higher Order Functions
- Metaobject Protocol
- Efficient Compilers. Checkout CMULisp for a free advanced compiler
Things I hate about lisp.- Not many good libraries. I would especially like to find a good gui library. I understand there are people working on this (Free CLiM).
- Language seems to be dying. Not many employers are interested in lisp people.
- Typing Issues. I prefer stronger typing than lisp has. I think
C++'s type system is just right. However, I understand there is no
right answer to a type system. It is a tradeoff. Lisp allows some
elegant tricks. For example, a pipe in lisp is built from a cons. The
second element of the cons can either be another cons (the next
element of the list), or a function to call to create the next element
of the list. After the function is called, it (the cdr of the cons
cells) is replaced with the new element. I can do the same thing in
C++, but both the new cons cell and the function have to share a base
class.
Just some random thoughts on lisp. BTW, I highly recommend Paul Graham's "OnLisp" if you're interested in seeing what the language can do. Other good books are: Norvig's "Paradigms of Artificial Intelligence Programming" and if you're interested in Lisp's object model try "The Art of the Metaobject Protocol" by Kiczales, Rivieres, and Bobrow.It's odd to see an article of this type (supporting the non-sharing of information, even if it's something as basic as not sharing what language you're using) posted on Slashdot, one of the primary supports of open-source. Larry Wall, on the other hand, is in support of the sharing of information, when he talks about Hubris, the basic motivation that should drive programmers (and the designers of languages) to get other people to want to use the same code/languages that we use.
> Lisp is, it's not based off anything.
Lisp is based on lambda calculus. It's not based on any other computer language.
> It has no syntax
Don't be daft. Every language has syntax, otherwise you wouldn't be able to type in programs. lisp syntax is, however, incredibly simple (and incredibly subtle and powerfull)
My Karma: ran over your Dogma
StrawberryFrog
I remember back in the AI days (the 80s), projects were categorized by the programming language:
LISP : Standard AI stuff.
Prolog: Theoretical AI Research.
C : HMM or Neural Net
Anyone know if prolog still exists?
Lisp (LISt Processing) is a language used in Artificial Intelligence circles. Emacs is written in Lisp.
--
"A dessert without cheese is like a beautiful woman who has lost an eye." -- Jean Anthelme Brillat-Savarin
According to my CS prof, LISP == Lots of Insane, Silly Parentheses.
--
"A dessert without cheese is like a beautiful woman who has lost an eye." -- Jean Anthelme Brillat-Savarin
It looks like his web store was BUILT in 1995!
(from the Yahoo Stores online tutorial...)
Maybe Museumcompany.com or Despair.com could offer Mr. Graham some design tips on getting the most out of his own store-building application.
Of course, with millions in the bank, he probably doesn't give a rat's ass whether he sells any LISP books or not. So I guess I answered my own question. Nevermind.
quite a few commercial products are based on lisp/scheme and provide the ability to load/run your own code within them (as proof of concept I offer the scan insertion tool I wrote a few years back that - gack - ran something like perl to scheme (run in router) to perl) - like all real hacks written under tapeout pressure as a stopgap and used for the following 5 years because it still worked as well or better than the vendor's :-)
LISP is a great medium for learning abstract thinking/programming - I've always thought of it as being a bit like 'programming backwards' (not necessarily a bad thing - just a different mindset) - but that's just my C-centric world-view
It's hat-eating time for me...
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
The real reason these guys did well is simply that they were good, fast programmers and their competitors were not. It has nothing to do with Lisp.
Agreed. This was strictly a right-time/right-place situation. We're talking '95 here; I could have started www.pictures-of-buckets-of-shit.com, IPO'ed, and sold-out to Yahoo or AOL and become a millionaire just as easily. EVERYTHING was new and exciting and profitable.
I eagerly read every page of the article trying to determine how exactly Lisp had been used, and I did not find anything. The article is so incredibly vague; the author spends more time touting Lisp then trying to convince the reader of it's specific applicability to the realm of web programming.
If someone has some code they could post, or a web page or two, done in Lisp, that demonstrates it's ultra-coolness, I'd love to see it (not doubting it exists, I just want to see it to make my own judgement).
Side note: the (macros that right micros)* part sounds wicked cool. I never got to that point in my AI class.
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
Don't forget Abuse-SDL, which lets you relive the fun in Linux. It has links to free levels, other Abuse projects, etc, as well.
:/
My only problem with it is that SDL uses a buggy mode of the emu10k1 (which doesn't work properly on 1Ghz machines). Only XMMS works at all
--
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Getting out to non-Lisp libraries is doable, but harder than just linking stuff (the fact that we call them "foreign function interfaces" should tell you something).
And it's also correct that if Lisp makes you N times more productive, but there are 100*N programmers whose work you can steal working in another language, you will probably still lose.
The conclusion is pretty clear. If you're combining existing tools to make new stuff, stick with their languages. If you're doing something *really* different, go with Lisp.
To a Lisp hacker, XML is S-expressions in drag.
To a Lisp hacker, XML is S-expressions in drag.
Graham noticed the activity on Slashdot and put more detailed papers up on his web site, most notably this, a pure-text file describing some of the guts of Viaweb/Yahoo Store, and why Lisp was the right thing for it.
To a Lisp hacker, XML is S-expressions in drag.
What he said was that Yahoo Store didn't contain any Java. Both what he said and what you said could be true. Do you have knowledge of the Yahoo store code base?
To a Lisp hacker, XML is S-expressions in drag.
To a Lisp hacker, XML is S-expressions in drag.
... since on-line store building is no longer rocket science. After Graham showed how it ought to be done, on-line store building became a solved problem, and hence boring. Thus, it needed to be redone in languages more suited to use and maintenance by less brilliant developers. Let's face it, 99% of IT work has to be doable by the average programmer.
... the first time.
I would argue that everything should be done in Lisp
To a Lisp hacker, XML is S-expressions in drag.
BEN: Remember, a Lisp Programmer can feel the Recursion flowing through him.
... luke gets his parentheses wrong and crashs. Han laughs heartily...
... Ben smiles quietly...
... Ben fires up emacs and separates out the parentheses...
... Han shakes his head. Luke runs the code, and it crashes again. Luke lets out a yell and attempts to smack the monitor...
... Luke stands in one place, seemingly frozen. Luke counts out fifteen levels of parentheses in his head and adds a sixteenth. The code runs.
LUKE: You mean it controls your algorithms?
BEN: Partially. But it also obeys your commands.
HAN: Hokey religions and ancient syntaxes are no match for a good C compiler at your side, kid.
LUKE: You don't believe in Lisp, do you?
HAN: Kid, I've hacked from one side of this galaxy to the other. I've seen a lot of strange code, but I've never seen anything to make me believe there's one all-powerful language for programming everything. There's no mystical programming model that controls my destiny.
HAN: It's all a lot of static casts and nonsense.
BEN: I suggest you try it again, Luke.
BEN: This time, let go your conscious self and act on instinct.
LUKE: (laughing) With the parentheses all over the place, I can't even grok the code. How am I supposed to debug?
BEN: Your eyes can deceive you. Don't trust them.
BEN: Stretch out with your feelings.
BEN: You see, you can do it.
HAN: I call it luck.
BEN: In my experience, there's no such thing as luck.
HAN: Look, going good against AI is one thing. Going good against UI? That's something else.
Look, I love Lisp, and with it I can get my emacs to do wonderful things. However, there is a major drawback to using a relatively obscure language for mainstream application development. Fewer third party libraries will be available in Lisp. This means that you'll have to do a great deal of work from scratch either porting, patching or layering libs into your lisp framework. Let's face it. Also, your code will potentially suffer from interoperability problems unless you are extremely careful.
Someone you trust is one of us.
Emacs is definetly difficult enough to qualify as a life long challenge. Emacs is like 42 in Hitchikers Guide to the Galaxy. Don't get me wrong, xemacs is my portal to the world. But, my configurations and modules are as cryptic as the Knights Templar. I've forgotten how half of them work anymore. Emacs is like Darth Vader. One day you realize that you are mostly Lisp/Emacs, but your not sure how you got there. You know its somehow evil, but the power of the darkside is just too tempting to ever go back.
Someone you trust is one of us.
-----------------------
Nicotine free Amish .sig.
Rewriting a program because no-one in the company understands the language it was written in, never mind the program itself, is NOT going to be a recipe for success.
You need to learn some humility, take a deep breath, write out a hundred times 'maybe the people who wrote this code knew something, I will attempt to learn from them' and get stuck in to their code.
"Scheme is a simple, yet powerful, programming language. As a member of the Lisp family of languages, it is dynamically-typed and mostly functional. Since it is much smaller than Lisp, it can also be used as an embedded language, a scripting language or an extension language. The Hotdog Scheme compiler currently compiles most of the Scheme language. It has been extended to support development within the .NET framework, allowing integration of Scheme and other languages targeting the runtime (Visual Basic, C++, C#, etc.).
I'm a little scared of the flame I'll get for bringing up .NET, but take a look at the site. It's some interesting stuff.
A speech...
http://www.gnu.org/directory/calc.html
Calc is written in elisp and runs in a pair of frames within emacs. It works really, really well. If you have gnuplot installed on your system, it'll even plot graphs for you.
Well, emacs plays games, how about that? In fact, I keep telling people but no one ever listens: emacs does everything. If I get bored at work, sometimes I'll pop up an emacs and M-x mpuz. There's also tetris, blackbox, gomoku, doctor...
A couple of weeks ago, I managed to completely destroy X on my home PC. I browsed the Web using emacs until I could get X back up.
Last week, I was talking to a co-worker. I mentioned, "I'm forgetting my calculus, I tried to integrate such-and-such, and I couldn't do it. Luckily for me, emacs does symbolic mathematics." His jaw dropped open. (He does tech support for my company's symbolic math package.)
Emacs does everything.
a really cool, funny, song. Download it. http://artists.mp3s.com/artist_song/234/234762.htm l
will the use of Lisp make web services more artificially intelligent?
huh? what year is this?
LISP is groovy man, and great for some things but there are better languages out there now for general purpose programming.
let me introduce you to one.
A very nice little language. I am biased but for a reason (no i didn't write it, just an enthuastic user who's helped a bit over the years). ICI embodies many of the Lisp ideas - it's author having written C, Lisp and Postscript implementations - in its object-based data model. It, however, adopts C's expression syntax and control structures (with additions to both). It has OOP constructs (classes, methods), native code modules, autoloading, regexps, reasonable performance, etc... Worth a look. See the ICI web site.
who can post a few links to good Lisp reference sites?
Stop by my site where I write about ERP systems & more
Would you please tell me where I can find a copy of Acroread for GS/OS. I have an Apple IIGS, there is a web browser for the GS... and Acro... oh wait. There is no version.
But of course I can just download the source and port it right? Please, could you point me to the source, I can't seem to find it.
Gee this seems like alot of work to read a simple english text article with no graphics or anything.
-Steve
"I opened my eyes, and everything went dark again"
However, html is even more useful than PDF.
This is the web afterall. I don't think that the "but its in pdf" was a complaint about pdf specifically, but rather "Not html or plain text", which are both universal, any web browser (with the exception of a few really weird ones, whose names I can't remember) can show html.
This article was a good read, but it was ALL TEXT. There was absolutly no reason to use pdf, ps, TeX, RTF, MS Word Doc, Powerpoint or whatnot. hell, html would have been overkill for the article in question! (it would have required nothing more than <p> and <h1> for the entire article (with maybe a little <em> thrown in.
PDF, PS etc all have their place. Articles posted on the web that are all text or text and simple graphics is NOT one of those places.
-Steve
"I opened my eyes, and everything went dark again"
A Lisp macro is simply a piece of Lisp code that writes another piece of Lisp code that it
then feeds into the compiler/interpreter. From the ANSI spec:
macro form n. a form that stands for another form (e.g., for the purposes of abstraction, information hiding, or syntactic convenience); that is, either a compound form whose first element is a macro name, or a form that is a symbol that names a symbol macro.
Essentially macros perform transformations on the source code before it gets interpreted/compiled, and unlike (say) C macros, they're a lot more predictable and less dangerous. They're not really like an exec or eval.
This is very interesting. I never paid enough attention to LISP to know any of the above.
Is anyone looking at updating the Emacs LISP to a modern LISP?
Would RMS agree with you that Emacs LISP is archaic and very poorly designed?
Do the modern LISPs come with an editor as part of the development environment? If so, are any of these editors good enough to be competition to Emacs?
Last question. This is not a flame or a joke; if I'm being silly please set me straight. Since LISP is considered to be a great language for writing programs that can write programs, would it be practical to write some LISP code that would chew up the Emacs LISP and spit out modern LISP?
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
When you said "typing issues", I thought at first you were talking about all those parenthesis you have to use!
--
Move '.sig'
Not relevant to Lisp, but the article contains a blatantly inaccurate statement that Yahoo does not have server-side Java code.
I find this rather amusing, considering that I work for Yahoo as a server-side Java programmer, and I've been here for years. My team has probably over a hundred thousand lines of server-side Java code at the moment.
ZFS: because love is never having to say fsck
I did not say we should all stick to one language -- you are putting words in my mouth. But the fact is, if you're the only programmer in the world who knows language X, and you insist on programming in it, you'll be doing it by yourself.
"Fringe" programming languages are useful as research projects, certainly. But the real world doesn't seem to need more than a handful of them.
ZFS: because love is never having to say fsck
...since you're the one who's reading it wrong.
I quote:
"Yahoo has server-side software written in all the languages Eric Raymond recommends to hackers, except Java."
You'll note that the word 'store' does not appear anywhere in that sentence.
ZFS: because love is never having to say fsck
Disclaimer: I work for Yahoo!, albiet not in the Store group. My opinions do not necessarily represent those of my employer.
Okay, with that out of the way -- yes, we have a little bit of Lisp code here. No, this was not a good idea, and no it is not a good way to get rich in the future. I have it on good authority that every single scrap of Lisp code we have is quickly being rewritten from scratch in C++, because there are so few engineers competent in Lisp here (read: zero).
I realise the hype is that you have free choice of languages and can write code in whatever works best. The sad reality is that there is a hell of a lot more to languages than just a different syntax, and it represents a tremendous investment of resources to become truly competent in a language.
Just as you would be irritated with your web site designers for dropping into Spanish because "Spanish had a better idiom for saying that -- hey, what's the big deal? It's just a different language", use of programming languages in the Real World is often tightly constrained by the fact that not everybody knows every language.
Usually when you have some lone rebel writing code in Lisp, it's because, well, he was a lone rebel. He could have written it in Sanscrit if he wanted to, but that doesn't make it a good idea. And, even though he got lucky, it wasn't a good idea -- because, as I said, all the code is being scrapped.
Take this article with a *very* large grain of salt, please.
ZFS: because love is never having to say fsck
LISP is also great for working with large numbers... :)
Symbolics hardware was innovative as well. It had a tagged architecture in which a data value included data type information. This meant the hardware could enforce the type system at run time with no additional execution overhead.
Here's a link to some Symbolics info: http://home.brightware.com/~rwk/symbolics/ (and it includes a picture of Zippy, the official Symbolics mascot!)
Scheme is actually seeen as a screening class since everyone who thinks of taking CS has to do it as 101. I dont know but I think that teaching them something as hard as scheme gets them discouraged and they end up taking Econ or Math.
Fractal
"Wireless : LAN
I admire Lisp for its advances as a symbolic manipulation of concepts while encapsulating all the object typing. I, however, have to say that many computer science majors have renounced CS in my small liberal arts college because they didn't find lisp useful or easy to grasp.
I hope not to sound off topic since Zach's post can branch into what I wanna say.
The intro level Lisp doesn't seem as encouraging in terms of opening people's minds to functions. I have recommended the CS department to teach C++ as intro and *then* Lisp. I find that higher level languages are better for learning CS than languages *based* on recursion and non-obvious return types in higher level functions --which students don't see in their highschool. All they know is how to match parenthesis for math, but they never see 8 parenthesis in a row, I bet
A function that takes another function seems to me like a disastrous thing to teach a 101 student who has *never* taken CS till the college level but has some hopes as a prospective major. In C++ class, higher level functions make more sense, and does the whole paradigm of programming to the intro student. List should be a powerful language used once you have a grasp of basic data structure concepts and program design.
"Wireless : LAN
LISP (Lost In Stupid Parenthesis (this is not the real acronym (the real acronym is LISt Processing))) is a really cool language with a really annoying syntax (lots of parenthesis (they can be a real pain to deal with)). The language was designed with recursion in mind. Recursion is a very elegant way to do tasks repeatedly until a goal is met (an in-order traversal of a tree for example). One of the biggest drawbacks with recursion is that it involves alot of overhead, and LISP is designed to minimize this.
Sig free since 2/6/2002
I disagree with this article's core point -- that one language is absolutely more powerful than another. He's right that Perl5 is more powerful than Perl4: it includes every Perl4 feature and a lot of new ones. But realistically, how often is this the case, other than a subsequent version of the same language?
He never formally defines "powerful", instead saying this:
So he thinks an operator to do something that a subroutine could do doesn't make the language more powerful, because there's another way to do it. Yet by what he just said, that all are Turing equivalent, there is always a way to do the same thing. It may be much more obfuscated, but it's there.
I would instead define powerful as this: providing a simple and elegant way to do a given task. This means powerful is not an absolute. A language like Perl is much more powerful at doing string manipulation because its string handling is part of the language. C obviously can do everything Perl can (Perl is written in C) but it's not as simple, so C is less powerful than Perl in this respect. Other languages are more powerful for other tasks. Some languages may be a poor choice for just about any task, but others are better for one thing than another.
Also, powerful is not all there is to think about. He mentioned execution speed. Readability is another concern. COBOL was written so even non-programmers could understand it. Whether you agree or disagree that this is important (I'm inclined to think it's a lost cause), it is another thing to consider. LISP...well, I just don't get it. I will eventually try again to (actually, I think it's going to come up in a class fairly soon), but I'm hardly alone. It does make it harder to find programmers for, etc.
unsigned long factorial ( unsigned long x )
{
return (x>2)?x*factorial(x-1):2;
}
Besides, on a 32 bit machine the unsigned long will overflow when x > 13. You won't get a stack overflow until hundreds of thousands of levels of recursion for a function this simple. By that time, the result will be over 1 million digits long and would require a 5 million bit wide unsigned long data type. I don't see that happening anytime soon.
I gather from your comments that you are a rabid fan of Lisp. Good for you. Nevertheless, you've missed my point. My point is that for fast, efficient development of an application like the Yahoo store builder, you sure as hell don't need a language which permits the definition of new syntactic forms. For God's sake man, come back down to earth! Most web programming is child's play, and the main problem is not the insufficient capabilities of the languages used, it's the pathetic incompetence of the average web developer, especially in the early phases of application development, which matter the most. Software of any significance must be designed before it is written, and most web developers simply do not have experience with this. Unfortunately, that is the *real* reason why web applications are so frequently mangled beyond the point of maintainability as they evolve in capability over time - the accumulation of hacks and partial rewrites eventually turns the thing into an unintelligible mess which nobody can decipher save for the one or two poor souls who are unfortunate enough to have been there almost since the beginning, and they probably think that their ability to understand the pile of garbage makes them programming gurus. I also claim that this is the *real* reason Graham et al were able to move faster than their competition - better design, not a better language. Look, Lisp is a great programming language and I'm really happy for you that you love it so much, but you have got to understand that the difference between a master of a language working in his element and the typical programmer far, far outweighs the differences between the various programming languages used in web development. Didn't you ever read "The Mythical Man-Month"?
How's that for a labor-saving device?
I claim that the end result of your work is something which could have been done in Perl with an equivalent amount of effort by programmers as proficient in that language as you are in Lisp. The design would have been totally different, of course, but it would do the same thing. To me it sounds like you're saying, "I had to do it this way in Lisp, and there was no other way to do it in a different language which would not have been excessively difficult to implement.". Do you realize how sweeping of a claim that is? Is your expertise in Perl sufficient to allow you to make that claim?
That prejudice alone is perhaps forgivable, but the logic used to support the claim - in particular, the reference to their use of Lisp macros - is laughable. Paraphrasing: "We used macros for 20-25% of our code, and Lisp macros are hard to write and can do things you can't easily do in other languages. ERGO, 20-25% of our application did things other languages can't do and was thus beyond the capability of our competitors to implement.". "I encourage you to follow that thread", the author exhorts. Sure, I'll follow that thread. I'll follow that thread right to where it ends in a frayed, tattered mess at the foot of a giant billboard that says, "Hey guess what? It's an online store builder, and that ain't rocket science. Calm down and save the Aikido speech for the choir, because they'll listen and nobody else will.". The real reason these guys did well is simply that they were good, fast programmers and their competitors were not. It has nothing to do with Lisp. Had they been faced with a team of Perl hackers of equivalent skill to their Lisp mastery, things would have been more interesting.
HTML is a tree, and you want to manipulate it as a tree, not as a text file. LISP is good for manipulating trees. Doing Viamall in it made sense. Back then, all the alternatives were much worse.
LISP concepts are still around. Java is conceptually quite close to LISP. The syntax is different, but the run-time systems look rather similar. Both offer a garbage-collected environment which can load new modules during execution without compromising safety. And to a considerable extent, XML is an attempt to re-invent LISP data structures, badly.
Scary, that you would mention Emacs, and Artificial intelligence so close to each other. No more Emacs for me..
Jeremy
Where would you recommend starting to learn LISP? I have the common lisp book but there are like a million and one compilers/interpreters out there. One for windows is prefferred, but I can throw it on one of my Unix boxes if I must.
Thanks
Jeremy
Thanks, I found that MIT book too, by susmann and someone. About Scheme. I may dig into that as I have been told Scheme is a more simplified version of LISP. Sounds fun, I love learning new languages. :)
Im not wure who wrote this but this was one of my first turn on's to functional programming languages.
For the link paranoid.
http://www.naggum.no/worse-is-better.html
Very cool reading.
"It was in fact the first big end-user application to be written in Lisp, which up till then had been used mostly in universities and research labs."
Crack dot com's Abuse? Naughty Dog's Crash Bandicoot?
Peace,
Amit
ICQ 77863057
[o]_O
LISP was designed at MIT for AI research, and was at the forefront of functional programming. LISP is based on Lambda Calculus and is controlled via recursion and conditional expressions.
Common LISP is a contemporary version of LISP available for UNIX and Windows systems (Debian users $ apt-get install clisp )
--jason
Close, but not correct. The oldest living language is FORTRAN, dated back to 1954.
I wonder how many of the successful web sites hide the secret FORTRAN power from their competitors :)
Oops... Haven't noticed the "one of" part. My bad, sorry.
Classes exist in the Haskell 98 standard (nt)
If you are referring to some asymptotic time complexity disadvantage of purely functional languages compared to Von Neumann languages ... well, while it might seem like such a thing is true, I have yet to see a proof. And you can use arrays through monads, in Haskell.
Also, you should check out a book titled: "The Optimal Implementation of Functional Programming Languages", which describes a new FP interpretation algorithm that is exponentially faster than the strict LISP interpreters/compilers because it optimally reduces beta-redexes (doesn't duplicate work when it doesn't have to). The nature of strict interpretation/reduction, which LISP uses, implies that function arguements are evaluated in a non-optimal way (arguements that aren't even needed are still evaluated and this can have exponential performance penalties... hell, it can have as bad of a performance hit as you want, depending on your program). While I don't know of any Haskell interpreter or compiler that uses this new theory... its just a matter of time before someone implements it.
The fact that LISP dialects don't use a strongly normalizing reduction is enough to point out several other resulting problems of the language, with regards to functional programming and programming in general.
Now, if you want the fastest full-fledged FP language available, you will want to check out Clean, which uses similar theory as the "Optimal" book mentioned above, except it uses Linear Logic theory to allow for linear types or unique types, which let the programmer destructivly update stuff, all the while keeping the language a purely functional language. Offices apps (spreadsheets and the like), video games, compilers, integrated development environments, and more have been implemented in Clean. Purity doesn't mean lack of efficiency or more difficult programming. In fact, purity means nothing more than easier program analysis... you end up with more correct programs because of it.
Clean is like Haskell with uniqueness/linear types. The only reason that I didn't make a post titled: "Why Lisp when Clean?", is because Clean is a proprietary programming language, and it is my belief that an open language has an advantage by default, over any closed language. Not that the people who maked Clean aren't cool and open, but the language is propreitary... anyway, I am ranting. Sorry bout that. It just starts happening.
A matter of taste, yes, just like: parachutes, seat belts, helmets, traffic lights, file permissions, and encryption are a matter of taste. People who understand the importance of saftey and garenteed correctness prefer static inference type checking, while those who have never read any software engineering studies on productivity with typed and untyped languages prefer whatever-untyped-language they started with. I am not going to sit here and explain why static type checking is important, while dynamic type checking isn't even really true type checking. Static type checking tells me about errors before I ship my code, and dynamic type checking has my customers telling me about errors through customer support calls. Takes some really bad taste to like that!
Also, you ask "why should I throw extra code at a problem that doesn't exist?" If you are talking about the code required to type things... well, you obviously do not understand Haskell's type inference system. You don't have to tell the compiler what the types of your code expressions are! If there is no problem like you say, then the compiler can figure out the types automatically. It is a win-win situation, and all untyped languages give you is less assurance that your code is correct. Taste has nothing to do with this rational preference for static type inference systems.
The only drawbacks to Haskell is that it is new and less people know about it and know how to use it. Many universities also do not teach Haskell because, again, it is too new.
So, I ask my question: Why fear new and better things? Why do people keep ranting about the virtues of an outdated programming language, when there are better alternative standard functional programming languages?
If you have no idea what I am talking about, then download Hugs (for Mac, Windows, Linux), a Haskell interpreter, and try it for yourself. Debian GNU/Linux users can simply "apt-get install hugs" and start running hugs. I also recommend a book, if you have never programmed or never programmed in a functional language before: The Craft. Read the book an hour each day, and play around with hugs while you are at it. After a few weeks, you will understand why writing code in Haskell is allot like writing the poetry of algorithms.
The famous (?) quote is:
GNU Emacs is a LISP operating system disguised as a word processor. - Doug Mohney, in comp.arch
See http://www.lickey.com/emacs/ for more quotes.
With data=program, and all that RTML, I'm wondering how the authors made sure that their users didn't add in "unwanted features" into their webapp.
With my webapp, I at least know that sort of thing is close enough to impossible. But at the same time, that means zero user customization of the webpages.
Cheerio,
Link.
Does anyone know where I can get a copy of Paul Graham's book "On Lisp"? It seems to be out of print, and I haven't been able to find a copy at any used book sites (half.com, alibris, powells, etc.)
thanks.
allagash98@yahoo.com
...there is a postscript link too.
"Rub her feet." -- L.L.
If nobody else finished the assignment its hardly surprising that yours was the quickest implementation
Special Relativity: The person in the other queue thinks yours is moving faster.
A great book for anyone interested in reading up on this is The Little LISPer, by Daniel P. Friedman. The entire book is a dialog, consisting of questions down one side of the page, and answers down the other. It starts with the basic concepts, (ie, What is an atom?), and just builds and builds. This is easily one of the most compelling computer instruction books I've ever read. Probably not that great as a quick reference, but if there were more language books like this, I'd learn more languages.
circa75.com
The part I love about lisp is:
(defun do-everything-you-ever-wanted ())
Of course, the implementation is left as an excercise to the reader.
/* 0x2b | ~0x2b is in fact -1 */
Check http://www.franz.com/success/ for a whole bunch of success stories from users of just one Lisp implementation.
Here is an excellent online introduction to Scheme, a lisp dialect.
h intro_toc.html
http://www.cs.utexas.edu/users/wilson/schintro/sc
And here are many links to Books, Online tutorials, etc for learning Lisp
http://www.lisp.org/table/learn.htm
Pride and Prejudice: Four Decades of Lisp
e /prejudice.html
Floating Point Performance of Common Lisp
http://kmi.open.ac.uk/people/snw2/papers/prejudic
http://members.home.net/vogt/fft-paper.html John McCarthy's Home Page (the creator of Lisp)
http://www-formal.stanford.edu/jmc/
Peter Norvig (Division Chief, Computational Science at NASA) recently reviewed 4 Dynamic environments and Lisp ranked _very_ highly. Here is the review:
e /0103e.htm
http://www.sdmagazine.com/articles/2001/0103/0103
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-s tudy.html
Blurb... "We have repeated Precheltís study using Lisp as the implementation language. Our results show that Lisp's performance is comparable to or better than C++ in terms of execution speed, with significantly lower variability which translates into reduced project risk. Furthermore, development time is significantly lower and less variable than either C++ or Java. Memory consumption is comparable to Java. Lisp thus presents a viable alternative to Java for dynamic applications where performance is important."
Because theyre not designed to be read on a moniter. Theyre meant for printing out. Theyre a throwback to an older medium.
They have their place yet, but ultimately, when we quit printing out things on paper, theyll go away.
yeths, we all love theth lispths, some timeths iths helpfull in a cthndy Brady kind of way
________
Does anyone actually have a Java program designed to control air traffic, or for the operation of a nuclear facility?
Howth that thupothed to beat the competithion??? ;)
This sig is xenon coated, and will glow red when in the presence of aliens
I think Paul Graham is tooting his own horn a bit too much here. Lisp was 35 years old when he used it in ViaWeb. His claim that "It was in fact the first big end-user application to be written in Lisp,which up till then had been used mostly in universities and research labs." is patently wrong. Has he forgotten about Emacs? When I was a lowly grad student, we used to work on Lisp Machines (a TI Explorer and a Symbolics Lisp machine). IIRC, their whole OS was written in Lisp.
So, for Mr. Graham to claim a first here is definitely hype.
For a laugh, why don't you email that comment to Erik Naggum... Anyway, functional languages, CL especially, are the most scalable in my (or opinion experience).
Ummmm, no. I write little Lisp programs in lieu of shell scripts or Perl. And I've written a package to process CVS logs (terribly painful format to parse, btw), which chows through megabytes of logs ridiculously fast.
CLISP compiles to bytecode, and CMUCL compiles directly to native code. Both are completely free, with source code and everything.
So use FFI. Call your C function from Lisp, and be happy.
To be sure, but it should be the language of everybody else too.
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
Prolog seems more popular outside .us, but that seems to be a territorial thing to me (Lisp was invented in .us, while the major dialect of Prolog is called "Edinburgh Prolog"). Japan, especially, had a big thing for Prolog in the 80s, but it seems to have died off (along with, thankfully, Turbo Prolog).
I actually tend to prefer Prolog for AI-type things, and use Common Lisp as my general-purpose language. It's also worth noting that implementations of simple Prologs in Lisp abound.
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
I'm a big fan of Common Lisp as well as Paul Graham (having read his book ANSI Common Lisp, I can see that he possesses both in-depth technical knowledge and a sense of humor). This article seems to match what I've read of him in quality, and I look forward to reading it in more depth when I get home.
I'm not a Lisp guru by any means, but the one thing that I always get a kick out of is how easy it is to become a low-level guru. After a few weeks of playing, I was doing things I wouldn't have dreamed of doing in C or Java. And it changes one's perspective. It all translates to machine code at the lowest level, of course, but after learning Lisp I can say without a doubt that I'm a better C programmer.
Lisp is an interesting language, because in some ways it's ridiculously high level (closures, generic functions, garbage collection, et cetera), but you're also able to get down and dirty with the cons cells with no trouble. I think this quote expresses it best:
Lisp is extremely versatile. While it was originally used in AI, it's honestly the best tool for most situations I come across. (You can see one thing I've done here, and I've done some other stuff that I haven't had a chance to post yet.) Whenever I need to do more in the shell than loop through a few files, I write it in Lisp (I've written 5-line programs to leech an entire Web page's MP3 archive). Lisp is great at processing logs, the output of various subprocesses, and other such things. It's also got a wonderful OO system.Graham's "Blub" example holds true for everyone I've met who has a disdain for Lisp. The advanced features it provides really do go over their heads, which is sad, because these are often intelligent people. Also, they don't look beyond the syntax differences, and often have a lot of misinformation (Lisp is slow, you can't do iteration in Lisp, Lisp is for lists and AI) fed to them by CS professors or whoever. I also often see a lot of posts from newbies who want to write "C-Lisp" and give up when that doesn't work. Lisp is a different paradigm, and needs to be treated as such.
If you're interested in Lisp, I would recommend reading The Evolution of Lisp (don't be angry at the poor fonts in the PDF; they didn't use scalable TeX fonts, the weenies :), Paul Graham's ANSI Common Lisp, and Winston and Horn's LISP, 3rd Edition (but ignore them when they disparage car and cdr), in that order.
Also, don't be confused by the various Lisps out there. First, ignore Emacs Lisp. Among its quirkyisms, it's dynamically scoped, which means that if you declare a variable, every function you call will also have access to that variable. Secondly, Scheme and Common Lisp are vastly different. Scheme is much leaner, and has 1 namespace, which means you can't name a variable and a function the same thing (I dislike this, but it's a hotly contested issue). Common Lisp has a huge set of standard APIs and much more versatility prebuilt into its core, while Scheme tries to stay small so as to provide an easily implementable standard. I'm a Common Lisp man, myself, but try things out for yourself.
One final thing is that if you hang out with them, you'll realize that most of the long-time posters are extremely knowledgable and have a great sense of heritage. I've learned a great deal by simply lurking through their flamewars, since I find out a lot about what issues may crop up for an individual programmer.
If you want a bit more advocacy, see my recent posts on the subject.
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
I have a couple of questions for the people rewriting the Lisp in C++:
In his article Paul Graham stated that 20-25% of the code took advantage of Lisp's macros, and that it wasn't in there for fun, it was necessary. What are the people rewriting this in C++ using to duplicate the functionality that the macro facility provides?
If zero people understand Lisp, how the heck do you understand the Lisp code enough to rewrite it? What's going on over there? I'm imagining the scene in 2001 where all the homonids are standing around trying to understand the monolith.
Over the years I picked up a course on Java. I did a little C++ on my own.
Now I do most things in Perl.
For example, I have to build a little script that will break up this monolithic file into multiple files, build a directory structure, and ftp the whole thing to another machine. Perl. Take a bit from this and a bit from that, throw in some CPAN and I'm done.
One of you fine folks with a view from the top tell me what would work better. I'm always interested in doing less and getting more.
Lay it on me.
As far as I know, it isn't based off of anything. You haven't heard of it because you are probably in the "under-25" crowd. LISP isn't really good for much, outside of artificial intelligence or other heuristical analysis-type applications. AutoCAD used to make extensive use of LISP for user-written scripts; in fact, it still has built-in LISP functionality, but as with most other CAD packages, those functions have probably been translated to C by now....
"I ain't 'nobody,' dork....right?"
I didn't say you COULDN'T use it for anything else. There are just better language choices today....
"I ain't 'nobody,' dork....right?"
It's pretty simple: just "car", "cdr" and parenthesis. Heh, heh. You can do amazing stuff if you get used to thinking right.
Two is not equal to three, not even for very large values of two.
Functional languages are different, but if you really want to fuck with people, make them learn prolog!
I'm not. The without permission part is *funny* yes Eric does ask that you credit the file but since the Jargon File is public domain you do not have to. See this http://www.tuxedo.org/~esr/jargon/quoting.html
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
:LISP: /n./ [from `LISt Processing language', but mythically from `Lots of Irritating Superfluous Parentheses'] AI's mother tongue, a language based on the ideas of (a) variable-length lists and trees as fundamental data types, and (b) the interpretation of code as data and vice-versa. Invented by John McCarthy at MIT in the late 1950s, it is actually older than any other {HLL} still in use except FORTRAN. Accordingly, it has undergone considerable adaptive radiation over the years; modern variants are quite different in detail from the original LISP 1.5. The dominant HLL among hackers until the early 1980s, LISP now shares the throne with {C}. See {languages of choice}.
All LISP functions and programs are expressions that return values; this, together with the high memory utilization of LISPs, gave rise to Alan Perlis's famous quip (itself a take on an Oscar Wilde quote) that "LISP programmers know the value of everything and the cost of nothing".
One significant application for LISP has been as a proof by example that most newer languages, such as {COBOL} and {Ada}, are full of unnecessary {crock}s. When the {Right Thing} has already been done once, there is no justification for {bogosity} in newer languages.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Functional programming is really only 20 years old, which is about how old a language has to be before the lowest-common denominator languages start paying attention. Is this the future? (god I hope not.).
As for teaching students, functionals are an excellent place to start b/c it *forces* students to learn to work with higher-level functions and learn to think in sets, domains, recursion, and mapping. I think it a great boon that a freshman can pick up mapping in a week in functionals whereas someone with years of experience will stumble through 'Patterns with C++' to learn to kludge together something similar.
vive le LISP!
I agree with you completely. Lisp & Scheme opened my mind like a psychadelic drug.
wishus
---
From the "I also know a programming language" section:
..) Java is really getting better in the library and working examples part. Checkout Yahoo for open source Content Management Systems in Java (great source of working examples to build your app on) and get IBM Visual Age for Java for quiche eaters integrated IDE and collaborative version management.
I mean, the discussion basicly is about software productivity, which is minimizing:
(func - lib) / (people * efficiency)
So go for libraries, people and efficient programming languages. Depending on the job, even SAP might work... (lots of functionality, good people...)
I think LISP falls short on the people part. The same unfortunately happens to Smalltalk and Prolog. Prolog is my personal favourite, and even more powerful than Lisp. See http://www.fraber.de/sitec for a full fledged content management system in 5000 lines. Checkout http://www.swi.psy.uva.nl/projects/SWI-Prolog/ .
But there are some golden combinations. Checkout ArsDigita, http://www.arsdigita.com/ . These folks are using a ridiculous language (TCL, no argument passing by reference!!!) together with a huge library, lots of working examples and a solid infrastructure to build incredible online communities. And the language is so easy to learn.
And (Im sorry, but
Were using ArsDigita in my company, were still in business, and our competitors just dont get it how fast were shelling out new modules.
Good luck!
Frank
Lisp is its own meta-language. That's the basis of much of its power.
Also while Dylan can be more efficient than Common Lisp in terms of the object subsystem, I believe CLOS with the Metaobject protocol fully implemented is more powerful.
Last, the condition system in ANSI Common Lisp is at least as sophisticated as Dylan's as far as I can tell. Do you have some particular feature in mind?
Hacking Lisp professionally since 1985... and still doing so.
-- I speak only for myself
As to the traditional meaning of "strongly typed", I think it's an almost archaic distinction (not obsolete, but missing all of what is truly interesting about semantics), but it still means what it means, compilers that check actual parameters agains formals and spew errors.
There are no typing issues with Lisp... If you want a string you've got a string
if you want a string and somebody passes you a cons, you've got a cons, and that's a problem. that's what the "strongly typed" crowd means by "weakly typed". Yes, lisp gives you the ability to inspect type at runtime, and that's very powerful, but it's not strongly typed. You may declare it to be better than strongly typed, but it's not strongly typed. You have similar problems with your statements casting [pun alert!] aspersions toward C. C is relatively strongly typed (with the exception of the short/long int business, the "see-through" typedefs and the "no formal paremeter" nature of cast operators)
And, polymorphism: once again, lisp allows you to implement powerful polymorphic capabilities with its first-class user defined types, but it is not polymorphic in the sense that OOP people mean. You might argue "better", ok, but still, it's not polymorphic.
I'm not sure how many people out there will remember, but many moons ago, back around post-Doom Year 1 or so, a non-id software company called crack-dot-com released a nifty side-scroller called Abuse. Not only did Abuse feature a cool mouse-keyboard combo for aiming/moving and some cool level designs, it also featured a complete set of game editing utilities and an honest-to-God LISP interpreter that let you completely reprogram the game. I can't think of too many games that feature their own LISP interpreter, unless you think emacs is fun and difficult enough to qualify as a game. J
Clearly the author is a talented programmer. Not only that he is such an expert on Lisp that he wrote books on it. Co-incidentally he wrote some popular software in the languagfe he is an expert in. The lesson here is that your startup will succeed if you have someone working for you who is such an expert on a language he has written books on that language. You know, I bet Randal Schwartz writes excellent software in perl. Funny how that works, isn't it?
They moved away from Scheme into Java for version 7.0 because most traditional companies (read: clients) couldn't get resources to maintain the stuff. So while the limited use of Lisp was an advantage to some startups, it was actually a disadvantage to Ariba. The article quoted in the story does talk about why that is, however.
Most of the class decided to write it in C, but I chose Common LISP. I was the only person in the class to complete the assignment on time, even though I didn't work in a group. LISP helped me for two reasons:
Now if only I had had the opporunity to sell it to Yahoo for $50 Million! ... :-)
What is "Lisp" based off of? Is it a C++ style code or something else, and why have I not heard of it before? What are some other "famous" applications that are using Lisp?
I have no signature
PDFs are immediately searchable for all platforms. You did download the searching version of Acroread, didn't you?
To search the current link tree for the same thing will take you longer while you either wait for a spider to index it for you or while you download the content page(s) to run a script on it. I'm interested in finding the information, not making a job out of it.
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
The Gnome default window manager, sawfish, uses Lisp as its extension language, via the librep package.
On my RedHat system, the lisp code is inThere's over 8000 lines of Lisp in the default implementation, plus another 2500 or so in the themes. People customize it heavily as well.
A visually impaired colleage, for example, can now use X Windows because he customizes it with Lisp to have audio cues.
First of all, a Lisper MIGHT write this as:
(defun factorial (x)
(if (= x 0)
1
(* x (factorial (- x 1)))))
(Sorry about the indenting!)
Some things to note:
(1) In Lisp, integers automatically overflow into big integers, so you can type (factorial 1000) with confidence; try that with your C version.
(2) Note that my function does the right thing on (factorial 1) and (factorial 0).
(3) Because Lisp is expression-oriented, there's no need for the explicit return statements (in this case) that clutter your definition.
(4) Of course, factorial can be written iteratively in Lisp using one of its many iteration constructs (dotimes, do, loop). The latter two put for(;;) style loops to utter shame, by the way.
(5) The Lisp functions are much more general than this example shows. For example, the = function can compare a variable number of items a once, e.g., (= arg1 arg2 arg3 20). The * function also takes multiple arguments (e.g., (* 1 2 3 4) -> 24) and includes the correct identity: (*) -> 1.
Well, not my Lisp snippet, since it isn't tail recursive. However, the following could be rewritten by a sufficiently smart compiler:
(defun factorial (x)
(factorial-helper x 1))
(defun factorial-helper (x result)
(if (= x 0)
result
(factorial-helper (- x 1) (* x result))))
(Again, excuse the indentation.)
Tail recursion is when the last expression of a function is a recursive call to the function. The recursive call cannot be a mere subexpression, as it was in my original code snippet:
(defun factorial (x)
(if (= x 0)
1
(* x (factorial (- x 1)))))
but i;m nearly certain that Lucid Common LISP would do the transform with a high enough optimization level.
:)
You may be right; Lucid had the original "sufficiently smart compiler". And to paraphrase Arthur C. Clarke, "any sufficiently smart compiler can magically transform common recursions into tail calls."
Anyhow, having said all that, could someone who knows Lisp better than me explain what it is about Lisp that makes it so good for AI? I've always heard that but being pretty far removed from that field I've never seen any cool Lisp AI code.
I'm not (unfortunately) a LISP god, but I think I know enough of the theory to answer. It's mentioned in the article, actually, where it describes LISP as a language where code and data are of the same form - that is, code returns data which is, syntactically, no different than code. What this means from an AI perspective is that LISP is designed to be able (given a good enough head start) to write itself. If one understands AI as learning systems rather than just logic-processing systems, this ability, in some form or another, is key.
The article does point out one thing that seems to get lost in the computer world. Better to use a tool that does what you need than to use a tool that does what you want. Most want easy to use, but how often have we learned good enough isn't.
By definition, a government has no conscience. Sometimes it has a policy, but nothing more. - Albert Camus
The text for the course is available here.
This was pretty much all I did last October.
Enjoy.
Bryguy
microsoftword.mp3 - it doesn't care that they're not words...
This is a shame, because I think a top-notch open source common lisp implementation (of the same quality as ACL) would be a great thing. It would allow curious hackers to experiment with the language and get over lisp's rather long learning curve, which would increase the pool of lisp hackers, which might even make the language a practical choice for internet startups. As others have mentioned, what Graham conveniently forgets to mention in his article is the difficulty of finding (or training) qualified CL programmers; for a startup company, this is a show-stopper.
thats what i was going to state.
lisp has been in autocad for as long as I can remember - and provides a very powerful way of scripting things that are done on an everyday basis.
almost every arch/eng firm you find that uses autocad will have its own custom set of commands for everything that autocad does (all in lisp)
works extremely well for that sort of thing.
i actually wish that every program had the ability to write out command macros and functionality programs in lisp to help acomplish many things.
This is a follow up question, not an answer ;-)
I just found (at www.gnu.org/manual/emacs-lisp-intro) an introduction to Emacs Lisp, which the document describes as simpler than Common Lisp. Can anybody explain what that means (not literally what it means...).
Is this still a worthwhile introduction to Lisp (and a particularly convenient one if you have Emacs handy)?
-------------------------
-------------------------
A person of moderate zeal
The footnote of page one reads:
"1.Viaweb at first had two parts: the editor,written in Lisp,which people used to build their sites,and the ordering system,written in C, which handled orders. The first version was mostly Lisp, because the ordering system was small.Later we added two more modules,an image generator written in C, and a back-office manager written mostly in Perl."
It is very rare to rely on only one language for any application on the Web. I think this article, other than the provided footnote, mistakenly leads a reader to believe that the entire application (Viaweb) was written in Lisp.
(write-line "Hello, world.")
If the faq page is correct sawfish uses lisp.
I still program lisp on my HP48 calculator. That thing was (and still is) very cool. Only 128k of memory though, but thats a whole heck of a lot for a little calculator.
- This isn't the sig you're looking for. Move along, move along..
...I only got into Lisp a few weeks ago, but already the flexibility of the language is paying-off. I find the development of my code is much more rapid and "hands-on" - I'm able to spot logical errors and specific code flaws as I write them, rather than days or weeks down the line. Well - I won't rant, but I've found that the best IDE for my purposes is Franz's Allegro CL Franz also has an interactive Lisp course linked from their site.
LISP: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds... -taken from the Internet...
Try Forth.
MCL is the most popular Mac environment, it seems.
Well, let us just say that we disagree on this.
Which book do you have? It may or may not be a good place to start. (Graham's own ANSI Common Lisp is a good starter.)
There are plenty of good implementations. XAnalys Lispworks, Corman, and Franz have free trial versions of their environments which are suitable for learning. Also CLisp is a free (GPL) Common Lisp for Windows. All of the preceding except for Corman are also available for various Unices (although there may well only be free trial versions for Linux), and CMUCL is also available there. You'd be hard pressed to go too far wrong with any of those (I use Lispworks for most of my work and like it).
Really? Discounting the fact that the article linked to in the story demonstrates a quite non-AI use for Lisp, there are others as well. I, for example, use it for business programming.
ML is your daddy! Seriously though, someone told me about some CMU researchers who wrote a pretty fast web server in ML, sweet ...
I must say that since I learned ML I have thought of everything at work (Java) in terms of how much easier I could do it in ML.
Some of my notable past accomplishments:
- Wrote the first video game in a late night hacking session in 1989
- Developed a completely anonymous digital cash system... first in the world!... in 1997.
- And finally, I was the first person to figure out how much smarter i was than the rest of the world and write a paper about it... in 1999!
Apparently we are supposed to trust this guy that LISP is such a great business language... because (gasp!) he was able to sell out in the great business school rush to the Internet of the late 90's. Well, congratulations Paul, but if we all wrote applications in whatever Yahoo was buying, lets see, we'd be writing in C, C++, Perl, Python, PHP, Java, shell, LISP.... OhI think that for practical purposes, something like Python is very close to CommonLisp. The major differences are lack of macros in Python (not necessarily a bad thing), a less complex object system (probably a good thing, too), and lack of compilation to native code for Python source code (but you don't get that much of a speedup). And Python actually has a better standard library, better built-in datatypes, better OS integration, and cleaner semantics. Jython with Java for compute intensive stuff actually does better than most CommonLisp compilers.
Yes, it is silly and wasteful that languages like Python, Perl, Tcl, etc. essentially reinvented Lisp and Smalltalk (Java made some sort of unholy but very functional compromise between Lisp and C++). But they did, and you might as well use them. None of those more recent languages have made the transition to a natively compiled environments like Lisp did, but on fast modern hardware, that matters less and less, and sooner or later they probably will.
Dylan fixes near all the complaints that I have seen posted here about Lisp:
Dylan is fully objected-oriented from the ground up.
Dylan has highly-readable infix syntax.
Dylan has a module system.
Dylan has a sophisticated exception handling system.
The complaint that Dylan does not fix is the small user base. Unfortunately Dylan has a much smaller user base than even Lisp. But lack of other users should not stop a true geek.
This article is riddled with logical flaws. Here are just a few:
There is a big difference between using something because it helps you train for the real thing, and using something for the real thing. Using this same logic, football players should suddenly drop and start doing push ups on the field after the ball is snapped.
This short sentence manages to contradict itself.
But in the process of considering what will work best, you need to consider what other people are doing. Businesses do not operate in a vacuum.
"The only rights you have are the rights you are willing to fight for."
The biggest mistake I believe this author makes is the fact that he makes it sound like Lisp is universally the best language to use except for a few edge cases. Lisp may very well be a good short-term choice for this narrow problem domain, but to assume that the rest of the world is so dumb that they would overlook the massive competitive advantage alleged by the author is ridiculous.
Lisp is definitely good at rapid prototyping. I have been involved with two major projects which were initially written in Lisp. But after a while, as they grew in size, both projects became unmanageable. This was not because the developers involved were not skilled. Ultimately, each project needed to call a time out, and each was rewritten in C++ to regain control.
The same will happen for the project that is discussed in this article. The author is just lucky that it didn't happen at a bad time.
"The only rights you have are the rights you are willing to fight for."
Apparently not as skilled as you were led to believe
No, the problem was not him.
But this was just one test. To really get a good understanding, many more competitions like this should be conducted: with different people and different projects.
So, we've done our job. Go and try it for yourself and add to the knowledge. If you do, please email me the results.
"The only rights you have are the rights you are willing to fight for."
I agree! I don't think I've made my objection to Lisp's syntax clear. It's basically all parens. When I was regularly using Lisp, auto-indentation was fine, but there was no color. Perhaps that would help me. But the simple fact that it's all parens I find leads to poor readability.
"Uniform" is both good and bad. A language should be sufficently uniform so that it is easy to understand and predict, but not so uniform that after a few hours of coding the whole screen looks the same.
I actually don't like this. The language should dictate the syntax. One of the reasons that I prefer Java over C++ is that C++ let's programmers rewrite the language a little too much. Java's developers were smart enough to create a language that allows you to extend the language, but not rewrite it forcing the next guy that needs to read your code to learn your language.
The code == data aspect of Lisp is very cool. I've been sold on that since I first learned about it. But I just wish that it didn't have to imply the syntax that it has. I want it all.
The C preprocessor is horrible. It leads to some of the worst readability known to man. Too many programmers have #defined too many things to make their program not even look like C or C++. That's why it's another feature left out of Java.
I'm not a big fan of templates either. Again, another feature left out of Java. For smaller projects that need efficiency, they are fine. But for larger projects they can really clog up the works. If you have, say, 1000 or so classes which represent basic objects in your system, and of you need a smart Ptr for each, and you need, say 20 container classes, suddenly you have 40,000 classes. Compile times go through the roof, not to mention binary sizes and the number and size of your symbols, making debugging a royal pain. But this is a fundamental problem with templates for any language.
Templates do have akward syntax, but only because of typing. This is what they are for. I don't recall Lisp having this same problem with macros since everything was basically left typeless.
That's not fair. Just because C and C++ offer a way of specifying characters on lame keyboards doesn't mean that the language's syntax is poor.
Are you refering to the OO qualities of CLOS? I prefer C++ classes over CLOS. Do you mean to compare templates with macros?
"The only rights you have are the rights you are willing to fight for."
But there is a contradiction in the conventional wisdom:Lisp will make you a better programmer,and yet you won't use it.
This is faulty logic. It is not a contradiction. There are lots of things that you can learn to become a better programmer. I too believe that Lisp is one of them. But this does not imply that Lisp is a good programming language. It implies that it makes a good learning tool. That's it.
Lisp is a neat language, but it's software engineering qualities are way behind the times. A friend and I actually did an interesting project comparing Lisp to Java. He was well skilled in Lisp, and I Java. We defined a project, and then I implemented it in Java, and my friend implemeneted it in Lisp. We then compared the results: the Java version took less time to develop, took less time to debug, contained slightly less lines of code, was more easily modified (we added an additional objective), and was more efficient. Keep in mind that my friend is a Lisp advocate, and a skilled developer.
"The only rights you have are the rights you are willing to fight for."
Please, please, please stop it, everbody. Lisp is not infamous. The only things seen on slashdot threads that could be considered infamous are Microsoft, the FCC and Cowboy Neal. infamous adj. 1. Having an exceedingly bad reputation; notorious.
Lisp(taught(me(to(count(parenthesis))))))))))))))
RC
RC
I like the comments about scanning your competitors job listings hehe... very clever. Don't get frightened by the Oracle guys bwahahah
is guile dying? look at http://www.gnu.ai.mit.edu/software/guile/docs/docs .html last updated at 23 Sep 2000
You know, I remember when that came out, but I swear I remember it being an emacs variant. I really had no idea that emacs wasn't abuse...
i don't know about you guys, but I really like English. Its cross-platform compatible (especially in America), and I've had a lot of experience with it (I've known it since I was like 2). Some people get hung up on the syntax but man it totally kicks lisps ass :)
OK, kids. Here's a script I run on my website each night to produce a page which references files which have changed in the last day.
How would you write this in your favorite programming language? Don't forget to have the program parse the page and insert the new stuff at the beginning, because the version below does. Yes, you could hack this with a pattern matcher. Gross.
A couple people have mentioned that I didn't explain in sufficient detail what we did with Lisp. Sorry about that; I had been planning (and still plan) to write a second, more technical, article. In the meantime, there are more technical details in these excerpts from a talk I gave recently at BBN. -- pg
Macros are used to create new special operators in Lisp that behave just like built in ones like if, loop, let, etc. -- it's a given that without learning macros you can't understand the truly groovy examples, but here's a simple one: Say I only have if/then/else, and I want to make a simpler form called "when" that only ever has a then clause.
"if" is written thusly:
... a.k.a. predicate, consequent, alternative
(if test then-clause else-clause)
I want "when"to look like this: ...)
(when test then-clauses
please excuse the lack of proper lisp indentation.
I can define a macro that is run whenever a function is compiled which uses "when," right along with any other macros I want, in this manner:
(defmacro when (test &body body) ,test (progn ,@body) nil))
`(if
This allows me to use the "when" macro around any conditional code I like, wherever I like, and it will be treated as if I had the if statement right there in the code -- it's not like a function call because the "arguments" passed to a macro are CODE, not VALUES (well, except in lisp they're the same thing, but that's another posting).
For the "can't write games in it" crowd...
Say I want macros to push and pop transformation matrices in a 3d game. It's basically not reasonable to do this in C++ any other way than by hand because if you pass functions into a function which does the pushing and popping they lose their lexical environment and end up having to be more complicated than just doing it by hand. Not so with macros.