My initial reaction to this coincided pretty much exactly with Zaxo's reply. C-like syntax and a mixture of OO and procedural style--hands-down favorite. I also thought that the exposure to the true nature of storage, the need to convert between types--number->string->number--would be good in that it would assist the OP in understanding what, exactly, each statement of his later perl programs are doing. This is always good to understand even if 95% of the time you don't really need to know. The crutch:) of a Garbage Collector to prevent the hours I spent trying to track down memory allocation/deallocation errors when I first used C is a bonus.

As the thread has progressed, I've weakened from a "definately C++" to a "probably C++ but.." stance. The source of my indecision is the question, "What will he learn from the exposure to one of these other languages?".

I should say up front I have a distaste for all 3 languages on offer.

I dislike C++ for it's needlessly over-specific semantics and ultimately futile, over-tight, type control.

I dislike COBOL, for it's verbose, parochial syntax, it's very manual and very pedantic storage specification. The way it forces me to think about and describe every single aspect of both my storage requirements and my algorithms in long (and long-winded) monolithic step-by-step fashion.

I dislike VB, (which I have had very little exposure to by choice), not so much on the basis of the language itself, nor even because of the source of the language. My biggest problem with VB its that it makes programming almost too easy! The point being that it allows people to get into programming without much in the way of understanding of the lower levels. This is a problem in many high-level languages, but VB's accessability has meant that it has single-handedly convinced many people, coders and management alike, that there is no need for formal training nor an in-depth understanding of the bits and bytes of hardware, nor the nuts and bolts of algorithm design. The result is that it has contributed greatly to the de-valueing of the programmers art.

By which I mean, that in many instances, coding skills have become a commodity product. Imagine the release of AI-Doctor v1.1 Suddenly, anyone with the hardware and the ability to read an on-line manual can set up shop as a doctor. They asked the patient a series of questions as prompted by AI-Doctor, and after a few seconds (and perhaps a call back to the central, online case histories DB, out pops a diagnosis (97.32% probability), a prognosis (94.21% probability) and a recommended course of treatment (brand-name drugs only "from our partners XXX Drug CO.). After all, 95% of the skill of a doctor is in recognising, & corrollating symptoms and recalling treatments, so why not?

The statistic in that last statement is made up, but the sentance is essentially true. Does this mean that an AI program with a huge DB, fast search algorithm and near instant, total recall should replace the Doctor? I assume everybody will agree with me when I say NO. (NO! NO! NO!). The question is "Why not?". With something like health there is always the emotional component involved:

"I want my doctor to be flesh and blood like me not some damn machine! That way, if he recommends cutting in to me, he at least has a concept of what pain is."

might be a typical reaction to this kind of suggestion. However, there was -- and still is in some quarters. I have a cousin who actively avoids airlines that use AirBus planes because he "wants a human being in control not some damn computer" -- a similar resistance to the use of computers in fly-by-wire flight control systems, especially in commercial aircraft. "It removes the skill of the pilot!". Of course, it also removes the inherent fallability of the pilot too. Pilot error is responsible for many more aircraft accidents and deaths that mechanical failure by a very great margin.

Even so, I still don't want to replace my doctor with a computer. I will be very happy when (have no doubts, it will happen eventually) my doctor--or perhaps a semi-skilled delegate--starts using such a centrally connected, AI-driven database to narrow down my symptoms to a small set of possibles; to present him with a list of possible treatments, contrasting their statistical effectiveness along with the statistics regarding side-effects (and the eventaul outcomes).

However, I still want my human, fallable, but trained-in-depth-and-breadth, real-world experienced GP to interpret and explain those damned statistics and to prescribe my treatment. Why? Because of statistics. It's all those 2.68%'s and 5.79%'s etc. that worry me. And it's the fallable, but intuative, freely associating, leap-in-the-dark abilities of my doctors grey matter that are my best protection against them.

Whoa! A bit off-topic here aren't we? Well, ... No. Whilst 95% (guess) of programmers decisions aren't critical, and an even smaller percentage are ever going to be "life threatening", it's the precentages that get you. And on that score programming is different to many other professions--and similar to doctoring in a small way--in that it's the boundary area's, the edges, the first and last percentiles where skill, rather than trade is the key. It's perfectly possible to be a working, productive programmer without huge experience or vast formal training, but when the need is greatest and the critical hour is upon you, if you don't have the knowledge--gained through formal education or experience or prefereably some of both--then your up that famous creek without a paddle.

So, if you want to choose the language that will ease your learning curve with Perl, I'd have to say VB. It has language elements like eval, regex's, OO and flexible typing, but most important, transparent storage management. Learning these would make transition to Perl much easier I think.

C++ would probably do more for your formal education regarding algorithms, data-structures--the benefits and costs of perl's hashes, uniquely flexible arrays and scalars and references--and the nuts & bolts of OO and its 4 tenants. As for the syntax, I'm not exactly sure that C++ is that much better for this than VB. Perl has enough quirks that your going to hit them regardless of the background you come from.

COBOL. My first encounter with COBOL at college 25 years ago was "Yuk!". My second, around 10 years ago was "I still don't like it, but its certainly come along way". Many have talked as if COBOL were dead. It isn't. A quick look at the splash banner here will prove that. Their claim that "seventy-five percent of the world's data are accessed by COBOL applications" is a strong argument against that notion, and one which I have no reason to doubt. Anyone who has done work in the financial or insurance markets will confirm this. Every time you use a credit card, it is almost guarenteed that the credit checks and balance updates are processed by big-iron running COBOL. What's more, COBOL is making inroads into the world of the web. See here for some samples. If you've got a moment to download and peruse the online shop demo code (188k), do so. It was a revalation to me. Also a walk down a painful memory lane, but that's another story.

So, finally, I'd have to say, if your convinced that Perl is your future and you are going to learn it and use it regardless of what other languages you are likely to encounter, then I would suggest taking the COBOL course. The very horrors of the language that I described above--its step-by-step nature, pedantic, manual storage management etc--are the very reason for the recommendation. Not only will they make you appreciate the benefits of the GC and much else. They will also be instructive of what actually happens when you read in a piece of text (in ascii), split it into two scalar variables, add those two variables together--with transparent, implicit conversion from ascii, to one of two or three basic machine 'types'--assign the result back to a third scalar, and write it back to the screen or a file, as ascii. Ie.  my ($n,$m) = split' ', <NUMBERS_FILE>; my $answer = $n + $m; print $answer;. One line of (probably needlessly verbose) Perl. In COBOL, you would have to take care of each of the steps in the preceeding textual description, and more, yourself.

I did try to remember enough COBOL to write an equivalent program, but got hung up on the PIC (9999) and  USAGE COMPUTATIONAL stuff. If anyone reading wants to do take care of this (possibly anonymously :), it would strengthen the point.

As always, good luck.