How do you keep all your languages straight?

Question

I think I'm going a little crazy.

Right now, I'm working with the following languages (I was just doing a mental inventory):

• C++ - our game engine
• Assembler - low level debugging and a few co-processor specific routines
• Lua - our game engine scripting language
• HLSL - for shaders
• Python - our build system and utility tools
• Objective C/C++ - game engine platform code for Mac and iPhone
• C# - A few tools developed in our overseas office
• ExtendScript - Photoshop exporting tools
• ActionScript - UI scripting
• VBScript - some spreadsheet related stuff
• PHP - some web related stuff
• SQL - some web and tool related stuff

On top of this are the plethora of API's that often have many different ways of doing the same thing: std library, boost, .NET, wxWidgets, Cocoa, Carbon, native script libraries for Python, Lua, etc, OpenGL, Direct3d, GDI, Aqua, augh!

I find myself inadvertently conflating languages and api's, not realizing what I'm doing until I get syntax errors. I feel like I can't possibly keep up with it, and I can't possibly be proficient in all of these areas. Especially outside the realm of C++ and Python, I find myself programming more by looking at manuals that from memory.

Do you have a similar problem? Ideas for compartmentalizing so you're more efficient? Deciding where you want to stay proficient? Organizational tips? Good ways to remember when you switch from Lua to C++ you need to start using semi-colons again? Rants on how complicated we programmers have made things for ourselves?

Any ideas welcome!

Answer 1

I think after a while it comes natural to you. When I was first getting serious about programming I was using a variety of languages - Java and C# especially. I found myself accidentally using certain Java features in C# and the other way around. Luckily for me a lot of their features are identical so it saved me there, but as I moved on this wasn't really a problem.

Try spending a significant amount of time with each language. Sit down and read a good book (or a couple) on each language and get familiar with it. Ask your boss if you can spend most of your time on one section at a time. You will begin to catch more of your mistakes before you make them. For the ones you don't, this is why debuggers were created - a programmer's best friend. I have a terrible memory, and I mean TERRIBLE. You may think it makes programming harder for me but it really doesn't. After using a language for a significant amount of time the functions just seem to come to you.

