for what it is worth, here is a version of a lisp interpreter I wrote in python:
https://github.com/keithgabryelski/plisp
I used _Interpreting_LISP_ by Gary D. Knott as a guide.
Lisp as the Maxwell Equations of Software (2012)
71–80 of 131 posts
Re: Lisp as the Maxwell Equations of Software (2012)
#72for what it is worth, here is a version of a lisp interpreter I wrote in python:
https://github.com/keithgabryelski/plisp
I used _Interpreting_LISP_ by Gary D. Knott as a guide.
Re: Lisp as the Maxwell Equations of Software (2012)
#73surely 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
Re: Lisp as the Maxwell Equations of Software (2012)
#74I 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.
Einstein tensor notation is amazing. :)
Re: Lisp as the Maxwell Equations of Software (2012)
#75I 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.
Perhaps, but when you add alternates like Algol and PL/1 (1964) that case becomes a lot weaker. (Although I don't really know Algol and only know PL/1 as of IBM's late '70s version.) The weaknesses of COBOL were widely realized (and in it's niches it's not hardly so bad, or so I say from one week of using it).
Re: Lisp as the Maxwell Equations of Software (2012)
#76Earlier quoted context omitted.
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 thinki…
I agree completely, and didn't mean to compare the Turing machine to Lambda calculus, only to the C language (it made more sense before the context above was deleted).
Re: Lisp as the Maxwell Equations of Software (2012)
#77surely 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.
Re: Lisp as the Maxwell Equations of Software (2012)
#78Earlier 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…
A big problem is people being too smart for their own good. But that happens in all languages.
Re: Lisp as the Maxwell Equations of Software (2012)
#79I 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…
I saw that bit about McCarthy too. I wonder if his point was that while you can do functional programming in lisp, you can do a lot of other non-functional-programming stuff too, and so in that sense he didn't see Lisp as an implementation of lambda calculus.
Re: Lisp as the Maxwell Equations of Software (2012)
#80Earlier 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…
It depends on the complexity of the new language, doesn't it? If these new languages are highly domain-specific DSL's for complex domains, then the entire software package might be more understandable overall.