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
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.
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.
Since data and programs are the same thing in lisp you can fluidly shift from one to the other, like I did with "knowledge" vs "rules". They both have the same representation (defstructs) but they are also code and have execution semantics. Clojure allows you to do this with map objects.
The fact that you can use the whole language on everything at any time and that everything at any time is also "the language" is how you "think in lisp". Nobody thinks of Python programs as "data" or data as Python programs.
Watch anything Rich Hickey talks about. He really "gets it".