Jump to content

  • Log In with Google      Sign In   
  • Create Account


Is LISP fluency worth it?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
46 replies to this topic

#21 Dobbs   Members   -  Reputation: 164

Like
Likes
Like

Posted 21 June 2004 - 10:52 AM

Quote:
Original post by Forcas
Has anyone read "On Lisp" by Graham? I'm thinking about reading it. It's free online.


On Lisp is a great book, definitely worth a read. If you're a relatively experienced programmer you should be able to work your way through it with little previous Lisp experience, although parts of it are tough. And if you do read it, keep in mind that the real point of the book is the last few chapters, so you're really wasting your time if you stop halfway through. Why?

It's not a "teach yourself Lisp in XX days" book, and it's not a reference book. What it really does is demonstrate how to use Lisp to create specialized programming languages that are geared towards whatever problem you're trying to solve. Most of the book focuses on teaching you the tools you need to do this (Lisp macros), and the real meat (where these specialized languages are implemented using macros) isn't until the end.

Keep links/copies of the Hyperspec and CLTL2* handy while you read it though, or as a Lisp newbie you'll be lost.

edit: that's a common abbreviation for "Common Lisp The Language 2" which you can find free online with a quick Google - basically the Lisp bible, it will explain a lot of the Lisp concepts while the Hyperspec really explains the syntax of the various built-in functions that implement those concepts.

Sponsor:

#22 civguy   Members   -  Reputation: 308

Like
Likes
Like

Posted 21 June 2004 - 11:47 AM

Quote:
Original post by Dobbs
Most of the book focuses on teaching you the tools you need to do this (Lisp macros), and the real meat (where these specialized languages are implemented using macros) isn't until the end.
Disagreed.. "How macros work" was actually explained pretty quickly, and then there were all these different techniques using variable capture and other stuff with small examples. The very last chapters weren't that interesting IMO, but pretty specific and almost tiresomely lenghty examples of how macros can be used in some particular problems. Not so useful as the chapters before those, which had more general ideas that you can apply to your own macros.

#23 Woodsman   Members   -  Reputation: 426

Like
Likes
Like

Posted 21 June 2004 - 02:10 PM

Quote:
Original post by civguy
pretty specific and almost tiresomely lenghty examples of how macros can be used in some particular problems. Not so useful as the chapters before those, which had more general ideas that you can apply to your own macros.

I see your point and I suppose it depends entirely on the interest level of the reader and what she expects out of the text.

#24 xg0blin   Members   -  Reputation: 752

Like
Likes
Like

Posted 21 June 2004 - 02:47 PM

Did SabreMan leave the forums or something? You'd think he'd be all over this.

#25 Sneftel   Senior Moderators   -  Reputation: 1776

Like
Likes
Like

Posted 21 June 2004 - 02:57 PM

Lisp is kinda fun, but it feels inelegant and pieced-together. Just as the first airplane ever probably ended up with a lot of ugly nailed-on afterthought pieces, so does this pioneer of functional languages. Scheme may be more to the liking of the programmer who wants to make use of functional programming.

However:

GUY STEELE COMMANDS YOU TO LEARN LISP.

#26 Diodor   Members   -  Reputation: 517

Like
Likes
Like

Posted 21 June 2004 - 06:19 PM

Quote:
Original post by Sneftel
Lisp is kinda fun, but it feels inelegant and pieced-together. Just as the first airplane ever probably ended up with a lot of ugly nailed-on afterthought pieces, so does this pioneer of functional languages.


Elegance is the first thing I'd claim in favor of Lisp. For instance, I love how lists are used everywhere - including the &rest parameters of a function and the apply function. The cons pair is a pinnacle of elegance.

Can you give some examples of ugliness?

Quote:
Scheme may be more to the liking of the programmer who wants to make use of functional programming.


Lisp is not necessarily functional, nor is functional programming the high point of Lisp.

#27 Alpha_ProgDes   Crossbones+   -  Reputation: 4680

Like
Likes
Like

Posted 21 June 2004 - 06:22 PM

Quote:
Original post by xg0blin
Did SabreMan leave the forums or something? You'd think he'd be all over this.

i was wondering the same thing

#28 Sneftel   Senior Moderators   -  Reputation: 1776

Like
Likes
Like

Posted 21 June 2004 - 06:53 PM

Quote:
Original post by Diodor
Elegance is the first thing I'd claim in favor of Lisp. For instance, I love how lists are used everywhere - including the &rest parameters of a function and the apply function. The cons pair is a pinnacle of elegance.

