C : Twelve years

Five huge projects (managed, designed, wrote key algorithms).  Managed C programmers.  Set company-wide standards for C coding.  Used tools like sophisticated linkers (RtLink), debuggers (BoundsChecker) and version control systems (PVCS) because the projects that I designed and coded for were large and complex.  Examples of the kinds of routines that I typically coded (as opposed to delegating to others):

parsers, communications, memory management, code mimicking ODBC drivers for non-standard databases, code to translate HP pen plotter commands into HP laserjet commands while minimizing the printer memory consumed, etc.

Basically, if the complexity was too great, the constraints too narrow or the timeframe too short - that's the kind of C programming situation I have been entrusted with across three companies and twelve years.

C++: intermittent experience - Five years

Several applications.  In most cases, I would rather develop in C or VB because I find the maintenance costs lower.  One counter-example is when programming with dates - I found it very useful to be able to define date objects and supply increment/decrement operators.  Once dates are well-defined, working with them is a breeze!

Another exception would be in cases where existing objects or third-party code provide significant benefits.  It is critical in these cases to have access to the source code or to be able to quickly eliminate any potential bottlenecks.

Visual Basic and VBA (Visual Basic for Applications): Eight years

Several products and dozens of applications.  Managed VB development.  Used the Excel SDK together with some .dlls that I developed and some VBA to speed up Excel projects.   Experienced with ActiveX, COM and DCOM development from the VB environment.  Use of third-party controls.  Use of Windows APIs.

EPS - DRI (currently DRI-WEFA)

Econometric Programming Software.  Completely object-oriented before the term became popular - you created or retrieved objects, manipulated them and controlled their storage.  Objects included time series and arrays for data, and routines, memos and equations to facilitate programming and data analysis.

The best EPS programmer outside of the developers themselves for virtually my entire career at DRI.  Dozens of large and complex applications.  Hundreds of smaller projects.  I have not programmed in EPS for over 8 years but would still program at the expert level assuming it still exists!

VBScript:  Four years

Several applications - including database access.    Added for completeness since VB experience makes learning VBScript simply a matter of learning about some Web-specific objects and knowing the differences between VB and VBScript.

JavaScript: Three years

Several applications.   Similarity with C makes analogous to the VB / VBScript situation.  When I have a choice, I use whichever language I can "borrow" existing code for or is most maintainable with the current staff.

Perl: < 1 year experience

A couple of applications.   Thoroughly studied a manual.  C similarities and that review make me comfortable with programming in Perl.  Cannot think of situations where this would be my first choice, but...

Macro languages: 1-2-3, Excel, Quattro Pro

Most familiar with Quattro Pro and Excel - have written extensive macro programs.  Some 1-2-3 macros.  Would consider myself an expert in Quattro Pro and Excel macros except that it has been a while and I might have to rely on documentation more than an expert would.  Excel macros are less relevant given VBA...

Basic, Fortran and Cobol: learned in high school / college

Listed for completeness - it is unlikely I would take a job where knowledge of these languages was important (except maybe porting mainframe applications).  I was expert in these languages - but it was a long time ago.