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.
I was going for funny, but the slashdot mods found me insightful. Amazing!
I read
Except a lot of the really powerful stuff (Genera), was developed commercially at Symbolics, which is still very much a commercially licensed product (although it comes with almost all source code.)
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 understand, this stage of development was a hundred man-years or more of improvement over the MIT Lispm stuff. But hey, maybe this is a start.
I don't know, but does anybody still program in Algol dialects like C or Java? That is soooo 60s.
What, Java has garbage collection? You mean that feature that they took from Lisp which had it for decades already? And they still haven't gotten exceptions right, nor OO?
By the way, Autolisp and Emacs Lisp are old dialects (as is the Lisp machine stuff, I'm afraid, but the system was decades ahead of its time, meaning it runs circles around current Java IDEs). Get the real thing, Common Lisp.
Methinks a lot of folks would argue that Python isn't a spiritual descendant so much as a wannabe. My understanding (I haven't programmed in Python much) is that it lacks a lot of the features that make lisp So. Damn. Cool., such as macros, and its closures are broken in the eyes of a lot of lispers. To me, the real kicker is that there is still a strong division between data and code in Python.
Only if you confuse 'reputation' with 'loudmouth /. trolling'.
you had me at #!
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...
Between Algol, Lisp, and Smalltalk, all the modern core language ideas were present. The last 30+ years of programming language design have added efficiency and better syntax, but I can't think of any new core ideas in that time. Perhaps the idea of running on an emulator on *every* platform counts.
Socialism: a lie told by totalitarians and believed by fools.
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?
Well, I can't argue with your phrasing.
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.
Yeah right. Dylan tried that, look where it got them. People just use parentheses as an excuse to not try a language they're too chicken to try anyway.
A deep unwavering belief is a sure sign you're missing something...
Python is strongly typed, Perl isn't
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 differentiates "scalars" from other objects, requiring reference hacks to build real data structures, and may actually cause dangling references(!)
I'd say the languages are pretty different.
The whole point of macro is readability! Reading Lisp code with a well-chosen set of macros is like reading code written in a language precisely-designed for the problem you're trying to solve. It keeps the boiler-plate and the implementation details from interfering with the expression of the core algorithms.
A deep unwavering belief is a sure sign you're missing something...
Ever since I bought an extra 2 Megs of RAM for my 386, that doesn't happen anymore.
Don't drop the soap, Tommy!
You're not solving the basic problem that macros solve, however. Receiving a function as a closure doesn't allow you to manipulate the function. You can use it as-is, but a lot of very powerful constructs require that manipulation. Many of the macros used in Common-Lisp programs could not be rewritten as a function taking a closure. A trival example is PUSH. Bigger examples are DEFUN, DEFCLASS, DEFMETHOD (pretty much all of CLOS, really), etc. Your loop example is particularly good. Languages like Python rely on hard-coded syntaxes for their looping constructs, which invariably express only a very limited subset of the looping constructs the programmer wants to use. Something like CL's LOOP macro is far more powerful (and wisely used, can be every-bit as readable), but could not be implemented as a function taking a closure.
As for "giving up a readable syntax", I consider Lisp's much more readable than C++. Lisp is readable if you're used to reading Lisp. Its unreadable if you're not. The same is true of C++. Before anybody complains about Lisp's syntax being unreadable, they should have at least a thousand lines of code (in an actual program, not some homework assignment!) under their belt. A thousand lines seems like a lot, but its a decent metric for seperating those who know Lisp and those who do not. Ask yourself: would you hire somebody who claimed to "know" C++, when they hadn't written more than a thousand lines in it?
A deep unwavering belief is a sure sign you're missing something...
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.
I took enough lisp in CS to determine it's a language for people like you who see the world in black and white, where all the world is a nail and lisp is the hammer.
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.