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

Marvin Minsky – The beauty of the Lisp language

webofstories.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Marvin Minsky – The beauty of the Lisp language

#31

Post by svantana »

ISL wrote: post #10

What does he mean when he says that it's not possible to write a C program that can write other C programs? Seems like there are counterexamples here: http://www.nyx.net/~gthompso/quine.htm Furthermore, it's possible to encode another programs' code into a single print statement, thereby writing one piece of code with another. As that's trivial, I suspect he meant something else. What was it? :).

He's most likely referring to the homoiconicity of lisp (http://en.wikipedia.org/wiki/Homoiconicity) - when processor operations are a data type, writing a subprogram and executing it is as simple as filling in an array. In C, you would need to have a C compiler and a virtual machine in your program to run it!

Re: Marvin Minsky – The beauty of the Lisp language

#32

Post by protomyth »

malandrew wrote: post #24
calibraxis wrote: post #4

Earlier quoted context omitted.

I get the impression Lisp tended to be taught awfully, uninspiringly. Maybe even worse than other programming languages. Cheating sounds like a reasonable response to such a farce of "education"; sad to hear when exposure to Lisp is a soul-crushing experience. I've seen a few old AI books where Lisp code is formatted unreadably. I wonder why.

The Little Schemer is think is one of the most inspiring ways to learn. Truly a book every software engineer should enjoy.

The sequel books are also work looking at (The Seasoned Schemer, The Reasoned Schemer).

Re: Marvin Minsky – The beauty of the Lisp language

#33

Post by weland »

ISL wrote: post #10

What does he mean when he says that it's not possible to write a C program that can write other C programs? Seems like there are counterexamples here: http://www.nyx.net/~gthompso/quine.htm Furthermore, it's possible to encode another programs' code into a single print statement, thereby writing one piece of code with another. As that's trivial, I suspect he meant something else. What was it? :).

Quines are not quite the same thing.

Reasonably simple illustration: in Common Lisp, it is possible to write a function that takes a mathematical expression as an argument and returns another expression, as its derivative.

So basically I can write (pseudo-lisp-ish):

(defun diff (f) ... )

then call it like this:

