Tips and Tricks When Learning Multiple Languages? 76
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."
Try implementing the same programs in each (Score:5, Informative)
Re:Try implementing the same programs in each (Score:1)
the second year sees C/C++ replacing COBOL... but STILL we have Oberon/F
not to mention Java only starts in the third year...
huh? (Score:4, Insightful)
study, play with the langs and generally learn.
Re:huh? (Score:5, Insightful)
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!
Re:huh? (Score:1)
I presume this is not your first programming class. Provided you have taken Data Structures and basic principles, learning new syntax shouldn't be a serious problem for you.
If you are serious about making this your career I suggest you bite the bullet and "Get Used To It!" In the "real world" you may get a week to come up to speed on a new language. Granted you won't be an expert but nor will you be after taking the classes.
As an undergrad I took every programming language elective there was (including COBOL { there was no
Not meant to be harsh,
Scott
Re:huh? (Score:1)
Re:huh? (Score:1)
While languages themselves are easy to get used to, types of programming need to be taught seperately. (Well, the types that need to be taught. GOTO-spagetti code programming maybe shouldn't be taught.;) ) I'd like to see seperate classes for OO, standard procedure, functional, and even event driven vs. polling and coverage of multi-threading. And I've probably forgotten a few.
Once you've figured all those all concept, you can spend a few hours and grasp the basics of any language.
Re:huh? (Score:1)
Re:huh? (Score:2)
i remember doing two all-nighters in a row and sleeping in bell hall as that guy got arrested for breaking into the vax cluster.
Quick, transfer to another school!!! (Score:3, Insightful)
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!!! (Score:2, Informative)
A good program is spending time on developing a firm foundation for software engineering, regardless of what language is used. You know, modularity, code reusability, supportability--stuff that's taught in Computer Programming 101/102. With a firm foundation, a student can pick up a new language with relative ease. Without a firm foundation, all is lost.
Here's some facts for you, Mr. Dinosaur! (Score:2, Informative)
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.
Re:Here's some facts for you, Mr. Dinosaur! (Score:2)
COBOL proggers are in the dole queue (Score:1, Informative)
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.
Re:Here's some facts for you, Mr. Dinosaur! (Score:1)
My point is COBOL is alive and kicking today and many businesses still use it. Your 242 hits reaffirms that COBOL is not deal. If it were, you'd see 0 hits. To reiterate, if one can apply the concepts learned in the beginning computer science courses, they should be able to learn something and apply that to other languages, with OO being an exception. Of course, I am not advocating that one can stick with just one language either--I did not say that at all. That's where the "Computer Languages" course comes in. This course was a prerequisite when I went to university and I would be surprised if this is not the case today. If employers cannot see that one's grades in school only gives an indication of how trainable that student is, they are missing the whole point.
Re:Here's some facts for you, Mr. Dinosaur! (Score:1)
The orginal poster probably can't up and transfer in the middle of a semester, and thus will want to follow some of the more constructive suggestions that others have made (such as, implement the same programs in COBOL, VB, and C++ and then benchmark them. That'd be a good learning method). But somebody had to point out that it's ludicrous for a school to require COBOL.
If you want to acquire a dead language, I recommend Classical Latin.
Re:Here's some facts for you, Mr. Dinosaur! (Score:2)
If my last COBOL program was not over 7 years ago I'd look for some COBOL gigs.
Re:Here's some facts for you, Mr. Dinosaur! (Score:3, Informative)
The COBOL job market is quite different from the Java job market. Mostly it's people who've been in the industry a long time and communicate through word-of-mouth, the trade press, and a network of recruiters.
Re:Quick, transfer to another school!!! (Score:1, Interesting)
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!!! (Score:3, Informative)
Since the
Yes, it is simple to whip up a poorly written program using VB.net, but if given to someone who knows what they are doing, it is an extremely powerful & flexable language.
Also, like it or not, there are quite a few jobs with
Re:Quick, transfer to another school!!! (Score:1)
And what I was trying to say about VB was that it should be very easy to learn enough to pass an intro-level college course. I think the point of VB is to be easy to learn and use, neh?
But thanks for the
You are certainly right that there are more jobs available for VB jocks than Icon afficianados.
Re:Quick, transfer to another school!!! (Score:2)
Yes, now that they've made it Java, it is indeed just as good as Java. It's a shame that they didn't look at taking a major step beyond Java, though.
But still I'll skip it for now; anybody that takes seven versions just to get a language out of the "sucks majorly" zone isn't somebody I'm going to trust right away.
I would imagine there are a lot more jobs for VB than there are for the languages you listed as should be required (Eiffel, Lisp, Icon).
True, but unrelated to getting an education. Nobody buys CDs of people singing scales, but nonetheless, you gotta sing scales.
Re:Quick, transfer to another school!!! (Score:2)
OTOH, Eiffel and Lisp (I don't know Icon, so I won't comment on it) will teach you new concepts, like DBC and a lot about robustnes resp. functional programming (Lisp could also be used to teach generic or OO programming, but this is rather unpopular in academia for some reason...). VB doesn't have anything other languages don't, and will only show you that a language designed for beginners some decades ago might not be the best choice for all problems.
Re:Quick, transfer to another school!!! (Score:4, Interesting)
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. ;-)
Re:Quick, transfer to another school!!! (Score:1)
Re:Quick, transfer to another school!!! (Score:2)
But a one semester class isn't going to teach you enough to really write large COBOL programs. But what it will give you is a working knowledge of the language that will come in useful when you are tasked with porting the application from COBOL to Java and need to read the current code to understand the logic.
Visual Basic is so trivially easy to master that it hardly requires a college course
It's not quite clear to me you understand what "master" means.
If these are intro classes (Score:2, Interesting)
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??
Re:If these are intro classes (Score:1)
Yes you go to college to learn things. And contrary to a popular believe here on
But you do have a valid point, You won't learn anything unless you get down and dirty with a language.
ALthough your professor may have been a prick for taking off points, it may be a valid thing to take points off of. If s/he had instructions to make the background pink and you put it orange i'd mark you off too. That's not following directions, no matter how trivial it is.
Easy to learn both well. (Score:3, Insightful)
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.)
Re:Easy to learn both well. (Score:1)
I usually find I need to "brush up" a little on a language I have not used in a while, but really even the most obscure languages tend to have a lot in common.
Re:Easy to learn both well. (Score:2)
It's easy to get to the point where you can write working and useful code in a given language if you are a good programmer, but not to the point where your code is elegant.
For a more general take on this, read Teach yourself Programming in Ten Years [norvig.com].
You're in luck. (Score:3, Interesting)
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 [infogoal.com] 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.
Re:You're in luck. (Score:1)
That's 55,000 lines of new code per coder. Pretty aggressive estimate there.
Re:You're in luck. (Score:2)
That's 55,000 lines of new code per coder. Pretty aggressive estimate there.
Well, this is COBOL we're talking about here.
How I learned multiple languages (Score:5, Insightful)
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!
Re:How I learned multiple languages (Score:2)
For instance, perl is a good string manipulation language, as was intended. Why? Because of regexp's and it is a script language. Quick to develop. Learn how to exploit those features.
Ruby and Java are good OOP languages (from my experience), learn how they work, what features are there, why, and how to use them. I didn't say python since I don't know the syntax to say bupkis about it.
Lisp for it's own reasons. It's good for expert systems (I believe).
It overlaps your post, but it forces you to know what tools to use before you use them. So you wouldn't go writing an OS in perl, or a large OO system, since it isn't the most secure of languages in the sense of encapsulation.
-s
Re:How I learned multiple languages (Score:4, Insightful)
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.
Re:How I learned multiple languages (Score:1)
However, this is usually the best way to get through most university classes when they change languages on you. The laziness factor hopefully would kick in, you won't want to write more than you should so learning to take advantage of the language facilities will know how to learn the language effectively.
Re:How I learned multiple languages (Score:2)
I'll agree with you there.
The last guy I interviewed for a programming job was a Perl coder. I asked him if he knew Lisp. He replied that he didn't. I then took out a half-page of Lisp code, and told him to add a particular feature. This wasn't a test to see if he got the answer right; I wanted to see how he handles stressful situations, and how well he can adapt to unusual circumstances. (He was hired, by the way, and is doing great.)
Functional programming for Perl programmers (Score:2)
- 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
Re:How I learned multiple languages (Score:2)
I fully agree. Different languages have different capabilities, advantages, and disadvantages, but the basics (which is all you're going to get in an early CS class anyway) are pretty much universal(1). Once you have one language under your belt, picking up others is pretty easy. And you should have exposure to all the languages you can, so you can pick the right tool for the job!
What else is involved in these classes, though? I certainly hope that they're not just "Learn COBOL" and "Learn VB.net". That'd be a serious waste of time. The courses I had in college (even the freshman year "learn to program" courses) typically had a goal and used the language as a means to achieve it. Like "Numerical Analysis" which happened to be done with FORTRAN at the time. But the language itself wasn't the focus of the class; the focus was on what you could use the language to do.
Way back when, when the giant reptilian mainframes were starting to die and be picked apart by the annoying little mammalian micros, I had two courses the same term: Sperry-Univac 1100 assembly (Whee! 36 bit words! No stack! Whee!) and an intro to microprocessors course that taught 8080 assembly. Oh, and I was playing with 6502 assembly on my own at the same time. There was no cognitive dissonance. If anything, using various different-but-similar languages at once taught me more about programming than just learning a single language would have.
After all, that's what it boils down to. Yes, companies advertise for a "Java programmer" or a "VB programmer" or a "COBOL programmer", but what they really want is a programmer. Damn the language, a real programmer can pick up a new one in a week. I got at least one job on this premise. They wanted a "C programmer", but I didn't know C. I did know Perl, though, and brought some Perl source from a large project to show them that yes, I could program. I also spent a weekend with K&R and banged out a simple "C" program. Hey, I can program and I can learn! I got the job.
Re:How I learned multiple languages (Score:1)
mmmmmaughughguhguh.. ball of fish...mmmmaughguhgmmmm..delicous ball of fish..mmmm
Concepts (Score:5, Insightful)
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.
Re:Concepts (Score:2)
Re:Concepts (Score:1, Funny)
You may be in for a surprise
Hmmmm (Score:2, Insightful)
"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.
Re:Hmmmm (Score:1)
Study hard... (Score:2)
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.
learning how to learn languages.. (Score:1, Insightful)
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.
not that difficult (Score:1)
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!
COBOL.NET (Score:4, Funny)
I saw some scary examples of it in the
Re:COBOL.NET (Score:1)
Fujitsu is making a big push with NetCOBOL for
Spinning knowledge of COBOL together with
Learn a real language prior to VB (Score:2)
Re:Learn a real language prior to VB (Score:1)
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. Please read the whole story before you post.
Make a Comparison Table (Score:3, Insightful)
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.
Re:Make a Comparison Table (Score:2)
At the risk of being flamed for the simplicity of this idea, you might also consider keeping your two sets of class notes in two different colors. Then if you are trying to remember which language uses which kind of loop, you might be able to shut your eyes and try to visualize the page where you wrote it down...
The "Real World" way to do it... (Score:5, Funny)
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 (Score:4, Insightful)
I would recommend some courses in compiler design. That will give you a good understanding of grammars, languages, and programming constructs.
It is trivial or you should drop out (Score:3, Insightful)
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.
An important similarity (Score:3, Informative)
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.
Find another major. (Score:3, Insightful)
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.
separation anxiety? (Score:2)
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.
You that you may not want to ignore COBOL (Score:1)
thinking back to the /day/ I learned COBOL... (Score:2, Insightful)
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...
Re:thinking back to the /day/ I learned COBOL... (Score:1)
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...
Most modern languages do not even have the same powerful features. These are like GOTO, very powerful if you know how to handle them, but easy to misuse if you do not grasp their implications.
I do much programming in Perl, but the way you can layout data structures in COBOL is one of the things that I really miss.
gah, i hate institutionalized education.... (Score:1)
Good practice to be a bad consultant. (Score:2)
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.
In a similar boat (Score:1)
This could be a good thing... (Score:2)
This benefit is dependent on the languages being learned concurrently, of course...