Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp as the Maxwell Equations of Software (2012)

michaelnielsen.org

Post reply on HN
Print view View original

41–50 of 131 posts

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

#41

Post by [deleted] »

Delmania wrote: post #29
RodgerTheGreat wrote: post #17

Earlier quoted context omitted.

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.

[deleted]

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

#42

Post by phkahler »

I hate that. The half page of code is not Lisp. Not even close, and I'm not talking about a standard library. There is no parser in there. Eval is operating on Lisp data, not lisp source code. There is no support for efficient math, or strings, or anything really.

If that is lisp, then a byte code interpreter loop is every interpreted language: read_opcode, inc_pc, call a function indexed from a list indexed by opcode. It can be written in one line of C. This BTW translates to hardware a lot easier than the half page of Lisp. That one line of code by itself is also just as useless as the half page of Lisp.

It's still interesting, but people need to stop claiming it's Lisp defined in this tiny little block of code.

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

#43

Post by [deleted] »

mjburgess wrote: post #19
cousin_it wrote: post #13

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

[deleted]

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

#44

Post by [deleted] »

[deleted] wrote: post #43
mjburgess wrote: post #19

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

[deleted]

[deleted]

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

#45

Post by [deleted] »

phkahler wrote: post #42

I hate that. The half page of code is not Lisp. Not even close, and I'm not talking about a standard library. There is no parser in there. Eval is operating on Lisp data, not lisp source code. There is no support for efficient math, or strings, or anything really. If that is lisp, then a byte code interpreter loop is every interpreted language: read_opcode, inc_pc, call a function indexed from a list indexed by opcod…

[deleted]

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

#46

Post by gsg »

davexunit wrote: post #23
dasmoth wrote: post #14

Earlier quoted context omitted.

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.

There are schemes to "unroll" conses, too. CDR-coding, Appel's paper (although IIRC that requires immutable conses), etc.

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

#47

Post by pjmlp »

hga wrote: post #37
pjmlp wrote: post #28

Earlier quoted context omitted.

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

Although the funny thing is, as the 2nd oldest surviving computer language after FORTRAN, and at least back then used for very difficult problems, to be competitive let alone justifiable on extremely scarce and expensive hardware, "Lisp" has always been "obsessed" with performance. ADDED along with a bit before: It first ran on the IBM 704, a vacuum tube computer. It was derived from the IBM 701, which initially used…

Yes, but there are many ways to be obsessed with performance while keeping correctness.

As you might imagine by my post history I had a specific language in mind.

Funny that you mention FORTRAN, as it reminds me of a systems programming language used for writing several OS, about the same age as FORTRAN and Lisp, namely Algol and its variants.

When they questioned their customers if Algol compilers should support disabling bounds checking, they said no responsible engineer would ever need it. As described by Hoare on his Turing award.

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

#48

Post by rdmckenzie »

quarterwave wrote: post #15

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

Almost certainly not, see the most recent post on this subject https://news.ycombinator.com/item?id=9013669

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

#49

Post by abecedarius »

cousin_it wrote: post #13

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…

Turning that around, there was the Scheme-79 chip: http://dspace.mit.edu/handle/1721.1/6334

This takes Lisp as the machine language of a high-level machine (with READ as the assembler). You could do the same with C, but without a compiler stage it'd be absurd.

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

#50

Post by [deleted] »

abecedarius wrote: post #49
cousin_it wrote: post #13

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…

Turning that around, there was the Scheme-79 chip: http://dspace.mit.edu/handle/1721.1/6334 This takes Lisp as the machine language of a high-level machine (with READ as the assembler). You could do the same with C, but without a compiler stage it'd be absurd.

[deleted]
Post reply on HN