Slashdot Mirror

Well he wasn't the first one to do it, Common Lisp already has a disassemble command.

Hi, responding back...

I've actually learned LISP this semester in AI class. LISP is... interesting. I mean, I get it, but it's so weakly typed (the same problem I had with learning perl)that I have troubles visualizing code for it. The C/C++ programmer in me is screaming "use a callback!", the Java programmer in me knows that Java doesn't allow pointers, so extend an abstract class, and the newly found LISP/perl programmer in me is in a corner sucking his thumb, quickly rocking back and fourth.

Lisp is definitely an experience unto itself. :) I would strongly suggest "Successful Lisp", it's online at http://psg.com/~dlamkins/sl/contents.html . It gets you through some of the rough spots early on. Also look at cliki and Lisp commons for some actual live code to wade through. I've got CLTLv2, the HyperSpec, and the SBCL/CMUCL docs bookmarked for easy access. The easy part is figuring out what you want to do, the hard part is learning where to find the answer. comp.lang.lisp (a.k.a. c.l.l) is invaluable too.

Lisp does have both pointers and callbacks, but the pointers are more like Java's references than C's raw memory access. However, you *can* get to raw memory by using FFI. An example of FFI is here:

----snip---- ;; Debian: /usr/include/asm/posix_types.h
(uffi:def-foreign-type gid-t :unsigned-short)

(uffi:def-struct
group
(gr-name (* :unsigned-char))
(gr-passwd (* :unsigned-char))
(gid gid-t)
(gr-mem (* (* :unsigned-char))))

(uffi:def-function
("getgrgid" c-getgrgid)
((gid gid-t)) :returning (* group))

(defun get-group-name (gid)
"Returns the name of a group given its GID from the operating system. See getgrgid(3)."
(declare (type integer gid))
#+:SBCL
(declare (sb-ext:muffle-conditions sb-ext:compiler-note))
(let ((x (c-getgrgid gid)))
(if (uffi:null-pointer-p x)
(error "Invalid group ID")
(uffi:convert-from-foreign-string (uffi:get-slot-value x 'group 'gr-name)))))
----snip----

This bit defines get-group-name that takes a gid and calls getgrgid() to return the actual name. In my REPL I can call it like so:

CL-USER> (get-group-name 12)
"man"
CL-USER>

As for types, Lisp actually has strong typing (everything *is* typed) but weak checking. If you want to absolutely ensure that a parameter to a function is a given type, you can use "the" as in (the integer x) . If x is not an integer, a TYPE-ERROR will be thrown. When you define slots on objects, you can also specify the type then. Finally, you can use (declare (type integer foo bar)) to hint to the compiler that foo and bar will be integers. The declare goes right after the docstring on a defun or after the variables list in a let form.

I mean, LISP performance screams for raw text processing, but it's like BASIC, in that I can't form a great mental image of encapsulated code. Although you mention subclassing in LISP, this isn't in common LISP, is it?

Subclassing is actually in common Lisp, but some Lisp's can't do it (namely Emacs and GNU Common Lisp (gcl)). Classes are done through CLOS, and behave a lot like Perl classes in that nothing is really private/protected (slot-value can *always* get the value), but also a bit like C++ in that multiple inheritance is easy. The only wrinkle is that Lisp classes do not have member functions,

I've noticed that some people don't like Tcl as a language, but can't personally understand why. Tcl seems to be a favorite of a lot of well experienced people who can make it stand up and sing.

I used to think that Tcl-aversion was due to extreme syntactic simplicity, but now I think the simplicity is deceptive, and Tcl is just too hard for some programmers: you need a deep stack to write Tcl well.

same song (same verse even) ... read the full thread over on NANOG; especially interesting is Randy Bush's followup, featuring some slides (specifically, slide 20) he presented recently that basically say "yeah, there's a problem; no, the sky is not falling; none of the forced-cutover plans thus far presented have fully taken into account operational and business issues. Careful thought and deliberate action (rather than panic and haste) are needed here to avoid creating problems we'll be living with for the next 30 years." (Apologies if Randy thinks I'm paraphrasing him incorrectly; I doubt he spends much time reading /. though. :))

