HN Explorer

Ask HN: What language do you think in?

22 points by endlessvoid94 ↗ HN
Whenever I'm thinking about a problem, my solutions are immediately prototyped in my head in python.

I'm curious to see if anyone has an interesting languages that are not really popular that they attack problems with first.

67 comments

[ 8.5 ms ] story [ 668 ms ] thread
yan
I think in C.

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.

gdp
It depends on the situation, but I generally think in terms of pure (recursive) functions and types. This then usually provides me with a reasonably quick mapping to my preferred languages (e.g. ML or Haskell), as well as providing a reasonably simple way of mapping back to languages like Java or C or PHP or whatever else I might be called upon to write occasionally.

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.

plinkplonk
"It depends on the situation, but I generally think in terms of pure functions and types. "

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.

gdp
Well, I think it's reasonably intuitive to think that way. It basically involves asking yourself the questions - "what types of values am I interested in?" "what types of results do I expect?" and finally "how do I get from input to output?"

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).

mechanical_fish
having worked in... a high-level functional language gives you some mental machinery that doesn't rely on decomposing this thought process into some concrete syntax

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!

gdp
I kinda skipped SICP (I had already been programming for a long time before it even occurred to me that there might be texts available that attempted to teach "computational thinking" rather than just individual languages), but having browsed it since, I always recommend it to anyone who wants to learn programming (or HtDP, which also seems to cover similar ground).
byoung2
I think in pseudo-code, then figure out what language is best suited for the task.
gdp
When you say "I think in pseudo-code", what are the semantics of this pseudo-code?

'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).

mbrubeck
It's perfectly possible to express solutions at a high level without much regard for formal semantics. Knuth's The Art of Computer Programming expresses most of its algorithms in a combination of informal English and ad-hoc pseudocode. It's usually not difficult to translate them into languages with semantics varying from machine code to Haskell.
gdp
I didn't say "formal semantics", I said "fixed semantics", as in "something you understand and can apply consistently within a context". Within the context of a single code-fragment, the semantics are not changing. They might change from example to example, but that's perfectly reasonable.

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

byoung2
For example, if someone asked me to do the fizzbuzz test (http://www.codinghorror.com/blog/archives/000781.html), I might think to myself in pseudocode:

  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
Then I might turn that into PHP:

  <?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 />");
    }
  ?>
fake_pg
I take a slightly more abstract approach: I first think of the problem from the user's perspective (and their expectations), then I map out a work flow before diving into pseudo-code and wire-frames.

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.

doki_pen
I still don't think it adequately answers the question. Maybe the question should be rephrased as "What programming paradigm do you think in?"
fake_pg
Yes, perhaps the original question is too open-ended, but without a proper context, all answers will be leaning towards the abstract.

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.

nathanb
I think in English. Whenever I'm thinking about a problem, my solutions are immediately described in my head at a high level. This allows me to rapidly iterate over the solution space without having to venture down into the pseudocode or code level until I've found something I'm convinced will actually work.
eleitl
I'm trilingual, but I tend to also think primarily in English (not my native language).

Apart from that I prefer to think in images.

davidw
I think in English about programming stuff too. I think in either Italian or English depending on the context, but mostly English as that's my native language. Italian is more for things or events that happened in Italy or with Italian speakers (so... actually I do think in it a fair bit, because I live in Italy).

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.

nailer
I think in English, but it looks and sounds similar enough to Python anyway. I find this awfully handy.
der_ketzer
My native language is spanish but I think in german (my partner is from Switzerland) so I read and speak (not always) in german.

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

eleitl
I tend to do it visually.
tsestrich
I would say I think in pseudo-code, using natural language to describe the problem in a way that can be converted to code ("for all of these values in this array/container...", etc). That said, I work a lot in C#, so I usually go right to that pretty quickly, if not right away for commonly-solved problems.
mlLK
I think in data-structures opposed to one language in particular, if anything I think in markup; everything starts as a list, each item evolves into another list until it eventually ends up as dictionary, which can sometimes spawn another list. . .my thought-process is hopelessly recursive, this is easily my cardinal sin for all my unproductive days.
esila
Cypher: ...I...I don't even see the code. All I see is blonde, brunette, red-head. Hey, you uh... want a drink?

-The Matrix 1999

adrianwaj
How about thinking in general, say when waiting to fall asleep?
chaosprophet
It usually depends on what language I'm working in. These days I've been working in actionscript, so that's how I think. I think this behavior is partly because I sorta loose familiarity with other languages when I'm working in one language for an extended period of time.
sli
Op and I should be best friends. I can't count how many times I've solved a PHP problem using Python. Or generated PHP code using Python (won't go into detail, but it wasn't TDWTF material, I promise). Or simply explained something in a given language in terms of Python.
apgwoz
Scheme, though I end up having to translate it to Python 9 times out of 10.
restruct
First I think visually about object classes and data structures, and how they relate to one another. Then I think in pseudo-code.
teilo
This is so funny, because ever since I was first introduced to OOP (about 19 years ago - C++), I've had visuals in my head for objects - not clear ones, but somewhere floating in there is the idea of some shape with sockets and protrusions, switches and dials, representing getters, setters, methods, etc. Again, it's always vague, but the concept always seems to be there. I can tell you, though, that they are an off-white color.
keyist
I think in the subdialect of English known as social media stream of consciousness.

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>

Chirag
I think is algorithm, state-diagrams and images;and curse in Hindi :)
mononcqc
It depends on the problem. If it's something algorithmic that fits into a given data structure, I go through a bunch of mental visual representations; graphs, trees, etc. If the model fits, I usually imagine the code in the language I used the structure the most in.

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.

psadauskas
I used to think in pseudocode, but once I learned Ruby, it turns out I had been thinking in Ruby all along. Ruby just matches up really well with the way my brain already solved programming problems, then I had to translate it to C or Java or whatever else.
warfangle
I tend to think in terms of abstract flowchart of the process/algorithm/structure of what needs to happen.

And then I make it happen.

jaddison
I tend to think in terms of workflow.

  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
It's a pretty high level list, so I am probably missing some key points.

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.

[deleted]
(comment deleted)
dazzawazza
I've been coding long enough that most problems don't need thinking about. I just 'know'.

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 :(

Hexstream
I focus on the semantics first: I try to capture the essence of what I really mean to "say". Then I try to imagine the most idealized language that would let me specify as exactly and easily as possible what I really mean, unambiguously.

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.

alexgartrell
I think in whatever language I'm writing unless I've just started it. Then I think about what I'd imagine they'd call it and google around for it.

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++.

diN0bot
i think in diagrams.
[deleted]
(comment deleted)
jk4930
If the problem requires science, I think in English because most of my relevant university education and R&D was/is in English and thus most of the terminology I know. If it's business-related, I think most the time in German. I draw causal diagrams and sketch in Haskellesque pseudo code.