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

Try implementing the same programs in each

[elliotj]

This is just an idea, I've never tried it: how about taking simple programs and trying to implement the exact same program in each langauge. Oh sure, VB and COBOL are very different and the interfaces will no doubt be different, but looking beyond that, trying out the same exercise in each language could teach you a lot about them both as you see how they are similar and different. Using a common problem domain will allow you to focus on the differences in structure and syntax. I'm not suggesting trying tough projects here, just simple exercises: memory management, arrays, search trees etc.

huh?

[kevin lyda]

i took three programming courses one semester and learned fp, ml, prolog, lisp, clos, vax assembler and ada. in addition i had some projects in modula-2 and c. and you're worried about cobol and visual basic? come on, yer just messing.

study, play with the langs and generally learn.

Re:huh?

[kevin lyda]

did i learn all the ins and outs? no. but i learned enough to do my projects. and i learned some other things along the way - how to learn languages, how to work with a language, how to get information on a variety of tools and how different languages have cultures around them.

that last part is hard to explain, but a good example might be perl - cpan, perlmonks, perl mongers and naming conventions. back then it was just newsgroups, but even those had their own conventions.

you'll learn the depths of languages later on - primarily when you get a job programming. first learn what exists - though cobol and visual basic would admittedly be rather vile choices. kinda fun learning fp and vax assembly at the same time. fp had not variables or control structures; vax assembly was practically c! :)

Quick, transfer to another school!!!

[Ashurbanipal]

Any place that considers COBOL a requirement, and Visual Basic worth spending course time on, is seriously out of touch with both the academic and business worlds.

Most of the giant COBOL shops killed off their COBOL dependency during the Y2K fixup. COBOL programmers with 20 years of experience are a dime a dozen now. Most people I know with COBOL experience don't even bother putting it on their resume.

Visual Basic is so trivially easy to master that it hardly requires a college course - a good manual and an on-line or CD tutorial should have you up to speed in two weeks or less.

A school with a good program would be requiring C, and offering perl, C++, Java, python, and some more esoteric languages like Eiffel, Lisp, Icon, or such.

Given no other choice, I'd skimp on the COBOL and practice the VB; you can use VB at home when you get a job as a Salesdroid, or use it with MSWindows in a mid-level management position.

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. ;-)

Easy to learn both well.

[karnat10]

Programming is something you know or you don't. Sure your skills improve over time, but there are some basics to that activity that won't change with different languages.

During a programmer's lifetime, you will have to learn a lot of languages, and frankly, if you know how to program, you can learn a new language in an afternoon, and get to be an expert after a month or so working with it.

So this is my advice: Choose a project for each of the languages, realize it, and you will know both of them well.

(I have to admit I never learnt COBOL so in a way I don't know what I'm speaking of. In another way, in my life I have learnt Basic, Pascal, C, C++, Java, Visual Basic, JavaScript and all that stuff, and I got easier every time.)

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.

How I learned multiple languages

[trajano]

Most languages tend to have 3 basic building blocks:

1) Assignment (a = 1)
2) Conditional (if ... then)
3) Loops (do while ...)

Everything else around it is syntactic sugar and what really defines the language.

The syntactic sugar basically manages the complexity of the program (it does not make things less complex).

What I normally do is learn how to do those three things first and get a simple program that does something like

a = 10
while (a > 0) {
if (a > 5) {
print "greater than 5"
}
else {
print "less than 5"
}
a = a - 1
}

Then I learn how to do procedures if it is a procedural language or how to do objects if it is OO. I tend to go to procedural first if it is supported since it is easier to learn and deal with.

Next thing I learn to do (if needed) is the memory and pointer stuff. Nowadays I do not deal with it since most modern languages already handle it for you.

By this point, I now have the basic framework of the language itself. However, it does not stop there.

For any task that is given to you, you should always think that it should've been done before. So its quite helpful to get a searchable reference handy. This is basically the key thing.

For example, I won't implement sort myself, I would use qsort() in C or the std::sort() in C++. Nor would I implement a stack or other simple data structures, I usually expect them to be there now, of course I still adjust to the language and I still remember how to do it anyway, it will just take some elbow grease.

To paraphrase the Perl reference, there are 3 virtues each programmer should have... laziness (don't implement what you think should be standard), impatience (keep the reference guide with you when you are coding, its the fastest way to get at the information), hubris (well that just builds up as you get better and start getting A+'s)

Good luck!

Re:How I learned multiple languages

[Piquan]

I disagree. The most popular languages today all more or less follow this (mostly because they're all Algol descendants), but not all languages do.

Alan J. Perlis said, "A language that doesn't affect the way you think about programming is not worth knowing." I agree. Once you've learned C, then learning Pascal or Perl is nothing. But I've seen a lot of people who are sharp-on in Perl that couldn't wrap their heads around functional languages. Ditto for teaching people OO for the first time.

If you're just learning languages by thinking they're all the same, then you're not learning languages. Don't write Perl code in Lisp; learn Lisp.

Concepts

[Apreche]

I'm a CS major as well, and I know what it's like to learn many languages. I took a class called Programming Language Concepts (PLC). We learned LISP, PROLOG and Simulink(not really a language) in 10 weeks. The way I learned them so fast was to focus on the concept, not on the language itself. This has proved useful especially in the object oriented languages.

Once you know the concepts behind a certain type of language. Say object oriented languages. You know things that are true about every object oriented language. There are classes, methods, public, private, exceptions, threads, locks, static stuff, polymorphism, inheritance, etc. Once you understand all of these things, every object oriented language should come easily to you. It took me awhile to learn C++, and a little less time to learn vb, then java. I learned C# in a matter of days, and I learned all of the basics of python in a few minutes this morning (no joke). Perl is next on my list.

Get a book on object oriented/event driven programming. And get another book on procedural programming. Learn the concepts behind the languages, and not the languages themselves. The syntax and the API will be most of what you have to learn when picking up a new language. And those are things you can just reference repeatedly until you memorize them.

COBOL.NET

[Atomizer]

With .NET it doesn't matter what language you use, so in this case the obvious thing to do is to learn COBOL.NET.

I saw some scary examples of it in the .NET seminars.

The "Real World" way to do it...

[Bald Wookie]

Write all of your assignments in COBOL. Even the ones for your VB class. No matter what it is, implement it in COBOL first.

Go party. Hard. Fear and Loathing in Las Vegas hard. Once your dorm room is full of bats start renaming variables and stripping out comments. If you can still remember what you wrote and why, you didn't party hard enough. Don't keep a backup copy of the original COBOL. That's cheating.

The night before a VB project is due, dust off the corresponding COBOL. Now all you have to do is port the heavily obfuscated and undocumented COBOL to VB. You can even get extra points for realism by getting the prof to change the project spec sometime midstream.

Once you've turned in your VB project, look back at the COBOL source. By now it should look like a bizzare cross between the tax code and naughty refrigerator poetry. The night before your COBOL project is due, start backporting it from the VB. Bonus points are awarded for targeting an ancient punchcard based architecture and then updating it to meet the project requirements.

Wrong approach

[cheezedawg]

Good CS school programs have almost nothing to do with specific languages. You need to spend some time learning the discrete mathematics and the fundamentals of languages. When you learn that well, picking up the little quirks of a new language is easy, and you are a more versatile programmer.

I would recommend some courses in compiler design. That will give you a good understanding of grammars, languages, and programming constructs.