You add an encrypted header to all outgoing emails which says "Yes, this email came from this server." Then, when you receive a bounce message, you check for the key. If it has it and its correct, it gets through, and if it doesn't, it gets rejected. This stops ALL normal bounces that result from spammers, and the only thing you do get are auto-responders which aren't actual bounces.

Here's the Exim howto http://psg.com/~brian/software/authbounce/configur e-authbounce.txt

I'm working on a sender stores system for a distributed social networking software called Appleseed based, in theory, on Internet Mail 2000. I figured early on that since the system was distributed, which means that anybody could set up an Appleseed social networking "node", that it would suffer from the same problems as any mail system if I used the standard reciever-stores system.

I don't harbor any illusions about a sender stores system being able to eliminate spam entirely, but the reason I went with it, especially after reading this indepth critique, was that it created a system of accountability. You may not be able to stop spam, but you have much better tools for knowing exactly where the spam came from.

The disadvantage is that it becomes, ideologically anyways, incompatible with current email systems. I consider this a small price to pay to allow admins to have better control and protection over their systems.

The system I'm building is rudimentary for now, and only uses direct HTTP->HTTP connections to send notifications and retrieve messages, and won't have any of the fancy abilities that email has right now, but it's a start, and there's no reason that those features can't be added as it evolves. It's gonna be a big experiment, and I'm expecting a whole lot of unforseen issues, but this whole project is a big experiment, so I'm excited about the possibilities in general.

Is "bounce keys". Essentially, you sign every email leaving your server, and if a bounce doesn't return with a valid signature, you don't accept it. My domains have been used by spammers (I guess I got on their nerves, heh), and this stops about 99% of the bounces.

https://rip.psg.com/~randy/index1.html

http://psg.com/~brian/software/authbounce/configur e-authbounce.txt

This mishap wasn't so bad really, but somehow managed to get a lot more public attention than I cared for.

i bought the cabinet, and built the insides. the monitor board and monitor were included, but it didn't have any joysticks, buttons, or coin acceptor.

i put a pc in, bought a j-pac from http://www.ultimarc.com/ and loaded up my mame dvds. it was done in a day, but i still had an amazing feeling of accomplishment.

http://psg.com/~jjohnson/arcade.html

Naturally it was used for many things.

Basically, you add an encrypted header to all outgoing emails which says "Yes, this email came from this server." Then, when you receive a bounce message, you check for the key. If it has it, it gets through, and if it doesn't, it gets rejected.

Here's the Exim howto http://psg.com/~brian/software/authbounce/configur e-authbounce.txt

Yeah. But it isn't cooler then Randy Bush

As for online resources, a good place to start is probably the cliki, a CL-related WikiWeb with emphasis on free software.

