LispM Source Released Under 'BSD Like' License 336
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.
BSD like license? (Score:5, Funny)
Re:BSD like license? (Score:3, Funny)
= 9J =
Lisp? (Score:5, Funny)
Bee - Ethh - Dee?
As Einstein once said... (Score:2, Interesting)
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.
LispMachines are Dying (Score:2)
I was originally going to title this "Symbolics is Dying", but it turns out Symbolics [symbolics.com] is still around, selling things like Macsyma, just not making Lisp Machines any more.
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.
Re:Argh! (Score:2)
Re:Argh! (Score:2)
Python is more like Scheme and its philosophy than Common Lisp.
--Pat
Re:Argh! (Score:2)
Perl being what you get when you take C, awk and bourne shell and drop it in a blender.
Re:Argh! (Score:2, Interesting)
Re:Argh! (Score:4, Insightful)
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.
Re:Argh! (Score:2)
Re:Argh! (Score:3, Insightful)
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 differ
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.
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.
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.
Re:Why design a new language? (Score:3, Insightful)
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
Re:Argh! (Score:5, Insightful)
Norvig (Score:3, Informative)
Re:Argh! (Score:5, Informative)
Re:Argh! (Score:2)
you shouldn't need an editor to assist you with the syntax hell of a language. paren hell also makes restructuring code
Re:Argh! (Score:2)
Re:Argh! (Score:3, Insightful)
Re:Argh! (Score:3, Insightful)
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.
bad reputation?? (Score:3, Insightful)
Only if you confuse 'reputation' with 'loudmouth /. trolling'.
Re:Argh! (Score:3, Informative)
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! (Score:2)
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! (Score:2)
Re:Argh! (Score:3, Funny)
I'm surprised no one has brought up emacs as an example of a lisp app...
Re:Argh! (Score:2)
Re:Argh! (Score:2)
"Meekly deproceduring to MOID FORM"
Only some LISP dialects had GC.
The first major language to have it was Visual Basic
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)
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)
Re:Great News! (Score:2)
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.
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.
So do the RIAA... (Score:2)
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)
Re:There's some duplication. (Score:3, Insightful)
Re:But I thought... (Score:5, Funny)
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, Insightful)
Re:But I thought... (Score:3, Informative)
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.
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
Re:Nice... (Score:2)
Going even further back, the original UNIX code was relea
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)
Re:Somebody had to say it... (Score:2, Funny)
Re:Somebody had to say it... (Score:2)
? (great-news-p 'this)
> T
geez, kids these days.. somewhere, David Moon is weeping...
Re:Somebody had to say it... (Score:2)
#t
(I prefer scheme)
Richard Stallman and the Lisp Machine (Score:5, Interesting)
Re:Richard Stallman and the Lisp Machine (Score:2, Funny)
I always thought it was pot. Live & learn.
Re:Richard Stallman and the Lisp Machine (Score:2)
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.
Newbie here... (Score:2)
Thanks.
Re:Newbie here... (Score:2)
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].
Oops... (Score:2, Informative)
I used one of those things (Score:2)
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! (Score:4, Funny)
being able to get the hardware would be better (Score:3, Interesting)
Re:being able to get the hardware would be better (Score:2)
Makes it more usable, and distributable.
Getting closer.... (Score:2)
Yes! Now I just need someone to find and publish the source to PLANNER and CONIVER.
--MarkusQ
back to the future (Score:2, Informative)
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:3, Informative)
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 v
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!
Re:This is News? (Score:5, Funny)
Just like your opinion. Now get back to work, those burgers won't flip themselves!
Re:This is News? (Score:2)
Re:This is News? (Score:2)
Re:This is News? (Score:3, Informative)
As in Philip Greenspun's 10th Rule of Programming you mean?
Re:cdr cdr car? (Score:5, Funny)
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!
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:2)
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? (Score:3, Insightful)
Re:cdr cdr car? (Score:3, Interesting)
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
keycode 45 = 9 braceleft
keycode 46 = 0 braceright
keycode 71 = parenleft bracketleft
keycode 72 = parenright bracketright
Then, in a suitable init file (suc
Re:9 track tapes? (Score:2)
Maybe you think you're funny but d00d, Skynard never sounded so good!
LISP (Score:2, Informative)
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
Re:LISP (Score:2)
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 wa
Re:LISP (Score:3, Informative)
Since the demise of LISP machines, the concept of a stack-based machine
Re:LISP (Score:3, Interesting)
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 difficu
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.
Wikipedia Ref (Score:3, Informative)
LISP Machine Wikipedia Page [wikipedia.org]
Comment removed (Score:4, Interesting)
Re:Rethinking Lisp Macros (Score:3, Insightful)
Re:Rethinking Lisp Macros (Score:3, Interesting)
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 mac