So try spending more time on each language instead of jumping around and trying to learn them all at once. The information will stick with you better and you will become a lot less flustered and confused when coding time comes around. Try doing things that help keep you focused while programming. If a lot of caffeine helps, go for it! If listening to your favorite music helps, go for it! (for me I can't concentrate whatsoever with the smallest sounds, but everyones different).

Best of luck!

Answer 2

I personally have almost no hope of forward progress without my half-dozen API and language reference bookmarks sitting right on my desktop.

Answer 3

I feel your pain, bro.

I don't know, though; I think multiple-language proficiency (or at least multiple-language-general-awareness) is just sort of the world we're livin' in, and something we're just gonna have get used to. Somehow. Alas, I don't know what the secret is to keeping sane, though. (Although for me, I can say that beer definitely helps.)

Some folks on my team (I work at Real, too, incidentally) develop in C++ on Windows, for Windows, and that's it -- that's all they've been doing for years, and they're great at it, they love it, and they're totally happy doing that one thing really well.

Me, on the other hand -- I've never been able to settle into any one language, and I don't think I'd want to; generally speaking, I've learned about a language a year for the past ten years, some of them unlike any others (ColdFusion, anyone?), and these days, I do almost all of my work in Flash, Flex and ActionScript. If you'd told me two years ago what I'd be doing today, I'm sure I'd have laughed. Keeping up is exhausting sometimes (I posted similarly a while back -- a few good answers from other folks in there, too), but I can't seem to resist checking out the new stuff, keeping current, etc.

One thing I will say, though, following on from John T's and Scott's comments: books are the only way to go. Books, at least for me, along with reading lots of (good -- not bad) code, are the best way to let a language seep gradually and cohesively into your brain, and that just takes time. Like I said, I'm almost two years now with Flash, and I'm only now beginning to feel like I can speak ActionScript fluently. All told, I've probably got ten AS books on my desk, though, and there are two more downstairs waiting for me once I'm finished with the one I'm reading now.

It never ends. Woohoo!

PS: VBScript, though? Ugh, that's terrible. Sorry, man. ;)

Answer 4

One of the advantages of my job is that I am able to switch from one project to another, with different languages, operating systems, coding rules, QA requirements, ...

The only way I found to stay on top is not to know every bit of every language, but to know what are the reference docs and where I can find them. For instance, I use the man command for perl, TCL/TK and various flavours of Unix and Linux, the online Language Reference Manual for Ada, Apple Developer resources for Objective-C and Cocoa.

Answer 5

For any language I plan on learning thoroughly, I will write my own syntax highlighting in Vim. I try and make the colouring strict so that the colouring picks up obvious mistakes as I type them. This helps me remember where to put certain syntax items in case I forget (so // doesn't look like a comment in python, and I always have trouble remembering where to put * or [] in C). If I can't remember a function or method name, I guess it, and if it shows up in colour I know I've spelled it correctly. I also try and choose differing colours so that different languages stand out from each other, it helps my brain remember what language I'm writing in.

Answer 6

The feature I never get right the first time, when I change from one language to another, is arrays. They always have different syntax, and I end up looking them up every time. Here is a list of my most used languages and how to implement arrays in them:

//Java:
int[] array1 = new int[5];
int[] array2 = {0, 1, 2, 3, 4};
//C/C++:
int array1[5];
int array2[5] = {0, 1, 2, 3, 4};
//JavaScript:
var array1 = new Array(5);
var array2 = [0, 1, 2, 3, 4];
//PHP:
$array1 = array(5);
$array2 = array(0, 1, 2, 3, 4);
//Python:
array1 = []#According to the comments, we don't care about size!
arary2 = [0, 1, 2, 3, 4]; #Could use range to create a sequence

Answer 7

One of the things you find in web-dev is that almost by definition if you want to be capable of end-to-end work you need to be capable of at least 5 languages (SQL, mid tier, html, css, js), and every slightly different project is going to add something else (jQuery? Flash? XML?).

I think you just sort of have to grok this naturally, but two things really help:

• learn concepts, not syntax and lean on IDEs and google when you need to (another reason language specific interview questions make no sense), because these are applicable to anything and it's easier to see the domain specific components sliding in and out than to think you're learning something entirely different

• where possible stick to the similar families of language syntax - I know I personally find C# considerably more natural to use than PHP because it's sharing syntax with JS and Actionscript, XML because of it's familiarity for me from HTML

Answer 8

A few things I do to keep them seperate...

Use different IDE's / editors / colour schemes for different languages. You start to associate the language with the environment, and when you switch windows your brain gets a big visual cue that it needs to context switch to the new language.

Try to limit context switching to 2 or 3 active languages at a time. Close down any other IDEs or editor windows when you're done with them.

Try to forget the "fire and forget" stuff. A lot of the languages you've listed seem like they wouldn't be things you're actively coding in every day, but rather tools you use to automate daily tasks. As much as possible try to have a "tool day" where you do any work you need to on those tools. Seperate it as much as possible from your day to day coding, so your brain doesn't have to worry about page swapping that stuff in and out all the time.

-- edit cue, not queue.

Answer 9

I agree: there are too many languages and APIs out there.

If you were a customer, and languages and APIs were just like T-shirts, you would be happy that you have the biggest choice possible. Hey, if you want a statically typed language which gives you a lot of flexibility and high performance, go with C++! If you want something easier to maintain, go with Java or Python or Ruby or you name it. You have the choice. You should be happy.

But the truth is, you're more like a guy building a house, and languages and APIs are like screws and bolts: they're your tools. If you have 1000 different types of screws and bolts, each with different characteristics and limitations, then your job will be a nightmare. You'd be more focused on your tools than on the house you're building (does this ring a bell?). Of course, I know there is no one-size-fits-all bolt, but you certainly could imagine life with just a few different types of bolts, couldn't you?

I think the problem lies in the fact that guys in the building industry love the houses they're building... and we developers just love the bolts. I'm no exception: I just love to learn a new language or framework. Bolts are so beautiful. ;-)

Answer 10

Any project scheduling you can do to minimize the context switches could be helpful. Can you put off the web development until the C++ code is stable?

Another thing I try to do is have a good "worked example" of a new language. Try and find small to medium sized samples of the language you're currently using, and keep it handy. I find picking up syntax details from a piece of sample code I'm somewhat familiar with is often quicker than digging the details out of a reference manual.