7 ms·

> McCarthy built Lisp out of parts so fundamental that it is hard to say whether he invented it or discovered it. I loved that sentence! I'm guessing epistemol

> McCarthy built Lisp out of parts so fundamental that it is hard to say whether he invented it or discovered it. I loved that sentence! I'm guessing epistemology or a similar field has pondered the "invented or discovered" question already, and if so, I want to read about it. > [on SICP:] Those concepts were general enough that any language could have been used What?? In chapter 4, you write your own Lisp interpreter. If they had chosen C++, would you be writing a C++ compiler? Or a Lisp interpreter in C++? Either way, it would be ugly. And most languages would encounter problems even before they got to chapter 4. What made SICP great was building abstractions out of primitives. Most languages give you some abstractions, and others simply can't be built (at least not elegantly). I can't imagine SICP using a language that doesn't feel a lot like Lisp. That said, count me among the people whose first Lisp exposure was SICP. And yeah, it was really fun and really enlightening. I am loving Racket now, but Racket is big and practical. SICP is small and beautiful - as I recall, the authors deliberately avoid using most of the language. (They used Scheme, but I think Lisp would have worked fine too, right?)

fsloth 8y ago
Incidentally, I found building a Lisp interpreter in C++ using the SICP interpreter recipe a great exercise.
- deleted 8y ago
  [deleted]
- yvdriess 8y ago
  We had a follow-up course to SICP that started with the meta-circular interpreter, broke that one down even further and eventually moved completely to a C-implementation. Most insightful course I ever had. We got assignments such as: "add co-routines to the continuation-passing style meta-circular interpreter, and to the stack-based C interpreter."
yiyus 8y ago
Chuck Moore always says he did not invent FORTH, but discovered it. It's fascinating the relationship between Lisp and Forth. I am quite sure there is something about these two old simple languages and the concept of duality in mathematics that we are missing.
- garmaine 8y ago
  You're not the only one to observe this. It was observed and explored by Manfred von Thun with Joy, a purely functional programming language based on Forth. Modern "concatenative" languages continue this tradition: https://en.wikipedia.org/wiki/Concatenative_programming_language https://en.wikipedia.org/wiki/Concatenative_programming_lang...
  - carapace 8y ago
    I've been working with Joy for a few years now and I have to say that it seems to me to combine the best parts of Forth and Lisp. It's ridiculously elegant.
    - garmaine 8y ago
      Do you have a link to whatever project you are working on? I'm interested in Joy but not aware of anyone working on or with it in recent decades.
      - carapace 8y ago
        Sure! I developed an interpreter for Joy in Continuation-Passing Style in Python: http://joypy.osdn.io/ http://joypy.osdn.io/ I had just implemented type inference[1] when I got smashed over the brain by Prolog. So now the Python code is in limbo because the Prolog implementation of Joy is blindingly elegant[2]. In Prolog, the Joy interpreter is also the Joy type inferencer.[2] The compiler (from Joy expressions to new Prolog rules) is five lines long.[2] [1] http://joypy.osdn.io/notebooks/Types.html http://joypy.osdn.io/notebooks/Types.html [2] https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/thun.pl https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/...
kragen 8y ago
> In chapter 4, you write your own Lisp interpreter. If they had chosen C++, would you be writing a C++ compiler? Or a Lisp interpreter in C++? Either way, it would be ugly. It's an interpreter for a small subset of Scheme, but Scheme is of course itself small and simple†, which means that it's not hard to mentally extrapolate from the small subset to the rest of the language. C++ is a large language, and so it would be less compelling to implement a small subset of it. And you could of course use C++ to implement Lisp, as you say; chapter 4 actually covers several programming paradigms quite alien to Scheme itself, so implementing a functional programming language in C++ would be quite reasonable. As I read it, the main point of chapter 4 is that it's not true that "Most languages give you some abstractions, and others simply can't be built." Metacircularity makes chapter 4 very effective at convincing you that what you've written is actually a real programming language, but it has confused you into missing (what I read as) the main point of the chapter. Perhaps it was counterproductive. If not, though, it would be quite reasonable to achieve the same pedagogical metacircularity in Lua, Prolog, Forth, ML, Smalltalk, GHC Core, my own Bicicleta, or any number of other small, simple languages. I don't know about you, but those languages feel very different (from Lisp and from one another) to me. † "Simple" here refers, for better or for worse, to the observed behavior of the language, not the difficulty of its implementation. Much of this is easy to gloss over in a metacircular interpreter, where you can inherit garbage collection, procedure call semantics, dynamic typing, threading, call/cc, and even parsing, lazy evaluation, and deterministic evaluation order, from the host language. (The book points out many of these points.) If you were going to design a language at Scheme's programming level with an eye to making the implementation as simple as possible, Scheme would not be that language.
- StreamBright 8y ago
  >>> It's an interpreter for a small subset of Scheme, but Scheme is of course itself small and simple†, which means that it's not hard to mentally extrapolate from the small subset to the rest of the language. C++ is a large language, and so it would be less compelling to implement a small subset of it Exactly. This is the point of Lisp. I think many languages are over complicated for no good reason.
  - 8y ago
