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.
"Imagination is more important than knowledge..."
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 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 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.
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.
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.
Yep, LISP -> Scheme -> Python. A pretty straightforward descent. Scheme removed the annoying complexity-of-use from LISP by discarding its historical baggage (if only that could happen to C++!). Python discarded the requirement that the language be trivial to parse because code looked like data in favor of syntax that favored humans, and added back a type mechanism. I found it interesting that Python was originally much less Scheme-like, with currying not really working and so on, but grew to be more similar over time as Scheme fans migrated.
Socialism: a lie told by totalitarians and believed by fools.
"The Lisp Machine, as well as Burroughs Algol hardware, embodies some computer engineering principles that address fundamental failures in the current computing environment:
[...]
3. Hardware designed for specific language implementation."
Just as the Lisp Machine, current hardware is designed for a specific language. The problem is that that language is C.
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
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/
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?
"Since the demise of LISP machines, the concept of a stack-based machine has surfaced repeatedly in virtual machines."
I guess I'm the only one who remembers the commercially available Harris RTX-2000
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
and in fact, that's exactly the kind of thing one has to do when working in functional languages with no macros, but (a) it's less elegant because you're making the programmer do some of the macro's work, and (b) this is still a pretty simple macro.
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 macro example so you cannot say that you have to "do" some of the macro's work. What work?
data = with(open_file('/etc/passwd', 'rb', lambda stream: stream.read()))
Macros empower the developer by enabling the construction of syntactic abstractions -- each of which extends the syntax of the language. Like any other power, it is sometimes abused by the inexperienced; one can certainly write utterly unfathomable code using macros. But used well, macros greatly enhance the elegance, readability, and maintainability of code.
Instead of changing the syntax itself, one can have a rich syntax to begin with, and only overload the semantics of the syntax. Some things should never change, for readability's sake. Things such as when code is evaluated and when its not. Macros break this rule and make reading Lisp much harder. While I can read code that uses functions I do not know with relative ease, I have no idea what's happening when macros are used, because there are no evaluation rules that the code adheres to.
As for why macros are not more widely used, there are a couple of reasons. Lisp's minimalist syntax, so strange-looking at first glance, turns out to be one of its greatest advantages. The very simplicity of the syntax is exactly what makes it so powerful and general: user-defined constructs are invoked just like built-in constructs. While in principle a language with keywords and infix expressions could have an extensible grammar, syntactic extensions get much harder to manage in such a language because they tend to interact, causing ambiguities in the grammar.
Again, if you assume syntactic extensions are a good thing (as opposed to semantic extensions by overloading an existing rich syntax).
And the second reason is one the above post touches on when it mentions the representation of code as data. Lisp is the only major language to give programmers access to a standardized tree representation of source code. The fact that the representation is a tree makes Lisp macros powerful (contrast the pitifully weak "preprocessor macros" of C/C++, which operate on a character string representation), and the fact that the representation is standardized makes them portable.
Again, if you assume syntactic extensions are an advantage. (btw: Python does allow you access to its code tree, but its rather inconvinient).
I have plenty of experience in more mainstream languages, but when programming for myself, I almost always use Common Lisp. Macros are a major reason.
You are one of a very tiny minority.