Tips and Tricks When Learning Multiple Languages?

BoneFlower asks: "Due to early registrations scooping up most of the good electives at my school, I'm stuck with learning COBOL(required CS class at my school) and Visual Basic.NET (only useful CS elective left) at the same time. The only tips I've gotten from IRC are 'drop one' and 'Focus on COBOL only enough to pass, and put most of your effort on Visual Basic'. I'd prefer to learn both well, do any of you have any suggestions on how to do this? What aspects of each could I use to enhance the other, and what apparent similarities should I keep in mind as dangerous traps? I also have some C++ knowledge, up to basic classes and memory management, so any of that that I could use in the current classes would be useful as well."

Comments

If these are intro classes

[GigsVT]

And I assume they are, then don't sweat it man, both of those languages are usually taught in an extremely simple way in intro classes. Especially VB. I wound up having to take two semesters of VB (even after already taking advanced data structures in C++), and I lost points for not changing the background of my windows from grey to something like pink or orange. In the second semester class. I'm not kidding. And people wonder why I dropped out.

The only way you will learn anything remotely useful is to work with the language you want to learn extensively on your own. You actually still think you go to college to learn things??

You're in luck.

[Jack Tanner]

COBOL and VB, arguably, come from similar philosophies -- they're both very verbose.

COBOL is not tough. It's a relatively ancient, simple programming paradigm. Without various proprietory add-ons, it doesn't get into any of the web integration technologies or anything of the sort. You might actually pick up some useful insights into mainframes and the 'suit' mindset. Despite the FUD about COBOL, it's still going and growing VERY strong. COBOL-2002 is a new standard of the language, and code is still being written in it for many, many legacy applications. For example, here's a recent press release from a COBOL compiler manufacturer.

Analyst firm Gartner estimates that applications managing about 85 percent of the world's business data are written in COBOL. Gartner further estimates that there are approximately 90,000 COBOL programmers in the U.S. and the annual growth of COBOL code over the next four years is 5 billion lines.

VB, on the other hand, is completely proprietary, very up to date, but not nearly as useful server-side, and will have you hunting down advisories on MSDN.

Summary: Focus on both. Neither is really hard. COBOL is easier. And if you really want to learn both, integrate a VB front-end with a COBOL legacy application.

Re:Quick, transfer to another school!!!

[Anonymous Coward]

Lot's of very large finanical shops still run COBOL. If it ain't broke don't fix it. Those 20 year old legacy systems have been built up and patched over the years to do major workloads. You don't just throw out a Multi-Million Dollar mainframe that you have 20+ years invested in.

Sure they hired Y2K COBOL programmers most of whom were retired and realized they could make a good buck for Y2K. Most of those were laid off after Y2K and the rest were laid off after the dot.bomb.

The remaining few simply maintain it. Now outsourced India shops are re-writing large portions of the legacy code to interface it into new network architectures for single sign on, etc. It will use SOAP to interface with Java App Servers, etc. The cost is cheaper to keep what we have rather than port it to something else or even rewrite it from scratch. Hell there's few people about who can actually wrap their minds around the enormity of the systems.

Knowing COBOL could come in handy someday. Sure it's a dying language but I'm sure you could learn something from it. Something along the lines of Latin being a dead language. There is still value in knowing Latin. Knowing COBOL is like knowing Latin not that COBOL is a basis for other language s like Latin; but because there is much in the way of legacy code still in operation out there. You may be tasked to interface with a COBOL system.

Re:Quick, transfer to another school!!!

[Sloppy]

The Microsoft proprietary language requirement is pretty suspicious for a CS cirriculum, but there may be a valid reason for the COBOL requirement.

I remember way-back-when, I had to use FORTRAN in a data structures class, precisely because it was so poorly suited. I suspect a lot of programmers are used to languages/libraries that automagically manage memory and garbage-collect, or else languages where the details of the heap and stack are managed for you, even if you have to keep track or your malloc()s and free()s. But if you use a language that doesn't have dynamic memory management and can't do recursion, then the programmer has to learn how to deal with all that under-the-hood stuff, using arrays or something. It's probably good for CS guys, at some point, to be exposed to the cost of all the things that modern tools do for them. Would you trust a CS grad who doesn't know how malloc/free work?

So maybe that's what the COBOL requirement is for? Or maybe not. ;-)