There are some free online books, like Successful Lisp, Loving Lisp - the Savy Programmers Secret Weapon, or Paul Grahams On Lisp (which isn't really a beginners book, but very enlightening once you are familiar with the basics). The Common Lisp Cookbook is not as big as it should be, but does contain useful information, and is growing.

An absolutely invaluable reference is the HyperSpec, a heavily hyperlinked online version of the standard. You definitely need that.

You might also want to check out the comp.lang.lisp newsgroup, or the #lisp channel at freenode. Depending on your specific interests, the LispWeb or Clump mailing lists may be interesting, the first deals with web programming using Lisp (surprise!), the second with general application developers issues.

Last but not least, there has been a movement of Lispniks gathering to drink beer and talk about all things Lisp (and everything else) in the last months. Check out this site, maybe there's a user group in your area. The people I've met so far are generally a nice and interesting bunch, and won't bite you even if you don't know the argument lisp of update-instance-for-redefined-class from the top of your head.

Happy hacking!

paradigm C C++ Perl Python Lisp

procedural yes yes yes yes yes
object-oriented no partly mostly* yes partly
event-oriented no ? yes yes no
list-oriented no no yes yes yes
functional no no yes ? yes
logical no no no* ? no


Why do you say lisp is "partly" object oriented? It has one of the more flexible and complete object systems around (clos)

[...]

BTW, Lisp isn't even a VHLL, just a regular third-generation HLL, and older than Cowboy Neal's grandfather, but I threw it in just to show how C suffers from comparison with even half-decent languages, if you compare it on the basis of something other than raw speed. Which brings me to my next point...

IF you mean lisp 1.5 (end of the 50s) then you _might_ be right. But modern Common Lisp is a completely different beast altogether! It is the most HLL i've seen so far. It is in fact the most flexible language I've used.

There is a nice book online that includes an overview of the CLOS object system.

CLISP is a fairly well-established implementation but due to some reason I cannot fathom, the implementors choose not to be fully ANSI-compliant. You won't notice it at first, but if you get into advanced object-system hacking CLISP will become unsuitable. Also, it's a byte-code interpreter system. This severely affects performance (except in bignums, due to some numerical methods magic), but it does have a smaller memory footprint. And it's widely ported.

CMUCL does purport to be a complete ANSI-conforming implementation, and it has a high-performance native-code compiler. But it's not ported very much (some ports have gone unmaintained) and only to Unixy systems. The current maintainers are interested mostly in features and speed, whereas...

SBCL is a fork of CMUCL, with the goal of being more easily maintained, cleaner, and conforming. It's also more widely ported now, having resurrected some of the old CMUCL ports and added some new ones (someone is working on OS X now). SBCL has been adding features back that were dropped, sometimes improving, for example, kernel-threads recently (vs user-threads in CMUCL).

Lately they've been driving the development of each other, since many patches can be cross-ported easily. This is all the better for the users :-).

I use CMUCL for most of my work, which involves database-driven web-app development, and it works fine. Though I am thinking about switching to SBCL soon, with nice features like kernel-threads coming around. Well, presumably I would be able to use either. I use libraries like AllegroServe (HTTP server), UncommonSQL (RDBMS OO interface), and IMHO (web apps w/Apache).

Neither work on Windows (yet) so there you would need to look into Allegro, LispWorks, or Corman Lisp (which I forgot to list in the previous post). All these are native compilers that can produce Windows applications. There are no free compilers for Windows which produce native code, afaik. You can investigate GCL or ECLS, which compile to C and may work under mingw. The commercial compilers all have GUI toolkits or bindings to the Windows API. Allegro is probably out of your price range, LispWorks is ~$900 and Corman is ~$150. All have free personal editions to play with.

Why do I say Scheme isn't as practical? Well, most Scheme implementations aren't anywhere near the same quality as the CL ones (with a few notable exceptions) and they all have to implement incompatible supersets of the language (because R5RS defines approximately nothing). Personally I think the design of Scheme itself works against practical usage and implementation, but there are those who disagree. In universities they teach Scheme, but as I was saying, as an academic exercise and not something to be used in industry. Which is a real shame.

Anyway, if you want a learning environment, I recommend the LispWorks personal edition IDE (Linux, Windows, Unix, and soon OS X). This will get you started with a minimum of fuss. Later on, you can setup Emacs with the ILISP package and interface with your CL implementation; this is a popular way. Or you may find some other IDE. The minimum needed really is parenthesis-matching and auto-indentation. After that you might like interactive features such as shortcuts to compile code-fragments, documentation at a keystroke, easy access to a Lisp listener, inspector, debugger, etc.

There are many books, such as Paul Graham's ANSI Common Lisp, Peter Norvig's Paradigms of AI Programming, online tutorial Successful Lisp, and sites such as CLiki with lots of pointers to resources.

CMUCL
SBCL
LispWorks
Corman Lisp

agreed. i just finished mine yesterday, and its a 2d gaming heaven.

have a look

you won't regret building one, even if you spend $2k on it like i did. arcade-infinity.com has some pretty cheap cabinets like mine for $500 or less, depending on what you're looking for.

• Successful Lisp
• Common Lisp Hyperspec(ANSI Standard Text on CL)
• Common Lisp The Language
• Common Lisp: A Gentle Introduction to Symbolic Computation
• On Lisp(great book on lisp macros among other things)

Here are some, and some more, and a few others.

You're right, C and C++ are awful languages. C has carved out a niche for itself as a "higher-level" assembly language. C++, on the other hand, I just cannot see very much reason for. It is a language shoehorned into the retrictive C syntax that was designed (or not designed, really) for systems programming, and to work around the flaws they had to implement all sorts of nasty things. It forces you to worry about memory management, which defeats the point of a higher-level language (which lets you reason about the logical structure of your program rather than the nitty gritty).

What I'd like to say about CSS is that it's headed in the opposite direction from just about every other language out there. You see languages like Python and Ruby, slowly they are approaching the abilities of LISP, moving away from Fortran and Algol. CSS seems to me to be a step backwards, and will probably flop as a result. (But then again, look at the popularity of Perl. I guess there's a lot of masochists out there).

I think I should point out that while Python and Ruby approach LISP, they won't ever be LISP. The critical difference is in the representation of the programs. LISP programs are data. Some have said that if you removed all the parentheses from a properly tabbed LISP program, it would resemble a Python program. This is true, to an extent (never mind the lexical scoping rules and such), but the parentheses are not there just for show. LISP programs are data, and the parentheses give structure to that data at a higher level than ASCII characters: symbols and lists. And you can manipulate that structure with ordinary data-operations. Not to mention, LISP has had native-code compilers for 40 years, so it's better than just a scripting language. (see Successful LISP for further elaboration on these topics)

Which brings me back to your first point: the C preprocessor. I'm sorry to disillusion you, but the C preprocessor is a pitiful thing compared to the LISP macro facility. And it doesn't take too much extrapolation to figure out why.

It's hard to see the point of a scripting language that lacks so much compared to something like Python or Ruby, or even LISP.

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.

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.

The thing that the Internet provides is the potential for new, "more direct" ways to sell things.

For instance, if I had a book ready to sell, I could set up an "auction" at EBay, or some such thing, set up an account on PayPal to accept payment, and thereby be fairly readily able to sell 50 copies of something that I might get printed by a "vanity press."

The fact of this making it easier to get access to "obscure titles" means that while there are doubtless losses to people simply "publishing on the 'net," there can be gains where things that would never otherwise have any market can attain one.

The author of Successful Lisp: How to Understand and Use Common Lisp apparently did not succeed at getting a "dead trees" publisher; it would surprise me not at all if he could get a couple hundred copies (of something of a more complete edition of the material) sold out of using a "vanity press." For $30, I'd almost certainly buy a copy, if only to encourage there to be continuance of such literature.

You might also want to add to that list: Paradigms of Artificial Intelligence Programming / Case Studies in Common Lisp. Also by Peter Norvig. A very well written introductory book in both AI and Lisp. (Even if your a hard-core C coder, some experience with a wholly different language like Lisp will be very good for your overall programming skills.)

Object-Oriented Common Lisp, Stephen Slade, Prentice Hall

I started with this book too and while it is an excellent reference book I didn't like it much to learn Lisp from. I'd advise using the book by Norvig I mentioned above or ANSI Common Lisp by Paul Graham (the man who wrote store.yahoo.com in Lisp and then sold it to Yahoo for $48 million) if you're interested in learning Lisp. There's also a nice on-line book by David B. Lamkins: Succesful Lisp

(LISP is the language of symbolic programming, and though I'd rather do my stuff in C*, it does cater to AI programming.)

I'd prefer to do my stuff in Lisp ;-) Just to help a common myth out of the world: Lisp is not just an AI language. It is a general purpose language useful for pretty much anything.

While your healhty dose of realism is certainly appreciated others have already shown that Apache is not just used on "I love my dog"-sites, but also on high-traffic e-commerce (fah!) sites like Amazon. And while your attempt at associating Apache with the porn-industry as something bad is funny, you should not forget that those sites probably get more traffic than your average small or medium business IIS user.

• The real-world, usable, easy to set up, high transaction internet infrastructure of tommorrow is being built by Microsoft

Please! I am not an experienced NT user, but that's no problem since that is exactly what my point is about: Coming from a Unix background I found the IIS interface extremely confusing (compared to a straightforward and well commented Apache config file) and the management console less than stable. I glad I convinced one of my clients to switch to a more sensible solution for a site I have to maintain remotely.

Ah! Netcraft finally knows what this site is running. Very cool. (Yes, I'm a lisp bigot.)

I'm by no means a Lisp expert (I have more experience hacking C and Perl), but the more Lisp code I write, the more I begin to appreciate the language. I started learning Lisp when I started using EMACS, then for a while I was hacking in Scheme (the Programming Language Concepts class at my alma mater was taught by a fellow who received his degree from Indiana University), and now I am doing a lot of programming (in my Copious Free Time) in Common Lisp - and I must say that of the three, I like Common Lisp the best.

Here's a short list of the things *I* like in Lisp (whither EMACS Lisp, Common Lisp, Scheme, Dylan, etc.):

• automatic memory management (aka "garbage collection")
• several excellent compilers available (ask about the difference between "interactive" and "interpreted" some time - those words are NOT synonyms)
• bignums and symbols
• CLOS (lots better than e.g. C++ or even Java, in my opinion), which has generic functions, multiple inheritance, CHANGE-CLASS, etc.
• continuations (only in Scheme, I think)
• "code as data and data as code"
• the macro facility

...and so forth. You can get a lot more information from the Association of Lisp Users web site (especially the pages Language Comparisons and What is Lisp?), or from the comp.lang.lisp FAQ. Another good place to get more information is from David Lamkins' on-line book Successful Lisp.

And if you have further questions on Lisp, feel free to send me an email or drop a note into comp.lang.lisp.

HTH.

CL has several advantages over both Perl/Python and C/C++.

• Like Perl and Python, Lisp provides an interactive environment. You can make changes to a running program without having to restart it. Plus, modern Lisps give you a real garbage collector, not a simple reference counter like in Python (although newer versions of Python may have a better GC).

• Like C/C++, Common Lisp is compiled. Unlike C/C++, CL allows you to call the compiler interactively---again, you never have to restart your program. Compiled Lisp code is about as fast as comparable C or C++ code. In fact, most interactive environments compile code on the fly as you type expressions in!

• Like Python and C++, Common Lisp also provides a robust and rich object system, called CLOS. I haven't done much with CLOS, although I like the idea of multiple inheritance and the ability to dispatch methods based on more than one object (Lisp methods and generic functions can dispatch on any of their arguments).

• Unlike C and Perl, Lisp is pretty clean, syntacticly. You never have to remember operator precedence or any of the funky variable naming rules. Lisp is case insensitive, although it is pretty easy to override this.

Several Lisp environments are available, both commercial (Franz, Harlequin) and free (CMU Common Lisp). There's a complete web server written in Lisp, the Common Lisp Hypermedia Server. If you want to learn more about Lisp, check out the Associate of Lisp Users and browse through the section on tutorials and books (a good book, by David Lamkins, is called Successful Lisp).

Not all is happy in Lisp-land, though. There's no archive network like CPAN or CTAN, so you'll have to go digging when you want a regexp package (although I can tell you to look at SCSH for that). While commercial Lisp environments from Franz and Harlequin are available on Windows, the only free Lisp I know of that has been ported to windows is Clisp, which "only" has a byte-compiler (like EMACS). CMU CL, the best free Lisp around, only runs under UNIX. I also don't know of an equivalent to mod_perl that embeds Lisp in Apache, although if you use CL-HTTP this isn't an issue. Still, Lisp may deserve your attention. As old as the language is, Lisp is still years ahead of its time.

You ask the wrong questions. Lisp is not used to solve common problems, people gravitate towards Lisp because their problems cannot be solved by the 'common' languages.

Anyway, take a look at:

• www.franz.com (the "applications" link)
• Lisp on the Deep Space 1 spacecraft
• Why Lisp?
• Lisp 'portal'

You should try writing code in it (I'd personally recommend Lisp, but that's just me). There is a free compiler available for Eiffel. I don't have an URL handy for you but if you just head over to Google you'll no doubt find one.

But what I REALLY wanted to say is: Eifel and any other programing language won't change the problem we got with software quality A BIT! "A fool with a tool is still a fool" (don't remenber who said this one) and someone who doens't care to make good code under C won't care to make good code under Eifel.

It's not a silver bullet, but it is certainly easier to write good code in less time in about any language other than Intercal, Brainfuck, C and C++ for a non-fool.