Slashdot Mirror
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.
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.
Dewey, what part of this looks like authorities should be involved?
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.
Telltale Games: Bone, Sam and Max
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.
Cyric Zndovzny at your service.
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.
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.
Please correct me if I got my facts wrong.
Here here! I find it incredible to see that C/Java people bitch about "superflous" punctuation. Compare this:
// 5 punctuation marks
// 7 punctuation marks
// 7 punctuation marks
// 10 punctuation marks (11 if you count the 'else')
// 4 punctuation marks
(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!
A deep unwavering belief is a sure sign you're missing something...
Parent screwed up link, try Squeak.org
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.
Dewey, what part of this looks like authorities should be involved?
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.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
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!
Software freedom...I love it!
LISP Machine Wikipedia Page
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
Does that make this the oldest software to be released under an "open-sourceish" license?
... the "Free Software Movement" was already in high gear years before Stallman decided *he* was going to invent it.
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),
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.
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.
A deep unwavering belief is a sure sign you're missing something...
As in Philip Greenspun's 10th Rule of Programming you mean?
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
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.
Peter Norvig has a nice comparison of Python and Lisp.
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.
A deep unwavering belief is a sure sign you're missing something...
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.
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.
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/
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.
Virtually serving coffee
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.