dstrohmaier 8y ago
Regarding the discovery vs. invention question. It has indeed already been discussed within philosophy. Here are just two examples in philosophy of mathematics: https://philpapers.org/rec/DETDIA-3 https://philpapers.org/rec/DETDIA-3 https://philpapers.org/rec/FINMDO https://philpapers.org/rec/FINMDO
kbp 8y ago
> What?? In chapter 4, you write your own Lisp interpreter. If they had chosen C++, would you be writing a C++ compiler? Or a Lisp interpreter in C++? That's in chapter 5 :) Exercise 5.51. Develop a rudimentary implementation of Scheme in C (or some other low-level language of your choice) by translating the explicit-control evaluator of section 5.4 into C. In order to run this code you will need to also provide appropriate storage-allocation routines and other run-time support.
- default-kramer 8y ago
  Ha, well I guess my secret's out - I skipped some of the exercises! And I'm not surprised to see I skipped that one. Even now, 5.51 and 5.52 seem like they would be more hard than fun. But given that SICP is my favorite CS book, maybe I owe it to myself to go for 100% completion.
avip 8y ago
It's discussed briefly [0] in Dirk Gently. [0] https://www.goodreads.com/quotes/488211-sir-isaac-newton-renowned-inventor-of-the-milled-edge-coin-and https://www.goodreads.com/quotes/488211-sir-isaac-newton-ren...
netcan 8y ago
"epistemology or a similar field has pondered the "invented or discovered" question already, and if so, I want to read about it." Yep. Me too. In fact, request for essay! It sounds like a topic I'd love to read pg meander into, for example. I think anytime invention starts to seem like a discovery, it's probably a good invention. I'm not sure there is a fundamental difference between the two. If you strain hard enough and get precise enough with your definitions, you could probably describe any invention as a discovery and the reverse. Recursively, that probably means any such definitions are inventions rather than discoveries.
MadcapJake 8y ago
>What?? In chapter 4, you write your own Lisp interpreter. If they had chosen C++, would you be writing a C++ compiler? There was a site [0] that had SiCP exercises in various other languages. [0]: https://web.archive.org/web/20100503233725/http://www.codepoetics.com:80/wiki/index.php?title=Topics:SICP_in_other_languages https://web.archive.org/web/20100503233725/http://www.codepo...
qubax 8y ago
> I'm guessing epistemology or a similar field has pondered the "invented or discovered" question already, and if so, I want to read about it. Any course or book on the Philosophy Of Science would cover that. Are numbers discovered or invented? Did the ancient hindu mathematician invent the number zero or did he discover it? You could argue that the symbolic representation of zero was invented ( or was it? ) but the idea of the number zero was discovered. The more you delve into it, the more you realize things aren't as straightforward as you might have imagined. Or quicksort. Is it an invention or a discovery? You could go back and forth on it forever.
jonjacky 8y ago
McCarthy himself said, "Pure Lisp was a discovery, everything that has been done with it since has been an invention." He said this to a class at Stanford in 2008, reported in HN! [1] [1] https://news.ycombinator.com/item?id=185348 https://news.ycombinator.com/item?id=185348
pweissbrod 8y ago
This resonates. I once sought to create a DSL on top of F# for workflows only to end up inventing lisp again. It was a humbling experience. The thing about lisp and why I dont use it in the workplace regularly is that it's dense and inconsistent. Dense because it's easy to write a profound amount of logic in one line which hurts readability if youre not careful. Inconsistent because you and I could be master programmers and write perfectly effective solutions that do the same thing and the code can look entirely different. This hurts interchangeability and it doesnt scale well, which disqualifies it from most enterprise projects. Similar to perl. That being said all my personal projects are done using clojure because it's such an easy/fun platform to work with
sytelus 8y ago
> I can't imagine SICP using a language that doesn't feel a lot like Lisp. SICP's main value proposition is not a language but developing thinking in terms of creating abstractions through compositions. LISP like language certainly helps but most modern languages does have this ability although verbose and possibly subjectively ugly in many cases. SICP with Python: https://wizardforcel.gitbooks.io/sicp-in-python/content/ https://wizardforcel.gitbooks.io/sicp-in-python/content/ SICP with JavaScript: https://www.comp.nus.edu.sg/~cs1101s/sicp/ https://www.comp.nus.edu.sg/~cs1101s/sicp/

