Apart from that I prefer to think in images.

This can make it weird working on programming stuff with Italians, as English really is where my brain wants to be for programming. It's not about knowing the terminology (I do), it's just that English is really what I want to use to reason about programming.

Incidentally, trying to think in another language about what's going on is a great way of practicing it if you're learning it.

In programming languages I think in Python and then translate according to my needs.

Ask Lazyweb about my blog's new design... that's like using the crowd as a source of wisdom... crowdsourcing... OMG I invented a new word wait check urbandictionary... oh cool I'm getting answers... upvote... hmm this submission is tangentially related to my blog, i'll promote it in the comments... upvote... hmm should I change my profile from 'social media expert' to 'social media genius'? Too forward? Oooh one of my older tweets is getting retweeted... Follower count... damn, just got rickrolled again! Hmm the world is moving to Twitter... it's a killer of something... subscriptions... RSS... hmm there's a photo of me that isn't tagged, let's come up with a clever nickname for myself in that tag... RSS Killer... means RSS is dead... Email alert... new follower! w00t fellow social media expert... I'll follow her too... doesn't seem as smart as me though... oh shit, it's Follow Friday! who's mentioned me? who's mentioned me? hmm I need a "10 Things" post to submit to Digg... 10 Things I like about you... funny movie, who was that actress? check imdb... is it in my Netflix queue? Oooh shiny funny new failblog post... I wonder what's new in the app store...

</satire>

Interestingly, I've spent a some extended blocks of time working inside theorem provers. I find that it requires me a bit of time to switch to and from that style of thinking.

This resonates. I think in a weird pseudocode myself and after getting a grip on type theory I find I think in typed weird pseudocode.

I think most programmers probably think it reasonably similar terms - it's just that having working in STLC or a high-level functional language gives you some mental machinery that doesn't rely on decomposing this thought process into some concrete syntax from a programming language.

(incidentally, this is one of the reasons why I think there is a lot of value in learning the Lambda calculus early in a computer science education).

This is what we are really talking about when we claim that reading, e.g., SICP will make you a better programmer even if you don't work in Lisp.

SICP is not a book about Scheme. It's a book about computation that happens to use Scheme. And it is resolutely abstract, encouraging you to think in non-linguistic terms. One of the bits I remember best was near the beginning, when they talk about the shapes of computational processes -- iterative processes have a different shape from recursive processes. Now I use that sort of mental picture all the time.

The goal is to think about software like a mathematician thinks about math. If you're thinking in a language, it's like the way I thought about math when I was nine years old -- to the extent that I knew what a mathematician was, I thought it was someone who was really really good at the long division algorithm. Someone who could subtract really fast!

