4 ms·

Please explain some of Paul Graham's points on Lisp

43 points by rayvega 16y ago

fleitz 16y ago
I always tend to think of LISP as following a Von Neumann architecture where there is no difference between code and data and non-LISP derived languages as Harvard architecture where there are distinct differences between code and data.
- axod 16y ago
  non-LISP derived? There's no difference between code and data in assembly language, but it's not LISP derived. Having no distinction between code and data isn't a LISP invention, it's the 'default' on computers.
  - listic 16y ago
    I think, you are referring to machine code, not assembly langauage. In assembly, code looks like cmp [eax], ebx jg bigger Data looks like ans db 42 msg db "Hello World!",0 They are not interchangeable.
    - axod 16y ago
      Same difference really... mov edi, blah mov byte [edi+1], 17 // Modify the instruction to mov al, 17 // Later... blah: mov al, 7 There's pretty much a 1->1 mapping between assembly language and machine code, so making a distinction doesn't make too much sense IMHO
  - sambeau 16y ago
    Having no distinction between code and data is the 'default' on Von Neumann architectures. Harvard architectures kept code and data in physically separate storage. http://en.wikipedia.org/wiki/Von_Neumann_architecture http://en.wikipedia.org/wiki/Von_Neumann_architecture http://en.wikipedia.org/wiki/Harvard_architecture http://en.wikipedia.org/wiki/Harvard_architecture
silentbicycle 16y ago
While there's an implied question here, the link has plenty of adequate responses. If you want to learn Lisp, I recommend Common Lisp, or else a Scheme implementation with lots of practical extensions (e.g. Chicken or PLT). _Land of Lisp_ is a good intro. _SICP_ is also excellent, but hell-bent on teaching you long-term deep theoretical wisdom rather than useful-today tricks. But either way: Do the exercises. Try writing your daily experimental code in it. Think in it. Make it work. Live in it.
ScottBurson 16y ago
To say that symbols are strings that happened to be interned, while true, doesn't, I think, capture their essence. I think the best way to understand symbols is that they are literals of an infinite enumeration type. Symbols are names that refer to things.
- lispm 16y ago
  enumeration type?
  - RiderOfGiraffes 16y ago
    http://www.google.co.uk/#q=%22enumeration+type%22 http://www.google.co.uk/#q=%22enumeration+type%22 http://en.wikipedia.org/wiki/Enumerated_type http://en.wikipedia.org/wiki/Enumerated_type http://en.wikibooks.org/wiki/Ada_Programming/Types/Enumeration http://en.wikibooks.org/wiki/Ada_Programming/Types/Enumerati... In essence, an "enumerated type" is a collection of uninterpreted values. You can assign them to variables, you can compare them to each other, but they have no intrinsic structure. Unlike ints you can't add or multiply, unlike strings you can't concatenate or search for substrings. Hence the observation that symbols are not strings, but are elements of an infinite enumerated type. You can only refer to them, copy them, assign them, and compare them. They are atomic. No disrespect intended - different people have different backgrounds, and I know some very fine coders who don't know this sort of thing - but this is very, very elementary CS material, and easily found with a Google search. You may find it interesting to learn more about these sorts of basics. Although it often doesn't help directly, it can provide useful insights to have different points of view and points of reference.
    - lispm 16y ago
      I know what enumeration types are. Symbols are not directly an 'enumerated type', but can be used to implement them. Like symbols can be used for many other things. Thinking of symbols as elements of 'infinite enumerated type' is misleading or useless. In Common Lisp symbols are not just a name, but part of a namespace (package), have a value, a function, a property list, etc.. They can only be kind of enumerated if they are part of a package. Symbols can also be not interned in a package, then you can't enumerate them.

43 points by rayvega 16y ago

I always tend to think of LISP as following a Von Neumann architecture where there is no difference between code and data and non-LISP derived languages as Harvard architecture where there are distinct differences between code and data.

axod 16y ago
non-LISP derived? There's no difference between code and data in assembly language, but it's not LISP derived. Having no distinction between code and data isn't a LISP invention, it's the 'default' on computers.
- listic 16y ago
  I think, you are referring to machine code, not assembly langauage. In assembly, code looks like cmp [eax], ebx jg bigger Data looks like ans db 42 msg db "Hello World!",0 They are not interchangeable.
  - axod 16y ago
    Same difference really... mov edi, blah mov byte [edi+1], 17 // Modify the instruction to mov al, 17 // Later... blah: mov al, 7 There's pretty much a 1->1 mapping between assembly language and machine code, so making a distinction doesn't make too much sense IMHO
- sambeau 16y ago
  Having no distinction between code and data is the 'default' on Von Neumann architectures. Harvard architectures kept code and data in physically separate storage. http://en.wikipedia.org/wiki/Von_Neumann_architecture http://en.wikipedia.org/wiki/Von_Neumann_architecture http://en.wikipedia.org/wiki/Harvard_architecture http://en.wikipedia.org/wiki/Harvard_architecture

silentbicycle 16y ago

While there's an implied question here, the link has plenty of adequate responses. If you want to learn Lisp, I recommend Common Lisp, or else a Scheme implementation with lots of practical extensions (e.g. Chicken or PLT). _Land of Lisp_ is a good intro. _SICP_ is also excellent, but hell-bent on teaching you long-term deep theoretical wisdom rather than useful-today tricks. But either way: Do the exercises. Try writing your daily experimental code in it. Think in it. Make it work. Live in it.

ScottBurson 16y ago

To say that symbols are strings that happened to be interned, while true, doesn't, I think, capture their essence. I think the best way to understand symbols is that they are literals of an infinite enumeration type. Symbols are names that refer to things.

lispm 16y ago
enumeration type?
- RiderOfGiraffes 16y ago
  http://www.google.co.uk/#q=%22enumeration+type%22 http://www.google.co.uk/#q=%22enumeration+type%22 http://en.wikipedia.org/wiki/Enumerated_type http://en.wikipedia.org/wiki/Enumerated_type http://en.wikibooks.org/wiki/Ada_Programming/Types/Enumeration http://en.wikibooks.org/wiki/Ada_Programming/Types/Enumerati... In essence, an "enumerated type" is a collection of uninterpreted values. You can assign them to variables, you can compare them to each other, but they have no intrinsic structure. Unlike ints you can't add or multiply, unlike strings you can't concatenate or search for substrings. Hence the observation that symbols are not strings, but are elements of an infinite enumerated type. You can only refer to them, copy them, assign them, and compare them. They are atomic. No disrespect intended - different people have different backgrounds, and I know some very fine coders who don't know this sort of thing - but this is very, very elementary CS material, and easily found with a Google search. You may find it interesting to learn more about these sorts of basics. Although it often doesn't help directly, it can provide useful insights to have different points of view and points of reference.
  - lispm 16y ago
    I know what enumeration types are. Symbols are not directly an 'enumerated type', but can be used to implement them. Like symbols can be used for many other things. Thinking of symbols as elements of 'infinite enumerated type' is misleading or useless. In Common Lisp symbols are not just a name, but part of a namespace (package), have a value, a function, a property list, etc.. They can only be kind of enumerated if they are part of a package. Symbols can also be not interned in a package, then you can't enumerate them.