fsloth 8y ago

Incidentally, I found building a Lisp interpreter in C++ using the SICP interpreter recipe a great exercise.

deleted 8y ago
[deleted]
yvdriess 8y ago
We had a follow-up course to SICP that started with the meta-circular interpreter, broke that one down even further and eventually moved completely to a C-implementation. Most insightful course I ever had. We got assignments such as: "add co-routines to the continuation-passing style meta-circular interpreter, and to the stack-based C interpreter."

yiyus 8y ago

Chuck Moore always says he did not invent FORTH, but discovered it. It's fascinating the relationship between Lisp and Forth. I am quite sure there is something about these two old simple languages and the concept of duality in mathematics that we are missing.

garmaine 8y ago
You're not the only one to observe this. It was observed and explored by Manfred von Thun with Joy, a purely functional programming language based on Forth. Modern "concatenative" languages continue this tradition: https://en.wikipedia.org/wiki/Concatenative_programming_language https://en.wikipedia.org/wiki/Concatenative_programming_lang...
- carapace 8y ago
  I've been working with Joy for a few years now and I have to say that it seems to me to combine the best parts of Forth and Lisp. It's ridiculously elegant.
  - garmaine 8y ago
    Do you have a link to whatever project you are working on? I'm interested in Joy but not aware of anyone working on or with it in recent decades.
    - carapace 8y ago
      Sure! I developed an interpreter for Joy in Continuation-Passing Style in Python: http://joypy.osdn.io/ http://joypy.osdn.io/ I had just implemented type inference[1] when I got smashed over the brain by Prolog. So now the Python code is in limbo because the Prolog implementation of Joy is blindingly elegant[2]. In Prolog, the Joy interpreter is also the Joy type inferencer.[2] The compiler (from Joy expressions to new Prolog rules) is five lines long.[2] [1] http://joypy.osdn.io/notebooks/Types.html http://joypy.osdn.io/notebooks/Types.html [2] https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/thun.pl https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/...

kragen 8y ago

> In chapter 4, you write your own Lisp interpreter. If they had chosen C++, would you be writing a C++ compiler? Or a Lisp interpreter in C++? Either way, it would be ugly. It's an interpreter for a small subset of Scheme, but Scheme is of course itself small and simple†, which means that it's not hard to mentally extrapolate from the small subset to the rest of the language. C++ is a large language, and so it would be less compelling to implement a small subset of it. And you could of course use C++ to implement Lisp, as you say; chapter 4 actually covers several programming paradigms quite alien to Scheme itself, so implementing a functional programming language in C++ would be quite reasonable. As I read it, the main point of chapter 4 is that it's not true that "Most languages give you some abstractions, and others simply can't be built." Metacircularity makes chapter 4 very effective at convincing you that what you've written is actually a real programming language, but it has confused you into missing (what I read as) the main point of the chapter. Perhaps it was counterproductive. If not, though, it would be quite reasonable to achieve the same pedagogical metacircularity in Lua, Prolog, Forth, ML, Smalltalk, GHC Core, my own Bicicleta, or any number of other small, simple languages. I don't know about you, but those languages feel very different (from Lisp and from one another) to me. † "Simple" here refers, for better or for worse, to the observed behavior of the language, not the difficulty of its implementation. Much of this is easy to gloss over in a metacircular interpreter, where you can inherit garbage collection, procedure call semantics, dynamic typing, threading, call/cc, and even parsing, lazy evaluation, and deterministic evaluation order, from the host language. (The book points out many of these points.) If you were going to design a language at Scheme's programming level with an eye to making the implementation as simple as possible, Scheme would not be that language.

StreamBright 8y ago
>>> It's an interpreter for a small subset of Scheme, but Scheme is of course itself small and simple†, which means that it's not hard to mentally extrapolate from the small subset to the rest of the language. C++ is a large language, and so it would be less compelling to implement a small subset of it Exactly. This is the point of Lisp. I think many languages are over complicated for no good reason.
- 8y ago

