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.

Comments

Re:There's some duplication.

[pmike_bauer]

I was going for funny, but the slashdot mods found me insightful. Amazing!

Re:Argh!

[Bastian]

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.

LispM had a superiour hardware model

[Anonymous Coward]

The Lisp Machine, as well as Burroughs Algol hardware, embodies some computer engineering principles that address fundamental failures in the current computing environment:

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?

Re:LispM had a superiour hardware model

[be-fan]

BS. Take a look at the die of something like an Athlon 64. Large portions of it are dedicated to C support. For example, the entire MMU. If C programs (more appropriately, the C memory model) didn't allow programs to write willy-nilly all over memory, you'd save enough die space to put a couple of more execution units on there. Consider also the massive amounts of out-of-order execution hardware. If C wasn't built on the model of a unit-width instruct stream, a lot of that hardware could be dispensed with.

Programmers seem to have this idea that "C works the way CPUs work". Nothing could be farther from the truth. Modern CPUs are out-of-order, parallel vector machines. The C machine model assumes in-order, single-pipeline scaler machines. C assumes a linear memory space, while modern machines have complex cache hierarchies and often have non-uniform main memories. There are a lot of elements of functional languages that map better to modern hardware than does C. For example, in (strict) functional languages, the following two statements can be executed in parallel:

a = makea()
b = makeb()

A compiler for such a language can map these statements directly to two commmand streams issued to seperate execution units. A C compiler can do something similar, but has to go through massive dataflow analysis to ensure that makea() doesn't modify anything used in makeb(). In another example, functional languages tend to encourage the use of lots of small, transient objects, while C encourages accessing large, long-lived global data structures. Guess which one is more suited to modern machines, with small-fast caches, and large-slow main memories?

And that's just how hostile C is to modern hardware. Don't even get me started on how hostile its "every pointer can overwrite every object" model is hostile to mdoern compilers!

Re:Argh!

[sickofthisshit]

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.

Re:Argh!

[be-fan]

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.