(diff '(+ (pow x 2) x)

and I'd get the expression

(+ (* 2 x) 1)

as a result. The point is, however, that this expression is Lisp-callable code. If I already have a function p, I can write:

(setq dp (diff p))

and dp is now the function computed by (diff p).

This is not necessarily the most practically-useful example, but I think it's closest to being a strong illustration of the principle. In a nutshell, you can do symbolic manipulation with code from within your code.

Edit: I just read your other post from this thread. It's important to note that this happens at runtime, not at compile time.

This isn't impossible to do in C if you really want, but it wouldn't be portable (the reason for this is left at the user's discretion). Think about how you would do the same in C: write a function that takes a pointer to a function f, and returns a pointer to another function g, so that g is the derivative of f. It's obviously ok to restrict f to common mathematical operators.

I can think about ways of doing it, but it ain't pretty.

Re: Marvin Minsky – The beauty of the Lisp language

#34

Post by p4bl0 »

weland wrote: post #33
ISL wrote: post #10

What does he mean when he says that it's not possible to write a C program that can write other C programs? Seems like there are counterexamples here: http://www.nyx.net/~gthompso/quine.htm Furthermore, it's possible to encode another programs' code into a single print statement, thereby writing one piece of code with another. As that's trivial, I suspect he meant something else. What was it? :).

Quines are not quite the same thing. Reasonably simple illustration: in Common Lisp, it is possible to write a function that takes a mathematical expression as an argument and returns another expression, as its derivative. So basically I can write (pseudo-lisp-ish): (defun diff (f) ... ) then call it like this: (diff '(+ (pow x 2) x) and I'd get the expression (+ (* 2 x) 1) as a result. The point is, however, that th…

Actually if you had to do this kind of thing in C or any other non-homoiconic language, the right way to go would be to define data structures that represent your mathematical functions, and manipulate these structures to compute the derivatives (by pattern matching of the represented mathematical expression, exactly as you would do in Lisp using Lisp code which kind of is its own AST). And you would have to embed an interpreter for the mathematical expressions encoded in the data structures of your program, so you can not only manipulate the expressions, but also use them (which also comes for free in Lisp).

See Greenspun's tenth rule of programming.

Re: Marvin Minsky – The beauty of the Lisp language

#35

Post by islon »

kirkthejerk wrote: post #25
kirkthejerk wrote: post #3

I got great grades in college, but could never wrap my head around LISP (Lost In Stupid Parentheses). For anything non-trivial, I cheated and handed in somebody else's work. There, I said it.

My prob wasn't really about being lost in parenthesis; I had an editor with bracket matching. My prob was the "inside-out" thinking that LISP requires. It's tricky when you're coming from a BASIC/PASCAL/C background. I'm a sucker for punishment, so after my first (bad) taste of LISP, I took an AI course that was 100% LISP. My AI teacher studied under McCarthy at Stanford, so I probably can't blame him for anything.

In clojure you have thread macros to solve the “inside-out” problem.

(-> 3 (+ 6) (* 7) (/ 12))

or (just an example, fictional names)

(->> object reflector fields (map :balance) (filter #(> % 1000))

Which reads like (pseudo language)

object.reflector().fields().map(:balance).filter(field -> field > 1000)

Re: Marvin Minsky – The beauty of the Lisp language

#36

Post by agumonkey »

ISL wrote: post #10

What does he mean when he says that it's not possible to write a C program that can write other C programs? Seems like there are counterexamples here: http://www.nyx.net/~gthompso/quine.htm Furthermore, it's possible to encode another programs' code into a single print statement, thereby writing one piece of code with another. As that's trivial, I suspect he meant something else. What was it? :).

First by 'cannot' he means 'cannot easily', as other stated it's more than printing source code, and goes into metaprogramming quickly, and high cost resistance will render attempts at doing so in C-like languages painfull.

Also, historical context matters, in the late 50s I believe this was very foreign to how machines were seen and used.

Re: Marvin Minsky – The beauty of the Lisp language

#37

Post by weland »

p4bl0 wrote: post #34
weland wrote: post #33

Earlier quoted context omitted.

Quines are not quite the same thing. Reasonably simple illustration: in Common Lisp, it is possible to write a function that takes a mathematical expression as an argument and returns another expression, as its derivative. So basically I can write (pseudo-lisp-ish): (defun diff (f) ... ) then call it like this: (diff '(+ (pow x 2) x) and I'd get the expression (+ (* 2 x) 1) as a result. The point is, however, that th…

Actually if you had to do this kind of thing in C or any other non-homoiconic language, the right way to go would be to define data structures that represent your mathematical functions, and manipulate these structures to compute the derivatives (by pattern matching of the represented mathematical expression, exactly as you would do in Lisp using Lisp code which kind of is its own AST). And you would have to embed an…

> Actually if you had to do this kind of thing in C or any other non-homoiconic language, the right way to go would be to define data structures that represent your mathematical functions, and manipulate these structures to compute the derivatives (by pattern matching of the represented mathematical expression, exactly as you would do in Lisp using Lisp code which kind of is its own AST).

Yes, of course. The language, being non-homoiconic, would require you to translate between a data representation that you can process and the data representation that the runtime can process.

However, if you were to do the equivalent thing -- that is, obtain the derivative based on the data representation that your runtime can process -- you'd have to examine the contents of the program memory itself. Needless to say, that would make things even unportable, or outright impossible due to compiler optimizations. But it would be the same thing :).

Edit: perversity bonus, you're working on a computer that does bank switching and the code that is computing the derivative is in a different memory bank than the function whose derivative it must compute.

Re: Marvin Minsky – The beauty of the Lisp language

#38

Post by 6d0debc071 »

kirkthejerk wrote: post #25
kirkthejerk wrote: post #3

I got great grades in college, but could never wrap my head around LISP (Lost In Stupid Parentheses). For anything non-trivial, I cheated and handed in somebody else's work. There, I said it.

My prob wasn't really about being lost in parenthesis; I had an editor with bracket matching. My prob was the "inside-out" thinking that LISP requires. It's tricky when you're coming from a BASIC/PASCAL/C background. I'm a sucker for punishment, so after my first (bad) taste of LISP, I took an AI course that was 100% LISP. My AI teacher studied under McCarthy at Stanford, so I probably can't blame him for anything.

Did you try thinking aloud what you were writing? Like, while writing (+ 5 6), saying "Sum of five and six." I found the prefix style a little odd until I started doing that.

Re: Marvin Minsky – The beauty of the Lisp language

#39

Post by nonrecursive »

Derbasti wrote: post #26
nonrecursive wrote: post #22

Earlier quoted context omitted.

I've been writing a book on Clojure, "Clojure for the Brave and True": http://www.braveclojure.com . It's meant to be an entertaining guide which focuses on getting you up and running quickly. It also explains the more novel parts of lisp in a clear, non-academic way. It's free online and is going to be published by No Starch eventually. Hope you find it useful!

Your book is beautiful! Highly recommend! I very much like your style! (there are some formatting errors though, like unresolved org-mode symbols)

Thanks :D

I've been trying to find and fix the formatting errors. I think most of them are fixed by now. At least, I hope so!

Re: Marvin Minsky – The beauty of the Lisp language

#40

Post by merry-year »

Mikeb85 wrote: post #5
kirkthejerk wrote: post #3

I got great grades in college, but could never wrap my head around LISP (Lost In Stupid Parentheses). For anything non-trivial, I cheated and handed in somebody else's work. There, I said it.

Strange. I never learned it in college, just on my own for fun, but I've found it to be quite elegant (if impractical compared to better modern languages). The fact that everything is an expression and you can use any expression anywhere makes it very easy to learn, and powerful. I personally find it more enjoyable to use than things like C. Then again, for one historical reason or another, C-type languages won, and…

>> impractical compared to better modern languages

How much did 'they' pay you to say that? :D

But seriously Lisps are by far the most advanced programming languages. They just take a huge amount of effort to learn.

Post reply on HN