While it's elegant, it's also oversimplified. Good Lisp implementations work like hell behind the scenes to make everything *look* like neat cons lists, while tossing that structure out behind the scenes wherever possible in favor of something more efficient. A good Lisp programmer needs to be aware, to some extent, of when and how such optimizations are being made (so he doesn't quixotically try to improve performance with something like RPLACD) even though he is encouraged by the interface to put such matters out of mind. Admittedly, any language is to some extent a compromise between a simple and usable interface and support for inherently efficient constructs, but I think Lisp leans a little too far towards the former.
Quote:
Can you give some examples of ugliness?

The number-one issue I'd point to is the bloated list of standard forms. Quick, what's the difference between (NTH 3 X) and (THIRD X)? Why is LENGTH called LENGTH, and LIST-LENGTH called LIST-LENGTH? Over time, the disparate and aggressively incompatible variants have merged into a more-or-less standard language, but IMHO the standards committee wasn't proactive enough in reforming the best pieces of each into a coherent whole.
Quote:
Lisp is not necessarily functional, nor is functional programming the high point of Lisp.

That's a good point. I'd hasten to point out, though, that virtually all Lisp primers strongly encourage a functional style of programming.

#29 Diodor   Members   -  Reputation: 517

Like
Likes
Like

Posted 21 June 2004 - 08:46 PM

Quote:
Original post by Sneftel
While it's elegant, it's also oversimplified. Good Lisp implementations work like hell behind the scenes to make everything *look* like neat cons lists, while tossing that structure out behind the scenes wherever possible in favor of something more efficient. A good Lisp programmer needs to be aware, to some extent, of when and how such optimizations are being made (so he doesn't quixotically try to improve performance with something like RPLACD) even though he is encouraged by the interface to put such matters out of mind. Admittedly, any language is to some extent a compromise between a simple and usable interface and support for inherently efficient constructs, but I think Lisp leans a little too far towards the former.


I'll disagree here. There's no such thing as "oversimplification" - anything that will make programming easier at the expense of efficiency is desirable.

Your argument is that because Lisp is too far removed from the "raw metal" when one _needs_ to optimize it's much harder to do so. It is argued that it is possible to optimize Lisp code, but I don't know much about doing that.

If I understand correctly, the standard counter to this is the "early-optimisations are bad" argument. Lisp allows one to code quickly without much care for efficiency, get the program working correctly early (!), and, _if_ necessary, optimize the bottlenecks. The flexibility of the language makes high-level algorithmic optimisations a lot easier too (while it makes low level ones harder).

Quote:
The number-one issue I'd point to is the bloated list of standard forms. Quick, what's the difference between (NTH 3 X) and (THIRD X)? Why is LENGTH called LENGTH, and LIST-LENGTH called LIST-LENGTH? Over time, the disparate and aggressively incompatible variants have merged into a more-or-less standard language, but IMHO the standards committee wasn't proactive enough in reforming the best pieces of each into a coherent whole.


THIRD (or CADDR) is a special case of NTH - I'd assume the compiler would like me more for using THIRD instead of NTH 3 if I can.

I knew LENGTH can tell the length of lists, arrays, strings and bit arrays. If I was smart enough I could have assumed LIST-LENGTH only tells the length of lists (although I've never encountered this one), but as it is I had to spend fifteen seconds to fire up Corman Lisp and write and execute (list-length '(1 2 3)) and (list-length "foo-bar") to make sure.

Anyway, I only know parts of the language well enough so I can't say much about how coherent the whole is.

#30 Diodor   Members   -  Reputation: 517

Like
Likes
Like

Posted 21 June 2004 - 09:01 PM

Quote:
Original post by Sneftel
That's a good point. I'd hasten to point out, though, that virtually all Lisp primers strongly encourage a functional style of programming.


Macros aren't functional programming are they? :)

That being said, I understand why keeping my functions functional is an advantage when looking from the outside of the function. Inside the function I really appreciate the freedom to setq and setf left and right - if no side effects are visible from the outside there should be no complaints.

But functional programming is only allowed in Lisp - the language itself has plenty of functions that perform destructive operations on their arguments (functions like sort or mapcan have caused me quite a bit of pain).

#31 Sneftel   Senior Moderators   -  Reputation: 1776

Like
Likes
Like

Posted 21 June 2004 - 09:10 PM

Quote:
Original post by Diodor
THIRD (or CADDR) is a special case of NTH - I'd assume the compiler would like me more for using THIRD instead of NTH 3 if I can.

Yeh, except that NTH counts from zero, not one. Thus, NTH 3 is equivalent to FOURTH. Wacky, no?
Quote:
LIST-LENGTH only tells the length of lists

That's part of it, but the real feature of LIST-LENGTH (and the reason it's in the language at all) is to avoid infinite loops with circular lists.

Why not implement NTH from 0, or put in a ZEROTH and shift the other operators accordingly? Why not rename LIST-LENGTH ACYCLIC-LENGTH or something? because those changes took CL too far from the proprietary Lisps. And although most of those Lisps haven't been in general use in years, their egos still contribute to the cruft of the language.

#32 Diodor   Members   -  Reputation: 517

Like
Likes
Like

Posted 21 June 2004 - 09:28 PM

Quote:
Original post by Sneftel
Yeh, except that NTH counts from zero, not one. Thus, NTH 3 is equivalent to FOURTH. Wacky, no?


You've got me there :)

Quote:
That's part of it, but the real feature of LIST-LENGTH (and the reason it's in the language at all) is to avoid infinite loops with circular lists.


