PL/I some preliminaries.  I used this in a couple of college courses.  I don't remember whole lot about it.

COBOL

COBOL where my journey as a professional began.  Hey, you've got to start somewhere.  Of course now I can hardly believe that I used to do that.  Verbose, ugly. EVIL.  Satan himself put the ALTER command into the language....   CICS was ... interesting because of some of it's oddities which I didn't understand until...

BAL

BAL aka assembler on the mainframe.  This is where I fell in love with programming.  To this day I feel that someone who doesn't have a good feel for what goes on at a very low level can't understand what is really going on in the computer.  Originally it was all applications for me because that is what IBM's life insurance application CFO was written in.  But then I began to really learn things.  Like the linkage conventions COBOL used so I could extend COBOL with assembler.  Then when I ran out of things to do in user space I learned about the real guts of the system... and became a systems programmer.  Raw IO in assembler on a 370 will put hair on your chest (and make it fall out of your head).  And since I knew BAL I could read dumps and did for years.  I knew in fine detail what made the 370's (and later 390) tick.

I also learned machine language on my home machine, then a comodore 64 (6502).  Wrote some interesting code, including my own implementation of xmodem.  When I got to PC's I learned a little of machine language on them, but lots was hidden - the IBM OS came with software source, and as a systems programmer patching and rebuilding the OS was part of my job. It made little sense to invest the time when I didn't have source to the operating system and by the time I got to linux, most processors were pipelined making assembler programming a nearly useless skill since the c compilers would optimize code for your processor's pipeline model.

BASIC

BASIC.  Of course I learned basic on the little c64.  And learned that we actually had it on the mainframe... where nobody cared, for good reason.   Um, not too long ago I had to do something in Visual Basic, even though it meant two weeks of crash cramming to learn it...  You realize that if you strip the COM/ADO/whatever this week constructs out of it, you're left with ... GW Basic.
Contempt!

REXX

REXX (of course preceeded by EXEC).  This was the primary scripting language for the mainframe.  It is a very powerful procedural language with two points of primary interest, it has the power to subsume multiple command environments via the "ADDRESS" command and stemmed variables.  Stemmed variables are essentially hashes automagically nested as deeply as you want them.  In my decade of mainframe systems work Rexx and assembler were my primary tools.  IBM ported Rexx to the OS/2 which I used for some cross systems work (a multi-system problem notification system) and there was also a version for the amiga (my later home computer) called ARexx.  Towards the middle of my mainframe years there was an implementation of Rexx and Xedit from Mansfield Software for the PC's which I used somewhat.  

None of the above are oo languages, though now there are oo implementations of cobol, basic and rexx.  BAL of course is not OO but the assembler has a very powerful if clumbsy macro system which I eventually used when I "got" oo to implement something like the beginnings of an OO usage of assembler.  Rexx has stemmed variables and the ability to call a function stored in a variable.  At one time I seriously and deeply played with trying OO paradigms in Rexx.  The most practical result was a tool called POPFETCH (under VM, there is now another Popfetch which looks like it may have built on my idea, but I have no sure knowledge and I released POPFETCH essentially pd.  It was used fairly widely at universities which ran VM).  The net discovery was that Rexx was ill suited for oo despite having some features which leaned that way, no big surprise.

Through most of my mainframe career, unix was the little brother of the mainframe.  We looked upon it with disdain.  But by the late 80's it was hard to deny it's growing presence.  And c was the language of choice on unix.  There was also a c compiler for my amiga, so I learned c.

c

c is really simplicity itself as a language.  There are about 30 keywords and the syntactic triggers for code blocks, functions and parameters and array indexes are fairly consistent.   Pointers are the magic of c, and that was nothing new to someone who well understood DSECTs in BAL.  There are some inconsitancies in the representation of arrays and pointers but they can be coded to be obvious in context.  There are a few syntactic variants which are implementation defined as well, and there are some oddities in the syntax of pointers and arrays that take some experience to understand but overall the language itself is clean.  

What happens next is not.  Macros.  Once again I learned all about macros in the mainframe assembler world; the ideas weren't hard.  What is aggravating is that when you look at some c code you can see macros within macros within macros five or more levels deep.  You may have to look at the source plus wind your way through three or four levels of headers in some instances to find out what's going on.  And to foreshadow things to come, it's really impossible to do things in an object oriented way.

Java

Once I learned c, my awareness of things unix slowly snowballed.  A few years later I was admin on an AIX (and still part time mainframe sysprog) box while running windows at work and taking steps towards becoming comfortable with Linux at home.  I wanted something where my work would translate across environments.  C was very good, the standard library worked well on both linux and aix, and passably well on mainframe... but it did very little for me on windows and worse, I paid for a compiler for windows, then just a little later win95 came out and my compiler wouldn't produce real 95 (32 bit code).   At the time java was being widely discussed, and though the blackdown port was poor, for most things it worked on linux, it worked on windows, the AIX version worked, and it was promised for mainframe RSN.  So I started learning Java based upon it's promise of "write once run anywhere".

