Slashdot Mirror

Well, there isn't static typing in Lisp. There is strong typing, but not static. Some implementations (CMUCL, for example) have some ability to make such static checks. But an implementation needn't, and in fact, may not be able to. For example, in your second example, what if we do (bar (read *standard-input*))? There's no way to know at compile time what type of data read is going to return, so reasonable static checking seems somewhat impossible here.

Also, the second example doesn't have to error. If you look here for example, you will see that if we do something like (bar 0) the spec. declares that the consequences are undefined. If you then check the definitions here, you'll see that this doesn't necessarily mean that an error is signaled. It may be, but it needn't be.

As for type declarations, they're there both for speed and correctness. The optional type declarations in CMUCL can serve both purposes. There is a tradeoff here: on the one hand, the need to keep track of the type information is a burden on the programmer when it is inessential to the logic of the program; OTOH, compiler needs this information to produce compact code and sometimes, catch errors. I like the CL's approach the best: it provides you with the option ONLY when you need it. Also, when programming in CL, I find type errors are rare; most bugs are logical.

Python is a very nice language, especially for beginners. But I doubt anyone who know CL well will prefer Python over CL. The expressiveness, the flexibility, the speed, the maturity of compiler and runtime system technologies; those are enough reasons for me to stick with CL.

As an aside: I like Python, and I've been watching Python's development for a while; however, I've yet to see a PEP (Python Enhancement Proposal) which cannot be implemented *within* the language in CL with a page or two using Macro, MOP, etc. Therefore I concluded that it is much less effort to bring libraries to CL, than it is to bring Python up to the level of CL in terms of language maturity.

In short, I think it is much easier to find happiness in CL! I believe most people will feel the same, too, if they're persistent enough to master the few beautiful concepts underlying the design of CL.

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:

What I like about Lisp is that you can feel the bits between your toes.

-- Drew McDermott

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.

--

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).

Here is a list of online books and references which I found useful:

• Common Lisp: A Gentle Introduction to Symbolic Computation -- David S. Touretzky
• Successful Lisp: How to Understand and Use Common Lisp -- David B. Lamkins
• CLtL2: Common Lisp the Language, 2nd Edition -- Guy L. Steele
• HyperSpec: The ANSI Standard for Common Lisp -- Kent M. Pitman
• CLOS: Common Lisp Object System -- Daniel G. Bobrow et al
• MOP: The Meta Object Protocol
• CLIM2: Common Lisp Interface Manager 2.0
  The CLIM perspective, user's guide, and specification.

Over time I've found this to be ridiculously true, and am deeply saddened by the lack of, well, not mainstream acceptance of Lisp, because mainstream acceptance always destroys anything good, but a willingness to let me, as a professional, select a language which:

• allows me to be incredibly productive
• is one of the few languages that really allow me to feel one with my code
• is not slow, nor necessarily (or usually) interpreted
• is not limited to AI
• does, in fact, allow iteration
• has many advanced data constructs beyond lists
• has the best general-purpose OO system I've ever seen
• is fun to hack in Emacs :-)

Sigh. Anyone have any Lisp jobs for an enthusiast and advocate with about a year's informal experience and a love of the language?

--

Many of them do, although as always, it depends on what you want to do. For Scheme, consider something like DrScheme. For Common Lisp, both Xanalys and Franz have good commercial environments. And these are just examples. Further, it's usually fairly easy to use at least C code from these languages, so the amount of code available is greater than it might look at first. I don't know as much about the statically-typed side of things, but from what digging around I have done there, I think that there is often a reasonable amount of stuff available there too.

At any rate, I certainly find that my Xanalys Lispworks environment gives me everything that I need to do a lot of the programming that I need to do.

I'd say that most Lisp and Smalltalk (and many other) systems already do pretty good automatic garbage collection (and not the reference counting type that can cause memory leaks), and have done so for some time. Nor does using this type of strategy for memory management slow things down much (if at all) - that seems to be mostly a myth caused by the state of garbage collection decades ago. While no one will deny that there are places where manual memory management is necessary, I think that for most higher level applications it is not.

A nice page of pointers to more information on this is at: Xanalys' Memory Management page

Take a look at the Common Lisp Hyperspec, in particular, the descriptions of what the Lisp Reader does - It parses the textual input stream into Lisp objects.

Since the Reader is modifiable (i.e., you can remodel it to take in program representation in any way you want and convert it into Lisp objects), and there is no constraint on how lisp objects are represented internally in a conforming implementation, it follows that Common Lisp is already a "representation independent, object oriented programming language" We get the "object oriented" part because the Common Lisp Object System (CLOS) is part of the standard, and part of all current implementations.

Seems to me these people would have spent their time better by writing some reader-macros for Common Lisp than reinventing the wheel.

Take a look at the Common Lisp Hyperspec, in particular, the descriptions of what the Lisp Reader does - It parses the textual input stream into Lisp objects.

Since the Reader is modifiable (i.e., you can remodel it to take in program representation in any way you want and convert it into Lisp objects), and there is no constraint on how lisp objects are represented internally in a conforming implementation, it follows that Common Lisp is already a "representation independent, object oriented programming language" We get the "object oriented" part because the Common Lisp Object System (CLOS) is part of the standard, and part of all current implementations.

Seems to me these people would have spent their time better by writing some reader-macros for Common Lisp than reinventing the wheel.

That's debateable. LISP has no typing, function arity, partial evaluation, composition, list comprehension, or even function predicates (not sure if that's the right name, it's where it only applies the function if the predicate matches).

