Live data from Hacker News

Lisp as the Maxwell Equations of Software (2012)

michaelnielsen.org

61–70 of 131 posts

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

#61
post #59
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]

I think you've missed the point of OPs question - he's not trying to argue that lisp isn't useful over Lambda Calculus from a practical perspective, but asking how both relate to the "fundamentals of computing" perspective.

So to answer your question, nothing (in this context), because the Turing machine is a more useful model for thinking about computation itself.

Perhaps the same might apply to lisp / lambda calculus, although I suspect the answer here is that it's just a lot harder to right a self-interpreter in lambda calc.

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

#62

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

Thanks for this reference.

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

#63
post #34

Earlier quoted context omitted.

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

Well, there's the first Connection Machine architecture, very roughly contemporaneous with Lisp Machines (I had to regretfully tell my friend Danny Hillis that LMI wouldn't be able to provide Lisp Machines for Thinking Machines Corporation in time (which had to be formed because the project needed 1-2 analog engineers, which MIT was structurally unable to pay, no one gets paid more than a professor). He was really, legitimately pissed off by what Symbolics did with Macsyma, a sleazy licensing deal to keep it out of everyone else's hands (and they tried to get everyone in the world who'd gotten a copy of it to relinquish it). Later neglected, even when it became the Symbolics cash cow.)

Anyway, if you're not talking ccNUMA, the limitations of which has got me looking hard at Barrelfish (http://www.barrelfish.org/), e.g. if you're talking stuff in the land of MPI, again it's going to be very hard to beat commodity CPUs.

Although in that dreaming, look at lowRISC: http://www.lowrisc.org/ looking at things now, they propose taping out production silicon as soon as 2016, and say 48 and 28nm processes look good. From the site:

What level of performance will it have?

To run Linux "well". The clock rate achieved will depend on the technology node and particular process selected. As a rough guide we would expect ~500-1GHz at 40nm and ~1.0-1.5GHz at 28nm.

Is volume fabrication feasible?

Yes. There are a number of routes open to us. Early production runs are likely to be done in batches of ~25 wafers. This would yield around 100-200K good chips per batch. We expect to produce packaged chips for less than $10 each.

And with a little quality time with Google, the numbers look good. Ignoring the minor detail of NRE like making masks, a single and very big wafer really doesn't cost all that much, like quite a bit less than $10K.

And we now have tools to organize these sorts of efforts, e.g. crowdsourcing. But it's not trivial, e.g. one of the things that makes this messy is modern chips have DRAM controllers, and that gets you heavily into analog land. But it's now conceivable, which hasn't been true for a very long time, say starting somewhere in the range between when the 68000 and 386 shipped in the '80s.

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

#64
post #34

Earlier quoted context omitted.

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?

One indication is that Azul, after 3 generations of ccNUMA systems with zillions of custom chips and a memory infrastructure that gives each one "mediocre" access speed to all the system's memory for running Java with gonzo GC ("generic" 64 bit RISC chips with things like a custom read barrier instruction), has given up and is doing their thing on x86-64 systems with their Zing product, albeit at least initially with tricks like kernel extensions to do bulk MMU operations before a single TLB invalidation. Look up their papers on the Pauseless and C4 GCs. The former was done in time to make it into the 2nd edition of sorts of the book on GC: http://www.amazon.com/Garbage-Collection-Handbook-Management...

Or to put it another way, without exhausting my bank account I could build from parts I can purchase today on Newegg a many CPUs 3/4ths TiB DRAM Supermicro system. Supermicro has standard boards with more memory, and has a monster you can only buy complete that'll hold 4 CPU chips and up to 6 TiB DRAM on daughter boards; I think based on some Googling that has a starting price of less than $35K.

Moore's Law is our friend. But its economics is not the friend of custom CPUs in competition with commodity ones.

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

#66

Earlier quoted context omitted.

As far as I know, re-posts are allowed after some period of time has elapsed. I don't think this is documented anywhere though.

I've always figured the URLS just fall off a queue, so there's no absolute period of time involved. No actual knowledge, just a guess.

sweet, so we could attempt to find out the queue size!!

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

#67

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…

It's the opposite side of the computing spectrum. Many languages aimed at using machines, Lisp was an ideal to express computability. As other said, yeah the eval definition hides away GC, IO and the read function, which fits my interpretation (sic) of lisp as an abstraction abstraction. They weren't interested much in the machine details, this itself is already a fun fact.

So it started an ideal until a student was foolish enough to actually program it. Yet this vaporous ideal was enough to write a symbolic differentiator. You don't have bytes nor integers but you can express non trivial mathematical concepts.

You had almost nothing yet you could do a lot, another fun fact. To me Lisp is like a linguistic library, on top of which you'll add primitive types as needed. The expressiveness is given by scope, lambdas, logic and recursion, the rest is secondary. Maybe my lambda calculus classes are making me biased though. McCarthy said he wasn't too inspired by LC even though I've read he was a student of A. Church.

ps: about scoping, I've read emails from Lisp users circa 59 who were discussing the addition of lexical scope, that was before Algol was publicly released.

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

#68

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…

If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases. - Guy L. Steele

That seems like a huge disadvantage to me. The bottle neck in any software project (> 1 person) is usually the time it takes to read and understand source code. Some estimates[1] claim that up to 78% of development time is spent just reading code.

With that in mind, I would not want to learn a new language for every project I was a part of. I'd even go so far as to say: The majority of programmers cannot design a good language, and if Lisp gives them the opportunity to try then that's a BadThing™.

[1]http://blogs.msdn.com/b/peterhal/archive/2006/01/04/509302.a...

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

#69
post #59

Earlier quoted context omitted.

[deleted]

I think you've missed the point of OPs question - he's not trying to argue that lisp isn't useful over Lambda Calculus from a practical perspective, but asking how both relate to the "fundamentals of computing" perspective. So to answer your question, nothing (in this context), because the Turing machine is a more useful model for thinking about computation itself. Perhaps the same might apply to lisp / lambda calcul…

> So to answer your question, nothing (in this context), because the Turing machine is a more useful model for thinking about computation itself.

This isn't obvious to me. It seems to me that a TM is more useful for thinking about computation from an operational perspective. But this isn't the only, or arguably even the most effective, way to think about computation. The lambda calculus is much more useful for thinking about computation from a denotational perspective.

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

#70

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…

Try writing a complex program in 1960s era COBOL. Then you will understand a large part of Lisp's claim to fame.
Post reply on HN