Java is still my favorite language for several reasons.  It has a simple and fairly clean syntax - even in reading expertly written code I almost never see any niggling uncertainties from syntax.  The keywords are fairly obvious in meaning and their expected location.   It comes with an extensive library of utility classes and methods - this is probably the foundation of it's general popularity.  Almost any utility process you can think of is already implemented as a class with the corresponding methods to achieve; any extras you need are usually simple extensions or encapsulations of the utility class.  And it implements threading natively.  Towards the end of my mainframe career I was writing some simple servers on the mainframe. The mainframe does not have the process memory model that unix has and most server processes must be written as threading; I learned a lot about threads writing them in assembler on the mainframe.  When I learned unix the process-owns-its-own-memory model it was a revelation, and I understood immediately how it made simple services trivial to write, but at the same time it makes writing slightly more intricate multi-task accessable services which need to share updatatble information more difficult.  Java has built in facilities to solve these problems, and that appealed.

Of course Java never entirely lived up to it's wora claim to fame, but the largest inconsistencies were in the graphics system, beloved by many but not my area of interest, so that was not a handicap to me (early linux versions had some threading inconsistencies that bit me, but they were quickly cleaned up).

Finally Java has a fairly clean object oriented model. Object orientation is not a panacea for all things wrong with programming, but after years of re-inventing the wheel in each project, the power of OO to allow code reuse between projects was blinding.  Somewhat related to this at a deep level is purely automatic memory management - it seems half my c code is devoted to tracking who owns what memory structures at any given state; in Java all that goes away.

C++