I'm not sure what you mean by no typing. Perhaps you haven't looked at the types and classes section of the Common Lips HyperSpec. Maybe you also forgot how to declare the types of arguments your function takes.

I'm guessing by "function arity" you mean functions taking arbitrary numbers of arguments. Sorry. Common Lisp has those (so does Scheme, as a matter of fact).

Composition of functions? Lisp has had those for a long time. So what if you have to write the function to do it yourself? It's not that hard (think two lines or so).

Partial evaluation == lazy evaluation? Can be done. A macro and a function -- less than five lines total.

Function predicates? Where you check the arguments of a function before executing it? Not that hard and can even be integrated with the type-checking (see above).

I don't know what you mean by list comprehension, but I'm willing to bet that it's not hard.

Functional languages are somewhat open to argument. If you're talking about pure functional languages, then no, Lisp is not a functional language. However, I would argue that much of the research on functional languages and the techniques used in their compilation have come from Lisp. And if you're willing to fudge a little bit, Lisp looks a lot like a functional language.

All the languages that you mentioned are Turing-complete, so you can do anything in one language that you can do in another. It's my opinion that you can do it all easier in Lisp (what's the deal with the syntax of OCaml or Haskell? very very ugly! no syntactic abstraction like Lisp).

If you think Lisp is just Pascal, then you haven't looked at Lisp very closely. Try "On Lisp" by Paul Graham or "The Art of the Metaobject Protocol" by Kiczales et al to see a few things that Lisp is capable of doing.

-sugarescent

That's debateable. LISP has no typing, function arity, partial evaluation, composition, list comprehension, or even function predicates (not sure if that's the right name, it's where it only applies the function if the predicate matches).

I'm not sure what you mean by no typing. Perhaps you haven't looked at the types and classes section of the Common Lips HyperSpec. Maybe you also forgot how to declare the types of arguments your function takes.

I'm guessing by "function arity" you mean functions taking arbitrary numbers of arguments. Sorry. Common Lisp has those (so does Scheme, as a matter of fact).

Composition of functions? Lisp has had those for a long time. So what if you have to write the function to do it yourself? It's not that hard (think two lines or so).

Partial evaluation == lazy evaluation? Can be done. A macro and a function -- less than five lines total.

Function predicates? Where you check the arguments of a function before executing it? Not that hard and can even be integrated with the type-checking (see above).

I don't know what you mean by list comprehension, but I'm willing to bet that it's not hard.

Functional languages are somewhat open to argument. If you're talking about pure functional languages, then no, Lisp is not a functional language. However, I would argue that much of the research on functional languages and the techniques used in their compilation have come from Lisp. And if you're willing to fudge a little bit, Lisp looks a lot like a functional language.

All the languages that you mentioned are Turing-complete, so you can do anything in one language that you can do in another. It's my opinion that you can do it all easier in Lisp (what's the deal with the syntax of OCaml or Haskell? very very ugly! no syntactic abstraction like Lisp).

If you think Lisp is just Pascal, then you haven't looked at Lisp very closely. Try "On Lisp" by Paul Graham or "The Art of the Metaobject Protocol" by Kiczales et al to see a few things that Lisp is capable of doing.

-sugarescent

One big theme I notice in all the comments on this topic: Functional languages didn't take off because there are (were) no good implementations.

Wrong.

I will speak only about Common Lisp and its direct predecessors, because of all the functional languages I know it is the most flexible and useful for real-life development.

In the 1970s and 1980s there were Lisp Machines. Read up on them sometime---I claim that they were the most advanced and powerful workstations of their time. They had graphical development tools and environments that were mere dreams in the minds of other programmers at the time. They had hardware specialized to run Lisp, and they did so very, very well. Lisp Machines (Symbolics et al.) went out of fashion at around the time when general-purpose hardware began to pick up a lot of momentum and the personal computer began to gather popularity.

Their place was taken by implementations of Lisp running on workstation-class computers. Digital, Sun, IBM, and HP boxes all had third-party Lisp implementations. Most of these implementations are alive today, and available for most UNIXes, as well as Windows and MacOS. These would be Franz Inc.'s Allegro CL, and Xanalys' (formerly Harlequin) LispWorks. Both are robust and powerful. In fact, well-written Lisp will outperform comparable C code with either of those compilers. The real issue here is that there are no free Lisp implementations that compare to the commercial offerings in quality and ease of use. There are CMUCL and CLISP, but neither holds a candle to ACL or LispWorks, for example.

The lack of popularity of functional languages stems mainly from ignorance. As several other people have pointed out, it takes some effort to learn the paradigm, and most people, even those with CS degrees, do not choose to make that effort. Lisp hackers tend to have a strong background in language theory and other topics too complicated for the average ``geek'' whose competence ends at some Perl shopping cart script.

All the three bigger vendors (Franz, Xanalys and Digitool) provide advanced graphical IDEs. Unfortunately there is no free IDE per se as far as I know, but Xemacs with ILISP makes for a pretty nice environment for the free Common Lisp systems.

If you'll excuse me ranting for a bit, but I find it baffling how many people seem to think that if they haven't heard about something, it doesn't exist. Even rabid users of obscure operating systems turn their brain off when it comes to programming languages, industrial applications of computers, and what not, and loudly proclaim that the most popular choice is the only choice.

The world is a big place. There is an enormous number of multi-billion dollar "niche" markets you have never heard about out there.