If I understand how most people think (which I most likely don't), they have an internal monologue going, like they are thinking about going to the store and they think in their inner voice, "lets see, what do I need? Some eggs, milk, cheese". I never have any monologue internally, I either see a little picture flash by, or more often my thoughts have no relation to anything I could describe as sensory at all.

For example, I just thought of what I wanted to get to drink because I was really thirsty from gardening. No words were thought, but in quick sucession I percieved in my thoughts the flavor and temperature of tap water, and then the cold sweet syrupyness of coca cola, and I grabbed the coke. I can't describe it really, it's very much a 'now you are breathing manually' thing, once you think about how you think you are changing how you think.

'cause it's actually a bit of a non-answer, when you think about it. Saying 'pseudo code' means that the language you think in has some informality in its syntax - but presumably you still have some fixed understanding of what it does?

If it has no fixed syntax and no fixed semantics, then is it actually helpful as a mental model? I would argue that it is not.

(Note: I'm not just being antagonistic here, I'm genuinely curious. I don't think in terms of "syntax", so this is all a bit alien to me).

My assertion is that when people say "I think in pseudo-code", they actually mean "an idealised version of language X", where language X is some paradigm or language they understand well.

I just wrote a blog post about this very subject, based on the flood of comments (shameless self-promotion follows):

http://news.ycombinator.org/item?id=802780

  Loop from 1-100:
    if the current number is a multiple of 3, print "fizz"
    if the current number is a multiple of 5, print "buzz"
    otherwise, print the number
    print newline

  <?php
    for($i=1;$i<=100;$i++) {
      if($i % 3 == 0) {echo("Fizz");}
      if($i % 5 == 0) {echo("Buzz");}
      if($i % 3 != 0 && $i % 5 != 0) {echo($i);}
      echo("<br />");
    }
  ?>

Overall, I agree with the parent because before you can dive into coding, you have to think of the problem and solution abstractly.

But which language is used for writing out the solution? Whichever is the best tool for that particular problem.

While I may express the solution in Objective-C, PHP or Python, I always think of the solution in terms of logic.

Also, if you have experience in multiple languages (and environments), then you're less likely to be constrained by a single mindset.

-The Matrix 1999

If I'm looking at a website, I think in SQL (cf. dude I can write SO in like 4 minutes ;)

If I'm looking at stats/ML stuff, I try to think in pictures (usually of probability densities being transformed in various ways), and sometimes slip into "pseudomath," which is basically English that sounds like "argmax integral x filtered by f times hessian of g".

If I'm doing information theory I tend to think geometrically or graphically, seeing distributions as points/nodes and then reasoning about what the picture looks like as distances/edges between them grow and shrink.

If I'm looking at an attractive member of the opposite sex, a good bottle of wine, or someone that needs cursing at, I think in French.

Translation from one language to another is just another layer of indirection and makes you slower. It's easiest and best just to learn languages from scratch or near-scratch, IMHO. If you get used to learning in that way, it's easy to keep doing it.

Caveat: I think in C when I'm coding C++.

If it's about something I don't know much, I'll go through pseudo-code and/or a list of tasks the code has to perform and then imagine it in the best-suited language for it.

If it's more about organizing concerns or how should a larger problem be split up, I'll take a sheet of paper and draw components and tasks, then linking them with arrows until it makes sense and it's clean. I then try to fit that in the language best suited for it; usually for that kind of splitting, actor-based languages do the best job. It's probably why I like Erlang/OTP so much; they provided actual design patterns for higher-level representations such as Client-Server relationships, Finite State Machines, Event handlers (such as loggers and whatnot) that make it really easy to turn a visual representation into an actual application with minimal boilerplate code.

If I have access to such a language, I use it. If I don't, but know how to implement it, I might do just that if I think it's worth it in terms of time and effort. Otherwise, I try to think of the next best language that could represent what I mean and that I can use or implement more easily. At some point I get to "really low-level" abstractions like Common Lisp objects, closures and macros...

It's a surprisingly high-quality and slow way to program. I figure at some point I'll have accreted so much language implementation knowledge and infrastructure that I'll be unstoppable because I'll almost always be able to make a good approximation of the best tool for the job quickly.

However, I've been alive long enough that if I don't 'know' the solution I need a whiteboard. I can't think without a whiteboard.

Age brings wisdom and experience but it certainly has dulled my brain quite a bit :(

And then I make it happen.

Here is another thing, tell me if this is true of you: I can't understand anything about how to solve a problem if I don't know completely 'understand' the context. In other words, I took several years of experimental physics at University, but it was totally bewildering to me. I understood the experiments perfectly (I mean, they aren't anything complex at that level), I understood the apparatus, I understood the mathematics and so on and on. At some point in every experiment, however, you had to decide whether your data supported or did not support the hypothesis. This is usually pretty obvious, but you were supposed to support it using chi-squared calculations and other statistical measurements of how well the data fits the hypothesis. I hadn't taken any statistics courses, so it seemed totally opaque and impossible to me to do this. I could never figure out what equation to use, or how to do it. I could follow step by step in the workbook and if I did so I would get a fine grade, but I was literally looking at the equations every 3 seconds as I worked the problem out. Anyway, I looked up the stuff in a statistics text, read the proofs and explanations of all the things I needed to understand, and suddenly it all made sense at once and I never had to refer back to anything. Once it 'clicks' everything is clear, like someone turned the light on in a dark room, before it 'clicks' I feel like I am suffocating.

Anecdote: In physics class (I was a physics major for awhile, so it was a 'real' physics class) there was what I guess was a very complex problem. The professor posed the problem and asked 'how do we solve this', and I raised my hand and told him the integral. It took me about 10 seconds or so f talking to say the entire equation. It blew everyone's mind, but it was really obvious if you could see it. I don't mean to brag, but if I was trying to think it through like socrates in a dialog I would have taken a week.

  1. How would user interaction occur?
  2. What systems are necessary?
  3. How can the problem(s) involved be solved? (what languages/tools/infrastructure)
  4. Pseudo-code
  5. Get crackin' on code

I tend to spend a fair amount of time just thinking and pondering the problem; once I reached some indeterminate threshold, I start typing up point-form notes. As I think more to gain more definition of the problem and potential solutions I add new, revise existing and remove obsolete notes.

And to actually answer the question "Which language do I think in?", it depends on my answers to #3.

Today I have learned to think in work flows and the visualizations of the UI. This is how the users of the program view it. To users the UI is the program. Now the users accept my work 90% of the time. I seldom think about the methods or data structures anymore until I am actually sitting there typing it in.

As a really low-level example, previously when I needed to make a comma separated list of items I would do something like this:

$result = ""; $sep = ""; for ($items as $key => $val) { $result .= $sep." ".$val; $sep = ", "; }

of course now I just do join (", ", $items);. all languages I currently use have such a join function or method, and that idea is in my head; the exact syntax is not.

This does result in minor annoyances when I for example solved something in my head with a coroutine, only to realize that I'm at work coding in php, which doesn't have them.

after that, with sleep & time to breathe i went back and checked my work from that night because i assumed that a mind so frazzled would be similarly error prone. alas, that mode of thought, while not suited for normal-person-tasks worked well for the project. no bugs (from that night at least) and that single all nighter put the whole thing way ahead of schedule.

I think in "flow". It's hard to describe, but it's not entirely visual -- it isn't like a flow chart in my head. Instead I get an idea of what I want a particular thing to do, and then I "feel" how it gets there, kind of like I'm mentally bouncing through a pinball machine.

I use the same approach for working on engines, circuits, and other complex things.

I've also been known to write out in mostly English sentences as comments, then fill in the code that implements that explanation.

Python is a fairly straight-forward mental translation and functional languages I tend to need to spend more energy thinking about unless the problem is embarrassingly recursive.

For example, last night I awoke about 5 times, every single time with a new solution to a current problem.

But before that, I always try to really relax in the evening, for some hour, preferably in nature (and nothing beats the sea).