That's good to know, thanks.

#33 MadKeithV   Moderators   -  Reputation: 971

Like
Likes
Like

Posted 21 June 2004 - 09:34 PM

Quote:
Original post by Sneftel
And although most of those Lisps haven't been in general use in years, their egos still contribute to the cruft of the language.


list-length (and many of the other non-trivial Lisp functions) can be implemented in Lisp. It depends on the implementation of course, but really, it's part of the library, and not the language.

#34 Diodor   Members   -  Reputation: 517

Like
Likes
Like

Posted 21 June 2004 - 09:58 PM

Quote:
Original post by MadKeithV
list-length (and many of the other non-trivial Lisp functions) can be implemented in Lisp. It depends on the implementation of course, but really, it's part of the library, and not the language.


I don't think you can usually separate the library from the language, and even less so in the case of Lisp. Here even basic operators like and or or are implemented in Lisp.

#35 MadKeithV   Moderators   -  Reputation: 971

Like
Likes
Like

Posted 21 June 2004 - 11:21 PM

Quote:
Original post by Diodor
I don't think you can usually separate the library from the language, and even less so in the case of Lisp. Here even basic operators like and or or are implemented in Lisp.


I feel exactly the opposite: what makes a library a library is that it is separate from the language. Note though: that doesn't take away the fact that libraries are important in the Real World ™ to make a language useful.

I can agree with "Lisp has some pretty strange library functionality", because it's just downright true, but the language itself is quite clear and concise. It is testament to its conciseness and power that even some of the operators that are considered "basic" are in fact library code. If tomorrow you wake up and decide you need a "list-length" that operates differently (perhaps even written in a different language, though I have no experience doing that in Lisp), you can actually do it.

Important side note: I'm still pretty much a C++ programmer for all this Lisp evangelism ;)




#36 Woodsman   Members   -  Reputation: 426

Like
Likes
Like

Posted 22 June 2004 - 12:28 AM

Quote:
Original post by MadKeithV
Quote:
Original post by Sneftel
And although most of those Lisps haven't been in general use in years, their egos still contribute to the cruft of the language.


list-length (and many of the other non-trivial Lisp functions) can be implemented in Lisp. It depends on the implementation of course, but really, it's part of the library, and not the language.

I agree. I believe that with Corman Lisp (as is likely with many others), only the most basic functionality (car, cdr, symbols etc) are written in C++, and the rest is written in Lisp itself. IIRC, you can actually see the Lisp code for the "fluff."

#37 Nekhmet   Members   -  Reputation: 132

Like
Likes
Like

Posted 22 June 2004 - 05:25 AM

> Good Lisp implementations work like hell behind the scenes to make everything *look* like neat cons lists, while tossing that structure out behind the scenes wherever possible in favor of something more efficient.

I think he's talking about CDR-coding. Boy, I haven't thought about that in a long time. Do any implementations still use that?



#38 Forcas   Members   -  Reputation: 181

Like
Likes
Like

Posted 26 June 2004 - 03:40 PM

Here is an example of why LISP is harder than C++:

I just spent an hour debugging a program consisting of three functions. I kept getting "WRONG-NUMBER-OF-ARGS", but couldn't find a function with the wrong number of args.

I ended up having to trace just about every function I used and finally discovered that in an if statement, the function for a non-nil predicate was being called even though, in this particular case, the predicate evaluated to NIL.

How do you pick up on the numerous intracacies of LISP? Are they consistent in any way?



#39 Diodor   Members   -  Reputation: 517

Like
Likes
Like

Posted 26 June 2004 - 11:20 PM

Post the code - I don't really understand what went wrong with your program.

#40 Woodsman   Members   -  Reputation: 426

Like
Likes
Like

Posted 27 June 2004 - 04:00 AM

Quote:
Original post by Forcas
Here is an example of why LISP is harder than C++:

Maybe your inexperience is a slight factor? :p




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS