Live data from Hacker News

Lisp as the Maxwell Equations of Software (2012)

michaelnielsen.org

21–30 of 131 posts

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

#21

Earlier quoted context omitted.

>LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. Yeah, let's just forget about decades of Lisp development since. >something like the Java ArrayList makes more sense. Except you lose the most important detail of Lisp pairs: persistence.

Persistence has some good properties, particularly if you are writing compilers. Just about every language that promises an advance in parallelism (other than solidly "worse is better" approaches such as Hadoop and Pig) is selling some kind of snake oil, and immutability is one of the worst of them. Immutability has benefits in terms of correctness, but not in terms of scalability to more processors or total throughp…

>Immutability has benefits in terms of correctness, but not in terms of scalability to more processors or total throughput.

I'll take correctness over raw performance any day.

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

#22
post #8

Earlier quoted context omitted.

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…

The car/cdr list is the only data structure described in cute metacircular interpreters, and even then only when supported by a substantial amount of implied runtime code.

This doesn't look like a substantial runtime code.

http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

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

#23
post #14

Earlier quoted context omitted.

>LISP was popular in the 1980s before caches, branch prediction, and complex memory hierarchies. Yeah, let's just forget about decades of Lisp development since. >something like the Java ArrayList makes more sense. Except you lose the most important detail of Lisp pairs: persistence.

And in practice, compromise is possible. E.g. Clojure's vectors which are unashamedly LISP-like to work with, but still avoid much of the pointer-chasing of a linked list.

Yes, there are various implementations of persistent vector-like lists, Clojure's being one of them. They are extremely useful, however, they are far more complex than a cons cell. Most of the time, I want simple cons cells.

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

#24
post #22

Earlier quoted context omitted.

The car/cdr list is the only data structure described in cute metacircular interpreters, and even then only when supported by a substantial amount of implied runtime code.

This doesn't look like a substantial runtime code. http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

That doesn't look like sufficient runtime code. That paper quite explicitly avoids implementing a garbage collector, among other things.

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

#25
Hi, Submitter here,

I stumble upon that article from my bookmarks while pouring my latest side project (http://www.learn-computing-directory.org/languages-and-progr...) and thought about submitting it to HN. By the way, feel free to give me feedbacks about the directory! (in still in very alpha state but already online). I only fill for the moment the "Algorithms and Data Structures", "Compilers" and "Theory of computation" topics.

Two great articles that complements perfectly the one submitted are LISP interpreters in Python from Norvig: http://norvig.com/lispy.html and http://norvig.com/lispy2.html Also, the book "Understanding Computation" (http://computationbook.com/) can be a great companion as there is a section about Lambda Calculus.

Jérémie.

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

#26

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…

>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...

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

#27
While this is nice academic view. As a Lisp programmer, the Power of Lisp comes from being big ball of mud, see: https://en.wikipedia.org/wiki/Big_ball_of_mud#In_programming....

Usable and efficient Common Lisp implementation can be build from just ~25 primitives (more than core LISP but still very elegant). Elegant derivation of Lisp world does not matter when the atoms and the molecules can't be distinguished. Is the object system and meta-object protocol implemented as primitives by people who designed the Lisp implementation, or is it external library? Who cares. Only performance and correct function matter.

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

#28

Earlier quoted context omitted.

Persistence has some good properties, particularly if you are writing compilers. Just about every language that promises an advance in parallelism (other than solidly "worse is better" approaches such as Hadoop and Pig) is selling some kind of snake oil, and immutability is one of the worst of them. Immutability has benefits in terms of correctness, but not in terms of scalability to more processors or total throughp…

>Immutability has benefits in terms of correctness, but not in terms of scalability to more processors or total throughput. I'll take correctness over raw performance any day.

I am with you, specially since we all know where languages obsessed with performance over correctness lead to.

http://web.nvd.nist.gov/view/vuln/search-results?query=&sear...

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

#29

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…

No language that is developed is perfect on release. The timeless wisdom of Lisp, as you call it, rest largely on macros and lambdas. Those ideas are powerful in their ability to allow you to build abstractions and customize the language to your needs. Basically, Lisp allowed for DSLs before the concept of a DSL was even recognized.

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

#30
post #22

Earlier quoted context omitted.

This doesn't look like a substantial runtime code. http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

That doesn't look like sufficient runtime code. That paper quite explicitly avoids implementing a garbage collector, among other things.

A simple reference counted implementation with cycle collector is not a big deal to implement, nor a substantial effort.

It might perform like a dog, but that is another matter.

Post reply on HN