LispM Source Released Under 'BSD Like' License

mschaef writes "Announced on Bill Clementson's Blog, Brad Parker has stated that he has 'permission from MIT to release all the LISPM source code with a "BSD like" source license.'" Zach Beane has also set up a torrent for easy download.

Comments

BSD like license?

[Anonymous Coward]

Is that anything like a death certificate?

Re:BSD like license?

[bombadier_beetle]

Aw, c'mon, somebody mod that up. That's the first thing I've laughed out loud at here in weeks.

Re:BSD like license?

[uberchicken]

Sure, that's the "Blue Screen of Death" license.

Re:BSD like license?

[ninejaguar]

My wife wondered at my guffaw when that quip caught me by surprise. I then made the sad mistake of trying to explain why a particular joke about software licensing was so funny...I was soon given a sympathetic smile and shown the hand as she quickly walked away saying it was more than she needed to know...sigh. I think my cat's a nerd and would've enjoyed it, but I don't speak cat.

= 9J =

Lisp?

[cdn2k1]

Does that mean we have to pronounce it as

Bee - Ethh - Dee?

Re:Lisp?

[Anonymous Coward]

Lithp huh?

Nith job on the firtht potht!

Re:Lisp?

[tntguy]

Yeth.

As Einstein once said...

[Anonymous Coward]

"Imagination is more important than knowledge..."

Re:As Einstein once said...

[IntelliTubbie]

"Imagination is more important than knowledge..."

For some reason, this quote always reminds me of rich people who say that there's more to life than money. It's much easier to say when you've got it in spades.

Cheers,
IT

Re:As Einstein once said...

[Anonymous Coward]

As Einstein once said, "Everything that I've said is inerrant and insightful."

Let's be orderly now

[Minwee]

Okay, you know the drill. A new story has been released and you're all aching to comment on it without reading the article, so let's get going.

All "What is LISPM?" comments over on the right.

"This proves BSD is dying" comments on the left.

Wordplay that desperately wants to be clever, like "I guess that makes it a 'Bee Eth Dee Licenth'" comments go there by the door.

If you have read the article, know the history of Brad Parker, LISPM and their involvement in the Church of the Flying Spaghetti Monster, and have something intelligent to say, then we don't want your kind around here. Slashdot has standards to maintain, you know.

Re:Let's be orderly now

[cdn2k1]

Wordplay that desperately wants to be clever, like "I guess that makes it a 'Bee Eth Dee Licenth'" comments go there by the door.

Looks like you liked my earlier post.

If you have read the article, know the history of Brad Parker, LISPM and their involvement in the Church of the Flying Spaghetti Monster, and have something intelligent to say, then we don't want your kind around here.

I don't see what religion has to do with this.

Re:Let's be orderly now

[Anonymous Coward]

But who is Bill Clementson ?

* let the bashin' begin *

Re:Let's be orderly now

[Anonymous Coward]

Thith ith preffostheruth! I had thomething to thay. I bet ith this were perl or pythhhon, you wouldn't be making thun of them.

Bathtardths!

Re: Let's be orderly now

[Narcoleptic Electron]

All meta-comments that desperately want to be clever, not including this one, can go up above this post as a parent.

All meta-meta-comments that desperately want to be clever, not including this one, can file in an orderly fashion below this post as responses.

All other meta-comments can go right here.

(I guess it makes sense that in a LISP thread, posts are first-class entities.)

cdr cdr car?

[Anonymous Coward]

Lots of Insignificant Stupid Paranethesis (LISP), yea...

Re:cdr cdr car?

[RAMMS EIN]

Yeah! This clearly shows that C is superior! At least in C you have superfluous parentheses, semicolons, commas, ...

Re:cdr cdr car?

[__aamcgs2220]

That's not it, you insensitive clod! It's Lethargic, Impractical Soiree Prognosticator Malfeasance. Duh!

Re:cdr cdr car?

[be-fan]

Here here! I find it incredible to see that C/Java people bitch about "superflous" punctuation. Compare this:

(defun square (x) (* x x))    ; 6 punctuation marks

To C:

double square(double x) {return x * x;}    // 5 punctuation marks

To C++:

template <typename T>
T square(T x) {return x * x;}    // 7 punctuation marks

To Java:

public class Square
{
    public double operate(double x) {return x * x;}
};        // 7 punctuation marks

Compare this:

(if (something)           ; 8 punctuation marks
    (do-this)
    (do-that))

To C/C++/Java:

if(something())            // 10 punctuation marks (11 if you count the 'else')
    do_this();
else
    do_that();

Compare this:

(do-something to-this with-that in-there)       ; 2 punctuation marks

To C/C++/Java:

do_something(to-this, with-that, in-there)      // 4 punctuation marks

The only reason it seems like there are so many parentheses in Lisp is because of LET and because Lisp uses just a single type of punctuation while C/C++/Java use all sorts of different punctuation. With a good editor, the parentheses don't even matter, all you see is the indented structure!

Re:cdr cdr car?

[Anonymous Coward]

That's all well and fine, but let's look at a more common example:

Common Lisp: 12 punctuation marks

(tagbody
    10 (print "hello")
    20 (print "world")
    30 (go 10))

BASIC: 4 punctuation marks

10 PRINT "hello"
20 PRINT "world"
30 GOTO 10

C: 24 punctuation marks, but you don't even have real line numbers

#include
main() {
        ten: printf("hello\n");
        twenty: printf("world\n");
        thirty: goto ten;
}

Java: 22 punctuation marks, but you don't even have GOTO!

public class HelloWorld {
        public static void main(String args[]) {
                System.out.println("hello");
                System.out.println("world"); // crap!
        }
}

Re:cdr cdr car?

[lgw]

With a good editor, the parentheses don't even matter, all you see is the indented structure!

Which, of course, is why Python dispensed with the parentheses and kept just the indented structure. IMO, that was one of the very few genuinely new ideas in computer languages in the past 30 years - the realization that the punctuation that was only there for the computer, not for the human, could be dispensed with entirely.

Re:cdr cdr car?

[kpansky]

The issue is not the raw number per-se. The crux of the problem is the way in which you have many of the same punctuations bunched up in one place. Lisp is exceptionally bad with everything being a parend. C/C++/Java has its problems when you do lots of embedded control statements and {}. C/C++/Java mixes it up a bit which makes things easier on the eye.

Re:cdr cdr car?

[be-fan]

The problem with the Python mechanism is that it makes macros quite a bit trickier to implement.

Re:cdr cdr car?

[be-fan]

So you're saying that the problem isn't too many parentheses, but that the parentheses are hard to distinguish? First, that's an awfully subjective argument. I find { and } and ; to be much harder on the eyes than ( and ). They stand out too much compared the actual code. Which leads to my second point: the parentheses aren't supposed to be easy to distinguish. You're not supposed to pay attention to them. It's a skill, but no more so, for example, than learning to not voice the words in your head when reading. The editor is supposed to take care of the parentheses. For example, say I have:

