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?
"Imagination is more important than knowledge..."
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.
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.
No, a Lisp is a speech language as well as a programming impediment.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
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.
Parent screwed up link, try Squeak.org
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.
Only if you confuse 'reputation' with 'loudmouth /. trolling'.
you had me at #!
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");
}
}
The problem with the Python mechanism is that it makes macros quite a bit trickier to implement.
A deep unwavering belief is a sure sign you're missing something...
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
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?
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.
I am TheRaven on Soylent News
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
Take a look and feel free: http://www.PieMenu.com
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),
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.
A deep unwavering belief is a sure sign you're missing something...
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.
http://notanumber.net/
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.
You want to learn about xmodmap
.xmodmap) which has lines like
.xinitrc) you want to put a command
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 (such as
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?
Peter Norvig has a nice comparison of Python and Lisp.
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.
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.
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/
Comment removed based on user account deletion