Live data from Hacker News

Lisp as the Maxwell Equations of Software (2012)

michaelnielsen.org

111–120 of 131 posts

Re: Lisp as the Maxwell Equations of Software (2012)

#111
post #26

Earlier quoted context omitted.

> Modern Lisps are substantially different in syntax and semantics from these earliest ideas; we're just still calling them Lisp. An interesting take on "modern", meaning "the last 3 decades or so", which is like millenia in the IT industry...

I'm not sure what you're talking about here. The latest language in Lisp family is Clojure and it came out in 2007. The syntax that it uses is quite a bit different from Lisps from 30 years go.

I wouldn't call it quite a bit different. Really just seems to have a few small changes where they prefer [] over (). Otherwise just a different set of standard macros.

Or are you referring to some other difference?

Re: Lisp as the Maxwell Equations of Software (2012)

#112

I admit that I don't completely understand Lisp's claim to fame. Yes, programs in the language are represented by a built-in data type, and you can write a self-interpreter quite easily. But the same is true for a simple assembly language, if you know the instruction encoding! You can represent a program as a code pointer, and it's easy to write an analog of "eval" by hand, using just a handful of arithmetic instruct…

Lisp gets a great deal of undue credit as being some kind of timeless enlightened wisdom, which I see as ignorant of the history of the language's development. It took years to develop approaches to garbage collection (the earliest prototypes used bump allocators and crashed when they exhausted a heap), years to finalize the syntax of the language (you'll notice that the "maxwell's equations" are written using M-Expr…

Exactly the same is true of Maxwell's equations. The four we use today are different than the 20 he originally came up with; most of that reduction comes from vectorizing them, and they gain a lot of clarity by using vector-calculus operations such as gradient and curl.

Together these changes brush the computational complexities under the rug, and leave only the descriptive power of the laws:

* "the gradient of the electric field is proportional to the amount of electric charge"

* "the curl of an electric field is always zero"

* "the gradient of a magnetic field is always zero"

* "the curl of a magnetic field is proportional to the size of the electric current plus the amount of change in the electric field with respect to time".

Re: Lisp as the Maxwell Equations of Software (2012)

#113

I admit that I don't completely understand Lisp's claim to fame. Yes, programs in the language are represented by a built-in data type, and you can write a self-interpreter quite easily. But the same is true for a simple assembly language, if you know the instruction encoding! You can represent a program as a code pointer, and it's easy to write an analog of "eval" by hand, using just a handful of arithmetic instruct…

The "claim to fame" has more to do with homoiconicity, ie. that the language is its own syntax tree. This allows you to extend the language in arbitrarily complex ways in the language itself - a consequence of this is the simplicity of writing a self-interpreter. Languages involve a lot of apparent mystification, in part because the syntax tree and the semantics of the syntax tree are not the program you are writing.…

Where this argument loses me is that I have yet to see a single Lisp person going around extolling the virtues of Prolog, a language that is also homoiconic and has macros.

(If Lisp people want to start doing that though, I'd be happy. Prolog is great.)

Re: Lisp as the Maxwell Equations of Software (2012)

#115
post #26

Earlier quoted context omitted.

> Modern Lisps are substantially different in syntax and semantics from these earliest ideas; we're just still calling them Lisp. An interesting take on "modern", meaning "the last 3 decades or so", which is like millenia in the IT industry...

I understand that by "IT industry" you mean the Web, which is the industry's equivalent of a fashion show. Work clothes, suits and hazmat wear also don't change their design every three months.

Not redesign, but recycle old ideas. It might change in details, but as far as I've thus far observed, IT operates in cycles. The terminal + mainframe -> the personal computer -> the cloud (personal mainframe) -> ?

Like cycles in economics, climate, fashion, etc.

Re: Lisp as the Maxwell Equations of Software (2012)

#116

Earlier quoted context omitted.

The "claim to fame" has more to do with homoiconicity, ie. that the language is its own syntax tree. This allows you to extend the language in arbitrarily complex ways in the language itself - a consequence of this is the simplicity of writing a self-interpreter. Languages involve a lot of apparent mystification, in part because the syntax tree and the semantics of the syntax tree are not the program you are writing.…

Where this argument loses me is that I have yet to see a single Lisp person going around extolling the virtues of Prolog, a language that is also homoiconic and has macros. (If Lisp people want to start doing that though, I'd be happy. Prolog is great.)

Maybe that's because a "Lisp person" who did so would be considered a "Prolog person." :)

I'll give Prolog a shot!

Re: Lisp as the Maxwell Equations of Software (2012)

#117

Any chance of a resurgence in Lisp machines? Especially in view of the changes in CPU architecture due to semiconductor scaling challenges.

There is at least one current project - Mezzano -that boots a Common Lisp and some apps on bare metal.

But the Lisp Machines were more than Lisp on hw. They were about the software, the shell, the IDE. Some work was started more than 15 years ago to revive the CLIM API that made this possible and the original authors still work on it now. I'm really glad about this:

https://github.com/froggey/Mezzano

https://github.com/robert-strandh/McCLIM

Re: Lisp as the Maxwell Equations of Software (2012)

#118
post #114

Any chance of a resurgence in Lisp machines? Especially in view of the changes in CPU architecture due to semiconductor scaling challenges.

I think emacs is as close we are going to get to a Lisp Machine today.

Emacs just lacks the whole operating system written in Lisp, a capable Lisp implementation, the GUI library, and a whole bunch of other things...

Re: Lisp as the Maxwell Equations of Software (2012)

#119
post #39

Earlier quoted context omitted.

What's stopping you from making it happen? Developing your own special-purpose hardware is easier than ever these days. There are numerous open-source off-the-shelf FGPAs that are mature and fast.

One of the biggest issues is that a FPGA design running at 50-100 MHz (compare to the contemporaneous Cray-1 80MHz), with little memory that can be used as cache, gets blown out of the water by a +3GHz CPU with megabytes of on die cache. In terms of just being a "Lisp Machine", it only makes sense as retro-computing. Even a CADR, 3600 etc. simulator running on a fast x86-64 CPU would be (a lot) faster. See more in my…

Aren't we loosing the focus by looking at the Lisp Machines only from "HW" point of view? They were "ported" on Alpha, and I can run them today on a x86-64 VM.

I think we're overwhelmed by nostalgia and this stops us from looking at what's important: software. We are missing the software pieces that made the Lisp Machines. We don't have those and this is more important than not having a CL CPU.

I would hate to have a Lisp Machine made with today's custom hardware and all the C/C++/Java/Python guys come and ask: what was the fuss was all about? Where's that IDE from 25 years ago you so proudly preached?

Re: Lisp as the Maxwell Equations of Software (2012)

#120
post #8

Earlier quoted context omitted.

Things change. LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. The car/cdr list is just about the worst way to represent lists in terms of performance on modern CPUS. Conceptually it is really clean, but about the only application it makes sense for is first order theorem proving, or in languages that support pattern matching. If you actually want to use lists as lists…

That's... basically not even wrong. Lisp implementations that run well on, and take advantage of, architectures with caches, branch prediction and complex memory hierarchies are well-known, and have been well-known for, literally, decades. http://pt.withy.org/publications/VLM.html is an example from 1994. More importantly though, even the earlier Lisp machines (at least since 1983!) implemented a form of instruction…

I've been looking for some time for the whole paper but could not find anything but the abstract. Is it anywhere to be found?
Post reply on HN