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.
Is that anything like a death certificate?
Does that mean we have to pronounce it as
Bee - Ethh - Dee?
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.
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!
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))))?
Reality test... am I dreaming?
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.
Please correct me if I got my facts wrong.
...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.
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.
I read
Does that make this the oldest software to be released under an "open-sourceish" license?
-Rob
Biblical fiscal responsibility
(This(truly(is(great news))))
Yeah! This clearly shows that C is superior! At least in C you have superfluous parentheses, semicolons, commas, ...
Please correct me if I got my facts wrong.
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.
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.
In Thoviet Rutha, LITHP lithenthes you!
Sorry, it needed to be done. That and a co-worker suggested I post it.
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...
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.
That's all well and fine, but let's look at a more common example:
// crap!
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");
}
}
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?
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.
Comment removed based on user account deletion