4 ms·

False and misleading? The chosen languages have changed the way I've thought about programming. In my 'lived experience', Lisp is 'THE language' of thought. I'd

by daly 6y ago

False and misleading? The chosen languages have changed the way I've thought about programming. In my 'lived experience', Lisp is 'THE language' of thought. I'd welcome your choice of language and why you think it deeply affects the way you program. I've used 'lisp' since 1970, in a FORTRAN implementation of Lisp 1.5 out of Bell Labs. Clearly 'lisp' has evolved since that time. But all versions I've used, like MacLisp, Symbolics, Interlisp, Lisp/370, VMLISP, CCL/MCL, Portable Standard Lisp, KCL, AKCL (I'm a minor author), Emacs Lisp, CLISP, Lucid, Gold Hill, ABCL, Clojure, and a few others I've probably forgotten. They are all 'different' but all are recognizably 'lisp'. I don't know AutoLisp but I suspect that it might have the 'clay-like' property of other 'lisps'. The point of this series is to find languages that change the way you think. Don't confuse an implementation with the concepts.

kazinator 6y ago
Is this non-implementation language of thought documented somewhere, so that people can learn it and think with it? And does this language have mutable cons cells, with lists terminated by nil, which is a self-evaluating symbol that also denotes false? Are there interned symbols, quote and all that?
- martyalain 6y ago
  Hi kazinator, are you replying to "daly" or to "martyalain"? If it is to me and about lambdatalk, some answer can be found in the links given previously.
- daly 6y ago
  Assuming you're not trying to be sarcastic... As a "language of thought" it is often the case that I will write my solution in Lisp and then "hand translate" it to the target language. This has two effects. First, assume I'm "translating" to Python, for example. The Lisp "Gedanken" keeps me from depending on strange local language behavior. For example, I won't have to catch missing dictionary entries. But if I happen to want a local language behavior I can just make a macro. Second, the Lisp "Gedanken" allows the ability to "factor" solutions since Lisp tends to "encourage" functions. For example, I'm working on a design for a dependently-typed language that allows proofs of the resulting programs. Lisp allows me to create a domain-specific language easily. Gedanken experiments led me to factor the category, domain, and representation for the specification, implementation, and proof languages. I know from experience that whatever domain-specific language constructs I dream up, they can all be implemented as macros and compiled efficiently. When "thinking in Python", you'll find yourself restricted by implementation issues or searching for some library and then shaping your problem to fit the library. When "thinking in Java", you'll find yourself trying to force your solution into "objects". When "thinking in C++", you'll find that (a) you have to choose WHICH C++ (there are so many) and (b) by the time you implement something C++ will have changed. I can still run Lisp code I wrote in 1980. Assuming you ARE being sarcastic... there's Greenspun Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp The fact that you've immediately gone to "interned symbols" means you aren't used to using your language for thinking. These things don't arise in Lisp Gedanken. Cogito, ergo Lisp
  - kazinator 6y ago
    The thing is, if your language of thought doesn't have interned symbols, or conses, is it really Lisp? Does your language of thought at least have first/rest recursion on lists, and do you use those idioms? If you naively transliterate that to Python, that's not very performant or idiomatic; you can't work with Python people that way. Are you sure your language of thought is really Lisp? Actual programs in a sophisticated Lisp dialect can't easily be spun off into Python or Java, at least if they are effectively using that dialect. If you want to treat Python through Lisp glasses, you may be best off getting one of the Lisp-over-Python implementations and adapting to them. Over the past several years, I have written a working program in an actual Lisp dialect to try an idea, which I translated to Python (system requirement: not introducing anything new to a container). I had to backpedal from some nice idioms in that Lisp dialect, and adapt to the Pythonic way of doing things. Part of the reason for that was people: the script had to pass code reviews, as well as lint programs like pylint3 and flake8. > When "thinking in C++", you'll find that (a) you have to choose WHICH C++ (there are so many) and (b) by the time you implement something C++ will have changed. If you think in terms of C++98 through maybe C++2003, you're okay. Hipsters working with your code will moan and groan that there is no emplace, move semantics or lambda, but not that it doesn't work.
    - daly 6y ago
      Language limits what you can think. For example, you clearly feel that an interned symbol is essential to "lisp". But if I think about Lisp as lambda calculus notation there is no notion of "interned", yet it is still "lisp". When I transliterate to Python I am not, by definition, worried about performance. Python has horrible performance. Ah, the "Pythonic way" of doing things! Like the "Steve Jobs" way of doing things, aka the one-finger interface. "Steve Jobs thinking" would bring us a "self-driving car" that we "drove" by tracing a finger along a moving map, clicking on stop signs to stop. We'd be singing about how marvelous it is... it "automatically" blinks the turn signal when we trace a finger along a left turn! Python is the "Steve Jobs" of languages and thought: so easy! so intuitive! so limited! You ask "Are you sure your language of thought is really Lisp?". I'm also a mathematician. You're asking me if I think about math in terms of multiplication. I do, but not the way you expect. MY multiply can be non-commutative if I'm working in matrix algebra. It can be a map function in category theory. It can be limited to finite fields or expanded to octonions. I'm still thinking of "multiply"; I'm just not limited to numbers. Similarly, when I'm thinking about a problem my "lisp thinking" isn't limited to symbols. I worked on a Human-Robot cooperative task to change a car tire. I needed a knowledge base...lisp (aka Scone). I needed rules... lisp (aka ops5). I needed human language... lisp (my own code). I needed it all to work together so that rules could be represented as knowledge and knowledge could be expressed as rules (all were defstructs). When thinking about the problem I could write "lisp pseudocode" and then simply execute it. If I needed "multiply" to be non-commutative in some section of code I knew I could make it work trivially. Indeed I didn't even have to think about it. Thinking in Lisp has nothing to do with interned symbols, just as thinking in math has nothing to do with numbers. Thinking in Python is like doing math on a calculator. Everything is "Pythonic", but just like your "calculator" in math, limited to numbers. I think the reason people "don't get lisp" until "they get lisp!" (aka the epiphany event) is that they stop thinking in other languages and begin to think in lisp. A whole new world opens.

by daly 6y ago

kazinator 6y ago

Is this non-implementation language of thought documented somewhere, so that people can learn it and think with it? And does this language have mutable cons cells, with lists terminated by nil, which is a self-evaluating symbol that also denotes false? Are there interned symbols, quote and all that?

martyalain 6y ago
Hi kazinator, are you replying to "daly" or to "martyalain"? If it is to me and about lambdatalk, some answer can be found in the links given previously.
daly 6y ago
Assuming you're not trying to be sarcastic... As a "language of thought" it is often the case that I will write my solution in Lisp and then "hand translate" it to the target language. This has two effects. First, assume I'm "translating" to Python, for example. The Lisp "Gedanken" keeps me from depending on strange local language behavior. For example, I won't have to catch missing dictionary entries. But if I happen to want a local language behavior I can just make a macro. Second, the Lisp "Gedanken" allows the ability to "factor" solutions since Lisp tends to "encourage" functions. For example, I'm working on a design for a dependently-typed language that allows proofs of the resulting programs. Lisp allows me to create a domain-specific language easily. Gedanken experiments led me to factor the category, domain, and representation for the specification, implementation, and proof languages. I know from experience that whatever domain-specific language constructs I dream up, they can all be implemented as macros and compiled efficiently. When "thinking in Python", you'll find yourself restricted by implementation issues or searching for some library and then shaping your problem to fit the library. When "thinking in Java", you'll find yourself trying to force your solution into "objects". When "thinking in C++", you'll find that (a) you have to choose WHICH C++ (there are so many) and (b) by the time you implement something C++ will have changed. I can still run Lisp code I wrote in 1980. Assuming you ARE being sarcastic... there's Greenspun Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp The fact that you've immediately gone to "interned symbols" means you aren't used to using your language for thinking. These things don't arise in Lisp Gedanken. Cogito, ergo Lisp
- kazinator 6y ago
  The thing is, if your language of thought doesn't have interned symbols, or conses, is it really Lisp? Does your language of thought at least have first/rest recursion on lists, and do you use those idioms? If you naively transliterate that to Python, that's not very performant or idiomatic; you can't work with Python people that way. Are you sure your language of thought is really Lisp? Actual programs in a sophisticated Lisp dialect can't easily be spun off into Python or Java, at least if they are effectively using that dialect. If you want to treat Python through Lisp glasses, you may be best off getting one of the Lisp-over-Python implementations and adapting to them. Over the past several years, I have written a working program in an actual Lisp dialect to try an idea, which I translated to Python (system requirement: not introducing anything new to a container). I had to backpedal from some nice idioms in that Lisp dialect, and adapt to the Pythonic way of doing things. Part of the reason for that was people: the script had to pass code reviews, as well as lint programs like pylint3 and flake8. > When "thinking in C++", you'll find that (a) you have to choose WHICH C++ (there are so many) and (b) by the time you implement something C++ will have changed. If you think in terms of C++98 through maybe C++2003, you're okay. Hipsters working with your code will moan and groan that there is no emplace, move semantics or lambda, but not that it doesn't work.
  - daly 6y ago
    Language limits what you can think. For example, you clearly feel that an interned symbol is essential to "lisp". But if I think about Lisp as lambda calculus notation there is no notion of "interned", yet it is still "lisp". When I transliterate to Python I am not, by definition, worried about performance. Python has horrible performance. Ah, the "Pythonic way" of doing things! Like the "Steve Jobs" way of doing things, aka the one-finger interface. "Steve Jobs thinking" would bring us a "self-driving car" that we "drove" by tracing a finger along a moving map, clicking on stop signs to stop. We'd be singing about how marvelous it is... it "automatically" blinks the turn signal when we trace a finger along a left turn! Python is the "Steve Jobs" of languages and thought: so easy! so intuitive! so limited! You ask "Are you sure your language of thought is really Lisp?". I'm also a mathematician. You're asking me if I think about math in terms of multiplication. I do, but not the way you expect. MY multiply can be non-commutative if I'm working in matrix algebra. It can be a map function in category theory. It can be limited to finite fields or expanded to octonions. I'm still thinking of "multiply"; I'm just not limited to numbers. Similarly, when I'm thinking about a problem my "lisp thinking" isn't limited to symbols. I worked on a Human-Robot cooperative task to change a car tire. I needed a knowledge base...lisp (aka Scone). I needed rules... lisp (aka ops5). I needed human language... lisp (my own code). I needed it all to work together so that rules could be represented as knowledge and knowledge could be expressed as rules (all were defstructs). When thinking about the problem I could write "lisp pseudocode" and then simply execute it. If I needed "multiply" to be non-commutative in some section of code I knew I could make it work trivially. Indeed I didn't even have to think about it. Thinking in Lisp has nothing to do with interned symbols, just as thinking in math has nothing to do with numbers. Thinking in Python is like doing math on a calculator. Everything is "Pythonic", but just like your "calculator" in math, limited to numbers. I think the reason people "don't get lisp" until "they get lisp!" (aka the epiphany event) is that they stop thinking in other languages and begin to think in lisp. A whole new world opens.