dstrohmaier 8y ago

Regarding the discovery vs. invention question. It has indeed already been discussed within philosophy. Here are just two examples in philosophy of mathematics: https://philpapers.org/rec/DETDIA-3 https://philpapers.org/rec/DETDIA-3 https://philpapers.org/rec/FINMDO https://philpapers.org/rec/FINMDO

kbp 8y ago

> What?? In chapter 4, you write your own Lisp interpreter. If they had chosen C++, would you be writing a C++ compiler? Or a Lisp interpreter in C++? That's in chapter 5 :) Exercise 5.51. Develop a rudimentary implementation of Scheme in C (or some other low-level language of your choice) by translating the explicit-control evaluator of section 5.4 into C. In order to run this code you will need to also provide appropriate storage-allocation routines and other run-time support.

default-kramer 8y ago
Ha, well I guess my secret's out - I skipped some of the exercises! And I'm not surprised to see I skipped that one. Even now, 5.51 and 5.52 seem like they would be more hard than fun. But given that SICP is my favorite CS book, maybe I owe it to myself to go for 100% completion.

avip 8y ago

It's discussed briefly [0] in Dirk Gently. [0] https://www.goodreads.com/quotes/488211-sir-isaac-newton-renowned-inventor-of-the-milled-edge-coin-and https://www.goodreads.com/quotes/488211-sir-isaac-newton-ren...

netcan 8y ago

"epistemology or a similar field has pondered the "invented or discovered" question already, and if so, I want to read about it." Yep. Me too. In fact, request for essay! It sounds like a topic I'd love to read pg meander into, for example. I think anytime invention starts to seem like a discovery, it's probably a good invention. I'm not sure there is a fundamental difference between the two. If you strain hard enough and get precise enough with your definitions, you could probably describe any invention as a discovery and the reverse. Recursively, that probably means any such definitions are inventions rather than discoveries.

MadcapJake 8y ago

>What?? In chapter 4, you write your own Lisp interpreter. If they had chosen C++, would you be writing a C++ compiler? There was a site [0] that had SiCP exercises in various other languages. [0]: https://web.archive.org/web/20100503233725/http://www.codepoetics.com:80/wiki/index.php?title=Topics:SICP_in_other_languages https://web.archive.org/web/20100503233725/http://www.codepo...

qubax 8y ago

> I'm guessing epistemology or a similar field has pondered the "invented or discovered" question already, and if so, I want to read about it. Any course or book on the Philosophy Of Science would cover that. Are numbers discovered or invented? Did the ancient hindu mathematician invent the number zero or did he discover it? You could argue that the symbolic representation of zero was invented ( or was it? ) but the idea of the number zero was discovered. The more you delve into it, the more you realize things aren't as straightforward as you might have imagined. Or quicksort. Is it an invention or a discovery? You could go back and forth on it forever.

jonjacky 8y ago

McCarthy himself said, "Pure Lisp was a discovery, everything that has been done with it since has been an invention." He said this to a class at Stanford in 2008, reported in HN! [1] [1] https://news.ycombinator.com/item?id=185348 https://news.ycombinator.com/item?id=185348

pweissbrod 8y ago

This resonates. I once sought to create a DSL on top of F# for workflows only to end up inventing lisp again. It was a humbling experience. The thing about lisp and why I dont use it in the workplace regularly is that it's dense and inconsistent. Dense because it's easy to write a profound amount of logic in one line which hurts readability if youre not careful. Inconsistent because you and I could be master programmers and write perfectly effective solutions that do the same thing and the code can look entirely different. This hurts interchangeability and it doesnt scale well, which disqualifies it from most enterprise projects. Similar to perl. That being said all my personal projects are done using clojure because it's such an easy/fun platform to work with

sytelus 8y ago

> I can't imagine SICP using a language that doesn't feel a lot like Lisp. SICP's main value proposition is not a language but developing thinking in terms of creating abstractions through compositions. LISP like language certainly helps but most modern languages does have this ability although verbose and possibly subjectively ugly in many cases. SICP with Python: https://wizardforcel.gitbooks.io/sicp-in-python/content/ https://wizardforcel.gitbooks.io/sicp-in-python/content/ SICP with JavaScript: https://www.comp.nus.edu.sg/~cs1101s/sicp/ https://www.comp.nus.edu.sg/~cs1101s/sicp/