Ah, the software wars. This must be what it's like to have a preference for cars, or sports teams right?

Here are the questions you should ask yourself:
Q1:
Are you willing to pay? For books? For licenses? For tutoring? How much?

Q2:
Is this the only thing you are really going to do? Or do you harbour a hidden desire to discover the true Black Arts(tm) of software?

Q3:
Is there *ANY* chance that you will *EVER* want to make *ANY* changes to this program in the future?

Q4:
How much time do you have to spend on this?

Q5:
What is the targeted platform? Do you want this program to run three years from now?

Q6:
If you wanted to know how to build a car would you ask the guy on the production line how he puts them together?

These are the questions you need to answer, and in that order. The language you pick should reflect that, not some arbitrary choice or preference you picked up from someone here. Like cars, there are a lot of choices which have a lot in common, and a lot of differences.
That's the facts part, now I'll add my *opinion* too:

1+2. I *don't* agree that "if you know one language you know them all", anyone who wants to argue that point should PM me a breadth-first-search method in Miranda and Prolog (or another functional and logic language), at which point DA GAME WILL BE ON!

Speaking from my experiences, it can be very hard for some students to learn the object oriented approach once they have locked themselves into a static mindset. If you are going to do more programming, it will be worth big dividends spending time at the start learning what OO means before you waste time picking any particular OO language.
3. It is harder to *read* code than *write* code, even your own code. Even 6 months later you will find yourself looking at files wondering "why does this call method X again?" And don't even think you can make "one little change" without everything breaking.

That goes double for any 'hacking language'. It is a good idea to plan before you start. Actually plan. Like actual paragraphs of writing. Like on paper. Like with a pen too if you have one.

If you pick up the jigsaw and screwdriver and start cutting randomly what will you get?
5. Remember, most platforms have an active shelf life of about 3 years tops, after which point you don't want to have to re-write everything because you used some Super-Dooper API(tm) to (supposedly) make your life easier. Repeat after me: "INTERNATIONAL STANDARDISATION". And forget about this "fast code" myth, unless you are actually building something for an embedded microprocessor your PC will have plenty of cycles whatever language you pick, so pick for design and maintence, not "speed". I would happily give up 1s every time my OS booted up if it meant it had 1% fewer bugs. Waste your time reading math books if you want to find better algorithms. Occassionaly even I learn something new!

1+6. I know some 3l33t hakerz, and I know some people who write VB scripts to "get the job done", I know people who write tiny little 10,000 line applications and think they are god's gift to programming. No book, no website, no email buddy can compare to actually learning from somebody who knows about actual software engineering. You will be much better off to try to and find someone nearby who has taught problem solving with computers for a half-dozen years and sit down with them and just talk about what you want to get done. Failing that just sneak into the lecture theatre twice a week, lecturers don't get paid enough to care if you're supposed to be there as long as you are quiet.
Lastly, don't be afraid to post your code because you think people will bag you for it. It's a fantastic way to help simplify things and clean up comments that are absolutely useless. And after all, lucindrea here even admitted they still program in Assembly! That's like, y'know, what Babbage programmed in!
