Slashdot Mirror
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."
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.
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.
US Citizen living abroad? Register to vote!
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.
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??
I've had enough abrasive sigs. Kittens are cute and fuzzy.
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.)
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.
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.
Most languages tend to have 3 basic building blocks:
... then) ...)
1) Assignment (a = 1)
2) Conditional (if
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!
Archie - CIO-for-hire
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.
The GeekNights podcast is going strong. Listen!
I went to www.jobsearch.com (which is a website I have NEVER visited before, AFAIK, I just figured the name would work and it did) and did some simple searches in their "help wanted" database.
COBOL -- 242 hits
JAVA -- 1183 hits
" c program" -- 1740 hits
So, COBOL's obviously the language to choose for a healthy career, right? It's DEAD, Jim. The only companies that use it will make you sit in a room with no windows and wear a tie. C'mon, you know it's true.
Incidentally, I agree with almost everything else you said. But don't take it personally.
If you were one of my advisees, I would substitute something more useful for the COBOL class.
"Due to early registrations scooping up most of the good electives at my school..."
Maybe instead of worrying about programming languages, you should use an elective to learn about effective time management. Knowledge of all the programming languages in the world will not keep you in a job if you can't get to work on time and think ahead about projects.
Basing any career decision (or business decision, for that matter) on a Gartner Group proclamation is pretty foolish.
It's sort of like trusting a used car salesman to pick out a car for you that he'll make the least commission on.
I've worked in engineering, manufacturing, defense, academia, and finance, and I've been programming computers for 30 years. COBOL is a dead end, and most of my old pals that thought otherwise are now jobless in the Bush Miracle Economy.
Learning two languages (natural or artificial) at the same time can be tricky. You have a few things going for you though, including that COBOL and VB.NET are pretty different languages, especially considering the specific features and library aspects which will be stressed in each of the classes. VB.NET will likely be app development, basic OOP, .NET library, GUI building; and COBOL likely text-interfaces, business forms, financial processing. Two relatively different problem domains.
In general, if you don't take to a learning languages well (e.g., you're not a big lang nerd!), the best thing is to study a lot. Write a lot of example code. Don't skimp on reading. The more you learn, and the firmer it is learned the better you'll be able to seperate the knowledge between languages and be able to apply it better.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
This is sort of echoing many of the other comments here, but my personal experience:
I had some compulsory courses in a variety of odd languages when I was at college, and originally thought it was a total waste of time. I mean, Modula-2, Poplog (Pop-11), 68k assember and a bunch of others so obsure I don't remember the name. They're ancient! I was itching to get onto the C/C++ stuff so I could start some "real" programming.
It was only afterwards that I realised the extent of the knowledge and skills that had been subconciously implanted into me - among them the ability to pick up a new language and learn it quickly. When it came to learning C++ - it was a snap.
My job requires use of C++. However, if I hadn't been in the mindset of exploring other languages, I would never have learned (on my own time) Python, Lua and x86 assember. They're more suited than C++ for many tasks, and have used them both in my work (for auxillary tasks) and my hobbies.
There's never a danger of knowing too many languages.
Most CS majors have done this at one time or another. Last term I learned LISP, PROLOG, Matlab programming and assembler for a digital project. At the same time I was doing a course in C/C++ and teaching a Java Programming Seminar/Lab.
.NET material, but if you know your basic C++, then you shouldn't really have any problems. If you know Java, then all the better, because some of the Java techniques/principles can be applied to the C# aspect of .NET.
The most important thing I can suggest is lots of review as often as possible. Someone above suggested implementing the programs from one language in the other languages you are learning. That's a pretty good suggestion, but I'd suggest a slight modification:
Implement the basic techniques of each language in the other language(s). Things like making/assigning variables, looping, file access, etc.
I don't know a lot about the Visual Basic
Good Luck!
Very true. Unfortunately for COBOL programmers, it hasn't been working out that way lately.
All my C programmer friends are employed. Some of my VB-and-similar programmer friends are employed. Very few of my COBOL programmer friends are employed, and every one of them that is employed is working for a bank, and all those banks are trying very hard to eliminate their dependency on COBOL.
COBOL has been steadily dying since the 1980s - it is entrenched in some businesses, but it isn't getting new footholds at the rate it is losing them.
My company replaced half a million lines of COBOL with about 5000 lines of GNU Awk, which is OS independent (COBOL claims to be OS independent, but most real life COBOL shops are dependent on CICS, which has no fully functional ports to any cheap non-IBM platforms).
The Gawk code runs more than ten times faster on a cheaper, less powerful machine. The programmers who coded it learned the language from scratch in two weeks and did the implementation in six months.
No-brainer, people. COBOL is an interesting but obsolete language.
With .NET it doesn't matter what language you use, so in this case the obvious thing to do is to learn COBOL.NET.
.NET seminars.
I saw some scary examples of it in the
I would say learn a real programming language before you learn Visual BASIC, as VB is a good language to ruin you for other languages. It is bloated and keeps you well away from the machine. Learn how to program properly before you touch VB.
Make a comparison table between both languages, listing similarities and differences, and features which exist only in one or the other language. This way, when you think about both languages in terms of differences, you are less likely to mix them up, but at the same time, best leverage similarities in your learning.
Trying to create a good structure for that table is probable alone going to give you some insights into the structure of programming languages!
When you're done, be nice and put your table up somewhere on the web, might be helpful for anyone coming from COBOL wanting to learn VB or the other way round. One never knows.
Stupidity is mis-underestimated.
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.
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.
"The defense of freedom requires the advance of freedom" - George W Bush
Learning programing languages is trivial to a programer. Learning how to use any on to the best advantage can take years, but all you do in those years is memorise more and more library/template procedures and the gotchas of useing them. If you cannot learn both well enough to fool the teacher, then you should not be in CS.
When I took CS the only language course that was required tought 12 langugaes in 10 weeks. It wasn't a big deal, we learned the syntax, and how to do some simple things (a binary tree or simlear) and moved on. Of course we were just told what the "standard library" was called, and told if we really used the language to look it up, because it will save a lot of time.
Come to think of it, other than the one class that covered 12 languages, we wre simply told in class to submit assignments in such and such a language, and if we didn't know it (and the introduction class was tought in Scheme in large part because it was likely we didn't know it!) we were expected to pick it up on our own. In this was I knew 3 of the 12 languages tought in the languages class when I could finially get into it.
In the course description of Cobol there was a warning "CS student may not take Cobol for credit". The same line was in the description of Fortran and C. A CS student should pick up anything that a class on a language can teach on their own. A CS student is expect to spend their time learning data structers, algorithms, and other things that make the different between someone who can bang out a little ugly code when needed, and someone who can take requirement and turn out a maintanable program in as few line as possible.
Both Cobol and VB are a response to a business advanced by the major programming language firm of the time.
In the early 1950s IBM pushed Fortran as a replacement for assembly arguing (succesfully) that it allowed for a large increase in programmer productivity without much loss of system performance. Fortran however was too "computer oriented" and many programmers with a strong business background found it difficult to express business ideas in terms of fortran succesfully. So an alternate language called COBOL was created which allowed for a better expression of business concpts at the cost of both performance and abstracting the details of how the machine was opperating.
In the early 1990s Microsoft pushed visual development in C++ (visual C++) as a replacement for standard C arguing (succesfully) that it allowed for a large increase in programmer productivity without much loss of system performance. VisC++ however was too "computer oriented" and many programmers with a strong business background found it difficult to express business ideas in terms of fortran succesfully. So an alternate language called Visual Basic was created which allowed for a better expression of business concpts at the cost of both performance and abstracting the details of how the machine was opperating.
So obviously the important thing to do since you understand C++ (and Fortran takes a day to learn) is to look at these languages as a reaction to the dominant languages of their day. Understanding what they were reacting too.
Perly things that may help Perl people in functional programming (or at least that help me) are:
- Perl's map, grep and global match/substitution functions
- Anonymous subroutines with lexical scoping (ie Scheme closures), and lexical scoping with my in general
- eval
- the distinction between lists and scalars
- foreach
I'm sure other people with less Shiraz inside them can think of other functional language constructs in Perl
Judging from your comment about how Visual Basic is the only useful elective left, that leads me to think this is your senior year. If you're an upperclassman and you're having trouble with COBOL and Visual Basic, find another major.
COBOL and Visual Basic are both pretty simple imperative languages--the simplest form of language to understand. (Yes, VB has objects nowadays, but it's usually used in a mostly-imperative fashion.) Not only that, but you already know C++, which supports both imperative and object-oriented programming.
It's not like you're suddenly dropped into an AI course and you have to learn LISP and PROLOG both; it's not like you've been thrown a copy of Ullman's Elements of ML Programming and told you have a test on OCaml in a week. These languages all make you think about problems in a totally new way, and that can take a significant investment of time. But learning imperative languages when you already understand imperative programming should not be difficult. You're not learning anything new; you're just learning a new vocabulary and grammar to express things you already know.
If it'll give you any problems, you should give very serious thought to whether or not you want to make computer science your career. It sounds as if you possess neither inclination nor motivation, and you will probably be a much happier person if you can find a field for which you possess both inclination and motivation.
I'm not a CS person, although I have taken a little programming.
I studied C++ the way I studied other languages (German, Italian, organic chemistry, art history): Make a conscious note to yourself at the start of your programming that "I'm now working on COBAL," and do your COBAL stuff. Then, take a half-hour break and do something completely different (dinner, drawing, skydiving). When you come back to your desk again, say, "Now, I'm working on Visual Basic," and do the next set of stuff.
To quiz yourself, translate stuff from one to the other, find which works better, see if it gives you ideas for the original (don't do this until you're done with the assignment!
This sounds really stupid and self-evident, but I found that it works.
"Two things are infinite: the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein
There are a lot of manufacturing and transporation companies that use COBOL and RPG and I'm pretty certain the Army still has a lot of RPG in some places... you may not like the idea of a job maintaining or porting code; but it could be an easy six-figure salary like many mainframe and VMS jobs [look at Geekfinder; they ARE out there] can be. I know that the IRS has a hard time finding certain older and more obscure systems knowledge though that kind of contract work can be risky - their favorite phrase is "knowledge transfer" in the job description.
I think with the interesting people, their lives can't possibly be wrapped up into a nice little package.
Generally I don't go for the "one upmanship" stuff of how fast I learned this or that, but in this case I make an exception because when I finished lunch I specifically remember thinking to myself, "OK, I've just skimmed through the book and I'm fairly certain I already know the concepts that will be presented during this semester." This was in the early 80's, I think my second semester in "college", and I had a pretty solid understanding of BASIC, a non-trivial amount of (z80) assembler, and a dabbling of "other languages" [APL, fortran, etc.]
I had picked up the required book from the school's bookstore, went to lunch at the aforementioned BK, and started looking through the chapters. It didn't take long to realize that some things were simply renamed terms (table == array) and other things were "syntactic sugar" ("accept" vs. "input") At first, the amount of "preamble" seemed a bit daunting, but in practice that's when I found out how to effectively use a "mainframe" style line editor... :)
One of the BEST things I think I've learned from COBOL is the underlying format of data in a "structure" -- don't underestimate the power of "redefines" or a level 88 variable! Investigate these to learn their "counterparts" in other languages...
this all depends on your own mind. COBOL isn't that hard of a language (at least it wasn't for me).... i learned it in my spare time from my father, actuall... and at the time, i was also self-teaching myself XML from a few books. i can't say too much to help you though, because most of my tips would only help in a non-institutionalized learning atmosphere. tests and grades ruin education:\
The best way to learn these is to go to the class once a week or less just to find out about assignments, and learn the entire thing from a book.
That's what you are going to be doing when you graduate, after all...
But more seriously...
Don't worry about getting the two confused - it just doesn't happen; the brain doesn't work that way. The biggest trick is to learn a concept and immediately use it in a sample program.
Keep these snippets of code for your real projects. You'll be using most of them.
Don't forget to have at least an extra book available to get a second opinion.
Finally, don't panic. It really isn't too bad.
I have started a CS degree through Unisa in South Africa and I have to learn 3 languages this year. for Intro to programing 1 I have Pascal. Intro to programing 2 is C++ and Intro to visual programing is Dephi. Unfortunatly the compilers/dev tools used in the books are all winblows based, meening I now have to duel boot between windows and linux. Apparently next year they wil be using C++ for Intro to programing 1 but that dosn't help me. I can see I am going to be very confused by the end of the year trying to ad these 3 new languages to the languages I already know(basic, perl, php). I guess there is no chance of me kicking my caffine addiction this year.:-)
I think learning two languages at the same time can actually be better than learning them separately. My university taught C in its Intro to Programming course for Freshmen and assembly language in its Computer Organization course for Sophomores. I transferred into CS as a Sophomore, so I had to take them concurrently. At first, I was worried about mixing them up, but then I found that I was actually getting a better appreciation for how programming languages worked. It was very eye opening to learn a construct in C, like loops or conditionals, and then learn how they are implemented in assembly the next week. I feel that I had an advantage by learning the "innards" of C at the same time I was learning the syntax.
This benefit is dependent on the languages being learned concurrently, of course...
When violence rules the world outside / And the headlines make me want to cry / It's not the time to just keep quiet