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

81–90 of 131 posts

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

#81

Post by MeadowTheory »

abecedarius wrote: post #51
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.

I'm rather partial to the differential form version. Something about the neat almost symmetry (in the layman's sense) of the two equations. And how deceptively innocent looking they are.

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

#82

Post by MeadowTheory »

one-more-minute wrote: post #77
jheriko wrote: post #73

surely this is actually that a short lisp compiler or interpreter is the maxwell's equations. the analogy is way off the mark for software as a discipline in total. you can know nothing about lisp and understand pretty much everything... thats not true of classical electromagnetism and maxwell's equations

Not necessarily. You learn a ton about electromagnetism before you ever get to Maxwell's equations.

Faraday sure did.

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

#83

Post by MeadowTheory »

one-more-minute wrote: post #77
jheriko wrote: post #73

surely this is actually that a short lisp compiler or interpreter is the maxwell's equations. the analogy is way off the mark for software as a discipline in total. you can know nothing about lisp and understand pretty much everything... thats not true of classical electromagnetism and maxwell's equations

Not necessarily. You learn a ton about electromagnetism before you ever get to Maxwell's equations.

Faraday sure did.

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

#84

Post by michaelsbradley »

RodgerTheGreat wrote: post #17
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…

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…

Some of the "old Lisp things" are becoming new again.

For example, John Shutt has developed a non-trivial theory of F-Expressions (vau-calculus)[1] and a language named Kernel that employs them[2]. Neither has received wide attention yet, but the Lisp renaissance of the past few years is still young...

[1] https://www.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unr...

[2] ftp://ftp.cs.wpi.edu/pub/techreports/pdf/05-07.pdf

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

#85

Post by cousin_it »

agumonkey wrote: post #67
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…

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…

There's a spectrum of near vs. far from the machine, but there's no spectrum of computability, all Turing complete languages are equally Turing complete. There's no difference between Lisp and assembly in this regard. In fact if you take into account the big-O time complexity, then assembly is better than the version of Lisp described in the OP, because the latter suffers a logarithmic penalty due to immutability.

More to the point, Lisp is nice because it's in a sweet spot of language complexity vs self-interpreter complexity, and lambda calculus is nice because it's a simple basis of computation. But there are many languages that make self-interpreters simple (assembly, Forth...) and many simple bases of computation (SKI calculus, rule 110...)

To call something the "Maxwell equations of software", IMO you need something more substantial. For example, Haskell folks can claim that lazy evaluation is provably superior (in termination and time complexity) to any other evaluation strategy. The dependent typing folks can claim that all valid programs correspond to valid proofs and vice versa, and that strict and lazy evaluation are equivalent w.r.t. termination. The guy behind Kernel can claim that the one true Lisp should allow you to mapcar a macro. There are many kinds of wonderful math that give you insight into computation!

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

#86

Post by julienchastang »

Permit wrote: post #68
julienchastang wrote: post #32

Earlier quoted context omitted.

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

The thing is when you know lisp (or scheme) you understand programming languages much more fundamentally than you would otherwise and so jumping from one programming language to another becomes much easier. (BTW, I hated Scheme in school, but I have since seen the light thanks to SICP.) Overall, I agree with the theme of this sub-thread that non-idiomatic code in any language is a real pain in the ass. I see this everyday when I look at code written by scientists who are smart, driven, motivated people and therein lies the problem.

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

#87

Post by hga »

cousin_it wrote: post #85
agumonkey wrote: post #67

Earlier quoted context omitted.

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…

There's a spectrum of near vs. far from the machine, but there's no spectrum of computability, all Turing complete languages are equally Turing complete. There's no difference between Lisp and assembly in this regard. In fact if you take into account the big-O time complexity, then assembly is better than the version of Lisp described in the OP, because the latter suffers a logarithmic penalty due to immutability. Mo…

Please correct me if I'm wrong, since this is very much not my field, but as I understand it, there are at least 4-5 mathematically equivalent fundamental models of computation, and in practice the Turning machine and the lambda calculus (developed by Turing's thesis adviser ... I gather that was a small world back then) are useful.

E.g. does the additional math you're talking about stand on top of either of those? I don't know (By nature and calling I'm a scientist of the continuous world, not discrete, damnit! :-).

Of course, I'm moving the goalposts by using "Lisp" as a stand in for the lambda calculus (and I remember someone, maybe McCarthy, saying Lisp is what you get after you've read and only understand the first chapter of a book on it :-), which I don't even know at the poets level (but am maybe starting to correct that; don't know if the payoff is worth it to me at this point in my life).

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

#88

Post by GregBuchholz »

hga wrote: post #39
copsarebastards wrote: post #31

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…

Modern high-end FPGAs can have upwards of 5-10 megabytes of on die memory:

http://www.xilinx.com/products/silicon-devices/fpga/virtex-u...

http://www.altera.com/devices/fpga/stratix-fpgas/stratix-v/o...

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

#89

Post by sedachv »

Permit wrote: post #68
julienchastang wrote: post #32

Earlier quoted context omitted.

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

What's wrong with DSLs? They make it easier to read and understand code.

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

#90

Post by hga »

GregBuchholz wrote: post #88
hga wrote: post #39

Earlier quoted context omitted.

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…

Modern high-end FPGAs can have upwards of 5-10 megabytes of on die memory: http://www.xilinx.com/products/silicon-devices/fpga/virtex-u... http://www.altera.com/devices/fpga/stratix-fpgas/stratix-v/o...

What do they cost in single unit quantities, or rather, what does a development board that I can stick GiBs of hopefully ECC DRAM cost? And the development tools?

I know I can do this with small scale ones, including some of the tools, on sub-$100/$200 boards with not a lot of memory (the research lowRISC has prompted me to do has been fascinating). If the answer to the above is 6 figures, the intersection of those who can afford it and those who are inclined to do it would be small.

Maybe not 0, then again, at what speed could you get a synchronous microcoded CPU working? Aren't we still talking way way below +3GHz, like the 50-100MHz I just cited? Is 200MHz possible?

I've read of one that uses magic (and no doubt $$$ in tools) to translate your sync design into an faster async one in the middle of their magic FPGAs, but even then I don't recall the potential speed breaking past a GHz if that. Although that was a while ago, 1-2 Moore's Law doublings ^_^.

Flip side, are the FPGA companies going to open up their kimonos to allow a lot more people to design in their increasingly inexpensive (Moore's Law) parts?

Post reply on HN