(defun wumpus (x)
    (let ((foo 1)
                (bar 2)
                (baz 3))
        (when (+ foo bar baz)
            (let ((temp (do-something foo bar baz)))
                (when (> temp 0)
                    (do-something-else temp...

What's the proper termination for that fragment? It's '))))))'. How many parentheses is that? What closes what? Who cares! No Lisp programmer actually looks and counts to see if they have 6 parentheses. A Lisp programmer simply tapes SHIFT-0 until the paren to the left of the 'defun' lights up. What happens when he needs to insert something after the "when" clause? Does he look through the '))))))' at the end and try to figure out where to insert the cursor? No! He uses an editor hotkey to place the cursor for him. It takes a bit of practice to get the hang of it, but there is a benefit. Since the parens demark the bounderies of each fragment, the editor is fully capable of moving the cursor around the AST. One of the benefits is that Lisp programmers don't have to use the arrow keys to move between expressions. They simply use the hotkeys for "next sibling expression" or "parent expression". Say I'm deep in a nested IF statement, and want to edit the predicate. In C, I'd arrow up and over until I get to the predicate clause. in Lisp, I'd tap the "parent expression" a couple of times, then "next child" once. Since the editor highlights what is currently selected, this process can be extremely efficient, since it basically becomes a hand-eye exercise.

Re:cdr cdr car?

[sickofthisshit]

Shift-0? What kind of stone age are you living in, man?

Remap your keyboard so the parentheses replace the (mostly useless?) square brackets.

Kind of like http://www.asl.dsl.pipex.com/symbolics/photos/IO/.

Re:cdr cdr car?

[be-fan]

LOL. I'm too dumb to remap keys in X :-/ Also, I need a keyboard with #' and ,@ keys :)

Re:cdr cdr car?

[thakadu]

You may be interested to know that Python was not the first to do this. The language OCCAM did the same thing and it too may not have been the first.

Re:cdr cdr car?

[sickofthisshit]

You want to learn about xmodmap

First, do xmodmap -pke

That will print out the current keymap you have.

Then, you want to find lines like

keycode 45 = 9 parenleft
keycode 46 = 0 parenright
keycode 71 = bracketleft braceleft
keycode 72 = bracketright braceright

(the lines show unshifted shifted)

Then, you want to create a file (call it .xmodmap) which has lines like

keycode 45 = 9 braceleft
keycode 46 = 0 braceright
keycode 71 = parenleft bracketleft
keycode 72 = parenright bracketright

Then, in a suitable init file (such as .xinitrc) you want to put a command

xmodmap $HOME/.xmodmap

to load it when you start up or just type it from the command line to try it out: You can do it one line at a time by using the syntax

xmodmap -e "keycode 72 = parenright bracketright"

Note: the alternative keysym syntax is a briar patch: it allows you to make all the keys which emit left brackets to now emit left parentheses, but then it doesn't offer you a way to change only the ORIGINAL left parenthesis key to emit a left bracket. Perhaps your xmodmap has a swap syntax, but my clunky Solaris environment does not. The keycodes are unfortunately not guaranteed to be portable, but hey, how many machines will you need to customize?

Re:cdr cdr car?

[be-fan]

The moral of this post? We should all be programming in BASIC!

Re:cdr cdr car?

[Raffaello]

That's all well and fine, but let's look at a more common example:

Common Lisp: 12 punctuation marks

(tagbody
        10 (print "hello")
        20 (print "world")
        30 (go 10))

This is a "common" example only in the sense of "lowest common denominator" - congratulations, you've succeeded in reducing the power of lisp to the lameness of BASIC. In real life, lisp programmers do not write code with numbered tags a-la numbered source lines in BASIC.

Your infinite loop would be rendered in common lisp as:

(loop (print "hello") (print "world"))

or even

(loop (print "hello
world"))

since newlines are allowed in literal strings.

But really, one probably doesn't want the quotes in the output, so you'd really see:

(loop (format t "hello~%world~%"))

But this is still more punctuation marks than BASIC, thus proving that when trying to accomplish something so simple even a severely retarded chimpanzee would not be challenged by the task, BASIC requires fewer punctuation marks than lisp, c, or java. Unfortunately, when the task is quite complex BASIC isn't up to the job at all, no matter how many (or few) punctuation marks you use.

Re:cdr cdr car?

[LarsWestergren]

To Java:

public class Square
{
        public double operate(double x) {return x * x;}
}; // 7 punctuation marks

Minor nitpick - the final semicolon, while allowed, is surpurfluous and against the Java Programming Style guidelines.

Re:cdr cdr car?

[JollyFinn]

The guy was obviosly joking.
Look at what he says about the Java there.
Besides he wrote EVERYTHING in a way that slashdotters wouldn't do.

Re:cdr cdr car?

[Anonymous Coward]

The problem with Lisp is precisely what you've demonstrated, the use of a single punctuation pair to represent the entire structure of the program means that for linear thinking the clarity of where a particular statement ends is lost, because the ))))) is not at all clear which scope it's enclosing, whereas a well indented program in any mainstream language (Which Lisp is clearly not, nor has it been since C++ came alone, realistically speaking). Even today the whole point is fairly moot, when I do C++ programming my Visual Studio setup will close brackets, blocks and even insert the odd comma for me.

Even the best lisp programmers just cant get the code out as fast as a good C++ programmer, and the whole of lisp could be encapsulated into a C++ library and hidden away to play with if some deviant actually wants it. Theres a reason most lisp environments and lisp runtime engines are written in C++ and not in the lisp in question.

Think about it, jesus

Re:cdr cdr car?

[eff]

OCCAM isn't that much older than Python (which borrowed the idea from ABC). Pythoneers like to point to a Knuth quotation from 1974:

"We will perhaps eventually be writing only small modules which are identified by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language."

(but they sometimes miss the "only small parts" and "expressing local structure" parts when they do that...)

Re:cdr cdr car?

[sickofthisshit]

You're obviously a troll, but the claim that C++ programmers "get the code out" faster than Lisp programmers is a huge laugh.

How long do you wait for a re-compile when you've modified a header in your program? Most Lisp implementations compile as fast as you can type control-x control-e into your Emacs.

Linear thinking, by the way, reads from the beginning (where things like "defun" and "let" and "loop" let you know what is going on, and the automatic indentation shows you the organization), and by the time you've read the last non-parenthesis item, you understand it all, and the final group of parenthesis is not needed any more.

You seem to read your code from the bottom of the screen going up. That could explain why you have trouble understanding Lisp programs. Try turning your monitor right-side up, and see if that helps.

Re:cdr cdr car?

[be-fan]

1) The parens aren't clear because its the editor that handles the parens, not the programmer.

2) Linear thinking is mildly retarded when all lexically-scoped languages are tree-structured.

3) I'd really like to see you try.

4) What?

Re:cdr cdr car?

[Anonymous Coward]

I'd say "YHBT", but anything that makes it to +3,Funny isn't nearly subtle enough to be a true troll...

Re:This is News?

[Gordonjcp]

The permissioned release of 25 year old code is /. news now? This code is worthless IMO

Just like your opinion. Now get back to work, those burgers won't flip themselves!

Argh!

[Brent Spiner]

I don't know, does anyone still program in LISP (I'm sure some people do (personally I could never get used to its syntax (although I never really tried that hard (I did use it with Autocad (one of the really old DOS versions) for a while))))?

Re:Argh!

[Just Some Guy]

I don't know, does anyone still program in LISP

Naughty Dog used a variant to write "Jak and Daxter", an extremely popular game for Playstation 2. Many more people use spiritual descendents like Python.

Re:Argh!

[KarrottoP]

I do, sort of. I use AutoLISP alot, the command line interface in autocad is heavily incorporated with LISP. It may not be extremely featured, or friendly, but it was my introduction into programing and I still use it today. The libraries are available in Linux, I chuckle every time I see the binaries in debian, so I am sure somebody has programmed something for linux with it recently.

Re:Argh!

[DeafByBeheading]

Does this count? Or this? Lisp is a very powerful language. Paren matching is rendered trivial with any decent editor. The syntax is actually quite nice and clean once you get used to it. I wouldn't use it for everything, and it does have some core ugliness (hey, so does C++), but it has an undeservedly bad reputation.

Re:Argh!

[adavies42]

Speaking of games, Abuse (SDL Port, Bungie version) was apparently written mostly in LISP.

Re:Argh!

[MyDixieWrecked]

...does anyone still program in LISP...

According to the O'Reilly book on Applescript, Applescript behaves very LISP-like.

having never actually programmed in LISP, I can't comment on it beyond that, but LISP has intrigued me and I've considered learning it. or at least dabbling.

Re:Argh!

[Anonymous Coward]

I don't know, but does anybody still program in Algol dialects like C or Java? That is soooo 60s.

What, Java has garbage collection? You mean that feature that they took from Lisp which had it for decades already? And they still haven't gotten exceptions right, nor OO?

By the way, Autolisp and Emacs Lisp are old dialects (as is the Lisp machine stuff, I'm afraid, but the system was decades ahead of its time, meaning it runs circles around current Java IDEs). Get the real thing, Common Lisp.

Re:Argh!

[Anonymous Coward]

Lisp is mainly for hobbyists. It's not used much in the real world. Sort of like BSD.

Re:Argh!

[Stephen Chadfield]

I don't know, does anyone still program in LISP

Skill, the programming language that drives Cadence's DF2 IC Design CAD suite combines LISP and C like syntaxes in a mind boggling way. I infuriate my colleages by converting all the code I find into LISP style before performing any maintenance.

As far as I am aware Vim is the only editor which provides out-of-box syntax highlighting support for both styles of Skill syntax.

Re:Argh!

[Peter S. Housel]

Lots of people are using Lisp to write programs under Linux/FreeBSD/Mac OS/etc. these days. CLiki is a collection of free/open-source Lisp implementations and programs. A lot of them are hosted at common-lisp.net . The Association of Lisp Users hosts conferences and serves as a center for language advocacy.

Re:Argh!

[be-fan]

A surprising number of people, actually. Of the 230 million LOC in Debian, 3% (or 7 million) are written in Lisp. This puts it fourth, right after C, C++, and shell, and ahead of Perl, Python, Java, etc. With then number of people who hang out on comp.lang.lisp, you'd never know it was dead :)

Re:Argh!

[bani]

Python is a spiritual descendant of LISP? Python is more like the spiritual antithesis of LISP. Guido hates LISP.

Re:Argh!

[Bastian]

Methinks a lot of folks would argue that Python isn't a spiritual descendant so much as a wannabe. My understanding (I haven't programmed in Python much) is that it lacks a lot of the features that make lisp So. Damn. Cool., such as macros, and its closures are broken in the eyes of a lot of lispers. To me, the real kicker is that there is still a strong division between data and code in Python.

Re:Argh!

[RAMMS EIN]

It's funny how your post is actually a really nice illustration of what Lisp syntax is like: lots of parentheses, but actually very legible. And that's even without indentation!

Re:Argh!

[Just Some Guy]

My understanding (I haven't programmed in Python much) is that it lacks a lot of the features that make lisp So. Damn. Cool.

However, it does have a lot of the features that many of us liked about Lisp, but in an easier-to-use package (in the opinion of some). Example: trivially ease introspection and metaprogramming. Functions as first-class objects. Native, fast list operations. Elegance.

Maybe "spiritual descendents" was too strong; "strongly influenced by it" might have been better.

Re:Argh!

[bani]

if they would get rid of the parenthesis hell, a lot more people would be receptive to lisp.

you shouldn't need an editor to assist you with the syntax hell of a language. paren hell also makes restructuring code ... hell :)

Re:Argh!

[sickofthisshit]

However, [Python] does have a lot of the features that many of us liked about Lisp,

The comparison is a bit complicated.

From the starting point of, say, C++, Python has a lot of the same kind of appeal that Common Lisp does, and for many of the same reasons. In philosophy, however, the Pythonistas and the Lispniks seem to have much to disagree about.

For instance, it seems (from the noises I hear over in Lisp forums), that Guido actively works to eliminate Lisp-isms in favor of his own "clearer" syntax. Whereas the Common Lisp folks tend to keep stuff around *forever*, and if someone invents a clearer replacement, they migrate to it, but nobody cares much that the old stuff is left behind. However, Schemers like the "one elegant way instead of three different ways". Whether you consider Scheme to be a Lisp or not is a great way to start a flame war.

Where this matters most is in Lisp macros. (For the nth time, these have nothing to do with C preprocessor macros, rather, they let you implement language extensions using the full power of the language, and with seamless integration to the original language and other extensions). Lispniks would never give those up. Pythonistas seem to not understand what the big deal about macros is. Schemers don't like macros because it is possible to write buggy macros, and want their own elegant, bulletproof mechanisms to define language extensions. This is yet another great way to start flame wars.

Re:Argh!

[yppiz]

When one says Lisp, they can mean a range of languages, including (most likely) one or both of: Common Lisp, which was designed by committee and has everything including the kitchen sink built in, and Scheme, which is much cleaner and smaller.

Python is more like Scheme and its philosophy than Common Lisp.

--Pat

Re:Argh!

[bani]

python is perl with syntax which doesn't suck.

Re:Argh!

[bani]

Actually, a better analogy would be: Python is perl which doesn't suck.

Perl being what you get when you take C, awk and bourne shell and drop it in a blender.

Re:Argh!

[DrSkwid]

Algol68 had garbage collection, though they called it

"Meekly deproceduring to MOID FORM"

Only some LISP dialects had GC.

The first major language to have it was Visual Basic

Re:Argh!

[exp(pi*sqrt(163))]

It's also false to say that a good text editor fixes parenthesis matching problems. It's easy to get very confused even with help from a good editor. Look at the ML-type languages for how to do functional programming without redundant parentheses (or semicolons, braces and brackets for that matter too).

Re:Argh!

[cojerk]

I used to work in Clips and I heard it was similar to Lisp, but having never worked in Lisp, I don't know to what extent.

Based on the other posts, the syntax looks similar. While the prefix operators were a pain, the language was pretty cool. I'd consider using it again if the need ever arose.

Has anyone heard of Clips? If so, how much different is it from Lisp?

Re:Argh!

[lgw]

Yep, LISP -> Scheme -> Python. A pretty straightforward descent. Scheme removed the annoying complexity-of-use from LISP by discarding its historical baggage (if only that could happen to C++!). Python discarded the requirement that the language be trivial to parse because code looked like data in favor of syntax that favored humans, and added back a type mechanism. I found it interesting that Python was originally much less Scheme-like, with currying not really working and so on, but grew to be more similar over time as Scheme fans migrated.

Re:Argh!

[lgw]

Between Algol, Lisp, and Smalltalk, all the modern core language ideas were present. The last 30+ years of programming language design have added efficiency and better syntax, but I can't think of any new core ideas in that time. Perhaps the idea of running on an emulator on *every* platform counts.

Re:Argh!

[Anonymous Coward]

I do. At work.

Re:Argh!

[RevAaron]

the "paren hell" makes restructuring code a lot easier- not harder- than most other languages. an exception is something like smalltalk, which has a leg up on a lot of other languages as a virtue of the IDE. in lisp, moving some chunk of code out into a new meth of or function, then calling that method/func instead, is pretty easy, and again, with a half-decent editor, it's all taken care of for you.

you don't *need* a paren-matching editor with lisp. you don't with c either. but it's a lot nicer to have in c than not when you're trying to figure out how many }s or )s you need to close. nothing different in lisp; you can dilleniate it with tabbing, etc, just like folks do in c-like languages.

Re:Argh!

[Anonymous Coward]

What about Emacs Lisp?

Re:Argh!

[pnatural]

Pythonistas seem to not understand what the big deal about macros is.

Actually, the python community in general and Guido in particular understand very well what the big deal is. They've looked at macros and said, "yeah, that would be nice, but we don't want to allow the language to be rewritten on a user-by-user basis."

In other words, "readability counts", and that goes out the door with macros. Maybe not for disciplined programmers, but we all know the world is full of the other kind.

Re:Argh!

[sickofthisshit]

Well, I can't argue with your phrasing.

Yet, the Common Lisper's perspective is that the power to reshape the language to suit the problem (not to suit the individual user per se) is such a useful and time-saving innovation that no one should deprive the programmers of it. After all, people can write unreadable code in Fortran or C, but we don't take those languages away.

Crippling everybody because bad programmers would write bad code seems like winning the wrong battle. Which pretty much shows what side of the fence I live on.

To polarize it, "readability" doesn't count for much if we have to stick at the level of Dick-and-Jane. Faulkner and Joyce might be "unreadable" compared to Basic English, but you can't translate it back.

Re:Argh!

[WilliamSChips]

No, that's Ruby. Python is sorta the anti-Perl.

Re:Argh!

[feijai]

It's worthwhile being more clear there: Python does *not* have native, fast list operations. It has native, occasionally fast but more often than not unnecessarily O(n) *array* operations. Lisp's "lists" are singly linked lists. IMHO, Python is far from elegant. Its OO subsystem is a mess, combining the lack of dynamism and simplicity inherent in class-based OO with the slowness of proto-style OO. It's amazing, Python managed to combine the worst features of both approaches to OO. And functions as first-class objects counts for very little indeed if you don't have a clean, consistent, complete approach to closures. Only recently Python got (with an add-on) a complete closure mechanism. Consistent and clean, no. Metaprogramming also doesn't count for much if you don't have macros. I myself think "strongly influenced by Lisp" is too strong. Instead, I'd describe Python as "dumbed-down Lisp". No macros, poor closures, no efficient mechanism for compilation, no continuations, no real numerical tower, no general functions, and a poorly-thought-out (IMHO) OO subsystem. But hey, look, no parentheses! For a language closer to Lisp's beauty (though only a bit thus), see Ruby.

Re:Argh!

[Vindaloo]

Hahahaha. That's such a witty comment. Why don't you make fun of Lisp and parenthesis while you're at it?

Re:Argh!

[Hanji]

The cool thing about the parenthesis notation has nothing to do with function programming -- it's macros. Having code all be in the s-exp form makes it very easy to treat code as both code and manipulable data, making macros possible. That's not to say that you can't have macros with more syntax, but, to the best of my knowledge, no one's figured out how yet.

Re:Argh!

[be-fan]

Um, what? Visual Basic 1.0 dates from 1991. ANSI Common Lisp had already come out by then! Lisp had GC since the 1960s. It might not have been a "major language" by the time VB1 came out, but it was certainly a major language at the time.

Re:Argh!

[Anonymous Coward]

You've said this twice now on this topic. However, I think you mean to say, "Python is perl with syntax that doesn't suck". Your post further up states "Python is perl which doesn't suck." Translated (after adding a required comma): "python is perl and perl doesn't suck." Using "which" instead of "that" can change the meaning of your sentence.

Not that it matters for slashdot, but you wouldn't want to make such a mistake in a grant proposal.

Re:Argh!

[be-fan]

Yeah right. Dylan tried that, look where it got them. People just use parentheses as an excuse to not try a language they're too chicken to try anyway.

Re:Argh!

[feijai]

Not really, any more than any dynamic language is "Lisp-like". AppleScript is a direct descendant of one of the most verbose languages every created: HyperTalk. HyperTalk is *far* from a Lisp-like language.

Re:Argh!

[Peaker]

Python is strongly typed, Perl isn't
Python is polymorphic, Perl isn't
Python has a few concise operators that implement hundreds of possible operations via polymorphism, Perl has hundreds of operators to implement hundreds of possible operations
Python allows named arguments and reflection on those, Perl doesn't
Python has proper exception handling, Perl doesn't
Python has real classes and instances, Perl doesn't
Python has real data structures with no arbitrary restrictions on what they can contain, Perl differentiates "scalars" from other objects, requiring reference hacks to build real data structures, and may actually cause dangling references(!)

I'd say the languages are pretty different.

Re:Argh!

[be-fan]

It's not false. I'm a relative Lisp newbie and it doesn't confuse me. You just need to learn how to use the editor properly. As for the ML type languages, they don't have parens, but they also don't have macros, which is what the parens enable. Compare a kludge like caml4p to Lisp's macros.

Re:Argh!

[Anonymous Coward]

Yep. And 99% of those 7 million lines are Emacs.

Re:Argh!

[masklinn]

Yes, and new dialects of lisp are created these days (check Philip Greenspun's website).

Truth is that people don't use LISP, they'll use Lisp dialects, with more built-in things, and with CLOS (a Lisp Object implementation, to do easier OO in lisp), such as Scheme or Common Lisp.

As John Foderaro worded it,

Lisp is a programmable programming language.

after all

Re:Argh!

[Anonymous Coward]

awww poor baby. who peed in your cheerios?

Re:Argh!

[be-fan]

The whole point of macro is readability! Reading Lisp code with a well-chosen set of macros is like reading code written in a language precisely-designed for the problem you're trying to solve. It keeps the boiler-plate and the implementation details from interfering with the expression of the core algorithms.

Re:Argh!

[budgenator]

The first major language to have it was Visual Basic
Visual Basic and major language is an oxymoron, now if you left off the visual part I might have excepted it as a major language, however sense Basic was a training language for Fortran a some of people still might have problems with the notion.

Re:Argh!

[Anonymous Coward]

i was beginning to wonder when the /. grammar police would show up in this thread.

Re:Argh!

[GnuVince]

I don't agree with the "better syntax" part. If anything, the C-like syntax is the most god-awful syntax there is. Let's take a look at a loop in Smalltalk and in C:
Smalltalk: 1 to: 100 do: [ :i | "do something with i"]
C: int i; for (i = 1; i

I don't know about you, but the first one reads much better. What's more, it's not special, the #to:do: method is defined in the Integer class. You could of course add your own control structure quite easily by just adding a method. Try that in C.

Re:Argh!

[GnuVince]

Oops, forgot about the < thing... Well, you know how the C loop would look like.

Re:Argh!

[Anonymous Coward]

As a schemer, I'd just like to throw in that not all schemers think macros are evil. I mean, the specification for the language clarifies many different fundamentals of the language in macros of other definitions. Cond is a clear example. The only reason that schemers might seem to prefer to not use macros is that the boarder between macro and non-macro in scheme is so vague at times. Also, schemers aren't all about the "one true way". It just happens that the "right way" (ie, the most elegant) to do a lot of things happens to be many forms of the same thing, which often are reducable to a generic form. That's pretty much the basis of scheme's entrenching into lambda calculus.

Re:Argh!

[Anonymous Coward]

so basically you're saying lisp and dylan suck. thanks for the info, i'll avoid them both.

Re:Argh!

[RevAaron]

Out of that 3%, how much is emacs?

I'm surprised no one has brought up emacs as an example of a lisp app...

Re:Argh!

[be-fan]

No, I'm saying that your average C/C++/Java programmer is perfectly happy living with all the problems of his tools, just as long as he doesn't have to learn anything new or anything that doesn't have enough hype behind it. It's kind of like the "nobody ever got fired for buying IBM" type mentality. As long as nobody else is willing to push the boundaries either, everybody is fine!

To actually appreciate Lisp or Dylan, you have to actually program in it. You have to put the kind of effort you put in to learning C or C++ or Java, perhaps more because you have to unlearn all the things you need to do in those languages, but don't need in a good language. Very few people are willing to make that jump, and take that risk. Very few of the people who do can ever look back to C/C++/Java and find them acceptable. Its interesting to see just how many people on comp.lang.lisp have been using C/C++/Java for years, but now prefer Lisp. You'll find almost nobody on comp.lang.java who has been using Lisp for years and now prefers Java!

Re:Argh!

[Anonymous Coward]

Its ironic that CLiki, the supposed "Common Lisp" wiki, runs on PHP. I guess they couldn't even decide on a lisp dialect to do their CGI scripting in, and chose PHP because it runs anywhere? "Common" my ass.

Re:Argh!

[be-fan]

You have to be careful with that comparison. How much is emacs itself? About 500,000 LOC. How much is written in elisp? Considerably more.

Re:Argh!

[Peter La Casse]

Methinks a lot of folks would argue that Python isn't a spiritual descendant so much as a wannabe.

Methinks none of those folks are Python fans.

Re:Argh!

[ansible]

Schemers don't like macros because it is possible to write buggy macros, and want their own elegant, bulletproof mechanisms to define language extensions. T

And it looks like they can get that now with SRFI-72, "Simple hygienic macros". I haven't dug into all the details and compared it to all the other macro systems for Scheme, but it looks pretty good on the surface.

Re:Argh!

[sketerpot]

Damn it, indent your post! Lisp syntax sucks without indentation. (In fact, many experienced lispers argue that Lisp is an indentation-based language; it just has those parens in there for other reasons).

Re:Argh!

[GoofyBoy]

>you don't *need* a paren-matching editor with lisp.

Apparently, you also believe that you don't *need* captialization.

Re:Argh!

[Tayssir John Gabbour]

Scheme removed the annoying complexity-of-use from LISP by discarding its historical baggage (if only that could happen to C++!).

I think Common Lisp is actually simpler to use, though no doubt harder to pick up at first.

"Historical baggage" is lessons learned by others. Ignore them as you wish.

Obviously, people have their preferences, and I'm not going to opine which is the better tool for individuals, as people vary.

Re:Argh!

[Peter S. Housel]

It's not true that CLiki is written in PHP. As can be seen from CLiki's own CLiki page, it is written in Common Lisp and run using Steel Bank Common Lisp.

It is perhaps ironic that the Dylan Language Wiki is written in PHP, but that is being rectified.

Re:Argh!

[Anonymous Coward]

In other words, "readability counts", and that goes out the door with macros. Maybe not for disciplined programmers, but we all know the world is full of the other kind.

I think this is it exactly: What kind of programmers are you designing the language for?

Java, and it sounds like Python, are designed for mediocre to mid-range programmers. On average they're confused by too much abstraction and they can't design it well.

Languages like Lisp and C++, OTOH, are designed for genius programmers who are experts and using and designing abstraction and domain-specific syntax. An effort is made to ensure that novices can use the language, but not at the expense of experts.

Both probably have their places, and personally I think the place for the "mediocre" languages is on someone else's computer. :)

Re:Argh!

[Bastian]

Exactly.

Re:Argh!

[Anonymous Coward]

Based on the other posts, the syntax looks similar. While the prefix operators were a pain, the language was pretty cool. I'd consider using it again if the need ever arose.

I've seen Clips before, I played with it a little but didn't really do very much. I haven't used it or Lisp in a long time...

Syntax is VERY similar. (yes, prefix operators.) Logic and code structure, at least as far as what I did, are completely different. The expert system core that Clips is wired around is completely nonexistant in Lisp. (You can certainly implement such a thing, though.)

Judging from the information on the other side of that link, there's a lot in Clips that I never touched... so I'm not too confident in giving any more of an answer than that. Sorry it's not much, but it's an answer. :)

Re:Argh!

[Anonymous Coward]

You're right, until there is a bug. At which point you get to dissect the towering abstractions to find out which one isn't air-tight.

It is said that code is written once, and read many times, so optimize for readability. I suspect we'd be better off recognizing that code is debugged many times more than it is read, and adjusting our priorities...

Discussions of languages at this level seem somewhat academic when 99% of programmers use C++ or Java.

Re:Argh!

[bani]

So why has lisp largely failed to get any traction? There's >10x as many freshmeat projects in python than lisp. More ruby than lisp. Lisp is there toward the bottom with cobol and fortran.

it's not like lisp isn't taught in CS classes. people do get exposure to it. so why don't programmers stick with it?

doesn't matter how damn cool your language is if nobody uses it.

Re:Argh!

[Anonymous Coward]

Common Lisp is apparently so advanced it traveled back in time to before it was standardized to compete with VB.

A lot of languages used garbage collection for decades. Lisp dialects, ML, Smalltalk, etc. Without a clear definition of 'major' and a suitable definition of 'garbage collection,' pinpointing the first major language to make use of automatic memory management is all the more difficult. By the time VB rose upward in the business world, the AI winter had staked Lisp in the chest and doomed it to practical irrelevance.

Frankly which 'language' has the oldest garbage collection penis matters fairly little. Lisp is the second-oldest high-level language, and it should come as no major surprise that it had properties before all languages that followed it. Languages that follow needn't implement any particular set of functionality, simply because it's been added elsewhere; the target application of the language must be considered. That then features are later added when they become more practical for the intended application(s) of these languages, while always reassuring to the "Smug Lisp Weenies(tm)," are little reason to pound chests. This is especially the case when advances of implementation strategies make practical functionality that was previously undesired in the application domain. Take for instance variations in garbage-collection algorithms and their runtime properties. Only if Lisp somehow manages to take credit for all research in the field in the last 50 years does it somehow make its adoption a sign of its users' large phalices.

Re:Argh!

[Anonymous Coward]

1 + 6 * 10

What does that evaluate to? That depends on whether you're reading arithmetic or Smalltalk.

Re:Argh!

[Anonymous Coward]

You would have to be pretty desperate to include elisp into such figures. Elisp is a primitive, shitty language when compared to modern lisp. The method also does little for determining how much 'lisp' in part of 'Debian' where 'Debian' means 'stuff people actually install.' Adding in SBCL, CMUCL, CLISP, ABCL, Maxima, cl-*, 20 dialects of Scheme, etc when virtually no one installs or uses any of this is pretty pointless.

Re:Argh!

[Ulrich Hobelmann]

What's wrong with an easy association rule that equally applies to ALL binary operations, not just math + and *?

Re:Argh!

[Anonymous Coward]

Common Lisp has everything except a foreign function interface, networking, database connectivity, and a dozen other things to make developing for multiple platforms pleasant. As it is, there will never be a portable ffi for Common Lisp implementations. Who needs callbacks anyway, right?

Scheme and Python are only alike if you don't understand either overly well.

Scheme requires tail-call elimination. CPython doesn't even implement it. Everything in Scheme can be expressed in terms of recursive functions. Try writing that in Python and watch your stack explode.

Scheme has hygenic macros. Python has no macros.

Scheme has full lexical closures. Python's binding semantics prevent proper behavior.

Scheme has no object system. Python becomes more fully object-oriented all of the time.

Python has comprehensions. Scheme doesn't.

Python has rich reflection. Scheme doesn't.

Python has a module system. Scheme doesn't.

Python has actual iteration. Scheme's only iteration consists of macros that write recursive functions that are tail-call optimized.

Code written in Python is mostly imperative. Code written in Scheme is mostly functional. The pattern of ! suffixes for destructive functions makes mutation obvious.

Python has syntax. Scheme has practically none.

Re:Argh!

[Ulrich Hobelmann]

I don't know about other Smug Lisp Weenies, but to me point is not that Lisp has always been the best. In fact, older Lisps sucked a lot, with dynamic scoping, slow implementations, and subtle incompatibilities everywhere. For reasons like these I still refuse to learn Emacs Lisp, even though I like Scheme and Common Lisp (more the latter).

The point is that Lisp is a great, useful language, and its good features (talking of CL now) get picked up by all languages over time, so you might as well get the real thing.

Name one feature of another language that hasn't been present in Common Lisp since its inception in 1984. Feature, not library function.

BTW: ML started in the '80s, Smalltalk in the '70s, Lisp in the '60s, and the first two were first implemented on top of Lisp. That doesn't mean they're inferior, in fact ML is a great language, and Smalltalk one of the languages that show how Java *should* have been. But it shows that the viability of GC came from the Lisp culture.

Funny that the same people that decades ago argued that GC is too slow now argue that everybody should use Java, not C, because manual memory management is too error-prone. Ten years from now those weenies will say "look, restarts are so much cooler than exceptions", "multiple inheritance rocks", "multimethods are really convenient", and "why didn't they have macros in 200X?"

Re:Argh!

[Anonymous Coward]

Dylan decided to adopt an AlgolW-like syntax when the world had already opted for C, after its principle developer, Apple, had realized it spent large sums of money developing for a device that was no longer important to their future. Apple Cambridge closed without Apple Dylan ever being feature-complete, and the language went off to Harlequin and CMU to die. It offered little to the programming language research community, who largely focus on statically-typed functional languages, and it offered little to those doing practical development because of its verbose syntax, incomplete free implementation, and cost-ineffective commercial implementation.

That last part is also a reason that Common Lisp has seen little success. The implementations that work on Windows that are good cost a lot to license, and the ones that don't cost a lot to license aren't compliant with the specification and generate code that is of substantially-lower quality. The lack of standardization of important functionality across different implementations even on the same platform, increases the potential cost of development and in the face of steep licensing costs people aren't going to bother. Difficulty interoperating with existing libraries, system services, and providing component interfaces useable with other codebases potentially written in other languages further makes people not bother.

If people don't bother, there is less finished infrastructure for developing further software, and fewer people bother because they can get the same work done piecing together existing codebases. They not only can get free C, C++, C#, and Java compilers plus Python, Perl, and Ruby interpreters, but entire development environments and tens of thousands of libraries of code. They can get all of this with reasonably-similar syntax and without ever learning to use Emacs and SLIME. They don't have to make deployments as heap images, or heap images wrapped up in small executable loaders. They don't have to write bindings that have to contend with differences in ffi implementations for every library they want to use, because they already exist or they're unnecessary.

The world is literally full of people that could, but don't use Common Lisp. They don't use it for several years before deciding they would rather write code in Java, because they're not that masochistic. It doesn't even matter whether they like other languages more than the idea of Lisp or not, only that they could but don't use Lisp for any number of pragmatic reasons. While there are certainly no shortage of people that write software without any knowledge of Lisp, there are no shortage of people that don't use it because they would rather get their work done under the constraints that they actually have to work with. Pointing to all of the excited people that post on comp.lang.lisp or on IRC about how great Lisp is--often without ever actually making anything meaningful with it--and remarking that they're all happy is an obvious selection bias. I hear people over at comp.lang.perl are pretty happy with some language ot another, and aren't looking to switch over to developing in Java.

Syntax could very well be a real reason Lisp is unpopular. It isn't the only reason, but it's most-likely a reason. Not just because s-expressions are convoluted for representing certain common idioms, but also because it diverges so remarkably from the norm. If the syntax doesn't turn people away, then why aren't there any popular languages with semantics like C that use prefix notation?

There's a subset of fringe language enthusiasts that are a little divorced from reality. Consider it the extended Brandon J. Van Every Syndrome, where instead of turning inward to cause damage, the honeymoon of evangalizing in an entirely inappropriate audience in a completely self-destructive manner never ends. Where Brandon invariably finds deficiencies with every language or implementation and then changes his focus to annoying the community surrounding it, these people just constantly talk about h

Re:Argh!

[mango]

Not true - CLiki is writtin in Common Lisp. See here: http://www.cliki.net/CLiki

Re:Argh!

[sickofthisshit]

Could it be that Lisp is taught poorly? Lots of people don't like calculus, even though they were taught it at school.

Could it be that freshmeat is not representative of the pinnacle of software engineering? That popularity is not the only possible outcome for a perfectly good language?

People who are open-minded enough to get used to the white-space significance of Python *ought* to be more than open-minded enough to accept Lisp syntax.

Why some of them get cranky and defensive when faced by Lisp is a great mystery to me. Maybe they only have room in their head for one language.

Re:Argh!

[Bob Uhl]

The folks who stick with Lisp pretty quickly learn how to handle things such that the parens are No Big Deal. And what they buy is a pretty big deal: macros. Not C/C++ can't-use-em-for-anything macros, but real honest-to-goodness macros which let one create one's own syntactic structures. Very cool stuff.

Re:Argh!

[Bob Uhl]

But of course Lisp isn't (just) about functional programming. Scheme is, but Common Lisp is about multi-paradigm programming. In CL you can write:

• functional code
• declarative code
• procedural code
• imperative code
• object-oriented code
• aspect-oriented code

And in fact can add just about any paradigm you like onto the base language. It's pretty cool.

Re:Argh!

[Anonymous Coward]

Several of these are just plain wrong and it's thus hardly insightful.

Re:Argh!

[Anonymous Coward]

"I".

Re:Argh!

[bani]

Doubtful. Haskell has really taken off in comparison, while Lisp continues to flounder.

Maybe instead of whining how everyone is "too stupid" to "get" the "leetness" of Lisp, they should focus on why so many people are turned off by the language and choose other functional languages instead.

Perhaps the "everything is a nail" attitude of Lisp fanatics has something to do with it?

Re:Argh!

[bani]

Naughty Dog software pointed out that macros can make code written by other developers harder to understand. It's interesting that while C/C++ developers generally use macros sparingly (and those who use them a lot are generally frowned upon), Lisp macros are promoted as if it's the only way to get anything useful done with the language.

It's also interesting that those who do use Lisp in applications tend to use it as glue/scripting and not as the base.

Re:Argh!

[bani]

Why should you "just need to learn how to use the editor properly" in order to use a language?

I think it's worth noting that while there's only 3 real dialects of C (C, C++, ObjC) there's something like 30 or more dialects of Lisp.

Re:Argh!

[IpalindromeI]

What's interesting is that someone can be so outspoken against something they know almost nothing about. From your comments under this story, it's pretty obvious that you've never used Lisp for serious programming. Yet your comments that speak of Lisp are disparaging toward it. Parrotting the words of others, who probably also have only a passing familiarity, is not a good basis for argument or opinion.

What's truly interesting is that even though the comments that come from people who actually do have pertinent knowledge have almost universally praised the utility of macros, you proclaim your disbelief time and again. Perhaps the people who actually know what they're talking about have a better understanding of macros and how useful they are than you do.

Instead of just thinking, "It's ugly because of all those parentheses," or "My favorite language doesn't have that feature so it must be worthless," or "Everyone makes fun of it and no one uses it," maybe you should try to experience and learn it for yourself. I realize that you won't, but keep it in mind anyway. Ignorance doesn't help you make better decisions, and unless you've actually learned the language (not just laughed at the jokes about it), you are ignorant of it.

Re:Argh!

[bani]

I took enough lisp in CS to determine it's a language for people like you who see the world in black and white, where all the world is a nail and lisp is the hammer.

Your appeal "you're unqualified to criticize lisp until you really 'know' it" is like how christians assert you can't criticize christianity until you really "know" jesus.

Re:Argh!

[sickofthisshit]

30 dialects of Lisp? Where?

I see Common Lisp and Scheme as the only dialects of other than historical interest.

Lisp Machine Lisp, MACLisp, NIL, InterLisp, Symbolics Lisp, and others I've probably never heard of, all either flowed into Common Lisp or have died out by not doing so. Lisp 1.5 is a museum curiosity. Are you counting T? Previous revisions of the Scheme standard? MDL? I'm still missing 20 or so dialects from your count.

(And, BTW, I can write Lisp on the whiteboard just fine. It just doesn't execute very fast.)

Re:Argh!

[IpalindromeI]

I took enough lisp in CS to determine it's a language for people like you

I've never used Lisp. I don't doubt that you've had enough exposure to become frustrated with it, but clearly not enough to understand it. However, from your other comments under this story, I can see that you're not one to put aside prejudices long enough to gain that understanding. Your loss.

Re:Argh!

[bani]

why don't you try writing some applications in lisp before you whine about other people's criticisms of the language.

Re:Argh!

[feijai]

Haskell has really taken off in comparison, while Lisp continues to flounder.

That explains that giant Haskell industry then.

Languages come and go. Lisp was before its time, and now that hardware has caught up, Lisp is already in the "going" stage. That's the only reason why Lisp "continues to flounder".

Wake me up when Haskell has an actual optimizing compiler.

Re:Argh!

[sickofthisshit]

A charitable guess is that Bani is looking at Lisp from an academic functional-language perspective, in which case Lisp is no longer in the forefront of academic language research. Nobody is doing projects to implement Lisp dialects with, just to guess at what is going on, more elaborate type systems, or more purity in functional aspects, or whatever.

Certainly, if I were an academic looking at programming languages from some kind of purist perspective, Common Lisp would look dirty, grungy, without any prospect that it would get "cleaned up" anytime soon.

Meantime, people who want to deliver powerful, novel applications with maximum leverage of programmer talent, can go to a commercial Lisp vendor, and say "gimme some of that Lisp goodness" and actually do real-world development, academic purity be damned.

That's the only reason I can see for a Haskell guy to accuse any other language of not being "successful."

Re:Argh!

[be-fan]

That's an asnine comment. If learning a tool allows you to use a more powerful technique to solve you problems, what's the problem with that? Heck, by your logic, FORTRAN is a better language than Haskell, because you don't even have to learn how to type to use it --- just put holes in a punchcard!

Re:Argh!

[bani]

actually, yahoo rewrote their merchant system in C++ and Perl, and of Jan 2003 yahoo is no longer using lisp.

so no, yahoo doesn't count anymore.

orbitz uses lisp indirectly. they didn't write the software, they licensed it from ITA. to claim orbitz "uses" lisp is kinda like claiming someone "uses" C because the linux kernel is written in it.

Re:Argh!

[sickofthisshit]

The point of the Yahoo! merchant system example is that a small crew of people was able to develop the system (and Lisp was a huge advantage against their competition), and sell it off to Yahoo for big bucks.

Yahoo's decision to rewrite it doesn't change the original win. How many programmers is Yahoo using now compared to how many were needed to develop it? What else did they give up in the translation?

Likewise, ITA solved what was previously believed to be an *intractable problem*. And they used Lisp to do so. And, surprise, they are apparently able to get money from Orbitz because they did it.

Did a Lisper piss in your cheerios or something?

Re:Argh!

[Anonymous Coward]

yahoo abandoned lisp because while it was fine for ~200 stores it did not scale to 20,000. they were also unable to find enough lisp programmers skilled enough to maintain the mess left behind from the piles of near incomprehensible macro spaghetti.

ITA's stuff is lisp glued with lots of C and C++. it's not pure lisp. they also do a lot of very ugly things in lisp and use a lot of bruteforce to get things done. it's not like the problem space they are attacking is the exclusive domain of lisp -- other languages have cracked it using similar techniques.

lisp is not a magic bullet, contrary to what people are posting here.

Re:Argh!

[sickofthisshit]

I don't see anyone calling Lisp a "magic bullet."

What I do see is a bunch of people saying "Anything you can do in Lisp can be done better in $LANGUAGE" without having any clue at all about what Lisp actually IS, and Lispers doing their best to respond. "Macro spaghetti" is an obviously judgmental term. One of the Viaweb guys of course wrote the damn book on Lisp macros, so if you look down on his code, you must have something other than programmer talent in mind.

There are ALWAYS external factors, which eventually dominate decisions, largely independent of computer language. But those non-linguistic reasons aside, it's hard to come up with a computer language that dominates Lisp for purely linguistic reasons.

Great News!

[RAMMS EIN]

Let me be the first to say...Great News!!

This has long been the dream of those yearning for the revival of Lisp machines and their allegedly superior programming environment.

Re:Great News!

[sickofthisshit]

Except a lot of the really powerful stuff (Genera), was developed commercially at Symbolics, which is still very much a commercially licensed product (although it comes with almost all source code.)

Think "ultimate programmer workstation" where you can get the source to *any* function in an API by hitting Meta-., and replace it with your own code, if you wish. And point to *any* object on the screen, and hit a mouse button, and the data object inspector lets you see and manipulate it.

At least from what I understand, this stage of development was a hundred man-years or more of improvement over the MIT Lispm stuff. But hey, maybe this is a start.

Re:Great News!

[Abcd1234]

Sounds like Squeak to me.

Re:Great News!

[Anonymous Coward]

You can do this with SLIME (Lisp environment for Emacs):

Just put the cursor on any function, and hit M-., and it takes you to the source code. If you want to change it, start editing (or copy to a scratch buffer) and hit C-c C-c and it will be recompiled (I might not have the keys exactly right since they are commited to muscle memory).

The output values in the REPL are also "live objects", if you evaluate "(make-hash-table)" for instance, you can click on the resulting string and copy it and use it as if it was the hash table object (inspect it, copy it into other expressions, etc). You can tell because the text turns red when the cursor is over it.

Other cool stuff: when your program hits an exception, it doesn't STOP your program, it just suspends it, and you can GO INTO THE STACK FRAMES and fuck around. Want to change a value from 3 to a 4? No problem. Want to run some arbitrary code within a stack frame? No problem. Want to fix the bug in a function and restart the evaluation? No problem. Want to cancel a stack frame and return a different value? No problem.

Oh, and of course the Lisp image doesn't actually have to be running on the same machine you run Emacs on. You can do it over SSH transparently.

This is some mind-blowing shit, and it's been like this since the mid-70s. SmallTalk has been the same way. I wish I had half of it when I use Ruby, for instance. It's weird to see people make fun of this.. they clearly have never even tried it.

Re:Great News!

[hutchike]

Smalltalk is not Lisp my friend. At least Smalltalk has OO built in. Lisp and Scheme have it surgically added at a late stage with pseudo-OO a la Perl.

Re:Great News!

[sickofthisshit]

Yes, Lisp had OO added after Lisp was already a mature language. (Although it is included explicitly in the ANSI Common Lisp standard, so it's as much part of the language as CONS is.) So what? Common Lisp also added lexical scope to Lisp, but you can hardly tell Lisp wasn't this way from the creation.

*Except* for built-in Lisp functions not being extensible generic functions, you can hardly tell OO wasn't part of Lisp from the beginning. This flaw turns out not to be a big deal. The reason it is such a clean extension is mostly because the surgeons who added it on had the power of Lisp macros to design with.

To compare this to the Frankenstein-like addition that OO is to Perl or C++ is needlessly provocative. Language "surgery" doesn't have to be done with chainsaws.

Re:Great News!

[sickofthisshit]

Yes, SLIME implement Meta-. Emacs also implements Meta-. for C.

The difference is that (AFAIK) SLIME stops at the edge of the Lisp implementation, where Genera would keep going all the way down to the microcode executing on the hardware.

Your post makes me think I need to take a closer look at SLIME, though. I mostly use old-style ilisp-mode.

Re:Great News!

[be-fan]

Lisp is generally as OO as Smalltalk, and CLOS is anything but pseudo-OO (and far from the monstrosity that is Perl). All Lisp objects are CLOS objects, and you can specialize CLOS methods on any Lisp type.

Re:Great News!

[masklinn]

Come on, OO's support of Perl has been (as PHP's) added with much use of sledgehammers, even though the object programming paradigm was not built in Lisp (Lisp comes from pure mathematics, and objects just don't have any reality in mathematics), even checking old Lisp code looks OO all over...

Re:Great News!

[Anonymous Coward]

Check out the video here:

http://it.slashdot.org/article.pl?sid=05/07/30/182 0218&tid=156&tid=8

SCO needs to be all over this...

[bani]

...this is obviously stolen SCO intellectual property.

I mean if SCO can claim all your ELF are belong to SCO, why stop there?

SCO needs to start up a Lisp licensing program, it can be as wildly successful as their Linux licensing program.

Re:SCO needs to be all over this...

[Anonymous Coward]

Seriously, WTF?

But I thought...

[pmike_bauer]

• Tar file of the tape images, extracted files and extract software, 71Mbytes

This software was written in the 80s. Back then, all the programmers were supposed to have supernatural abilities and could, like, fit an entire operating system in 640K! What is this??!!! A modern JVM download is only 15MB.

Re:But I thought...

[Anonymous Coward]

This distro is JPEGs of the 80-column cards.

Re:But I thought...

[Zathrus]

Back then, all the programmers were supposed to have supernatural abilities and could, like, fit an entire operating system in 640K! What is this??!!!

LISP.

And that may shed some light why your box dies everytime you run emacs.

Re:But I thought...

[Anonymous Coward]

Not sure if what you're trying is a joke, but it's apparently not working.

Re:But I thought...

[RAMMS EIN]

One of the reasons Lisp "died" is that it didn't achieve the performance of FORTRAN (the other language of the time). Of the two, Lisp was tha language that had all the features (really..."modern" languages still don't have some of the features Lisp has), and FORTRAN was the one with the raw performance. As more research and implementation work was done, Lisp became competitive with "simple" languages in terms of performance, but it retains the image of being a slow, interpreted language to this day, no matter how false.

Re:But I thought...

[rsheridan6]

Ever since I bought an extra 2 Megs of RAM for my 386, that doesn't happen anymore.

Re:But I thought...

[sketerpot]

What horrendously old computer are you using that is incapable of running emacs properly? Emacs is very resource-light compared to most programs these days.

Re:But I thought...

[Alsee]

Can I get that in .BMP format for my Windows machine?

-

Re:But I thought...

[melonman]

For a start, it's source code. It compiled for a processor designed specifically to run Lisp (36-bits anyone?), so the object code was quite compact.

Second, it did stuff in the 80s that are still hard to do today. For example, how many development systems allow you to locate a piece of windowing behaviour that you like, anywhere in the OS, and import that behaviour to your own code with a few mouse clicks? Or drop into microcode when necessary? The JVM is smaller because it does a whole lot less.

Third, the machine I used cost £1M at the time, so I don't think they were worried about the odd extra RAM chip. Lisp uses lots of RAM when it runs, no matter how compact the code.

They were fantastic machines - in the year Apple released their first laser printer and IBM were talking seriously about a windowing environment, these guys were using a 68000 just to bootstrap the main processor, and there weren't a lot of other 24-bit displays around, let alone full-blown rendering packages to take advantage of them.

Re:But I thought...

[hr raattgift]

Surely you were using a Symbolics machine, and not an MIT CADR?

This is not Genera.

One can see in this software and the CADR the start of what evolved into the Symbolics 3600 series and its software.

Since you mention a price tag (in non-US currency even), and imply that it was used for commercial purposes, you are almost certainly not thinking of the CADR prototype and research system.

Probably this is what you are thinking of: Symbolics Lisp Machine Museum.

There is a link on that page to the CADR, under "Precursors and Competitors". The CADR was a precursor.

Re:But I thought...

[melonman]

You're right, it was a Symbolics, but pre-Genera. My understanding was that most of the OS-end of things was common with the MIT version - we beta tested a Texas Instruments clone of the Symbolics that was remarkably similar, for example. I think my general point stands that comparing this codebase with the JVM is a rather odd thing to do.

Nice...

[lpangelrob]

...they found it on 9-track tapes in the basement. Excellent.

Does that make this the oldest software to be released under an "open-sourceish" license?

Re:Nice...

[mccalli]

...they found it on 9-track tapes in the basement.

....with a sign on the door saying "Beware of the Leopard".

Cheers,
Ian

Re:Nice...

[Anonymous Coward]

I'm guessing that the lights were also out...

Re:Nice...

[TheRaven64]

The first BSD release was in 1978. This didn't include much - it was a relatively small patch-set applied to AT&T UNIX - but it was released under the 4-clause BSD license (Free / Open Source license, non-GPL compatible). It was later re-licensed under the 3-clause BSD license (GPL, and most other things, compatible). I don't know exactly how old this code is, but TFA said it's from around 1980, making it a couple of years younger than 1BSD.

Going even further back, the original UNIX code was released under an "open-sourceish" license, but not a truly Free one.

Re:Nice...

[Anonymous Coward]

And the filing cabinet locked. We've all read the books, here. ;-)

Re:Nice...

[John Meacham]

the Maxima computer algebra system is a decendent of DOE Macsyma, which is from the 60s and one of the first computer algebra systems. it is a really great project. http://maxima.sf.net/

Re:Nice...

[MichaelSmith]

they found it on 9-track tapes in the basement. Excellent.

Those heads are going to need a good clean after all the magnetic media comes off on the first read.

Re:This is News?

[Anonymous Coward]

And you are?

Btw, here's the Wikipedia entry on LISP.

Somebody had to say it...

[Anonymous Coward]

(This(truly(is(great news))))

Re:Somebody had to say it...

[kaarigar]

(great news (is (truly (this))))

Re:Somebody had to say it...

[Anonymous Coward]

(This (truly (is (great (news nil)))))

Re:Somebody had to say it...

[Iron Monkey]

(is this ((truly great) news))

Re:Somebody had to say it...

[davevr]

You must mean:

? (great-news-p 'this)
> T

geez, kids these days.. somewhere, David Moon is weeping...

Re:Somebody had to say it...

[Requiem]

> (great-news? 'this)
#t

(I prefer scheme)

Re:Somebody had to say it...

[chooks]

No cons???!!! No cadr??!?! What about a nice lambda?!?!? Come on guys -- you can do better than that... :) (and if it hadn't been 12 years since I last did some SCHEME-ing, I probably could do better too...)

Re:Somebody had to say it...

[Anonymous Coward]

must.be();
funny {
  because(languages, of.today);
  are(SOOO);
  much {
    easier();
    to(); read();
  } and {
    also {
      so( consistent() );
      you {
        never { need(an.ide()); to(sort.out().the(syntax())); }
      }
    }
  }
}

Re:Somebody had to say it...

[Anonymous Coward]

That doesn't sound quite right either... How about

(setf (great-news-p 'this) t)

? Bah, my memory is too fuzzy on the subject.

Re:Somebody had to say it...

[Mad Marlin]

* (|Great news?| 'this)
T
; That's right, that is a space in a variable name.
; Just be glad I didn't put in a newline (cause I can).
; suckOnThat, camelCaseRetards.

Re:Somebody had to say it...

[hr raattgift]

Wow... 12 years. Lots has changed since in far fewer years than that!

Maybe you should check out PLT Scheme, a modern scheme interpreter and compiler and IDE, with several "Teachpacks" which help one come up to speed in doing clever things with Scheme. DrScheme is the thing to download, for various platforms.

There are plenty of other Scheme implementations out there, interpreted and compiled.

Personally I do a lot in SCSH, the Scheme Shell which is handy for writing scripts and tools close to the metal on on UNIX/POSIX systems, however PLT and other environments are incorporating more and more of SCSH-like goodies into their libraries, and write stuff that needs to be fast in Chicken or Gambit, which compile Scheme to C. On the Common Lisp front, on a Mac, there is also OpenMCL, which compiles to *particularly fast* native PowerPC code and has a straightforward way of communicating with Cocoa and a number of other Mac-development-friendly features. In fact, all of these implementations have foreign-function-interface abilities which let you call e.g. C functions from Scheme/Lisp, or vice-versa, so you can write performance-critical sections in a low-level language of your choice, and use higher-level languages to develop "smarts".

My other car is cdr

[Anonymous Coward]

No comment

There's some duplication.

[CyricZ]

There are the original TPC tape images included, and then those same images in SIMH format. Then there's an archive of the extracted files, and the archive is also extracted.

Re:There's some duplication.

[pmike_bauer]

I was going for funny, but the slashdot mods found me insightful. Amazing!

Re:This is News?

[Anonymous Coward]

* ROFLMAO *

* stands up, tucks shirt in *

that was a good one *snif*

Richard Stallman and the Lisp Machine

[mschaef]

This was in the body of the story, but maybe it's more appropriate elsewhere. One of the more interesting links in the blog posts about this source code release was a transcript of a speech by RMS on how the Lisp Machine influenced his decision to start the free software movement. Interesting reading.

Re:Richard Stallman and the Lisp Machine

[$RANDOMLUSER]

> ...speech by RMS on how the Lisp Machine influenced his decision to start the free software movement.

I always thought it was pot. Live & learn.

Re:Richard Stallman and the Lisp Machine

[ArmorFiend]

Not only that, but the gnu system was originally to be written with multiple language front ends, one LISP, the other C, not unlike the .NET hype of a few years ago. Can you imagine if Lisp had won and Linux as a result was a system written in Lisp? Whoa.

Re:Richard Stallman and the Lisp Machine

[Anonymous Coward]

He wrote emacs in the 1970's? I never would've thought it was that old.

Does he even write code anymore? Or is it 100% politics for him nowdays?
Seems like he's quite a wizard.

Re:Richard Stallman and the Lisp Machine

[Usquebaugh]

Lisp = Pot

Both can calm the savage programmer.

I have to use a language that doesn't even have recursion much less OO! I'm as mad as hell and I'm not going to take it anymore. Any interesting startups in the East Bay using Ruby/Lisp?

Re:Richard Stallman and the Lisp Machine

[WryCoder]

Does he even write code anymore? Or is it 100% politics for him nowdays? Seems like he's quite a wizard.

He still develops Emacs, and he's leading the design of the GNU System (all GNU, Hurd kernel, no Linux).

He write the GNU C compiler (gcc), the debugger gdb, emacs, and many other critical utilities, all of which were prerequisites when Linus developed the Linux kernel. He's a legendary hacker.

Re:Richard Stallman and the Lisp Machine

[Anonymous Coward]

By the looks of it, he still really enjoys eating pie too.

Obligatory

[Acey]

In Thoviet Rutha, LITHP lithenthes you!

Sorry, it needed to be done. That and a co-worker suggested I post it.

BSD-like, not MIT like

[Anonymous Coward]

I am surprised that they said "BSD-like" and not "MIT-licence"m as the two are equivalent. Why are they not using the MIT licence for an MIT project?

Re:BSD-like, not MIT like

[Dragonmaster Lou]

Looking at the actual license used, it is the MIT license. I guess they referred to it as a "BSD-like" license as it is somewhat more familiar to the average techie.

9 track tapes?

[Anonymous Coward]

Are those like 8-track tapes but with a little extra oomph?
Like when you have one of those wicked amps that goes up not to 10 but to 11?

Re:9 track tapes?

[east coast]

Like when you have one of those wicked amps that goes up not to 10 but to 11?

Maybe you think you're funny but d00d, Skynard never sounded so good!

Newbie here...

[Spy der Mann]

mind explaining why the "th" jokes? For us uneducated masses.

Thanks.

Re:Newbie here...

[tntguy]

That'th why.

Re:Newbie here...

[Anonymous Coward]

You know those "special" classes you had to go to in school? That's what they were for, amongst other things I'm sure...

Re:Newbie here...

[Anonymous Coward]

lisp

Re:Newbie here...

[Anonymous Coward]

A lisp is a speech impediment as well as a programming language.

Re:Newbie here...

[BeBoxer]

'Lisp' also refers to a type of speech impediment which results in people pronouncing 'ess' sounds like 'thh'. The irony of course being that people with a lisp have a hard time saying 'lisp' rather than 'lithp'.

Re:Newbie here...

[$RANDOMLUSER]

No, a Lisp is a speech language as well as a programming impediment.

mod parent up!

[Anonymous Coward]

HAHAHAHA!! You made my day!

good

[idlake]

I think it's good that this is getting released. The LispM software contained a lot of low-level ideas that are being rediscovered now 25 years later. This will be useful for the history of computing, as well as a potential source of prior art in patent claims.

Still, personally, I think Smalltalk 80, developed around the same time, was more innovative and interesting than the LispM software. You can get a complete Smalltalk 80 environment in its original form as part of the Squeak project.

I used one of those things

[daviddennis]

I probably used it at about the same time that tape was created, since I graduated high school in 1980 and had a summer job dabbling with one of them.

They did some very cool things, yes, but at least the ones I used were dog-slow because of all the overhead associated with the windowing system and the like.

I hate to say it, but I remember actually preferring the PDP-10. Primitive compared to the Lispm but it was less overwhelmingly complex and actually had an easier time keeping up with my typing.

D

Thank Goodness!

[leighklotz]

Now I can fix that annoying bug that Symbolics introduced when they changed Zwei to say "is not a defined key" instead of "undefined", so when I press Meta-Symbol-B it will say "Meta-Beta Undefined (doo-dah, doo-dah)" again.

Re:Thank Goodness!

[rpk]

Worth the wait, isn't it ?

I'm going to search for my name/id in the source code ;)

Re:Thank Goodness!

[ArmorFiend]

So, uh, how often do you get to tell that joke?

Re:Thank Goodness!

[Anonymous Coward]

I don't get it. Am I missing some pun, or is "Meta-Beta" just inherently funny?

Re:Thank Goodness!

[ArmorFiend]

Sung to the tune:
Camptown Racetrack Five Mile Long (do-dah do-dah)

Its extra funny because he's clearly unsheathed a joke he's been keeping to himself for 20 years. Which we LISPers can appreciate. Everything in computing was better 20 years ago. Everything!

WTF mate?

[thekel]

What is a Lisp machine? I see tons of posts, but no explanations of what they are! Help!

Re:WTF mate?

[Anonymous Coward]

You know what a washing machine is?

It's like that, but you can redefine what "washing" is.

Oops...

[Alwin Henseler]

Parent screwed up link, try Squeak.org

Re:Let's be orderlies now

[MS-06FZ]

What about everyone who wants to bash LISP syntax?

(a ()(((b))(c)())q ((m ()() x))(w))(l)(((z)))) cdr bddr) oh crap it's just too confusing.

Re:This is News?

[be-fan]

Hmm. The Macsyma code dates from around the same period (and was also developed at MIT), and it (well, Maxima, the continuation of the codebase), is still one of the best free computer algebra systems out there. I use it every day, and I don't miss Mathematica at all.

So do the RIAA...

[jd]

They're using a p2p fileswapping program to distribute it - doesn't that make it defacto music piracy?

Re:Let's be orderlies now

[mustafap]

And thats worse than perl regular expressions? Me thinks not.

being able to get the hardware would be better

[ecloud]

Somebody needs to design a modern Lisp Machine. It would be a nice "open hardware" project. Maybe could run on an FPGA PCI board or something.

Re:being able to get the hardware would be better

[Krach42]

Well, as nice a hobby project as that would be... it'd probably just be better to emulate the environment.

Makes it more usable, and distributable.

Re:being able to get the hardware would be better

[Empty Threats]

Have you looked at Movitz? It's a minimal operating system and lisp runtime environment for x86 PCs, which makes kernel development in Lisp practical.

Movitz is arguably the first step to a modern "Lisp Machine." Actually doing it in hardware would be foolish; even Symbolics abandoned that path. Their last-generation products were a tagged-memory RISC architecture and a VM system that ran Genera (and Symbolics Common Lisp) on top of UNIX on the DEC Alpha.

Unfortunately, the Symbolics RISC project never saw the light of day. OpenGenera, the Genera-for-Tru64, is still available, but costs thousands of dollars.

Re:being able to get the hardware would be better

[ecloud]

Actually doing it in hardware would be foolish; even Symbolics abandoned that path. Their last-generation products were a tagged-memory RISC architecture and a VM system that ran Genera (and Symbolics Common Lisp) on top of UNIX on the DEC Alpha.

What's foolish IMO is having to give up some bits of resolution on fixnums in order to do type tagging. (e.g. only using 29 bits like Chez Scheme does) And there is no choice on a 32-bit architecture unless you do something much less efficient. But exchanging data with other systems or C functions is more work because you have to range-check every int to make sure its value can fit in 29 bits, or else upgrade it to a bignum. Right? I don't really know the internals that well but that's my understanding.

So when you say "tagged memory" what I'm thinking is that any machine that can address a 36-bit memory bus instead of 32 bits (or maybe 72 instead of 64) would be a good start. The extra bits could be thought of as "metadata" for every word, and this technique might even be useful for other languages. But it sounds like on the Alpha they just used the upper half of a 64-bit register for 8 bits of metadata, and that is also a "waste" of the power of 64-bit computing in some sense. The same problem will recur - when the world switches to the 64-bit int as the new standard, because all machines have 64 or more bit ALUs, again you will encounter numbers which fit into a 64-bit int but cannot become fixnums.

But if a Lispish OS and programming environment were as popular at some point in the future as Linux is today, some custom hardware would be justifiable.

Today it could maybe be prototyped using one or more FPGAs, and just use the old 30-pin SIMMs for memory - you will just need to use them in groups of 5 instead of 4, and will then get a 40-bit-wide data bus. Too bad it takes so many to get a decent amount of memory. :-)

Re:being able to get the hardware would be better

[Bastian]

Hmm. Interesting idea. I've always wanted a MacIvory system, but don't really think it's worth putting all the effort into hunting down a MacIvory card and a Quadra.

Re:being able to get the hardware would be better

[sickofthisshit]

You can order a macivory system assembled direct from symbolics.com.

LispMachines are Dying

[billstewart]

Dude! Are you still using Lisp Machines? This development just proves they're dying!

I was originally going to title this "Symbolics is Dying", but it turns out Symbolics is still around, selling things like Macsyma, just not making Lisp Machines any more.

bad reputation??

[toby]

it has an undeservedly bad reputation.

Only if you confuse 'reputation' with 'loudmouth /. trolling'.

Getting closer....

[MarkusQ]

Yes! Now I just need someone to find and publish the source to PLANNER and CONIVER.

--MarkusQ

LISP

[jd]

A LISP machine is very similar to a modern-day Java Virtual Machine - it's a device for running LISP - usually in bytecode form, but sometimes as an interpreted language. Depends on the implementation.

LISP, itself, is a language developed for parsing describable information - usually text. It was developed by an AI professor at MIT, IIRC, in one of the early attempts to develop a machine capable of learning.

Because LISP was run in a virtual machine, it was 100% portable. Any machine that had a LISP machine could run a LISP program. It was the real start of "run-anywhere" programming. Although LISP is not the most popular of languages, it has always been a surprise that it has never taken off amongst web developers for purely text-based processing. Java is way too heavy for that and Javascript is very cumbersome for text operations, yet LISP would be ideal for such work.

I'm not 100% sure of this, but I believe Tcl/Tk is derived from LISP, and the syntax used by the LambdaMOO virtual world is very similar and was probably influenced by it.

Re:LISP

[sickofthisshit]

The parent is very confused.

Lisp machines were mostly HARDWARE machines which were designed to support Lisp efficiently. Nothing "virtual" about it. (Although the last survivor of the era, Symbolics Genera currently runs on a virtual machine on Digital Alphas that emulates the original Ivory processor.)

This was necessary at the time to support Lisp environments that were competitive in runtime performance with C/Fortran type software on conventional processors. Nowadays, the tradeoffs are different.

There was no concept of an identical Lisp environment executing on vastly different infrastructure. If you had a different processor, say a DEC machine, you had a different Lisp implementation.

It was generally possible to port basic Lisp programs between Lisp machine implementations and more conventional Lisp environments, but a lot of the joy of using the Lisp machines was that the OS and everything on the machine understood and was designed around Lisp, instead of an environment in which the basic OS was designed for conventional languages.

As for what Lisp is "good for", it is a general-purpose programming language. It's not particularly biased toward text or "binary", whatever that is supposed to mean.

Re:LISP

[TheRaven64]

To add a little more information, LISP machines were a hardware stack-based architecture. Most modern CPUs are register-based - you load values into registers and then perform operations on them[1]. With a stack-based architecture, you load values and operations onto a stack, and then pop them to get results. The abomination of an FPU design that is known as the 8087 used this, and still survives to this day in `modern' x86 chips.

Since the demise of LISP machines, the concept of a stack-based machine has surfaced repeatedly in virtual machines. Pascal was originally compiled to a simple stack-based instructions set known as P-Code. A simple P-Code interpreter was all that was required to get Pascal programs running on new architectures. Other notable virtual machines based on the stack model are the Java VM and the .NET CLR. Parrot, in contrast, uses a register-based VM.

[1] If you are using x86, VAX, or something equally archaic, you may be able to do operations directly in memory, but in modern implementations these are actually run-time translated into load-operate-store sequences.

Re:LISP

[Detritus]

What's so terrible about the 8087?

I thought it was a major leap forward for its time.

Re:LISP

[be-fan]

Egads.

1) A Lisp machine isn't a VM. It's a computer with a native-code Lisp compiler and an OS and development environment written in Lisp.

2) Lisp was designed by an AI professor at Stanford, John McCarthy.

3) The early Lisp's were anything but portable, usually written in PDP or IBM assembly. Most modern Lisp's aren't terribly portable either. The major current Lisp compilers generate native code. Indeed, the only major non-compiled Lisps are Emacs Lisp and Clisp.

Re:LISP

[John Meacham]

The x87 is a stack machine and it was a major leap forward at the time when floating point loops tended to be hand-coded assembly, it was like having a little hardware forth interpreter. (sort of.. maybe..)

but the main problems are that is that it is very difficult to write an optimizing compiler that spits out code suitable to run on a stack machine, there are lots of algorithms for optimal register selection, but when your registers move around with every operation, things become considerably more difficult.

The other problem is that it does not parallelize well. modern CPUs are all about superscalar architectures where they have multiple execution units that try to execute non-conflicting instructions concurrently. since the x87 is stack based, pretty much all operations act on the top of the stack and the top only. this means that every floating point instruction conflicts with each other and you are forced to execute them in sequence. modern CPUs have taken some steps to alleviate this, but it is a non-trivial problem to solve, especially when you want to do it as fast as possible in your instruction scheduler.

Re:This is News?

[lgw]

Every modern language is LISP re-invented poorly. Including LISP.

back to the future

[rheotaxis]

According to the Unix Haters Handbook, the Lisp Machines were much better than the early Sun workstations that replaced them (except for cost, which is why people bought the first Suns instead of LispM.) Didn't they used to cost more than $50,000 each? I've been wating 20 years to get my own Lisp Machine, now I can run one on a cheap PC. Emacs is like eating crumbs from the table, its time to cook some real meals!

Re:back to the future

[sickofthisshit]

Didn't they used to cost more than $50,000 each?

http://lemonodor.com/archives/001190.html shows a November 1985 quote for a Symbolics 3675 with 474 MB disk, 8 Megawords of memory, 24-bit graphics card, monitor, and console, which came out to $124,900. (*after* a Christmas discount of roughly 30%)

Re:back to the future

[sickofthisshit]

You can also get a real, live Lisp machine from Symbolics for something less than $1500 if you are willing to live with a MacIvory II processor in a 199x-era Macintosh.

Wikipedia Ref

[billstewart]

Dude, they were made before you were born. LISP 1.5 came out in about 1960, a few months after COBOL, and unfortunately COBOL caught on and LISP didn't - most languages developed after it were inferior, though some were designed for special environments that didn't have the resources to run or develop LISP.

LISP Machine Wikipedia Page

Richard Stallman and Marijuana

[Anonymous Coward]

> ...speech by RMS on how the Lisp Machine influenced his decision to start the free software movement.

I always thought it was pot. Live & learn.

  Richard Stallman's stance on drugs (from the biography Free as in Freedom) at http://www.oreilly.com/openbook/freedom/ch04.html:

"I didn't like the counter culture much," Stallman admits. "I didn't like the music. I didn't like the drugs. I was scared of the drugs. I especially didn't like the anti-intellectualism, and I didn't like the prejudice against technology. After all, I loved a computer. And I didn't like the mindless anti-Americanism that I often encountered. There were people whose thinking was so simplistic that if they disapproved of the conduct of the U.S. in the Vietnam War, they had to support the North Vietnamese. They couldn't imagine a more complicated position, I guess."

Such comments alleviate feelings of timidity. They also underline a trait that would become the key to Stallman's own political maturation. For Stallman, political confidence was directly proportionate to personal confidence. By 1970, Stallman had become confident in few things outside the realm of math and science. Nevertheless, confidence in math gave him enough of a foundation to examine the anti-war movement in purely logical terms. In the process of doing so, Stallman had found the logic wanting. Although opposed to the war in Vietnam, Stallman saw no reason to disavow war as a means for defending liberty or correcting injustice. Rather than widen the breach between himself and his peers, however, Stallman elected to keep the analysis to himself.

LispM had a superiour hardware model

[Anonymous Coward]

The Lisp Machine, as well as Burroughs Algol hardware, embodies some computer engineering principles that address fundamental failures in the current computing environment:

1. Memory bounds checking in hardware.

2. Hardware typed memory.

3. Hardware designed for specific language implementation.

The current problems that plague the software industry are unreliable code, vulnerabilities to malicious software and poor programmer productivity. It's embarrassing that architectures that were abandoned 20 years ago had features that address these issues.

Memory bound checking is a complete no-brainer. When you declare a data structure you know the size. If you try to go outside that size, then something is wrong. It might be a run time bug, it might be a malicious attack. Who cares? If an exception occurs, you're going to be safer.

Hardware typing in memory is more of the same. If you add a floating point value to an address you are in trouble, and an exception should be the result. In the Lisp world, type bits support arithmetic between various numerical representations, so there is added value beyond error checking.

Hardware/software co-design is not quite as obvious, but it can have big payoffs. Both the Lisp machines and the Burroughs machines were incredibly reliable. They also ran very fast, as least on the tasks that fit the architecture. (Although Symbolics had a great graphics setup, they were not the fastest rendering engines.) Some of this was due to memory bounds checking and some because of typed memory, but much was because the software was designed to match the hardware and hardware was targeted as software. There are currently many examples of hardware designers building computers that are no good for software and software systems that have to make up for gaps in the hardware. Can you say Itanium?

I know I'm really going to get flamed for this, but I think it's true: RISC is to blame for a lot of these problems. RISC attempts to optimize one thing, the instruction execution pipeline. This was fine when speed was the bottleneck, but we are now at a point where the problems are not if we can run fast enough, but can we run reliably enough?

Re:LispM had a superiour hardware model

[Anonymous Coward]

"The Lisp Machine, as well as Burroughs Algol hardware, embodies some computer engineering principles that address fundamental failures in the current computing environment:

[...]

3. Hardware designed for specific language implementation."

Just as the Lisp Machine, current hardware is designed for a specific language. The problem is that that language is C.

Re:LispM had a superiour hardware model

[be-fan]

The LispM model is an obsolete one. Its bad engineering to make a "fast Lisp computer", when you can make a "fast computer" and run a "fast Lisp" on it. The advantages you mentioned are largely irrelevent in modern RISC designs.

1) Why bother with bounds-checks in hardware when, in a language like Lisp, you can have the compiler insert the bounds checks? With modern machines with several integer pipelines, some of which are usually idle, its not like the cost of a bounds check is noticible.

2) There is some validity in this --- it would be nice for hardware to provide tag bits so integers and floats wouldn't have to be twiddled before doing arithmatic on them, but type-checking can be handled just fine in software. Again, when you've got several integer pipelines, the cost of bounds check is not that big.

Re:LispM had a superiour hardware model

[the_2nd_coming]

umm.. no, it is not designed for C. C was designed for the hardware, as are all other languages out there.

Re:LispM had a superiour hardware model

[be-fan]

BS. Take a look at the die of something like an Athlon 64. Large portions of it are dedicated to C support. For example, the entire MMU. If C programs (more appropriately, the C memory model) didn't allow programs to write willy-nilly all over memory, you'd save enough die space to put a couple of more execution units on there. Consider also the massive amounts of out-of-order execution hardware. If C wasn't built on the model of a unit-width instruct stream, a lot of that hardware could be dispensed with.

Programmers seem to have this idea that "C works the way CPUs work". Nothing could be farther from the truth. Modern CPUs are out-of-order, parallel vector machines. The C machine model assumes in-order, single-pipeline scaler machines. C assumes a linear memory space, while modern machines have complex cache hierarchies and often have non-uniform main memories. There are a lot of elements of functional languages that map better to modern hardware than does C. For example, in (strict) functional languages, the following two statements can be executed in parallel:

a = makea()
b = makeb()

A compiler for such a language can map these statements directly to two commmand streams issued to seperate execution units. A C compiler can do something similar, but has to go through massive dataflow analysis to ensure that makea() doesn't modify anything used in makeb(). In another example, functional languages tend to encourage the use of lots of small, transient objects, while C encourages accessing large, long-lived global data structures. Guess which one is more suited to modern machines, with small-fast caches, and large-slow main memories?

And that's just how hostile C is to modern hardware. Don't even get me started on how hostile its "every pointer can overwrite every object" model is hostile to mdoern compilers!

Re:LispM had a superiour hardware model

[hr raattgift]

Hindsight.

At the time, the obviousness of being able to target an industry-standard, pervasive platform, just wasn't obvious. There simply wasn't such a platform with many megabytes of memory, many gigabytes of disk, processors which could handle hundreds of millions of operations a second, and so forth.

There were interpreted Lisps on a variety of platforms that were in common use. There were a handful of compiled Lisps. Most notably, MacLisp in ITS (and later on other OSes on PDP-10s), which was so popular at MIT's AI lab that enough was developed in it that performance became a key issue.

At the time it made sense to investigate hand-building a machine that would be an optimal target for a compiled Lisp, especially in that it would make known optimization techniques easier, and would welcome rather than tolerate large garbage-collected heaps.

Nowadays, Scheme textbooks like the excellent SICP: Structure and Interpretation of Computer Programs (or, say, The Schematics of Computation) introduce compiler-writing and target an implementation of a virtual machine. These VMs are directly analogous to the actual CADR hardware. On modern fast computers, they run faster than the actual processor hardware in the physical CADR. Running a VM with performances down in the 1/double-digit or 1/triple-digit of physical processors would have been intolerable back then.

There were always people working on targetting mass-produced general-purpose hardware, it's just that there was a lot of learning to be done about how to optimize things.

Lots of that work was done in the context of the amazing T project. The T compiler was a massive watershed development for Lisp compilation, as it implemented or introduced such things as efficient lexical scoping; simplifying the code through transformation until you were left with operations on only as many variables as you have registers; lambda-lifting; CPS-transformation; dramatically improved copying garbage collection; "pseudo-hardware typing". A number of other innovations directly stem from these.

One look at this is Olin Shivers writing about his memories of the T project.

Nowadays, with these techniques, and others learned since, compiling Lisp to practically any modern processor is straightforward. Modern Lisp and Scheme compilers generate either efficient and fast native code, or portable C (to the extent that it should work on any 32 or 64 bit platform gcc supports).

There remain some implementations that target a tight purpose-written VM, like CLISP or Scheme48 does. There are some implementation that target other VMs, particularly the Java one, compiling into JVM bytecodes or Java as an intermediate language.

The cheapness and reasonable speed of VMs, the efficiencies of compilers targeting C, assembly, or native machine code, and the tightness of runtime environments supporting type-handling and garbage collection, are such that practically nobody would seriously think about building hardware dedicated to supporting Lisp like languages.

With the benefit of hindsight, you are completely right.

The two points you raise, prior to T, would have been thought of as somewhere between funny and insane.

T was ca. 1982.

The CADR Lisp Machine was started ca. 1975 and documented in AI memo 528 in 1979.

Lisplike-compiled-language-favourable hardware chugged along until the early 1990s, when they collectively could no longer compete with the performance (never mind the price) of implementations compiling for x86, SPARC, Alpha, and a few other popular workstation instruction sets.

Re:LispM had a superiour hardware model

[hr raattgift]

would be nice for hardware to provide tag bits so integers and floats wouldn't have to be twiddled before doing arithmatic on them

Tag bits are nice so you can precisely distinguish pointers from everything else.

This lets you implement a precise garbage collector rather than a conservative one. This makes modern tracing GC (fast, compacting (especially to increase locality of reference), incremental, even backgroundable) much easier to implement.

If you sacrifice one bit from your native machine's word size, you can distinguish pointers from all other objects.

Most modern systems use byte addressing rather than word addressing, and if you word-align all your data, you don't need your least significant bits. So on a 64-bits-per-word machine, you can sacrifice your LSB and still have 63 bits to play with; on a 32-bits-per-word machine, you have 31, hell, on a 16-bits-per-word machine you have 15. Don't ask about truly 8-bit machines like the 6502. :-)

Word-alignment on a byte-addressed 16-bit machine gives you 15 bit pointers -- you only have to address every second byte, starting at all zeros. Address 1 is part of the very first word, so 0000000000000001 (binary) is something we don't need to address directly. We can use that 1 bit to indicate that the object is NOT a pointer.

We can do the same for 32 and 64 bits: ...00 (binary) is the address of a 32-bit word on a byte-addressed architecture; ...0000 (binary) is the address of a 64-bit word, and so forth.

All you need is a shift-all-the-bits-in-the-word-left instruction.

Instead of: load register,memory; , store memory,register, we:

1. Load register

2. Shift word to the right. bit0 goes away, most-significant-bit is now 0.

3. Perform arithmetic operations as usual, leaving result in register.

4. Shift word one bit to the left, immediate-or the word with 1.

5. Store the word into memory.

This works great for 2s complement integer arithmetic, with an absolute range of values of 2^wordsize-1.

As noted, on 32-bit architectures and 64-bit architectures, we have more bits that are meaningless in pointers to word-aligned objects. We just do more shifts.

Typechecking involves a step between 1 and 2, where we look at whether the least significant bit is really 1 before doing integer arithmetic.

If we have more tag bits, we can have more typechecking along these bit-testing lines.

The cost of the register shifting can be small or large depeding on architecture. Usually it's small on modern chipsets.

It's not clear that hardware tagging would be a clear win. Mostly it would have to be evaluated in terms of decreasing the number of instructions by consolidating dropping back to e.g. three to do an untypechecked integer load-add-store from six (load-shift-add-shift-or-store). That is, the extra three instructions are unlikely to add so much extra dependency or processing time, or rob users of sufficient fixnum precision, that pushing distinguished and precise identification of pointers into the processor becomes worthwhile.

Moreover, with foreign-function-interfacing, one can jump into another language (like C) to do full native untypechecked integer (or other) maths, just so long as it doesn't put results that look like pointers into GC-managed memory.

Chicken is one example of this approach. It uses Cheney-on-the-MTA to do the nursery area of its fast, compacting, generational garbage collector *portably* to byte-addressed 32-or-64-bit word architectures. Since all objects are word-aligned, that gives two or four bits of "tag", which it uses to precisely identify pointers, integers, and a few other types, both for typing and for GC purposes.

By comparison, the CADR's hardware architecture ultimately supports polymorphism

Re:LispM had a superiour hardware model

[IpalindromeI]

For example, in (strict) functional languages, the following two statements can be executed in parallel:

Just a minor point, but when you say "strict," do you mean "pure"? My main exposure to the functional paradigm is Haskell, where "strict" means "the opposite of lazy." In that sense, I don't see why it matters if makea() and makeb() are strict, but it would matter that they are pure. Just trying to clear up my own confusion.

Re:LispM had a superiour hardware model

[be-fan]

You are, of course, right. I didn't mean to imply that the LispM was "bad engineering", merely that in this day and age, with the types of processors we have, it wouldn't be performance-competitive to have a "Lisp chip". Ultimately, its a question of optimizing your performance by drawing the hardware | compiler line in the right place. As the nature of hardware and of compiler technology changes, that line will move around. It seems to me with clock-speeds hitting a wall, and hardware designers having more transistors than they know what to do with, that line may shift back towards hardware a bit. I'll wager that Intel and AMD *will* in the not too distant future eventually support pointer tag bits in hardware. With everything moving to .NET and Java as it seems to be doing, improving GC performance won't just be a niche goal. Moreover, stuff like indirect branch prediction, which is now being done to make up for the latency of accessing main memory, will help things like generic dispatch in Lisp.

Re:LispM had a superiour hardware model

[be-fan]

Yeah, I meant 'pure', not 'strict'. I just couldn't think of the word at the time...

BitTorrent is overkill.

[Anonymous Coward]

They could have simply set up a BitTrickle to handle both interested parties.

Re:LISP (OT)

[John Meacham]

the x87 is so broken but luckily, we are no longer shackled to it.

part of the x86-64 spec is full support for SSE and in fact, the SSE instructions are meant to completly replace the use of the x87, which is only there for legacy support.

I think a lot of the gain of x86-64 will be from being able to _count_ on sse support and use it when compiling in addition to just its 64bit nature.

although, a lot of distros are dropping support (at least optionally) for pre-SSE cpus to always compile with it enabled so we are already starting to see some of the benefits.

RMS Essay: Come Celebrate the Joy of Programming

[SimHacker]

How ironic that they released the LispM sources under a BSD-like license instead of GPL.

Here is an essay written a while ago (1986 or so) by Richard M Stallman (RMS), telling his side of the story about the MIT AI Lab, and the Lisp Machine Wars.

Many other sides of the story, less extreme than from RMS's viewpoint, are covered here and here and here and here and of course here.

Machine Room Folk Dance, Thursday at 8pm. Come Celebrate the Joy of Programming, with the World's Most Unbureaucratic Computers. (There were only five of us dancing, but we had a good time.)

[...] The Lab Betrayed

There is still an institution named the MIT Artificial Intelligence Lab, and I still work there, but its old virtues are gone. It was dealt a murderous blow by a spin-off company, and this has changed its nature fundamentally and (I believe) permanently.

For years only we at the AI lab, and a few other labs, appreciated the best in software. When we spoke of the virtues of Lisp, other programmers laughed at us, though with little knowledge of what they were talking about. We ignored them and went on with our work. They said we were in an ivory tower.

Then parts of the "real world" realized that we had been right all along about Lisp. Great commercial interest in Lisp appeared. This was the beginning of the end.

The AI lab had just developed a computer called the Lisp machine, a personal computer with a large virtual address space so that it could run very large Lisp programs. Now people wanted the machine to be produced commercially so that everyone else could have them. The inventor of the Lisp machine, arch-hacker Richard Greenblatt, made plans for an unconventional "hacker company" which would grow slowly but steadily, not use hype, and be less gluttonous and ruthless than your standard American corporation. His goal was to provide an alternative way of supporting hackers and hacking, and to provide the world with Lisp machines and good software, rather than simply to maximize profits. This meant doing without most outside investment, since investors would insist on conventional methods. This company is Lisp Machines, Incorporated, generally called LMI.

Other people on the Lisp machine project believed this would not work, and criticized Greenblatt's lack of business experience. In response, Greenblatt brought in his friend Noftsker, who had left the lab for industry some years before. Noftsker was considered experienced in business. He quickly demonstrated the correctness of this impression with a most businesslike stab in the back: he and the other hackers dropped Greenblatt to form another company. Their plan was to seek large amounts of investment, grow as rapidly as possible, make a big splash, and the devil take anybody or anything drowned in it. Though the hackers would only get a small fraction of the fortunes the company planned to make, even that much would make them rich! They didn't even have to work any harder. They just had to stop cooperating with others as they had used to.

This resulted in two competing Lisp machine companies, Greenblatt's LMI and Noftsker's Symbolics (generally called "Slime" or "Bolix" around the AI lab). All the hackers of the AI lab were associated with one or the other, except me, because even LMI involved moral compromises I didn't want to make. For example, Greenblatt is against proprietary operating system software but approves of proprietary applications software; I don't want to refuse to share either kind of program.

I strongly suspect that the destruct

Not even close (Re:Nice...)

[argent]

Does that make this the oldest software to be released under an "open-sourceish" license?

Hell no. Not even close.

There was a thriving free software community back in the '70s, with operating systems, compilers for C, Forth, Basic, Pascal, and other languages, editors, graphics systems... all released to the public domain or under BSD-style licences. Heck, there were already Berkeley Software Distribution tapes circulating when most of this code was being written, and those contained software under all kinds of licenses.

Let's see... just off the top of my head, thinking back a quarter of a century, I used Small C (1980), Fig-Forth (1978), Software Tools (1976), ... the "Free Software Movement" was already in high gear years before Stallman decided *he* was going to invent it.

Re:LISP [MOD PARENT DOWN]

[Anonymous Coward]

Shut the fuck off, shut the fuck off, shut the fuck OFF!

The parent is very confused and wrong. Please don't moderate up someone who simply pretends to know what he's talking about. That's so stupid.

Re:This is News?

[masklinn]

As in Philip Greenspun's 10th Rule of Programming you mean?

Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.

SUN had a superiour hardware model

[Anonymous Coward]

"I know I'm really going to get flamed for this, but I think it's true: RISC is to blame for a lot of these problems."

Umm, no it isn't. The adoption of an Algol based language was. The chips by SUN are RISC chips with a tag instruction as part of it's set. As for number one. Most processors have a memory access violation instruction. That's how one can have a multiuser OS.

Why design a new language?

[Peaker]

Why design a new language to solve the problem? We have Python...

The main feature you get from Lisp macros that allow new features to solve specific problems, is a performance enhancement. The vast majority of features that use macros in Lisp, can be implemented via passing around functions in Python (very similar to unevaluated arguments). Sure, performance-wise it sucks, but in Python, that doesn't matter.

There are very very few cases where an actual new syntax or language is useful for a specific domain, and in those cases you can use an ugly String for parsing.

The real tradeoff in most cases is between a readable syntax (Python) and performance (Lisp macros).

I'd take the former any day.

Re:Why design a new language?

[stevesan84]

It's been my experience that Lisp macros, _when used well_, make code more readable and natural.

The argument that Lisp macros make for un-readable code could also be applied to functions: if a bad programmer writes a bunch of functions named foo1 foo2 bar3 mybar myfoo, that would make the code unreadable as well. I guess ANY abstraction suffers from this potential flaw. It's just a matter of what we're used to.

Most (I hope) programmers know how to write nice, self-contained functions that are well-named and well-documented. This adds to the readability and maintainability of the code. dotproduct(a,b) is a lot clearer than (a.x*b.x + a.y*b.y).

Unfortunately, most programmers don't know how to write nice, self-contained LISP macros, so LISP macros get a bad rep. This is unfortunate, since LISP macros can make code MUCH clearer.

Paul Graham's "On Lisp" offers many great patterns for LISP macros, but he (ironically) names them very strangely. Like, map-> for example..it's not really obvious what that macro is used for. However, what about a macro like with-open-file? In my opinion, with-open-file makes it painfully obvious what a block of code does: It does some stuff to an open file, which is implicitly closed at the end of the block. And this avoids issues like forgetting to close a file after use, because the macro handles this implicitly.

Everyday in my non-LISP programming tasks, I see code that would be much clearer and easier to maintain given some LISP macro-like functionality. You really need to use LISP macros to realize their power, so it becomes second nature to see where they can HELP. Any language feature can be abused, but when used properly, they help greatly.

Peter Seibel's "Practical Common Lisp" offers some great examples of macro usage with the CD Database chapter.

Re:Why design a new language?

[sickofthisshit]

NO. YOU ARE ABSOLUTELY WRONG.

The point of Lisp macros is NOT run-time efficiency.

It is PROGRAM WRITING-time efficiency.

As a simple example, say you need a control structure which ensures that files are closed properly on abnormal exit. You can, of course write this with an

(let ((stream (open "foo.txt"))
    (unwind-protect ...your code to write stuff to foo.txt...
      (when stream (close stream)))) ; this gets executed "no matter what"

But, you decide this is too hard to remember to do every time.

So you invent (if it didn't already exist)

(defmacro with-open-file ((stream-sym pathname) &body body)
    `(let ((,stream-sym (open ,pathname))
          (unwind-protect ,@body
        (when ,stream-sym (close ,stream-sym)))))

Then, you can simply say

(with-open-file (stream "foo.txt") ...code to work on foo.txt...
)

That is, you have added a control structure to the language which transparently implements the otherwise annoying hassle of doing the right thing every time. The resulting code is more compact, MORE readable (because with-open-file replaces a verbose, spread-out unwind-protect form), and makes robust code EASIER TO WRITE.

You can do similar things to encapsulate database transactions, or what have you, or implement iterations over complicated data structures.

The way Lisp macros lead to program efficiencies is secondary: the macros are writing your program, and you can give them enough description of the problem with enough context for the macros to implement optimizations that would otherwise be a total pain to do by hand. Essentially, you write a compiler which takes your problem description and emits optimized Lisp code to solve the problem. Conventional compilers take source code and emit machine code. Lisp-based compilers take source code and emit Lisp code which is almost always in the form of machine code instructions. Macros make that kind of thing almost trivial to write.

Re:Why design a new language?

[Peaker]

You missed my point.

My point is that such macros are implementable, including with-open-file (See my reply to the sibling post).

Re:Why design a new language?

[Peaker]

You are missing my point.

(with-open-file (stream "foo.txt") ...code to work on foo.txt...)

My point is that the above is already implementable without macros.

In Python, for example, I can create a generic "with" that's even more powerful than (with-open-file) that does:
def with((initializer, finalizer), func):
        result = initializer()
        try:
                func(result)
        finally:
                finalizer(result)

def openfile(*args):
        def initializer(): return open(*args)
        def finalizer(file): file.close()
        return (initializer, finalizer)

And then I can use:

with(openfile('filename', 'wb'), write_to_file)

Or I can use:

with(mymutex(blah.lock), blah.do_stuff)

Can you find an example that is implementable with macros, but not implementable without the quirky evaluation rules?

Re:Why design a new language?

[sickofthisshit]

I didn't miss your point.

Passing around functions is something Lisp is perfectly capable of doing. (And without any performance hit, because our anonymous functions are compiled to machine code just like our named functions.) But--guess what?--we don't use it to implement control structures, even though we could. One quickly finds that the function-passing style is LESS readable and LESS convenient than real Lisp macros.

You plainly misrepresent Lisp macros if you claim they are about moving basic operations to read-time instead of run-time. They implement program *transformations* that BY DEFINITION must occur at code-reading time (but before compile-time). By the time the program actually runs, it is too late to rewrite it, after all.

Re:Why design a new language?

[sickofthisshit]

Argh, Slashdot seems to have lost my post. Here I go again.

I didn't miss your point.

Lisp can pass around functions as well, *without* any performance hit, because our anonymous functions are compiled to machine code in advance just like our named functions are. But--guess what?--we don't use that power to implement control structures because it turns out to be LESS readable and LESS convenient than real Lisp macros.

You plainly *misrepresent* Lisp macros if you believe they are about moving basic operations to read-time instead of run-time. They are about implementing program TRANSFORMATIONS that obviously have to occur before compile-time, because, once the program is running, it is too late to transform it. (Although there is still plenty of dynamic behavior a running program to use, including compiling new code. But that is more along the lines of introspection and reflection, not code transformation.)

Re:Why design a new language?

[sickofthisshit]

Argh, Slashdot seems to have lost my post. Here I go again.

Your point was not missed.

Lisp can pass around functions as well, *without* any performance hit, because our anonymous functions are compiled to machine code in advance just like our named functions are. But--guess what?--we don't use that mechanism to implement control structures because it turns out to be LESS readable and LESS convenient than real Lisp macros.

You plainly *misrepresent* Lisp macros if you believe they are about moving basic operations to read-time instead of run-time. They are about implementing program TRANSFORMATIONS that obviously have to occur before compile-time, because, once the program is running, it is too late to transform it. (Although there is still plenty of dynamic behavior a running program to use, including compiling new code. But that is more along the lines of introspection and reflection, not code transformation.)

Re:Why design a new language?

[hutchike]

Was your posting in triplicate by any chance a side-effect of your macros? I was noting this at "read time" ;-)

Re:Why design a new language?

[Peaker]

Lisp can pass around functions as well, *without* any performance hit, because our anonymous functions are compiled to machine code in advance just like our named functions are. But--guess what?--we don't use that mechanism to implement control structures because it turns out to be LESS readable and LESS convenient than real Lisp macros.

Maybe in Lisp, but in a language that has good closure syntax, what's the advantage of macros?

Why do I want macro transformations, if the same features can be achieved by passing around closures? Even if there's a very slight syntatic overhead of using a closure to basically denote: "I dont want this evaluated now", many would consider this an advantage because it makes it clear what code is evaluated when, and there's no need to look for "magic" in every used function.

To "prove" the point either way, please show any expressive power macros grant you, that is not possible without macros, using closures alone. By "possible without macros" I mean possible with the roughly the same amount of work for the macro user, up to a small factor of change. This means that if you can find a macro that reduces the amount of syntax I need to use to do something by a large factor, or by an order of magnitude, you win. If you can't, macros are unnecessary.

Re:Why design a new language?

[cpu_fusion]

Domain specific languages are actually very useful, and (with a simpler syntax than Lisp or Python), may be tailored for people on the periphery of programming.

Re:Why design a new language?

[sickofthisshit]

Well, how about adding object-oriented programming to a language which previously did not include it?

Multiple pre-CLOS object-oriented extensions to Lisp were written using heavy-duty macrology.

How about adding Prolog-style logic programming to a language which previously did not include it?

You can do so in Lisp, and macros are the best tool for the job.

How about adding an English-like syntax for defining common looping constructs? Lisp's infamous LOOP macro could be and was developed by *users* who didn't have to wait for some language implementor to do it for them.

How about a whole book's worth of code?

What about allowing simple application-oriented forms to declare and define multiple associated functions and data structures?

The basic fact is that Lisp programmers f*cking INVENTED the use of closures in programming, and they STILL PREFER MACROS by a large margin to implement control structures. Do you think they all are brainwashed, or stupid amnesiacs, or what? Does learning "defmacro" somehow block all memory of "lambda"? If it were just a matter of "good closure syntax", we'd use defmacro to define a nicer syntax and use it. But the plain fact is that the syntax is superficial---the expressive power is fundamental.

The code transformations possible greatly outnumber the total number of closures it is reasonable to ask a higher-order-function user to pass it. Furthermore, forcing the use of closures means the user of your utility has to jump through more hoops to use it, and makes your design more complicated.

Re:Why design a new language?

[sickofthisshit]

Some slashdot server decided to freeze up and take an hour to include my posts. Sorry.

Re:Why design a new language?

[Tayssir John Gabbour]

Also, many find this a great intro to Common Lisp. With examples of building .mp3 servers and unit test frameworks.
http://www.gigamonkeys.com/book/

Re:Why design a new language?

[Tayssir John Gabbour]

This means that if you can find a macro that reduces the amount of syntax I need to use to do something by a large factor, or by an order of magnitude, you win. If you can't, macros are unnecessary.

This is tiresome and unprofessional. What kind of computer "science" is this where technical matters win/lose based on slashdot discussions?

A very good recent book explains Lisp macros in readable detail. http://www.gigamonkeys.com/book/

Re:Why design a new language?

[be-fan]

Okay, here is an example I've encountered in my own code.

Say you've got a generic method A, and two types B and C. B and C are not related in the type hierarchy (because there is no logical relationship between the two), but as far as A is concerned, they are both handled the same way. In Lisp, I used a simple macro to extend defmethod to allow me to specify multiple matching subclasses. The macro would expand to multiple defmethods, each specializing on one subclass, but containing the same body. Basically, I could write:

(defmethod-multi A ((arg (B C))) ...long boring code using arg...)

No other code had to be aware of this implementation trick. They could just call A as usual, and get the expected result.

Try achieving the same thing with a function that takes a closure. Hell, try this:

; extend a list with another list
(defmacro push-extend (value lst)
    `(setf ,lst (append ,lst ,value)))

Re:Why design a new language?

[SimHacker]

Language design is like the opposite to mountain climbing:

Q: Why design a new language?
A: Because it isn't there yet.

We wouldn't have Python if people took your "why design a new language" argument seriously. Language design would have stopped years ago, with that parochial attitude.

Peaker, carefully read what "sickofthisshit" wrote about Lisp macros -- he hit the nail on the head: they're extremely important and Python suffers from not supporting them.

You are dead wrong about there being few cases where domain specific languages are useful.

I love Python and I write a lot of code in it, but the one big thing it's missing is macros. You can't just strap a decent macro system onto Python (or Java), because of Python's non-lisp-like syntax. Sure, Python has a parse tree api, but seriously, have you ever actually taken a look at it?!? It's *HORRIBLY* low level and totally inappropriate to implement a macro system with.

Lisp's parenthesis are just as easy to get used to as Python's indentation. There's nothing unreadable about Lisp syntax, unless you simply don't know the language, in which case you're not qualified to criticize it.

Sure, Python is great for whacking off web servers, but as you point out, it's not compiled, it's interpreted by its very design (which is why you seem to think that evaluating strings is as powerful as macros). You don't seem to get how important it is that Lisp code can be efficiently compiled, and that the programmer can deeply extend the compiler and tailor the language with macros.

-Don

Re:Why design a new language?

[Anonymous Coward]

Peaker, the problem is that you want to say:

with(openfile('filename', 'rb'),
lambda file:
for line in file.readlines():
        print "Another line from the file: %s"g % line
)

Now, you can't do that because lambda in Python doesn't actually let you do statements -- only expressions. You can do it in Lisp, and I don't know why these people don't.

Re:Why design a new language?

[FrangoAssado]

Peaker, the problem is that you want to say:

Exactly.

People who never *really* use closures to do serious programming are quick to dismiss them as a just superfluous convenience. It's like dismissing object orientation as just a convenient way to group together functions that manipulate some data structure.

While (in a very strict sense) true, this view misses the whole way of thinking that these concepts -- closures and object orientation (just examples, by the way) -- introduce and suggest.

You can do it in Lisp, and I don't know why these people don't.

In this simple example, it can be argued that a macro is an overkill (however, as it's available, I don't see why not use it). However, for more complicated examples, macros do *really* make code more readable, and using them is a huge time saver. If you excuse my saying so (I feel so dirty saying this, but it illustrates the point well): for a heavy macro user, using macros is a bit like going from ancient BASIC (where all you had was GOSUB) to its newer incarnations, where you can properly define and call functions.

Re:Why design a new language?

[Estanislao Mart�nez]

#
# Or in Ruby (if memory serves me right):
#
File.open('filename') { |file|
  file.each_line { |line|
    puts "Another line from the file: " + line
  }
}

Re:Why design a new language?

[Anonymous Coward]

Python doesn't suffer for not having macros. Lisp wishes that it suffered as much as Python suffers. Perhaps you find their absence especially disturbing. Personally I could find more annoying aspects to Python than its lack of macros with little trouble. The lack of fully-functional lexical closures. The existence of two object systems. A standard library without a complete collection of basic datastructures. Decorators. No assignment in control flow. Multiple types of 'true' and 'false.' The deprecation of xrange and continued embrace of the strict range.

Re:Why design a new language?

[eff]

You can do this in Python too, thanks to generators (which lets you treat inline code as "template methods" in controlling classes). There are some limitations in the current design (related to object passing and exception handling) which will be addressed in a future release:

http://www.python.org/peps/pep-0343.html

For the bigger perspective, see:

http://www.python.org/peps/pep-0340.html (an earlier version of 343)
http://www.python.org/peps/pep-0342.html (the "other half" of 343)

Re:Why design a new language?

[Peaker]

Language design is like the opposite to mountain climbing:
  Q: Why design a new language?
  A: Because it isn't there yet.
  We wouldn't have Python if people took your "why design a new language" argument seriously. Language design would have stopped years ago, with that parochial attitude.

My wording was bad.
I did not mean "Why design a new language?" in the general sense, I meant: "Why design a new language in the context of every software project?".

Designing a new language such as Python, Haskell, etc. is great. I find every new language great exploration. But I think creating a language-design platform such as Lisp is silly as I believe designing a new language whenever you write software is far from useful.

Peaker, carefully read what "sickofthisshit" wrote about Lisp macros -- he hit the nail on the head: they're extremely important and Python suffers from not supporting them.

I already replied as to why "sickofthisshit" is wrong, and explained how his example of a useful macro can be implemented just as nicely without a macro.

You are dead wrong about there being few cases where domain specific languages are useful.

Domain-specific languages are useful in many cases, but they are still a small percentage of most programming work. But even domain-specific languages, as I have shown, do not require a new syntax. They can be created in Python by overloading a new semantic to existing syntax (Operator overloading and instance composition).

I love Python and I write a lot of code in it, but the one big thing it's missing is macros. You can't just strap a decent macro system onto Python (or Java), because of Python's non-lisp-like syntax. Sure, Python has a parse tree api, but seriously, have you ever actually taken a look at it?!? It's *HORRIBLY* low level and totally inappropriate to implement a macro system with.

But as I explained, a macro's main power is that it takes its arguments unevaluated. This is possible by wrapping args in closures and not evaluating them. Python supports this (although with a bit cumbersome syntax), and thus almost every useful macro in Lisp can be rewritten as a function-that-takes-closures in Python.

Lisp's parenthesis are just as easy to get used to as Python's indentation. There's nothing unreadable about Lisp syntax, unless you simply don't know the language, in which case you're not qualified to criticize it.

There is a huge consensus about Lisp's syntax. Its the main point against its acceptance. It is very important to programmers how their language looks. Lisp syntax is harder to read, even after a few weeks of using it. Python syntax was immediately amazingly readable, after 2 days of toying around with it.

Sure, Python is great for whacking off web servers, but as you point out, it's not compiled, it's interpreted by its very design (which is why you seem to think that evaluating strings is as powerful as macros).

I don't think evaluating strings is nearly as powerful as macros, I just don't think that there are many cases in which that is requried (again, see my above claim about passing around closures).

You don't seem to get how important it is that Lisp code can be efficiently compiled, and that the programmer can deeply extend the compiler and tailor the language with macros.

I agree that the main point of macros is more optimized code, but I believe that:

• The vast majority of software written is not about localized performance, but about minimizing round-trips and doing "the smart thing". Thus, much Python software is actually faster than much competing lower-level language software.
  
• The effect of an optimized Lisp macro can be achieved by inlining the called function and the closure calls it uses. This should achieve the peformance gain in almost all uses of macros.
  
• Optimization macros can be supported by the language, ones that let you control register allocation policy, inlining, etc. Lisp macros cannot currently do this. I believe this is much more difficult, though, than just writing the smaller portions that need to be fast in a lower-level language.
  

Re:Why design a new language?

[Mad Marlin]

Here is a simple example.
There is no "while" loop in Common Lisp, but I think it sometimes makes the code clearer.  With it, I can write
(while (> x 10)
  stuff ...
  stuff ...
  stuff ...)

;;; A WHILE macro, operating in a matter similar to the while loop in C.
(defmacro while (conditional &rest body)
  `(do ()
     ((not ,conditional))
     ,@body))

Along the same lines, I defined an "until", which is of course achievable in C by
while (!whatever())
{
    stuff ...
    stuff ...
    stuff ...
}
but I view it as more clear as well.

;;; An UNTIL macro.
(defmacro until (conditional &rest body)
  `(while (not ,conditional)
     ,@body))

Now I can write
(until (x <= 10)
  stuff ...
  stuff ...
  stuff ...)
If that makes my intentions clearer.
This has the exact same results as above, but the difference can mean a lot to me when I try to understand the code later on.

I am reasonably certain that these are impossible in Python, especially in any way that would add clarity, which is the whole point.
I am absolutely certain that it is literally impossible in C, C++, Java, Fortran, Cobol, Perl, and basically anything else.

Common Lisp macros allow you to code what you mean, not just something which happens to be functionally equivalent.

Re:Why design a new language?

[Peaker]

Well, how about adding object-oriented programming to a language which previously did not include it?

Multiple pre-CLOS object-oriented extensions to Lisp were written using heavy-duty macrology.

How about adding Prolog-style logic programming to a language which previously did not include it?

You can do so in Lisp, and macros are the best tool for the job.

How about adding an English-like syntax for defining common looping constructs? Lisp's infamous LOOP macro could be and was developed by *users* who didn't have to wait for some language implementor to do it for them.

How about a whole book's worth of code?

What about allowing simple application-oriented forms to declare and define multiple associated functions and data structures?

The basic fact is that Lisp programmers f*cking INVENTED the use of closures in programming, and they STILL PREFER MACROS by a large margin to implement control structures. Do you think they all are brainwashed, or stupid amnesiacs, or what? Does learning "defmacro" somehow block all memory of "lambda"? If it were just a matter of "good closure syntax", we'd use defmacro to define a nicer syntax and use it. But the plain fact is that the syntax is superficial---the expressive power is fundamental.

The code transformations possible greatly outnumber the total number of closures it is reasonable to ask a higher-order-function user to pass it. Furthermore, forcing the use of closures means the user of your utility has to jump through more hoops to use it, and makes your design more complicated.

Why don't you just show an example of a macro that cannot be just-as-reasonably (or almost-as-reasonably) implemented without the quirky evaluation rules?

Ofcourse a language that has no macros is going to need to be very powerful in the first place. And indeed, when Smalltalk programmers wanted looping constructs, they also didn't have to implement new language features. They just implemented methods that take closures as arguments and create very nice and readable loops:

(pseudo-Smalltalk):

(1 to: 10) do: [ i |
    stdout write: i
]

[i < 10] do: [
    stdout write: i
]

Re:Why design a new language?

[Peaker]

I am not dismissing closures. I do think Python could enjoy more powerful closure syntax (It does have closures, they just require a lot of syntax).

Python was just an example. As some other poster showed, Ruby can use closures to achieve the same feat just as well.

Re:Why design a new language?

[Peaker]

Guido van Rossum has shown a multimethod implementation in Python. That implementation supports your example as well, as the rules which define what types invoke which methods are easily extensible.

Re:Why design a new language?

[Peaker]

Python does not support very nice closure syntax, so it is indeed difficult. But my argument is not about Python vs. Lisp, its about macros and their necessity.

Look at the implementation of loops in Smalltalk, they are implemented as methods that take closures and range objects, i.e:

[i <= 10] doUntil: [ i | .. ..
]

[i > 10] doWhile: [ i | .. ..
]

I find this very readable, and it does not have to break the evaluation rules of the language.

Re:Why design a new language?

[Anonymous Coward]

You're defining a method on a sum type. Dispatching on a sum type doesn't require the use of macros. As you've explained your macro, it duplicates code. A sum type that is the union of N types requires N copies of your method. The creation of a sum type on which methods are defined then requires no modification of the call sites at all, and doesn't require an implementation body defined for each member of the sum type.

Re:Why design a new language?

[sickofthisshit]

Assuming you are representing Smalltalk accurately, that seems to be a more "quirky" evaulation rule than most macros use.

How am I supposed to know that a simple expression like [i < 10], which looks like it should be a simple true/false test on the current value of i, somehow turns magically into a loop when followed by do? How am I supposed to know if it starts at 0? or 1? (That seems to be an artificial choice, after all there are plenty more integers like -1, -2, -3, ..., hey, an infinite number, in fact! ... which could satisfy that expression.) And how do I know that i takes only integer values?

Seems like any feature put in the language by a good language designer is fine by you, but the second anyone uses a Lisp macro to extend the language in a useful way...WHOA, YOU'RE GETTING QUIRKY!!! STOP IT, OR SOMEONE COULD LOSE AN EYE!!!

How about we just call all the Lisp programmers "language designers" and then they are allowed to get as quirky as they want?

Or how about you learn how Lisp programmers actually work or shut the fuck up about it?

Re:Why design a new language?

[be-fan]

You missed the point. I don't care about GVR's multmethod implementation --- I'm using CLOS. Since you say that functions taking closures are equivalent to macros, you should be able to write a function that emulates my macro.

It's easy to extend something that was designed to be extended in particular ways. That's not what you need macros for. You need macros to define constructs that aren't planned-in to the base code to begin with.

Re:Why design a new language?

[Peaker]

But CLOS is heavily based on macros in the first place. So it would be hard to extend it in other ways. A system based on closures would allow modifying it by giving different closures.

When the multimethod definition of CLOS itself is a macro, how am I supposed to use a function to call a macro differently? You are assuming macros as a basis, and then explaining that closures cannot extend them as macros can. If you take the equivalent multimethod system that's not based on macros, it becomes extensible without macros.

Re:Why design a new language?

[Peaker]

Actually [] denotes a closure in Smalltalk, and "do" may as well be called "doWhile" (it may called doWhile, its been a while since I used it). Its quite clear that a method called doWhile and takes a conditional closure argument and a body closure argument uses the predicate to determine whether to execute the body.

The fact it is being enclosed in a closure means that it is not evaluated here, but in the called "doWhile" method.

In an equivalent macro:

(do (< a 10) ...)

it seems as though the (< i 10) expression is evaluated here and now, and not every iteration. This is the quirky evaluation behaviour I was talking about.

When I read somebody's code, I want him to be a coder, not a language designer, because I am willing to learn how his code works, but don't want to learn a new language every time I read a program.

Re:Why design a new language?

[be-fan]

The basic point you're missing is that macros can extend *anything*. It doesn't matter that CLOS is implemented using macros, it could be built-in to the language or even a closure-based multimethod system. Macros can extend it anyway. However, the closure-based system can only extend functionality that is both closure based and designed to be extended in a fine-grained manner. This situation makes macros strictly more powerful than functions taking closures.

Argh!-Dylan

[Anonymous Coward]

If the syntax really bothers you? Try Dylan. The only problem I see Lisp having is obtaining a good free IDE (they're all payware, limitware). Even Smalltalk has good IDE's available (both Squeak and Dolphin). The other is current information that's not expensive. For those who want to start on Lisp, try plt-scheme. A very helpful learning environment.

what is LISPM?

[xquark]

and why would anyone other than paul graham care?

Arash Partow

Rethinking Lisp Macros

[Peaker]

Lisp macros are somewhat like a function that receives its arguments unevaluated. Sure, the function executes at read-time, but it could, in principle, do all the logic in run-time - as long as its arguments are unevaluated.

Now, suppose we provide the reverse feature, of saying "dont-eval-this" (much like Lisp's quote), and use normal functions instead of macros.

We may lose some performance (moving work from read-time to run-time), but we gain simplicity and readability.

In most dynamic languages, there is no "quote" operator, but instead there are first-class function objects which are, for most purposes, practically equivalent (as any piece of unevaluated code can be enclosed in a closure definition). So that in practice, aside for trivial syntax issues, (almost) every macro can be converted to a function call with a closure argument.

For example, the "loop" macro can be converted to a set of functions (for/while/etc) that receive the conditional as a closure, and the loop body as a closure. This approach is used by Smalltalk.

Advantages of this macro alternative:
A. Simpler to enhance language, much easier than to write a macro
B. More predictability and explicitness about the evaluation of code
C. Does not require code to be representable as data

Disadvantages:
A. Some macros may provide more syntatic sugar
B. Performance, read-time work is moved to run-time.

I would say that Disadvantage A is moot because a nice readable syntax is something Lispers must give up in order to support macros in the first place. And that advantage B is not relevant for the vast majority of software development.

Thus, contrary to popular oppinion, macros don't really empower the developer, they just make it possible to create really powerful performance hacks at read-time. Their disadvantages far outweigh their advantages, and that is why they haven't won out.

Re:Rethinking Lisp Macros

[be-fan]

You're not solving the basic problem that macros solve, however. Receiving a function as a closure doesn't allow you to manipulate the function. You can use it as-is, but a lot of very powerful constructs require that manipulation. Many of the macros used in Common-Lisp programs could not be rewritten as a function taking a closure. A trival example is PUSH. Bigger examples are DEFUN, DEFCLASS, DEFMETHOD (pretty much all of CLOS, really), etc. Your loop example is particularly good. Languages like Python rely on hard-coded syntaxes for their looping constructs, which invariably express only a very limited subset of the looping constructs the programmer wants to use. Something like CL's LOOP macro is far more powerful (and wisely used, can be every-bit as readable), but could not be implemented as a function taking a closure.

As for "giving up a readable syntax", I consider Lisp's much more readable than C++. Lisp is readable if you're used to reading Lisp. Its unreadable if you're not. The same is true of C++. Before anybody complains about Lisp's syntax being unreadable, they should have at least a thousand lines of code (in an actual program, not some homework assignment!) under their belt. A thousand lines seems like a lot, but its a decent metric for seperating those who know Lisp and those who do not. Ask yourself: would you hire somebody who claimed to "know" C++, when they hadn't written more than a thousand lines in it?

Re:Rethinking Lisp Macros

[5pp000]

The above is wrong in so many ways I hardly know where to start.

Well, I'll start at the beginning. Macros are not like functions. As David Moon famously said, "Functions compute; macros translate." A macro is a syntactic abstraction, not a procedural or functional one.

It is true that some simple macros can be implemented as procedures that are passed closures of the code that would have been the macro subforms. In general, however, this is not the case. Macros can, for instance, establish variable bindings that capture free references within the body. For example, consider the well-known Common Lisp macro with-open-file:

(with-open-file (stream pathname)
(read-line stream))

The variable stream is bound to the stream that results from opening pathname; the body of the macro, which in this example consists of a single form, can refer to that variable.

It's true that one could get the same effect with closures:

(call-with-open-file #'(lambda () (open pathname))
#'(lambda (stream) (read-line stream))

and in fact, that's exactly the kind of thing one has to do when working in functional languages with no macros, but (a) it's less elegant because you're making the programmer do some of the macro's work, and (b) this is still a pretty simple macro.

Macros empower the developer by enabling the construction of syntactic abstractions -- each of which extends the syntax of the language. Like any other power, it is sometimes abused by the inexperienced; one can certainly write utterly unfathomable code using macros. But used well, macros greatly enhance the elegance, readability, and maintainability of code.

As for why macros are not more widely used, there are a couple of reasons. Lisp's minimalist syntax, so strange-looking at first glance, turns out to be one of its greatest advantages. The very simplicity of the syntax is exactly what makes it so powerful and general: user-defined constructs are invoked just like built-in constructs. While in principle a language with keywords and infix expressions could have an extensible grammar, syntactic extensions get much harder to manage in such a language because they tend to interact, causing ambiguities in the grammar.

And the second reason is one the above post touches on when it mentions the representation of code as data. Lisp is the only major language to give programmers access to a standardized tree representation of source code. The fact that the representation is a tree makes Lisp macros powerful (contrast the pitifully weak "preprocessor macros" of C/C++, which operate on a character string representation), and the fact that the representation is standardized makes them portable.

I have plenty of experience in more mainstream languages, but when programming for myself, I almost always use Common Lisp. Macros are a major reason.

Re:Rethinking Lisp Macros

[Peaker]

You're not solving the basic problem that macros solve, however. Receiving a function as a closure doesn't allow you to manipulate the function. You can use it as-is, but a lot of very powerful constructs require that manipulation.

I think that useful manipulations of this type should not be a function of the actual content of the function, but manipulations of the function object, and of what happens before/after the function.

Many of the macros used in Common-Lisp programs could not be rewritten as a function taking a closure. A trival example is PUSH.

Push is really something that the sequence types must support. Any generic macro definition such as PUSH is going to fail to be optimized on new sequence types. It is also more readable to support this operation as part of the sequence protocol, and to not support it where it is extremely expensive. In Python, if it is not possible to insert an element to a sequence without a very expensive operation, Python exposes this by requiring the specification of the expensive operation with a bit of extra syntax, and this is an advantage.

Bigger examples are DEFUN, DEFCLASS, DEFMETHOD (pretty much all of CLOS, really), etc.

This is not true:

def defun(name, func):
        func.func_name = name
        caller_namespace()[name] = func
        return func

defun('a', closure)

def defclass(name, bases, items):
        return new.class(name, bases, items) ...

Your loop example is particularly good. Languages like Python rely on hard-coded syntaxes for their looping constructs, which invariably express only a very limited subset of the looping constructs the programmer wants to use.

Python is not actually the good example I was talking about, in this case. I was referring to how Smalltalk implements looping.

Something like CL's LOOP macro is far more powerful (and wisely used, can be every-bit as readable), but could not be implemented as a function taking a closure.

Again, look at Smalltalk. Such a macro can be implemented as a set of functions that take a closure.

As for "giving up a readable syntax", I consider Lisp's much more readable than C++. Lisp is readable if you're used to reading Lisp. Its unreadable if you're not. The same is true of C++. Before anybody complains about Lisp's syntax being unreadable, they should have at least a thousand lines of code (in an actual program, not some homework assignment!) under their belt.

A language must have appeal, and that includes its syntax. If people feel they have to decipher the code through highly-nested expressions that all look alike, they are not even going to write 1000 lines of code in the language.
Other languages have a different syntax for the creation of builtin data types, for assignments, for attribute getting/setting, etc. This helps programmers read the program.

A thousand lines seems like a lot, but its a decent metric for seperating those who know Lisp and those who do not. Ask yourself: would you hire somebody who claimed to "know" C++, when they hadn't written more than a thousand lines in it?

I have written less than a thousand lines in Lisp, and indeed I wouldn't hire myself to write Lisp (unless I knew that I am a fast learner, and was hiring for at least a few years).

Lispers seem to miss the fact, that when millions of students are exposed to C++ or Java, they keep on using them after university. While when they are exposed to Lisp, they remember it as some really bad memory, a language they would never touch again.

This is not unimportant.

Re:Rethinking Lisp Macros

[Peaker]

and in fact, that's exactly the kind of thing one has to do when working in functional languages with no macros, but (a) it's less elegant because you're making the programmer do some of the macro's work, and (b) this is still a pretty simple macro.

I find it a lot more elegant, as it uses simpler primitives to achieve the same goal. Also, it makes it very clear where the variables come from, even if I don't know the "with-file" function (explicit function arguments).

# This is not really longer than the macro example so you cannot say that you have to "do" some of the macro's work. What work?

data = with(open_file('/etc/passwd', 'rb', lambda stream: stream.read()))

Macros empower the developer by enabling the construction of syntactic abstractions -- each of which extends the syntax of the language. Like any other power, it is sometimes abused by the inexperienced; one can certainly write utterly unfathomable code using macros. But used well, macros greatly enhance the elegance, readability, and maintainability of code.

Instead of changing the syntax itself, one can have a rich syntax to begin with, and only overload the semantics of the syntax. Some things should never change, for readability's sake. Things such as when code is evaluated and when its not. Macros break this rule and make reading Lisp much harder. While I can read code that uses functions I do not know with relative ease, I have no idea what's happening when macros are used, because there are no evaluation rules that the code adheres to.

As for why macros are not more widely used, there are a couple of reasons. Lisp's minimalist syntax, so strange-looking at first glance, turns out to be one of its greatest advantages. The very simplicity of the syntax is exactly what makes it so powerful and general: user-defined constructs are invoked just like built-in constructs. While in principle a language with keywords and infix expressions could have an extensible grammar, syntactic extensions get much harder to manage in such a language because they tend to interact, causing ambiguities in the grammar.

Again, if you assume syntactic extensions are a good thing (as opposed to semantic extensions by overloading an existing rich syntax).

And the second reason is one the above post touches on when it mentions the representation of code as data. Lisp is the only major language to give programmers access to a standardized tree representation of source code. The fact that the representation is a tree makes Lisp macros powerful (contrast the pitifully weak "preprocessor macros" of C/C++, which operate on a character string representation), and the fact that the representation is standardized makes them portable.

Again, if you assume syntactic extensions are an advantage. (btw: Python does allow you access to its code tree, but its rather inconvinient).

I have plenty of experience in more mainstream languages, but when programming for myself, I almost always use Common Lisp. Macros are a major reason.

You are one of a very tiny minority.

Re:Rethinking Lisp Macros

[be-fan]

I think that useful manipulations of this type should not be a function of the actual content of the function, but manipulations of the function object, and of what happens before/after the function.

Well, you're free to think that, but that's not the point. You say that functions taking closures are equivalently powerful to macros. If one can do things the other cannot, then that's not true, is it?

Push is really something that the sequence types must support.

Again, that's not the point! If the language already does what you want, then that's easy. But macros aren't needed to solve those easy things, they are needed to solve harder things! Eg: you can use macros to write domain-specific languages. Sure, it'd be easier of Lisp supported all possible DSLs to begin with, but that's not a great idea, is it?

def defun(name, func):
                func.func_name = name
                caller_namespace()[name] = func
                return func

This presupposes that your language allows you access to the symbol table at runtime. In Lisp, most named function references are resolved at compile-time. Again, if you assume features the base language doesn't have, then you can always come up with a rebuttel. But the point is that macros are a single construct that can extend the base language, while here you are constantly inventing base language functionality for each thing that can be handled by macros!

Again, look at Smalltalk. Such a macro can be implemented as a set of functions that take a closure.

I'd love to see someone try to implement CL's LOOP as functions taking a closure. You can get the same functionality, of course, but the synactical contortions would be non-trivial.

Other languages have a different syntax for the creation of builtin data types, for assignments, for attribute getting/setting, etc. This helps programmers read the program.

In Lisp, you have functions that do this (and your editor highlights them!). SETF, MAKE-INSTANCE, SLOT-VALUE, etc, stand out just as much to a Lisp programmeras =, new, and . stand out to a C++ programmer.

Lispers seem to miss the fact, that when millions of students are exposed to C++ or Java, they keep on using them after university. While when they are exposed to Lisp, they remember it as some really bad memory, a language they would never touch again.

Millions of students are exposed to *Scheme* in school. They are also exposed in an educational setting, where the professor (for your own good), makes you rewrite MAP, etc, doesn't let you use macros, etc. That explains part of the bad memory. The other part is that students don't know enough programming at that point to know what is useful and what is not. My counter-example is that comp.lang.lisp has many people who are experts in C++ or Java. When you've dealt with C++ codebases reaching into hundreds of thousands to millions of lines, you learn to appreciate Lisp.

Re:Rethinking Lisp Macros

[Peaker]

Well, you're free to think that, but that's not the point. You say that functions taking closures are equivalently powerful to macros. If one can do things the other cannot, then that's not true, is it?

Technically, macros are stronger, by allowing to define new syntax and not just new semantics. I just don't think this extra tLisp echnical strength actually empowers the programmer in real-world scenarios.

The only "real-world examples" I've seen here to where macros actually add power that functions don't, is when they were used to extend already-macro-based systems, in which there's no way to use a function to "wrap" a macro. If all macros are replaced with functions, then suddenly it is possible to do all those things.

Also, I agree that a weak language with macros is much better than a weak language without them. But in my experience, especially seeing what macros are used for, is that a strong language does not require macros.

I think every problem I've seen solved by Lisp is solved at least almost as adequately, and in almost all cases, more simply and with a clearer syntax, by Python.

This presupposes that your language allows you access to the symbol table at runtime. In Lisp, most named function references are resolved at compile-time. Again, if you assume features the base language doesn't have, then you can always come up with a rebuttel. But the point is that macros are a single construct that can extend the base language, while here you are constantly inventing base language functionality for each thing that can be handled by macros!

Actually, I regret using the caller_namespace() hack altogether. You should use an explicit assignment in such a case, but it would force you to name the function twice. That's why Python does have a special syntax for assignment+naming in the same time.

I do think that the number of syntaxes required in a language, to solve the vast majority of problems is a finite number, and that the evolution of languages has already discovered all or almost all of this required syntax. As such, permissing new syntax for the supposed cases of lacking syntax, is not worth the readability it takes away from programs.

I can read programs in almost any language with virtually no learning curve, but I can say reading Lisp code, and defmacro's is much more of a challenge, despite knowing the concepts very well.

Maybe there's a way, in theory, to create a language with macros that doesn't suffer from such readability problems and a horrible learning curve, but for now, it does not seem so.

Lisp programs are not, as you would expect according to the claims you stand behind, orders of magnitude smaller than the equivalent Python, Smalltalk or Ruby programs.

Re:Rethinking Lisp Macros

[5pp000]

You are right that macros effectively change the evaluation rules of the language. As such they need to be well designed, well documented, and used sparingly. And it helps a lot if the documentation is available at the touch of a key, as indeed it was in the Lisp Machine system -- one just put the editor cursor on a function or macro name and hit Control-Shift-D, and up would pop whatever documentation the author had written.

The point of with-open-file, as I should have explained, is that it promises that on any exit from the body, including nonlocal exits to an outer context, the file will be closed. I'm not sure what with in your with(open_file(...)) example is supposed to mean, so I won't comment on that.

Let me give you a real-world example that I would love to be able to do in C++ today, if only I could. I'm working on a parser in C++, and like most parsers, it builds an Abstract Syntax Tree (AST). The AST is constructed from nodes of various classes, and the definitions of those node classes follow a certain pattern. For example, each such class has, in general, some instance variables that hold the children of the node within the tree, and others that hold annotations that are not part of the tree structure per se, such as type information. Each such class should have a method children that gathers up the children into a set and returns it.

In C++, I have no way to abstract these rules; all I can do is manually write out the definition of each class, making sure to include all the necessary bits. This makes the class definition both harder to write correctly, since there are plenty of details to get wrong, and harder to read, since the high-level structure of the class is somewhat obscured by the details.

In Lisp it is a fairly straightforward matter to write a new class definition macro that allows one to simply list the instance variables that hold tree children, and automatically generates the various methods such as getters/setters and the children method. This would provide a much more elegant and less error-prone way of getting these classes defined, and the resulting definitions would be much easier to read (though yes, one would have to learn the syntax of the macro).

There's no support in C++ for doing anything like this. Preprocessor macros don't begin to be powerful enough. The only way to do it is to create another preprocessor that parses the high-level class definitions and outputs the C++ definitions -- which is certainly possible, but far more work than one has to do in Lisp.

You are one of a very tiny minority,

I'm keenly aware of that. But I have to use C++ at the office, and I'm also keenly aware of how much time I waste doing that, by comparison to working in Lisp. I'm easily twice as productive in Lisp, maybe more so.

It just saddens me that so many programmers don't know what they're missing, so when I see people arguing that the benefits of Lisp -- benefits I experience every day -- are not real, naturally I want to speak up.

Re:Rethinking Lisp Macros

[Peaker]

I did not compare Lisp to C++. I compared macros to functions-accepting-closures.

C++ does not even have closures, so your comparison is a strawman.

The situation you are talking about is very possible in a dynamic language that can define a new class in a function. Its very possible to implement this in Python, with as little redundancy as in Lisp.

Re:Rethinking Lisp Macros

[Anonymous Coward]

Not only can you create and modify the bindings of symbols, function symbols, and packages at runtime, but if you couldn't dynamic compilation would break and also gensym among a number of other things wouldn't work. Construct a macro that creates a binding in an environment without being able to modify the environment. Lisp has a full reflection mechanism, so nothing is being invented here to compensate for the lack of macros. You should keep in mind that the binding created by defun isn't specified to exist at compile-time even if your compiler makes assumptions regarding compiled functions when optimizing.

There would be nothing especially complicated about constructing a set of messages in Smalltalk that implemented functionality of the loop macro. There are no major syntactic contortions necessary. The language has very little syntax to contort to begin with.

All of this talk about domain-specific languages is less about implementing DSLs and more about implementing control structures in Lisp for use in Lisp. It's not about DSLs, but rather the ever-growing blob that is your Common Lisp image. DSLs are about expressing the principle of least power, and are implemented in any number of languages using the rich featuresets available to them. Using Common Lisp macros to implement a real DSL, as opposed to something that is basically embedded in and looks exactly like Lisp only special meaning is given to a few blobs of text, would be completely non-advantageous.

Re:Rethinking Lisp Macros

[be-fan]

I just don't think this extra tLisp echnical strength actually empowers the programmer in real-world scenarios.

That wasn't your original argument.

If all macros are replaced with functions, then suddenly it is possible to do all those things.

You'll have to not only replace everything with functions (meaning that you basically need a Lisp, since any non-functional syntax will cause problems with your method), but you'll have to replace them with functions that are designed to be extended. Writing every function with the intent to be extended is non-trivial. With macros, you can write functions naturally, and still have the power of extension.

I think every problem I've seen solved by Lisp is solved at least almost as adequately, and in almost all cases, more simply and with a clearer syntax, by Python.

I'd love to see a domain-specific macro language implemented in Python. You can say that DSLs are "just syntax", but by that argument, assembly is fully equivalent to both Python and Lisp!

That's why Python does have a special syntax for assignment+naming in the same time.

More special syntax. That's exactly what Lisp avoids! Why bother with special syntax for everything when macros can be used instead? There is a reason that Lisp *does not* have a special syntax for assignment+naming at the same time. It'd be redundant, macros can be used to build that functionality out of existing infrastructure.

I can read programs in almost any language with virtually no learning curve, but I can say reading Lisp code, and defmacro's is much more of a challenge, despite knowing the concepts very well.

Translation: "I've got a lot of experience reading infix languages, but very little reading Lisp". You're basically saying: "I've got lots of experience reading English, but Japanese is hard to read, despite knowing the grammer very well". It's a stupid statement!

Lisp programs are not, as you would expect according to the claims you stand behind, orders of magnitude smaller than the equivalent Python, Smalltalk or Ruby programs.

Lisp programs can be an order of magnitude smaller than the equivalent Python program. Python is quite expressive, but I'd like to see something like ACL/2 in Python!

Re:Rethinking Lisp Macros

[5pp000]

I did not compare Lisp to C++. I compared macros to functions-accepting-closures.

C++ does not even have closures, so your comparison is a strawman.

Sorry, I was arguing with the wrong person :) Alas, I've had lots of time lately to hone my Lisp-vs.-C++ arguments, since I work with C++ lovers :)

I've only written a little Python and don't know a lot about it, but I have worked for years in an obscure language called Refine, which is higher-order but lacks macros. I've done all the things you're talking about involving closures, many times, and I still prefer to use macros in many cases. (Specifically, when the purpose of delaying evaluation is to set up some dynamic context before evaluating the forms, and tear it down thereafter, I find the macro approach to be clearer and more elegant. Passing functions as arguments absolutely has its place, and I do it all the time, but I don't find it to be the most natural expression of these particular cases.)

You say, in your response to someone else, that you don't want to learn a new language to read a program. In over 25 years of Lisp programming, I have not very often found other people's macros to be a particular barrier to understanding (not nearly as often as their data structures and algorithms are). Certainly macros can be and sometimes are misused, and junior programmers are perhaps best advised to avoid them. There is even one well-known macro that is part of the Common Lisp standard that I personally just absolutely detest (loop); but still, if you ask me whether the benefits of macros outweigh the cost, I don't have to think about the answer -- the benefits far outweigh the costs.

As for the class-definition macro example, if there's some way to do that in Python, that's great. I'm curious, though, what you do for syntax -- you still have to create a syntax for the high-level class definitions, and write a parser for that syntax, do you not?

Re:Rethinking Lisp Macros

[Peaker]

As for the class-definition macro example, if there's some way to do that in Python, that's great. I'm curious, though, what you do for syntax -- you still have to create a syntax for the high-level class definitions, and write a parser for that syntax, do you not?

Nope, you can just write a function that makes a class, for example:

def f(base, bleh):
    class TempClass(base):
        blah = bleh
        def bluh(self, x):
            return bleh*2
    TempClass.__name__ = 'bleh_class'
    return TempClass

Re:Rethinking Lisp Macros

[be-fan]

Loop is awesome! You're just not smart enough to figure it out :)

The point about Python doing the same thing as your example is crap. I'm a Python programmer, and yes, you can do what he's saying. But it's a dynamic hack that works only because in Python objects are just hash tables, and all member resolution is done at runtime via table lookup with a string key. It's *slow*, prevents you from doing *any* type inference, any optimization, or any type checking.

Re:Rethinking Lisp Macros

[Anonymous Coward]

The implementation strategy of CPython is irrelevant. You can construct and modify classes, the names of class, and anything else (it's a dynamic language after all). You can create classes, and modify the properties of CLOS objects at runtime too. To optimize the execution of code paths, you create specializations at runtime. CPython doesn't do this because it's an intentionally simple interpreter, but the implementations of dynamic languages like Self and Smalltalk do precisely that. Psyco does much the same thing for CPython, actually. Common Lisp implementations that don't preserve all dynamic behavior at runtime for compiled functions (the specification leaves much leeway and undefined behavior in the implementation of compiled functions) simply sacrifice flexibility for performance in a decidedly undynamic way.

Re:Rethinking Lisp Macros

[be-fan]

You misunderstand my point. I'm not suggesting an implementation that doesn't retain dynamic behavior. I'm pointing out that using that dynamic behavior has a very significant cost, and is not really equivalent performance-wise to the macro mechanism presented earlier. Sure, even in Lisp, you *can* do what the OP suggested and build the classes up at runtime. However, using this feature greatly reduces the ability of the compiler to perform static analysis on the program. Utlimately, it makes no sense to pay this performance price in the particular example we're talking about. Conceptually, the class hierarchy is known at compile time. It's not created in response to dynamic conditions, but is something known in advance. The language should be expressive enough to let you specify this succinctly, and not force you to do something unnaturally in the context of your problem domain just to reduce the number of primitives necessary in the language! Languages should be designed for programmers to use, not the other way around! There is a reason Lisp has both macros and dynamic classes.

LISP-A stack of chips.

[Anonymous Coward]

"Since the demise of LISP machines, the concept of a stack-based machine has surfaced repeatedly in virtual machines."

I guess I'm the only one who remembers the commercially available Harris RTX-2000

Norvig

[drewness]

Peter Norvig has a nice comparison of Python and Lisp.

Thylvethter thayth,

[alphapartic1e]

Thufferin' thuccotasth!

Re:This is News?

[Anonymous Coward]

Maxima interface sucks!

Re:This is News?

[be-fan]

Not when you use it inside Texmacs, it doesn't. Powerful math capabilities, great TeX output, what more could you want?

Re:This is News?

[Anonymous Coward]

...with Robert Morris' addition, "...including Common Lisp."

Re:GO DUBYA

[Anonymous Coward]

o dubya thy intellecutual prowess can be only matched by one thousand americans

Comment removed

[account_deleted]

Comment removed based on user account deletion

Lisp Machines vs Suns - myth and reality

[Anonymous Coward]

As somebody who programmed heavily on Symbolics machines, including the fastest XL1200 variety, the idea that they were much better than the Sun machines that replaced them is debatable.

True, Lisp Machines (all varieties) had much better development environments. But the Lucid team (including Rod Brooks) created a very good Common Lisp compiler for Suns, and it ran Lisp code much faster than the LMs did. After a while of complaining I found myself programming in Lucid more and more and every time I went back to the LMs I noticed the big speed hit.

We at MIT would schedule our dinners around Lisp Machine reboots or garbage collections (usually the first was faster).

The fact is that LMs were too far ahead of their time. They, and especially the academic research applications developed on them, demanded lots of memory and lots of computation. The special-purpose ICs used in them were too slow, and the lack of memory meant one was constantly paging (though the paging systems were very good).

A lot of the drawbacks of Lisp disappeared once machines hit about 30 meg of ram, because then the Lisp environment overhead was negligible.

About the only thing substantially missing from modern CPUs to get Lisp machine quality development environments is the notion of typed memory. It really helps to have a few extra bits on each word to tag the type, so that one can trap bad data usage, such as adding pointers or dereferencing floats. Java and other dynamic languages would benefit equally from this feature found on a lot of older architectures, and on 64-bit systems an extra 2 or 4 bits of memory per word is not much overhead.

Hell no.

[Estanislao Mart�nez]

Python is more like Scheme and its philosophy than Common Lisp.

Comparing Python to Scheme, no matter what Paul Graham may say, is a really bad comparison. Python supposedly aims to be a really clean imperative OOP language. Guido not only refuses to implement crucial features for functional programming like proper closures and anonymous functions; he's actually seeking to remove some such features, because he thinks they're "confusing." The general culture around Python strongly discourages use of techniques like higher-order functions; Python programmers write a loop in every other function. Python uses flexible arrays as its list datatype, and its list processing operations are built around that sort of datatype. It's never been intended to be self-hosting (i.e. Python has never been seriously implemented in Python, IIRC.)

Scheme, on the other hand, is an impure functional language that mandates anonymous lexical closures, tail call optimization, first-class continuations and a macro system. Its design is guided by absolute minimalism in terms of features, in favor of extremely general constructs. Most of the syntax called for in R5RS can actually be implemented in Scheme itself, using the macro system, as the language definition itself demonstrates. It uses singly linked lists as its list datatype (though it also provides fixed-size arrays). There is a heavy emphasis on higher-order functions of very general applicability; highly fluent Scheme programmers only need to write loops infrequently, because most of the time there's a higher-order function that does the job for you, like map, fold, or many others from the SRFI-1 list library.

The popular scripting language that's the most Lisp-like, really, is Ruby, whose pervasive use of code blocks echoes functional programming techniques.

What a great idea; here's a simple implementation

[Estanislao Mart�nez]

;;;
;;; delay, force, promise?
;;;
;;; (delay expression-1 ... expression-n)
;;;     => <a promise object>
;;;
;;; Returns a promise to evaluate the block of code contained within
;;; the delay expression.
;;;
;;; (force p)
;;;     => <a value>
;;;
;;; Forces evaluation of the code delayed by the promise, caching the
;;; result.  Forcing a promise a second or more time returns the
;;; cached value.  Forcing a non-promise returns the value itself.
;;;
;;; (promise? p)
;;;     => <boolean>
;;;
;;; True if and only if p is a promise.
;;;
(define-syntax delay
  (syntax-rules ()
    ((delay expression . expressions)
     (cons '*PROMISE-SIGIL*
           (lambda () expression . expressions)))))

(define (force p)
  (cond ((not (promise? p)) p)
        ((procedure? (cdr p))
         (set-cdr! p ((cdr p)))
         (cdr p))
        (else (cdr p))))

(define (promise? p)
  (and (pair? p)
       (eq? '*PROMISE-SIGIL*
            (car p))))

;;
;; Though actually, the Scheme standard already includes these...
;;

Nope.

[Estanislao Mart�nez]

The main feature you get from Lisp macros that allow new features to solve specific problems, is a performance enhancement. The vast majority of features that use macros in Lisp, can be implemented via passing around functions in Python (very similar to unevaluated arguments).

Macros in Lisp and Scheme are way more general than that. They don't just get you performance enhancements (and actually, I'd say that's a minor use for macros); they get you arbitrary evaluation rules, which allow you to do things like define new binding forms, that is, syntax for assigning values to variables within a scope.

For example, it's pretty simple to define a macro to do ML and Haskell-style pattern matching in Lisp; that is, a binding construct that tests whether arbitrarily complex data matches an arbitrarily complex pattern, and if it does, binds the variables in the pattern to the values that they match in the input.

I don't think you're going to find any remotely simple way of adding a new binding construct to Python within Python itself.

Bah, amateurs.

[Estanislao Mart�nez]

;;;
;;; Use automatically balanced parens, and indent automatically on
;;; newline.  Has other tricks up its sleeve, too; for example, if you
;;; want to put a parens around the next <number> s-exps after the
;;; point, just do C-u <number> (.
;;;
;;; balanced.el is available at:
;;;
;;;     http://www.cs.indiana.edu/chezscheme/emacs/balanc ed.el
;;;
;;; Only tried this in real Emacs, dunno if it works in XEmacs.
;;;
(require 'balanced)

(add-hook* '(scheme-mode-hook lisp-interaction-mode-hook emacs-lisp-mode-hook)
           (list 'balanced-on
                 (lambda () (local-set-key [13] 'newline-and-indent))
                 ))

(defun add-hook* (mode-hooks procs &optional append)
  "add each listed procedure to each listed mode hook.

If append is true, we append the hooks to the end of the list instead
of consing them on to the beginning."
  (for-each (lambda (mode-hook)
              (for-each (lambda (proc)
                          (if append
                              (nconc (eval mode-hook) (list proc))
                            (add-hook mode-hook proc)))
                        procs))
            mode-hooks))

Ah, Zach Beane

[Anonymous Coward]

Zach Beane? "Xach"? EFNet #doom's biggest dickhead operator in the mid 1990's? Or is this a completely different Zach Beane? Is he still a sniveling pretentious dickhead now in 2005, can anyone confirm? Say hi to biggles and munchkin for me.

Re:Ah, Zach Beane

[Anonymous Coward]

That's me! Fortunately, life moves on. Here's a picture of munchkin:

http://www.gatech.edu/innovations/robotics/avindex .php

I don't know what biggles is up to, or if he is a famous roboticist.

-- Xach

Re:Ah, Zach Beane

[NetJunkie]

Some of us are still around. :) I'll say hey to biggles for ya....

Re:Ah, Zach Beane

[Anonymous Coward]

Haha I remember you. You were the guy who knew that Gwar fellow who loved cats a bit too much :D

Re:Ah, Zach Beane

[Anonymous Coward]

Good to see him being productive for a change :)... did I perhaps see him on the Science Channel once? That robotic-dog-soccer feature looks very familiar. Then again there were several universities in that competition weren't there?

Rethinking Lisp Macros-FORTH

[Anonymous Coward]

"And the second reason is one the above post touches on when it mentions the representation of code as data. "

Forth can do the same thing.

Commas

[tgv]

It's the commas. If the language designers had chosen to make the space significant (e.g. as an argument or statement separator, just like LISP), then C would have won. Fortunately, Kernighan and Richie had the decency to add some syntactic sugar to their hieroglyphic language. Otherwise, the result would have been Python, but with less keyword. Plus, the IOCCC would never have started, since nobody would have been able to read even

main(int a char* b[]) { int c for c = 1 c a c++ puts b[c] }

Yes, that is a cut down version of echo...

Re: <

[tgv]

damn, the less than symbol fell out: read "c a" where you see "c a"

Re:

[heson]

Oops it fell out again, how did that happen??? *snicker*

On the subject of lisp

[kunzy]

The LISP song http://www.prometheus-music.com/audio/eternalflame .mp3

Re:

[tgv]

Holy cow, I ain't never going to get them darn ampserpersands right.

But I'm posting in "plain old text". I suppose the TCP/IP stack eats the mathematical operators...

Re:What a great idea; here's a simple implementati

[Peaker]

Just recently me and a friend of mine wrote a LazyExpression object in Python.

It indeed takes a few more lines (About a factor of 3), but it supports more functionality (and is simpler!). I can use the "promise" (my lazy object) in any context, and automagically, new "promises" are created.

What happens if you use (car my-promise)? Will it create a promise to run car on the result of the promise when it is evaluated, as you would want it to, or will it return an arbitrary piece of data that you did not mean for it to return?

These promises are a lot less useful than the Python Lazy object because everyone using them must be aware of the fact that they are not actual results.

Re:cdr cdr car? Python rules re punct

[Anonymous Coward]

Here here!
Please. Hear, hear -- or are you calling your dog?

I find it incredible to see that C/Java people bitch about "superflous" punctuation. Compare this:

(defun square (x) (* x x))    ; 6 punctuation marks

To C:

double square(double x) {return x * x;}    // 5 punctuation marks
             1        2 3         4  56       ?
To Python:

def square(x): return x*x   #  4 punctuation marks

To C++:

template <typename T>
T square(T x) {return x * x;}    // 7 punctuation marks

To Java:

public class Square
{
    public double operate(double x) {return x * x;}
};        // 7 punctuation marks

Compare this:

(if (something)           ; 8 punctuation marks
    (do-this)
    (do-that))

To C/C++/Java:

if(something())            // 10 punctuation marks (11 if you count the 'else')
    do_this();
else
    do_that();

To python:

if something:           # 6 puntuation marks
    do_this()
else:
    do_that()

Compare this:

(do-something to-this with-that in-there)       ; 2 punctuation marks

To Python:
   do_something(to_this, with_that, in_there)  # ok, 4

To C/C++/Java:

do_something(to-this, with-that, in-there)      // 4 punctuation marks

The only reason it seems like there are so many parentheses in Lisp is because of LET and because Lisp uses just a single type of punctuation while C/C++/Java use all sorts of different punctuation. With a good editor, the parentheses don't even matter, all you see is the indented structure!

And in Python, indentation itself defines the indented structure.
see http://www.python.org

Re:cdr cdr car? Python rules re punct

[sickofthisshit]

"*" doesn't count as punctuation: it's a freaking function!

And you should at least count the carriage return at the end of the Python example as punctuation. Isn't the white-space significant?

Plus, you have to use the redundant word "return". Think about why it is not simply

def square(x) x*x

Which is the Lisp example where white-space punctuation replaces explicit parenthesis punctuation.

In any case, the original poster was comparing to C++. Python and Lisp are pretty much on the same side of this debate: use a single consistent punctuation scheme instead of trying to use lots of punctuation to distinguish shades of meaning.

Backquote joke

[Anonymous Coward]

A LispM fortune:

(LET ((LET '`(LET ((LET ',LET))
            ,LET)))
    `(LET ((LET ',LET))
        ,LET))

C-optimised hardware

[steve_l]

I think I have to (provisionally) disagree with your statement that the out-of-order stuff is there because of C/C++. It is my belief that the OOO stuff, which as been in the x86 since the P6 core, is there to get around the finite #of CPU registers in the x86 design, and the gulf between CPU speed and main memory latency. Unlike risc/IA64 systems, with lots of registers for the compilers to allocate, you only have a limited number of general purpose registers. The CPU gets around this with its internal register set, scheduling operations out of order but only pulling them back in to the public register set (and raising faults) in the original order.

Now, you could argue that IA64 is a more C/C++ compiler-centric box, as it assumes plenty of time up-front to compile down code, and a compiler written by competent people. Its a lot harder to do dynamic stuff on there.

I do agree with your MMU comments, though note that i286 up had a segmented memory model which did offer better memory protection, and a strong model of executable code versus plain data. And you could program it in C and later C++, as I recall from my windows 3.x programming days. But believe me, it was not a nice paradigm to code against, partly because segments were too small (64K), and partly because some things (pointer comparision) get so very, very hard. C/C++ code does normally assume that if you have two pointers char *p,*p1; then if p1!=p2 a write to p (*p=X) does not mean that *p2==X. That is, different pointers point to different places. In Win31, there was no such guarantee.

Re:C-optimised hardware

[be-fan]

Out of order execution is there to wring parallelism out of basically single-threading languages. It's not an x86 issue, but a RISC one as well. The most massively OOO CPU in existance (the POWER4) is a RISC chip. In fact, the only significant RISC chip that is not OOO is the SPARC.

Re:Argh! Ruby!

[oldCoder]

Ruby's a better descendant than Python!

Macros?

[csirac]

Not a Python programmer myself (learning ruby, scheme and know ISO-C, Handel-C and Perl), but saying that you're trying to make "macros" in a language where there's no up-front strong typing like with Python indicates you don't understand the language...

Macros are incredibly useful in a strongly-typed language like C, but have pretty much no place at all in weakly typed languages like Perl and Scheme. Python is still "strongly-typed" (or so I understand it), it just defers the actual checking until the latest possible time at run-time. Or something. Like I said, I'm no expert...

If you are really missing macros, perhaps it's because you want to "abuse" it to write code that writes code.

Which is exactly what Scheme (and functional programming in general) is all about. Ruby, Scheme, and AFAIK Python all support "higher order functions", where you plug in functions or even anonymous code to other functions, and the result is a program that does something completely different expressed with almost mathematical precision and conciseness.

C's preprocessor "macro" language is totally barbaric, by comparison, and one of the fascinating things about Handel-C is its support for "macros written with C syntax" - having used Handel-C a lot, I really think the world would be a better place if ISO-C had the same macro language Handel does instead of the poor excuse for sanity we have now.

In short... "Python? Macros? What the...?"

DIY programming language

[ToyKeeper]

The thing which makes lisp different is not that it has feature parity with other languages, or that it has hordes of religious followers with a black-and-white view... or even that it's the Right Tool For The Job. What makes lisp different is that you can use it to build whatever tools you need. You're not limited to just what the language provides, like in most languages. You don't have to wait until the next upstream release to get new syntax or features. Instead, you can modify the language itself, and do so in a standard, compatible way.

For example, lisp doesn't have list comprehensions, a very useful syntactic feature which increases expressive capacity and reduces code size. But it's not terribly difficult to just do it yourself.

The point is that, unlike most languages, lisp does not limit you to only the predefined set of hammers which come with the language. If you need a power drill or a chalk line or some widget nobody ever thought of before, you can make one and use it as if it were there all along.

This doesn't make it the right tool for every job, or even most jobs. If your project needs Wonder Widget #32, it's much easier to use a language which already has one. You could build one in lisp, but that wouldn't be a very efficient use of time. Why reinvent the wheel? Most of those wonder widgets are already available in other languages. Where lisp shines is when you need tools nobody has ever thought of before.

One other interesting thing to note about lisp... it's often excluded from language comparisons. See quicksort implementations for an example. The reason it's not there is not because it's outdated or unpopular, but because there's simply no point. It's just taken for granted that lisp can match the expressive power of every language in the comparison, so there's no reason to bother including it.