Lisp as the Maxwell Equations of Software (2012) • Hacker News Board

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

#51

Post by abecedarius » Thu, Feb 12, 2015, 4:17 PM UTC

samatman wrote: post #36

I understand why Alan Kay said what he did, but a closer analogy would be to Euclid's Elements. If one follow's Lisps axioms, one ends up with Lispian Computation, elegant, clean, tail-call optimized. Other axioms of computing lead the user in different directions, notably Hindley-Milner. Lisp carves territory in mathematical state space, not physical reality.

Maxwell's equations in the usual Heaviside form aren't even the most elegant way to write them: http://www.av8n.com/physics/maxwell-ga.htm

I'm curious how people might carry that through the analogy.

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

#52

Post by unoti » Thu, Feb 12, 2015, 4:24 PM UTC

There's nothing inherently unnatural about taking a bottom up approach to solving problems. Sometimes, knowing you're going to need a particular tool and doing that first makes sense. I think of it like the cooking technique Mise en place [1], where you lay out all the ingredients before you start cooking. Neither bottom up, nor top down, is always the most natural way to attack a problem. Sometimes you can attack a problem from both sides at once.

http://en.m.wikipedia.org/wiki/Mise_en_place

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

#53

Post by abecedarius » Thu, Feb 12, 2015, 4:27 PM UTC

RodgerTheGreat wrote: post #24

pjmlp wrote: 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.

Here's the complete runtime of my garbage-collected self-hosting Lisp-to-C compiler: https://github.com/darius/ichbins/blob/master/ichbins.scm#L2...

(Yes, it's not the world's fastest.)

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

#54

Post by GregBuchholz » Thu, Feb 12, 2015, 4:28 PM UTC

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…

I think there are multiple factors to Lisp's claim to fame, and other have covered a few of them. But one thing to also keep in mind is the historical context. Lisp had features like garbage collection and much more of a "batteries included" standard library. It was a much higher level language, and more safe to use (memory safe, fewer incidence of off-by-one errors, etc.) compared to most other contemporary languages in the 70s and 80s (C for instance). You might still see a lot of Lisp advocacy aimed at wooing you away from those languages by touting the virtues of bignums/rationals, garbage collection, anonymous functions/closures, etc.. By the time the late 90s and 2000s rolled around pretty much of all of the popular languages had incorporated high-level features pioneered by lisp, and so now-a-days lisp doesn't probably seem quite as attractive to python or ruby or javascript or C# or Haskell users. Also, I think there may just be some personal preferences involved in different language choices. If you like C, and think it is a great language, then I'd say there is a lower probability that you'd like lisp, because they have a different philosophy about how programs could be built.

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

#55

Post by hga » Thu, Feb 12, 2015, 4:33 PM UTC

pjmlp wrote: post #47

hga wrote: post #37

Earlier quoted context omitted.

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

To indicate how far we've come from that, my biggest concern with the lowRISC project I mention elsewhere is that it's a RISC-V project, and in a very New Jersey way, that CPU has no provision for integer math errors other than divide by zero. Also makes the large integer cryptographic crowd rather upset.

While this is ... tolerable, I seriously wonder what other corners are being cut, e.g. in the unreleased privileged ISA.

(A bit more background: RISC-V is intended to be a open core for everything, so making the base processor simple for education is good, but promoting it as a CPU for industry is in the direction of bad, IMHO.)

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

#56

Post by quarterwave » Thu, Feb 12, 2015, 4:40 PM UTC

hga wrote: post #34

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.

I've been thinking hard about this lately, and the first question for me is "What would a 21st Century Lisp Machine mean ?" Lisp Machines were created in part due to the desire to get the most performance possible back in the days when CPUs were made out of discrete low and medium scale integration TTL (there were also ECL hot-rods, but their much greater costs across the board starting with design limited them to pr…

Thanks for the detailed perspective.

My limited & roseate view of a 21st century Lisp machine is based on an old theme - a massively parallel computing system using bespoke silicon logic blocks.

As you have noted below, not only are the cache sizes in a modern CPU monstrous, there's also the compilers optimized for these caches, instructions, branch prediction units, etc. No point in ending up with a chip that is much slower than an equivalent one running on a specially-designed virtual machine, which is itself much slower than MPI.

Dreaming on, such a Lisp machine would need a vast collaborative academic effort with substantially new IP design, in say the 32nm silicon process node. That's the most advanced node where lithography is still (somewhat) manageable for custom IP design.

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

#57

Post by hga » Thu, Feb 12, 2015, 4:42 PM UTC

[deleted] wrote: post #50

abecedarius wrote: post #49

Earlier quoted context omitted.

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]

ADDED: the author of the deleted post I'm responding to thought that he remembered that the Scheme 79 chip failed to actually run Lisp (Scheme). I replied:

Not that I know of, but only because of microcode errors. I was told "Sussman wasn't quite as smart as he thought he was" to tape it out without making really sure the microcode was correct.

In all fairness, at the time they had little in the way of available computer resources to e.g. simulate it, and it was all part of a very exciting time when MIT started doing Mead and Conway style VLSI, see https://en.wikipedia.org/wiki/Mead_%26_Conway_revolution and note the latter gave a famous course on it at MIT in 1978.

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

#58

Post by gobengo » Thu, Feb 12, 2015, 4:46 PM UTC

What does Lisp provide on top of e.g. the lambda calculus? I'd expect the latter to be even more fundamental. But I suppose one could reasonably argue that that wasn't 'Software', just Math.

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

#59

Post by [deleted] » Thu, Feb 12, 2015, 4:48 PM UTC

gobengo wrote: post #58

What does Lisp provide on top of e.g. the lambda calculus? I'd expect the latter to be even more fundamental. But I suppose one could reasonably argue that that wasn't 'Software', just Math.

[deleted]

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

#60

Post by protomyth » Thu, Feb 12, 2015, 4:48 PM UTC

hga wrote: post #34

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.

I've been thinking hard about this lately, and the first question for me is "What would a 21st Century Lisp Machine mean ?" Lisp Machines were created in part due to the desire to get the most performance possible back in the days when CPUs were made out of discrete low and medium scale integration TTL (there were also ECL hot-rods, but their much greater costs across the board starting with design limited them to pr…

I've been wondering about it since like every other programmer I hit that time when I'm really looking at programming languages and VMs (in the "what would I design" sense). Looking to Lisp Machines to see what they were about leads me to the question: would concentrating on hardware memory management / garbage collection be a starting point to answer your question?