The title may seem slightly self-contradictory, and I accept that you can't really learn a language quickly. However, an experienced programmer that already has knowledge of a few languagues and different styles (functional, OO, imperative etc.) often wants to get started quickly. I've seen a few websites doing effective "translations" in the form of "just show me syntax equivalence". I can't remember the sites now, but for related languages (e.g. Perl/PHP) it's quite common.
Is there a better resource that covers more languages? Is there a resource that covers idioms as well as syntax? I think this would be incredibly useful for doing small amounts of work on existing code bases where you are not familiar with the language. Looking at the existing code, as we know, is not always a good indicator of quality. Likewise, for "learn by doing" weekend project I always have the urge to write reasonably idiomatic, clean code from the start. Such a resource could also link to known good example projects of varying sizes for those that prefer to learn by reading. Reading a well-written medium sized code base can also be much more practical when access to development environments might be limited.
I think it's possible to find tutorials and summaries for individual languages that provide some of this functionality in disparate web locations but I'm hoping there is a good, centralised, comparative place that the busy programmer can turn to.
You generally have two main things to overcome:
Syntax
Reference
Syntax you can pick up fairly quickly with a language tutorial and a stack of samplecode.
Reference (library/API calls) you need to find a proper guide to; perhaps the language reference, or perhaps google...
With those two in place, following a walkthrough (to get you used to using the development environment) will have you pretty much ready - you'll be able to look up what you want to say (reference), and know how to say it (syntax).
This, of course, applies principally to procedural/oop languages; languages that require a paradigm switch (ML/Haskell) you should go to lectures for ;)
(and for the weirder moments, there's SO!)
In the past my favour was "learning by doing". So e.g. I know a little bit of C++ and a lot of C#.Net but I must write a FTP Tool in Python.
So I sit for an hour and so the syntax differences by a tutorial, than I develop the form itself and look at the generated code. Then I search a open source Python FTP Client and get pieces of code (Not copy and paste, write it self to see, feel and remember the code!)
After a few hours I get it.
So: The mix is the best. A book, a piece of good code, the willing to learn and a free night with much coffee.
At the risk of sounding cheesy, I would start with the language's website tutorial and/or FAQ, followed by asking more specific questions here. SO is my centralized location for programming knowledge.
I remember when I learned Perl. I was asked to modify some Perl code at work and I'd never seen the language before. I had experience with several other languages, however, so it wasn't hard to figure out the syntax with the online Perl docs in one window and the code in another, side-by-side. I don't know that solely reading existing code is necessarily the best way to learn. In my case, I didn't know Perl but I could tell that the person who originally wrote the code didn't know Perl either. I'm not sure I could've distinguished between good Perl and really confusing Perl. It would've been nice to be able to ask questions here at the time.
Language isn't important. What is important is learning your ways around designing algorithms and the proper application of design patterns. Focus on the technique, not the language that implements a certain technique. Once you understand the proper development techniques, any programming language will just become real easy, no matter how obscure they are...
When you put a focus on a language, you're restricting your own knowledge.
http://devcheatsheet.com/ seems to be a step in the right direction: it aggregates cheat sheets/quick references and they are (somewhat) manually reviewed. It's also wide-ranging. It still comes up short a bit in terms of "idiomatic" quick reference: for example, the page on Ruby doesn't mention yield.
Rosetta Code appears to be an excellent resource that includes hints on coding idiomatically and moves from simple (like for-loops) to things like drawing. I haven't checked out how comprehensive it is, but there are a large number of languages and tasks listed. The drawbacks re: original question are:
Some of the linking is not accurate
(navigating Python->ForLoop will
take you to the top of the ForLoop
page, not the Python section). It's a
wiki, this can be improved.
Ideally you could "slice" the wiki
however you chose to see e.g. the top
20 tasks for two languages
side-by-side.
http://hyperpolyglot.org/ seems to be an almost perfect match for what I was looking for. The quality is not always there, or idiom can be lacking, but it has the same intention and is pretty comprehensive.
Related
Using the right language for the job is the key - this is the comment I read in SO and I also belive thats the right thing to do. Because of this we ended up using different languages for different parts of the project - like perl, VBA(Excel Macros), C# etc. We have three to four languages currently in use inside the project. Using the right language for the job has made it immensly more easy to do automate a job, but of late people are complaining that any new person who has to take over the project will have to learn so many different languages to get started. Also it is difficult to find such kind of person. Please note that this is a one to two person working on the project maximum at a given point of time. I would like to know if the method we are following is right or should we converge to single language and try to use it across all the job even though another language might be better suited for it. Your experenece related to this would also help.
Languages used and their purpose:
Perl - Processing large text file(log files)
C# with Silverlight for web based reporting.
LabVIEW for automation
Excel macros for processing data in excel sheets, generating graphs and exporting to powerpoint.
I'd say you are doing it right. Almost all the projects I've ever worked on have used multiple languages, without any problems. I think you may be overestimating the difficulty people have picking up new languages, particularly if they all use the same paradigm. If your project were using Haskell, Smalltalk, C++ and assembler, you might have difficulties, I must admit :-)
Using a variety languages vs maintainability is simply another design decision with cost-vs-benefits trade-offs that, like any design decision, need to considered carefully. While I like using the "absolute best" tool for the task (whatever "absolute best" means), I wouldn't necessarily use it without considering other factors such as:
do we have sufficient skill and experience to implement successfully
will we be able to find the necessary resources to maintain it
do we already use the language/tech in our system
does the increase in complexity to the overall system (e.g. integration issues, the impact on build automation) outweigh the benefits of using the "absolute best" language
is there another language that we already use and have experience in that is usable in lieu of the "absolute best" language
I worked a system with around a dozen engineers that used C++, Java, SQL, TCL, C, shell scripts, and just a touch of Perl. I was proud that we used the "best language" where they made sense, but, in one case, using the "best language" (TCL) was a mistake - not because it was TCL - but rather because we failed to observe the full costs-vs-benefits of the choice:*
we had only 1 engineer deeply familiar with TCL - the original engineer who refused to use anything but TCL for a particular target component - and then that engineer left the project
this target component was the only part of the system to use TCL and it was small relative to the other components in the system
the component could have been also implemented in another language we already used that we had plenty of experience in (C or C++) with some extra effort
the component appeared deceptively simple, but in reality had subtle corner cases that bit us in production (not something we could have known then, but always something to consider as a possibility later)
we had to implement special changes to the nightly build because the TCL compiler (yes, we compiled the TCL code into an executable) wouldn't work unless it could first throw its logo up on the screen - a screen which wasn't available during a cron-initiated automated nightly build. (We resorted to using xvfb to satisfy it.)
when bugs turned up, we had difficult time finding engineers who wanted to work on it
when problems with this component cropped up only after sustained load in the field, we lacked the experience and deep understanding of the TCL execution engine to easily debug it in the field
finally, the maintenance and sustainment team, which is a much smaller team with fewer resources than the main development team, had one more language that they needed training and experience in just to support this relatively small component
Although there were a number of things we could have done to head-off some of the issues we hit down the road (e.g. put more emphasis on getting TCL experience earlier, running better tests to detect the issues earlier, etc), my point is that the overall cost-vs-benefit didn't justify using TCL to code that single component. Again, it was not a mistake to use TCL because it was TCL (TCL is a fine language), but rather it was a mistake because we failed to give full consideration to the cost-vs-benefits.
As a Software Engineer it's your job to learn new languages if you need to. I would say you should go with the right tool for the job.
It's like sweeping the floor with an octopus. Yeah, it gets the job done... kind of... but it's probably not the best tool for the job. You're better off using a mop.
Another option is to create positions geared towards working in specific languages. So you can have a C# developer, a Perl developer, and a VBA developer who will only work with that language. It's a bit more overhead, but it is a workable solution.
Any modern software project of any scope -- even if it's a one-person job -- requires more than one language. For instance, a web project usually requires Javascript, a backend language, and a DB query language (though any of these might be created by the backend language). That said, there's a threshold that is easily reached, and then it would be very hard to find new developers to take over projects. What's the limit? Three languages? Four? Let's say: five is too many, but one would be too few for any reasonably complex project.
Using the right language for the right job is definitely appropriate - I am mainly a web programmer, and I need to know server-side programming (Rails, PHP + others), SQL, Javascript, jQuery, HTML & CSS (not programming languages strictly, but complex things I need to know) - it would be impossible for me to do all of that in a single language or technology.
If you have a team of smart developers, picking up new languages will not be a problem for them. In fact they probably will be eager to do so. Just make sure they are given adequate time (and mentoring) to learn the new language.
Sure, there will be a learning curve to implementing production code if there is a new language to learn, but you will have a stronger team member for it.
If you have developers in your teams who strongly resist learning new languages, unless there is a very good reason (e.g they are justifiably adamant that they are being asked to used a different language when it is not appropriate to do so) - then they are not the sort of developers I'd want in my teams.
And don't bother trying to hire people who know all the languages you use. Hire smart programmers (who probably know at least one language you use) - they should pick up the other languages just fine.
I would be of the opinion, that if I a programmer on my team wanted to introduce a second (or third) language into a project, that there better be VERY VERY good reason to do so; as a project manager I would need to be convinced that the cost of doing so, more than offset the problems. And it would take a lot of convincing.
Splitting up project into multiple languages makes it very expensive to hire the right person(s) to take over that project when it needs maintenance. For small and medium shops it could be a huge obstacle.
Edit: I am not talking about using javascript and c# on the same project, I am talking about using C# for most of the code, F# for a few parts and then VB or C++ for others - there would need to be a compelling reason.
KISS: 'Keep it simple stupid' is a good axiom to follow in most cases.
EDIT: I am not completely opposed to adding languages, but the burden of proof is on the person to who wants to do it. KISS (to me) applies to not only getting the project/product done and shipped, but also must take into account the lifetime maint. and support requirements. Lots of languages come and go, and programmers are attracted to new languages like a moth to a light. Most projects I have worked on, I still oversee and/or support 5 or 10 years later - last thing I want to see is some long forgotten and/or orphaned language responsible for some key part of an application I need to support.
My experience using C++ and Lua was that I wrote more glue than actual operational code and for dubious benefit.
I'd start by saying the issue is whether you are using the right paradigm for the job?
Suppose you know how to do object oriented programming in C#. I don't think the leap to Java is all that great . Although you'd have to familiarize yourself with libraries and syntax, the idea is pretty similar.
If you have procedural parts to your project, such as parsing files and various data transformations, your Perl/Excel Macros seem pretty similar.
But to address your issues, I'd say above all, you'll need clarity in code. Since your staff are using several languages, they won't be familiar with all languages to an equal degree. So make sure of this:
1) Syntactic sugar is explained in comments. Sugars are pretty language specific and may not be obvious to a new reader. For instance, in VBA I seem to remember there are default properties, so that TextBox1 = "Hello" is what you'd write instead of TextBox1.Text = "Hello". This can be confusing. Also, things like LINQ statements can have un-obvious meanings. So make sure people have comments to read.
2) Where two components from different languages have to work together, make excruciatingly specific details about how that happens. For instance, I once had to write a C component to be called from Excel VBA. There's quote a few steps and potential errors in doing this, especially as far as compiler flags. Make sure both sides know how their side of the interaction occurs.
Finally, as far as hiring people goes, I think you have to find people who aren't married to a specific language. To put it vaguely, hire an intelligent person who sees business issues, not code. He'll learn the lingo soon enough.
Somewhere some guy said (I honestly do not know where I got this from), that one should learn one programming language per year. I can see where that might be a good idea, because you learn new patterns and ways to look at the same problems by solving them in different languages. Typically, when learning a new language, I look at how certain problems are supposed to be solved in that language. My question now is, what, in you experience, are good, simple, and clearly defined tasks that demostrate the differences between programming languages.
The Idea here is to have a set of tasks, that, when I solve all of them in the language I am learning, gives me a good overview of how things are supposed to be done in that language. I do not know if that is even possible, but it sure would be a useful thing to have.
A typical example one often sees especially in tutorials for functional languages is the implementation of quicksort.
Search for "Code Kata" for some resources.
Pick a problem. Solve it in different languages.
http://slott-softwarearchitect.blogspot.com/2009/08/code-kata-resources.html
In today's world, I don't think simple tasks like implementing a bubble sort will really give you a taste for that language. The reason being that several of them have C at their core (java, c#, php, javascript, etc).
Instead, go for small apps like a simple contact manager. This will allow you to work with the chosen language's UI, Database, and logic features.
Let's say a tester is to do some programming to create automated tests ... is Lua really easy to learn for someone who is not a developer?
It depends on the particular non-developer in question. Some people will utterly block on any programming language at all. Some will easily grok many languages and basic programming concepts. There is no silver bullet for putting the power of programming in the hands of someone who is untested on it.
That being said, my personal feeling is that Lua is as good of a place to start as any other programming language.
The Lua language has an active and usually novice-friendly community. It has a long history of use on the boundary between non-programmers and programmers. The language reference manual and standard text book are among the best written examples I've seen in my career. The full text of the reference manual is online, and the first edition of Programming in Lua is as well, although the second edition of PiL reflects the differences in the language that happened after PiL was first published and is well worth the investment to purchase.
One of Lua's strengths is the ease with which it can be integrated into an existing system to construct a configuration and scripting interface to an application. That makes the development cost to adopt it relatively low. Its small size makes the impact on an application release remarkably low as well. Thus getting an existing system to the point where it can be scripted enough with Lua to use Lua as a basis for testing will likely be a straightforward task with few hidden obstacles.
Lua is very forgiving which many people associate with "easy". You do not have to enter semi-colons, you do not have to scope variables, you can write all of your functions in the global scope. Of course doing these things only make your life easier when writing. When debugging even a new programmer may soon see why taking these short cuts is not such a good idea.
I also believe that you can write very simple, easy to use APIs in Lua and you could also create very complex APIs, which may involve object oriented concepts (such as the difference between . and :) or functional APIs with closures and passing around functions as function arguments, etc. Whether the user is able to properly use and understand the language to do the task at hand depends largely on the API as much as or more so than the language.
I do believe Lua is an easier language to learn than many others, like Ruby and Python (and obviously Perl). Lua's grammar and syntax are more consistent than Ruby's for instance; in Ruby you have so many reserved keywords, plus all sorts of symbols (curly-brackets for blocks and pipes for local variables etc), plus it gives you too many options (you can either use curly-brackets for blocks, or you can use the keywords do and end to start and end blocks).
I believe that for non-programmers Lua is much easier especially because of the reasons outlined above. As for programmers, I've read many people say this very same thing and I agree: programming in Lua is very pleasant. I believe that's also because of what I said above.
It probably is becausee its very similar to Python:
The number of universities using Python in there introductory Comp Sci courses is probably the highest of any language (empirically through google). Second probably being Java and Scheme.
The number of Python libraries is astronomical. And the number of people that know the language is quite high thus if you hire a new person there is a good chance they have seen the language before.
Ironically I have grown to not like the language so I am not saying this because I am python fan boy.
As long as you clearly explain to the testers the pitfalls that they may face when debugging in LUA it shouldn't be harder than learning the programming basics of any other language.
What goes through my mind is the situation where the tester made a typo and wrote a different, yet almost unnoticeable, name for a variable. The new variable will be created with the given value but the old variable won't be modified. That sort of thing can be pretty hard to debug when people are not extremely aware of it.
I'm a programmer for more than ten years.
I've learned and used different programming languages.
I've heard about Lua in different occasions, but I've never used it before.
Recently, I decided to learn Lua because our customers are using it.
After spending days on reading the PiL, it turned out for me that Lua is a powerful, flexible, yet sophisticated programming language.
From a software developer point of view, I don't think it's easy for me to be a good coder in Lua in a short time.
But if you just want to 'do something' with Lua, especially if you are from a background of non-programmer, you may feel pleased with Lua, which may be much easier to write some ready-to-use code than some 'traditional' language such as Java, C/C++, Python, etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Have you ever tried learning a language while on a project? I have, and from my personal experience I can say that it takes courage, effort, time, thinking, lots of caffeine and no sleep. Sometimes this has to be done without choice, other times you choose to do it; if you are working on a personal project for example.
What I normally do in this kind of situation, and I believe everyone does, is "build" on top of my current knowledge of languages, structures, syntax and logic. What I find difficult to cope with, is the difference of integrity in some cases. Some languages offer a good background for future learning and "language study", they pose as a good source of information or a frame of reference and can give a "firm" grasp of what's to come. Other languages form or introduce a new way of thinking and are harder to get used to.
Sometimes you unintentionally think in a specific language and when introduced to a new way of thinking, a new language, can cause confusion or make you get lost between the "borders" of your new and your current knowledge of languages.
What can be a good solution in this case? What should be used to broaden the knowledge of the new language, a new way of thinking, and maintain or incorporate the current knowledge of other languages inside the "borders" of the new language?
I find I need to do a project to properly learn a language, but those can be personal projects. When I learned Python on the job, I first expected (and found) a significant slowdown in my productivity for a while. I read the standard tutorials, coding standards and I lurked on the Python list for a while, which gave me a much better idea of the best practices of the language.
Doing things like coding dojos and stuff when learning a language can help you get a feel for things. I just recently changed jobs and went back to Java, and I spent some time working on toy programs just to get back in the feel for things (I'm also reading Effective Java, 2nd edition as my previous major experience had been with Java 1.4).
I think, in some respects no matter what the impetus for learning the language, you have to start by imitating good patterns in the new language. Whether that means finding a good book, with excellent code examples, good on-line tutorials, or following the lead of a more experienced developer, you have to absorb what it means to write good code in a particular language first. Once you have developed a level of comfort, you can start branching out and and experimenting with alternatives to the patterns that you've learned, looking for ways to apply things you've learned from other languages, but keeping within the "rules" of the language. Eventually, you'll get to the point where you know you can 'break the rules" that you learned earlier because you have enough experience to know when they do/don't apply.
My personal preference, even when forced to learn a new language, is to start with some throw away code. Even starting from good tutorials, you'll undoubtedly write code that later you will look back on and not understand how stupid you could have been. I prefer, if possible, to write as my first foray into a language code that will be thrown away and not come back to haunt me later. The alternative is to spend a lot of time refactoring as you learn more and more. Eventually, you'll end up doing this, too.
I would like to mention ALT.NET here
Self-organizing, ad-hoc community of developers bound by a desire to improve ourselves, challenge assumptions, and help each other pursue excellence in the practice of software development.
So in the spirit of ALT.NET, it is challenging but useful to reach out of your comfort zone to learn new languages. Some things that really helped me are as follows:
Understand the history behind a language or script. Knowing evolution helps a lot.
Pick the right book. Research StackOverflow and Amazon.com to find the right book to help you ease the growing pains.
OOP is fairly common in most of the mature languages, so you can skip many of the chapters related to OOP in many books. Syntax learning will be a gradual process. I commonly bookmark some quick handy guides for that.
Read as many community forums as possible to understand the common pitfalls of the new language.
Attend some local meetups to interact with the community and share your pains.
Take one pitch at a time by building small not so complicated applications and thereby gaining momentum.
Make sure you create a reference frame for what you need to learn. Things like how security, logging, multithreading are handled.
Be Open minded, you can be critical, but if you hate something then do not learn that language.
Finally, I think it is worthwhile to learn one strong languages like C# or Java, one functional language and one scripting language like ruby or python.
These things helped me tremendously and I think will help all software engineers and architects to really gear for any development environment.
I learned PHP after I was hired to be the project lead on the Zend Framework project.
It helped that I had 20 years of professional programming background, and good knowledge of C, Java, Perl, JavaScript, SQL, etc. I've also gravitated towards dynamic scripting languages for most of my career. I've written applications in awk, frameworks in shell, macro packages in troff, I even wrote a forum using only sed.
Things to help learn a language on the job:
Reading code and documentation.
Listening to mailing lists and blogs of the community.
Talking to experts in the language, fortunately several of whom were my immediate teammates.
Writing practice code, and asked for code reviews and coaching.(Zend_Console_Getopt was my first significant PHP contribution).
Learning the tools that go along with the language. PHPUnit, Xdebug, phpDoc, phing, etc.
Of course I did apply what I knew from other programming languages. Many computer science concepts are language-universal. The differences of a given language are often simply idiomatic, a way of stating something that can be done another way in another language. This is especially true for languages like Perl or PHP, which both borrow a lot of idioms from earlier languages.
It also helped that I took courses in Compiler Design in college. Having a good foundation in how languages are constructed makes it easier to pick up new languages. At some level, they're all just ways of abstracting runtime stacks and object references.
If you're a junior member of the team and don't know the language, this is not necessarily an issue at all. As long as there is some code review and supervision, you can be a productive.
Language syntax is one issue, but architectural differences are a more important concern. Many languages are also development platforms, and if you don't have experience with the platform, you don't know how to create a viable solution architecture. So if you're the project lead or working solo, you'd better have some experience on the platform before you do your design work.
For example, I would say an experienced C# coder with no VB experience would probably survive a VB.NET project just fine. In fact, it would be more difficult for a developer who only had experience in C#/ASP.NET to complete a C# WPF project than a VB ASP.NET project. An experienced PHP developer might hesitate a bit on a ColdFusion project, but they probably won't make any serious blunders because they are familiar with a script based web development architecture.
Many concepts, such as object modelling and database query strategies, translate just fine between languages. But there is always a learning curve for a new platform, and sometimes it can be quite nasty. The worst case is that the project must be thrown out because the architure is too wrong to refactor.
I like to learn a new language while working on a project, because a real project will usually force me to learn aspects of the language that I might otherwise skip. One of the first things I like to to is read code in that language, and jump in. I find resources (such as books and various internet sites) to help as I go along.
Then, after I've been working on it for a while, I like to read (or re-read) books or other resources on the language. By this time I have some knowledge, so this will help solidify some things and also point out areas where I am flat-out wrong in my understanding. For instance, I can see that I was making incorrect assumptions about similarities between languages.
This also applies to tools -- after using a tool for a while and learning the basics, reading (or skimming) the documentation can teach me a lot.
In my opinion, you should try to avoid that. I know, most of the times you can't but in any case try not to mix the new language with the old one, and never add to the mixture old habits, practices and patterns.
Always try to find resources that will help you get through the new language in the way the language works, not in the way other languages do; that will never have a happy ending, and if it does it will be very hard to modify it to the right way.
Cheers.
Yes I have.
I mean, is there another way? The only language I ever learned that was not on a project was ABC basic, which was what you used on my first computer.
I would recommend if you start with a certain language, stick with it. I only say that because many times in the past I tried more and more different ones, and the one I started out with was the best :D
Everytime I have/want to learn a new language, I force myself to find something to code.
But to be sure I did it well, I always want to be able to check my code and what it ouputs.
To do so, I just try to do the same kind of stuff with languages I know and to compare the outputs. For that, I created a little project (hosted on Github) with an exercise sheet and the correction for every language I learnt. It's a good way to learn in my opinion because it gives you a real little project.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
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!
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.
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.
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!
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
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
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. ;-)
I personally have almost no hope of forward progress without my half-dozen API and language reference bookmarks sitting right on my desktop.
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. ;)
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.
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.
Humans can't multitask. Period.
http://www.joelonsoftware.com/articles/fog0000000022.html
If you aren't allowed to let other people do the work because they already have full plates, then get more people hired. If you aren't allowed to get more people hired, then maybe people can at least shift priorities so each person can focus a bit more.
For example: If you're full time on the engine, or at any level of commitment beyond bug fixes, why are you working on game logic? And content tools? And build tools? And web development? If you're not talking about a one year time span, with maybe a separate solid month of concentrating on each, then it sounds like you do all the programming, and everyone else just twiddles their thumbs.
Surely you're the expert for only one of these areas, and not all of them. There's that whole "if you got hit by a bus" thing. If you're that guy, then that is job security for you, but terrible for your company and your sanity.
You could try matching up tools a bit more. Move as many things as you can to Python or .Net, since I assume you can't ditch your core technologies for your games.