Slashdot Log In
LispM Source Released Under 'BSD Like' License
Posted by
ScuttleMonkey
on Mon Oct 03, 2005 02:43 PM
from the stroll-down-memory-tape-lane dept.
from the stroll-down-memory-tape-lane dept.
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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
BSD like license? (Score:5, Funny)
Lisp? (Score:5, Funny)
Bee - Ethh - Dee?
Let's be orderly now (Score:5, Funny)
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.
Argh! (Score:5, Funny)
Re:Argh! (Score:4, Informative)
Naughty Dog [franz.com] used a variant to write "Jak and Daxter", an extremely popular game for Playstation 2. Many more people use spiritual descendents like Python.
Parent
Re:Argh! (Score:4, Insightful)
Parent
Re:Argh! (Score:3, Informative)
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! (Score:5, Informative)
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.
Parent
Re:Argh! (Score:4, Informative)
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.
Parent
Re:Argh! (Score:4, Insightful)
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.
Parent
Re:Why design a new language? (Score:5, Interesting)
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.
Parent
Re:Argh! (Score:5, Insightful)
Parent
Re:Argh! (Score:5, Informative)
Parent
bad reputation?? (Score:3, Insightful)
Only if you confuse 'reputation' with 'loudmouth /. trolling'.
Re:Argh! (Score:3, Insightful)
Great News! (Score:4, Interesting)
This has long been the dream of those yearning for the revival of Lisp machines and their allegedly superior programming environment.
Re:Great News! (Score:3, Insightful)
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 un
Re:Great News! (Score:5, Interesting)
Parent
Re:Great News! (Score:3, Informative)
*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 cle
Re:Great News! (Score:3, Informative)
SCO needs to be all over this... (Score:4, Funny)
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.
But I thought... (Score:5, Interesting)
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.
There's some duplication. (Score:5, Informative)
Parent
Re:There's some duplication. (Score:3, Insightful)
Re:But I thought... (Score:5, Funny)
Parent
Re:But I thought... (Score:3, Informative)
LISP.
And that may shed some light why your box dies everytime you run emacs.
Re:But I thought... (Score:3, Informative)
Re:But I thought... (Score:4, Informative)
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.
Parent
Nice... (Score:4, Interesting)
Does that make this the oldest software to be released under an "open-sourceish" license?
Re:Nice... (Score:5, Funny)
Cheers,
Ian
Parent
Not even close (Re:Nice...) (Score:3, Informative)
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
Somebody had to say it... (Score:4, Funny)
Richard Stallman and the Lisp Machine (Score:5, Interesting)
RMS Essay: Come Celebrate the Joy of Programming (Score:3, Interesting)
How ironic that they released the LispM sources under a BSD-like license instead of GPL.
Here [donhopkins.com] 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 [withington.org] and here [caltech.edu] and here [andromeda.com] and here [andromeda.com] and of course here [wikipedia.org].
Machine Room Folk Dance, Thursday at 8pm. Come Celebrate the Joy of Programming, with the World's Most Unbureaucratic Comp [donhopkins.com]
Obligatory (Score:3, Funny)
Sorry, it needed to be done. That and a co-worker suggested I post it.
Re:Newbie here... (Score:3, Funny)
good (Score:3, Interesting)
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 [squea.org].
Thank Goodness! (Score:4, Funny)
being able to get the hardware would be better (Score:3, Interesting)
LispM had a superiour hardware model (Score:4, Insightful)
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 (Score:4, Insightful)
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!
Parent
Re:This is News? (Score:5, Funny)
Just like your opinion. Now get back to work, those burgers won't flip themselves!
Parent
Re:cdr cdr car? (Score:5, Funny)
Parent
Re:cdr cdr car? (Score:5, Informative)
(defun square (x) (* x x)) ; 6 punctuation marks
To C:
double square(double x) {return x * x;}
To C++:
template <typename T>
T square(T x) {return x * x;}
To Java:
public class Square
{
public double operate(double x) {return x * x;}
};
Compare this:
(if (something) ; 8 punctuation marks
(do-this)
(do-that))
To C/C++/Java:
if(something())
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)
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!
Parent
Re:cdr cdr car? (Score:3, Funny)
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
Re:cdr cdr car? (Score:3, Insightful)
Wikipedia Ref (Score:3, Informative)
LISP Machine Wikipedia Page [wikipedia.org]
The perfect question.... (Score:4, Interesting)
Hardware, at first hand built (using a few thousand ICs I guess) and later manu-factured, to run dyamically generated code using microcoded instructions. This included an extra 4 bits for every 32 that included type information, which was checked and corrected in HARDWARE, something like cpu-ECC, not a common option with today's 'fancy' hardware. I don't recall whether they used a von Neumann (where program and data are processed together) style architecture, but I seem to recall hearing about two datapaths, one for instructions and one for data, well at least I know common lisp has two name(symbol environments
Well anyways, what this amounts to is that in 1980, when DO0S was Rad and apple were just starting the GUI revolution with their tiny screens, these machines had complex high res (albeit greyscale at the time) GUI's that rival some of the simpler Linux windowmanagers of today. They also had the first 32bit sound, as far as I'm aware. Of course this ran relatively slow, BEUCASE IT WAS ON A 4MHZ PROCESSOR, or something like that. But that was only possible at the time because of the amazing dynamicism allowed by the environment.
Next, the operating system itself was a true microkernel, since there was none of this 'virtual memory/process' stuff, which chews so much overhead it's not funny. There was one machine wide software environment, inside of which everything was effectively a microthread, independant object threads, each of course having their own environment (lisp for name space), but these could all share the same memory space since the system is globally managed and garbage collected. I SERIOUSLY want to build a modern operating system like this, close to the beos, but using dynamicism like this, so one could browse the runtime objects while the system is running, would be awesome for building code in real time, browsing it's operation as it runs, I mean come on computers are ridiculously fast now, in fact the only overhead these days is SOFTWARE becuase of poor modularity management, we have the speed to run dynamic environments, it's time to put their superior expressivity (read SUCCINCTNESS) to work, but anyways.
The final word I want to say about Lisp Machines was they were a commercial product for about a decade, from the early 80s when they began to take off, until the early 90s when the AI-bust happened and everyone, by association, apaprently, decided Lisp machines WEREN'T superior. But these are responsible for many of the computer animations people were seeing at the time, like in movies, or if anyone saw those Mind's Eye videos, those were awesome, well those were all done on Lisp Machines, costing like $20k each or something, by a company called Symbolics whose lisp software was called Genera, there's an Open Genera project, i believe?
Well anyways, as you can tell, I'm kind of obsessed with them, I think they were the most advanced software environments that I know of, of course I'm sure there's much cooler ones available that I just don't know about, but I"m talking like free software here, I want my dynamic microthreaded, hyper-interactive (in terms of manipulating runtime objects) software environment. Well, but now I've got it. So......HAHHAHAHAHHAHA!!!! (Oh, man, i'm just so happy
Parent
Re:LISP (Score:3, Informative)
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 (Score:3, Informative)
Since the demise of LISP machines, the concept of a stack-based machine