programmers don’t think in code. Sure, some might tell you they think in code, but I can almost guarantee that there’s a little voice in their head that’s still speaking a human language (especially since many programming language constructs are essentially unpronounceable
It doesn't seem to me so much as a victim of Sapir-Whorf (i.e. in the strong form, the hypothesis that the set of concepts that can be conceptualized is constrained by the language used for conceptualization) as a victim of some presumption that everyone thinks of their code "out loud".
I wonder if there's a correlation between this kind of thinking about code and a predisposition towards imperative languages and thinking of all programs as recipes with lists of things to do in a particular order.
Exactly, it's about structure. E.g. if you are an OO programmer you will be thinking "what classes do I need to represent this problem? Is this a has-a or an is-a? Do I need a Factory pattern here?" and so on. You won't literally be thinking "public static void main...".
Curiously, I almost never think of my code as "Is this a has-a or an is-a? Do I need a Factory pattern here?" I reach for the pattern names only when I need to explain things to coworkers. I do occasionally think in terms of "what classes do I need to represent this problem?", but more accurately it's "Okay, what interface do I want to present to the outside world, what data do I have available to me, and how can I transform that data so it does what the interface claims it does?"
But if you can think in structure (and I certainly do when I'm planning an application), it follows that thinking is not constrained into the realm of language - hence my reference to Sapir-Whorf.
Well, people will obviously plan their application in a way that makes most sense given what their preferred language makes easy, or what their language community values. A Java programmer will think "how can I make this enterprisey". A Perl programmer will think "how can I do this in one line of code". A Haskell programmer will think "what is the underlying maths". Like I say, no-one is literally thinking code. It's not that people can't think outside their language, it's just that why would you try to smush in a concept that's a poor fit?
All programming languages are very similar in their code: once you've picked up the nuances and the basics of the syntax coding in it is easy enough.
But "creating" (I think that's the wrong word personally; but cant think of a better one) in a specific language requires much more in depth understanding of how it works (for example how a compiler constructs your C program, or how a Javascript engine runs etc.).
TBH, I don't really care about being able to program a nontrivial program in a zillion languages. Cutting code is just a tool.
I much rather want to be able to think in data and I want to be able to easily grok the runtime model of a language, because if I can do that, getting able to write large things in a new language is not that hard. Certainly, if you never knew C and just look at it's runtime model (with the crucial part pretty much being the difference of data on the stack and on the heap), you won't be able to write an industry-strenght *nix-kernel immediately, but on the other hand, after about a week or two of doing stuff in C, you will be able to do quite a lot.
This is also the reason why I look at a lot of languages, but mostly stick with python. Most languages don't offer a better tradeof than python (even though I am still eagerly waiting for Haskell':) ), so I don't see a reason spending a month or two just doing stuff in them. If it grows necessary, I will certainly be able to do so, but currently, I don't need to annoy myself too much :)
I think it depends on whether you want to practice the skill of coding, or the skill of problem solving.
For me, coding is a means to an end: I want to solve a problem; I want to create something that does something useful; I want to breath life into a figment of my imagination.
I try to immerse myself in the problem; and then I find examining almost anything in related areas will inspire me with new perspectives.
I wonder what relation the code/create transition has to the transition from mental translation from your native language to thinking in your new language.
I wonder if this might have something to do with the distribution between language and math centers of the brain (speaking a foreign human language requiring much more of the former) and how quickly these different brain centers can adapt.
There is that point, too, where you not have to look up how to formulate something in your new programming language, but can write it just down. Is that not "fluent"?
What do you guys think about learning just one programming language or just one human language? I don't think you can be a real expert in a language, if you just a single one. First, you will not get a good feeling of what the style of your language is, if you just know this one. And second, there is stuff, you can write easy in language A but much harder in language B. There will be a point in mastering language B where you have to be able to write the same stuff, too. But you might never learn that stuff, if you never saw people doing it in language A. (pg's argument for stronger languages vs. weaker languages is some kind of subset of my second argument)
You make a good point, but we can use empirical data to settle it. Look at the greatest writers in a given language. Ask if they were monolingual or not.
For one instance, I (personally) am not aware of Shakespeare knowing any languages other than English; however, it may be that all educated people in that era knew Latin, and so the many great English writer so the past support your hypothesis.
Sigh. Another victim of Sapir-Whorf.