Of course C++ was OO before java was invented.  And it stems from c so it sounds like it would be a good thing, right?  Wrong.   Don't get me wrong, if I have a small project which needs to be compiled into something fast, I'm as likely as not to code it as C++, as c.  But I'll use only a few of the potential features.  Objects, constructors and destructors obviously, and the various stream constructs - it'll keep me from having to write thirty character function names to qualify handlers of various data structures and eliminate the need for tiers of printf statments (or sprintf's for internal string manipulation).  I've even used templates a couple times.   But the language in toto is an impossibility, a chimera you'd expect to see in a poor grade science fiction movie.  There are so many traps built in - minor syntactic variants with significant semantic meanings that unless you use it every day for five years or more, you're never going to be a master of its capabilities.  It violates the "least surprise" principle with several idioms.  

And of course without that level of mastery maintenance programming is impossible.  There are dozens (hundreds?) of syntactic tricks and every programmer is going to know and use a handful of favorites - but no two programmers will use the same bag of tricks.  So if you pick up someone elses code to look at, unless you are at master level,  your going to see things you don't understand and have to look up, which is a nuisance but not a problem ... but FAR worse you are going to NOT see some idiomatic construct he uses because at casual glance it looks like something else you are familiar with so you won't take notice.   And you'll spend hours or days trying to figure out a program when you've made wrong assumptions about what some class or method is doing with the data in certain circumstances.   If you're really, really lucky, your fixes will crash and burn because of those bad assumptions;  if you're not you may put in a fix that seems to work... until some borderline condition previously handled but not now handled right arises.   Another embarassment of the syntactic complexity is that a typo can inadvertently be handled as syntactically valid ... but meaning something far different than what you intended, and by not being flagged as a syntax problem you might not catch it until much later in the development process.

Perl

I'd now rate perl as my second favorite, but probably first in how often I use it.  It's very simple to to simple things, which is what makes it popular.  It has an interesting learning curve.  If you're otherwise familiar with programming you can learn perl well enough to be doing simple things in a couple days... and be very comfortable with the simple things in a couple weeks.   But then there's Larry's Wall.  The OO features of perl and some more bizarre constructs mean you really have to climb a mesa face before you really start to understand the why's of some of the odd constructs.  

Like c++ the newbie is going to see the multiple variants of syntactic structure as complications which he won't understand.  The "more than one way to do it" aphorism will sound to him like a cause for complaint much as I described for c++ - at the newbie level, you can't do maintenance programming for perl for the same reasons.  Every perl programmer has his own bag of favorite tricks.  But once you've climbed the Wall, it all makes sense.  All those syntactic oddities are closely related by some very common logic - there really are only a few structural elements used in perl (scalars, arrays, hashes, code blocks and handles) and all the wierd syntax is doing is telling you whether you are using them directly or as references.

OO in perl really is just syntactic sugar over hashes.   That makes doing OO in perl simple and transparent, i. e. very easy to understand, use and work with, but it also means that there is no such thing as true objectification.  You can't protect your objects from someone (sometimes yourself in a hurry) from using them as data rather than encapsulated objects.

PHP

PHP is really just a simplified Perl.  Too much simplified in my opinion, though there are changes coming in v5 which promise to correct some of what I'm about to comment upon.  Now PHP is great for it's primary purpose - quick web development.  It's possibly the language I use second most (actually currently probably most). but there are some things I don't like.  The first is that it is a purely procedural language... like Perl it has OO constructs now, classes and methods which are sugar over hashes.  But it has so many "built in" functions which should really be object and class methods that it's ridiculous to try to remember them... Still it fits its purpose well, and you can, and I have, take advantage of it's OO capability to do some pretty amazing things with your web pages.

My chief problem is it's memory model.  It presumes that everything is going to go away fairly soon, so it doesn't worry about allocation and stack deconstruction.  Worse (this won't make sense to you unless you know something of language internals) every variable value is bound to a symbol table entry.  This means that PHP references are almost nonsensical if you're used to perl references and c pointers.

Once you understand what's going on, you can use references almost as effectively as you can in other languages but it's bass ackwards until you understand it.  It also implies something else I've found to be true... you can waste a lot of memory if you're not careful exactly what your passing as references.  The flip side is also true: that you chew up a lot of cpu and memory if you don't use references where they are appropriate.

Ruby

Ruby is my future favorite language.  I'm serious.  I've played with it enough to understand how much I like it, but as it hasn't caught on and gained wider acceptance I can't yet deploy applciations which I might otherwise like to write in it.   Of course I'm not yet as comfortable in it as I am in perl or java, either.   Perhaps I'll rewrite ybsnarfz in ruby...

Ruby is a purer OO language than even java. And from what I've seen, its syntax is cleaner (more regular) than any other language I've worked with as well.

Pseudo languages ...

SQL

SQL isn't a programming languge; it's an execution language for manipulating tables and is largely constrained by that.  It's also incredibly verbose for what it's supposed to do, but of course the statements are compiled internally (by the server, and frequently cached depending on the "intelligence" of the server) before execution.  It does what it's supposed to do, but variants for various DB's are a nuisance.  I'm mostly familiar with MySQL, of course, but have used Postgresql, DB2, Sybase, MS SQL Server and a very little bit of Oracle.  You pretty much NEED to know SQL to do any professional programming these days.  As said the variants are painful - you have to know what features are supported by the server and what syntactic variants are required (are table and column names case sensitive? Is a dataspace specification required?  Is autocommit on by default or are you fully responsible for transaction management?).  But the core is common and fairly standard.  Aside from basic selects, inserts and deletes, you need to learn about inner and outer joins (it's good to know what cross joins are, but I've never found a real use for them!) groupings and havings.  A bit of relational theory - learn who Dr. Codd was - and what normalization means.

Web Development

Human resource types, probably aided and abetted by those most affected, have taken to calling HTML and stylesheet guru's or even just Dreamweaver jockeys "web programmers"...  which is good for raising my blood pressure a few points.   HTML and CSS are "languages" but their purpose is purely static.  Of course you need to know them to develop programs for the web, but there is no dynamic processing going on - if you say "control break" to a "web developer" you'll get a blank stare.   The number one problem, of course, is that not all browsers handle all HTML and especially CSS elements in the same way.  IE is particularly painful in "breaking" CSS rules.

Javascript really is a real programming language, and what I've seen of it is quite powerful.  I've only used a few instances triggered by "onClick", onSubmit, and onChange to do validation or in some instances to put up a warning message, but it really could be far more useful.  The problem, again, is the lack of standardization across implementations, which is the only reason I haven't invested more time in it.

XML

XML is a data structuring language.  It has it's roots in HTML, which is one of its problems: it's far more verbose than it needs to be for its purpose, and there are unnecessary redundancies.
The importance of a data structuring languge as an idea cannot be overstressed, but you probably don't understand what all the hype is about if you're not a programmer.  It meets its purposes fairly well though, and I've gotten quite comfortable with both the SAX (in perl) and DOM (java) models.   There are numerous levels of use I haven't yet explored but intend to, XSLT being the primary one, though I know what it is and I haven't had enough experience yet with schemas (XSD) and validating parsers (I have used DTD's some with xerces and validation enabled).  Aside from verbosity and redundancy, my largest complaint is that in designing new structures there are two separate and incompatible idions for specifying data, text elements and attributes.  I also do not like that name spaces are not inherited which leads to greater redundancy and programming overhead.

Actually in many ways, XML is the future. I expect Real Soon Now to see a programming language in which the syntactic constructs are pure and valid XML.  The quality of the language will depend upon how well semantic logic marrys up and how good the library support behind it goes.   Wish I had time to do this myself: you could, and perhaps should, rather than making a native XML language make an XML macro language to generate structures (and full programs) in almost any other language.