Great responses, I agree the easiest language to use is the one you are presently using.
While learning your fist language may be harder in the sence of a learning curve, it is often the funnist, and if you are enjoying learning something then there is no amount of complexity you are not willing to endure, as long as it stays fun. You also form preconceptions during this time. You naturally assume things happen this way or that and thats what really hurts people later as thy try to equate new ways of doing things with the ones they know. Example: Many BASIC programmers find C's string manipulations lacking, but in reality its far more versitile than most BASICs at that very thing. While PERL is arguably the best for manipulating strings( a task it was designed to do), many BASIC programmers find it far to complex. This is not that BASIC coders are stupid, they are simply used to the BASIC way of things. Thats the comfort some talk about.
Chatty - Don't let JAVASCRIPT throw you, its not JAVA, not even really all that close now days. If your school is using JACASCRIPT ( a goofed up language that barowed the name JAVA just as a marketing ploy and was, I beleive, created by NETSCAPE) to prepare you for real JAVA programming then I would think about going to another school. There is nothing in JAVASCRIPT that makes leaning JAVA any easier. However, it is a OOP language, so perhaps that is the goal. Still there are far better OOP languages they could have chosen than JAVASCRIPT, many of witch are far more OOP in nature. Perhaps PYTHON or some such.
For me, my favorite language and easiest to use at the time was TURBO C back in the mid 80s. I had learned BASIC as my first language but had been coding in ASM in 6502/6510/Z80/Z8000/TI9900/6800/68000/8080/8088 for so long that I had basicly been cleansed of the hole BASIC way of things, and C was sort of a natural step up from ASM. What made TURBO C my favorite was it was the first IDE I got to use, no more EDIT for coding and DUMP tools for debugging. :)
I sometimes forget how much fun, all be it almost equally frustrting, it was to code in those minimalistic systems where 64K was the cats meow. Now days good code is anything that runs, back then it had to run in less memory than it was possible to put it in. :)
To me, the Atari ST was a fantasic machine, I started with the TI 99/4A and a EAGLE CPM machine. Later got a C64 then a Atari ST, created my first net(over serial) capable game on the ST that used a server based in PBBS ( over dialup modems ) that was a text based galactic game(think old text based Star Treck sim, multiplayer) witch could handle upto 32 people at once, provided the BBS supported that many connections. When I got my first PC in 85, I quickly realized that the other consoles were soon to be dead ends and pretty much stuck to the PC. Hard choice when you went from 256 colors to 16 colors.
Now here we are 20 years later, the languages for me are BASIC and JAVA, I have seen no reason to code in C++ short of meeting requirments by a few customers. My language set is insane now, having to know everything from PERL to ASM to JAVA and be able to work profesionaly in them. Still I stick to Basic and JAVA as much as possible. My beleif is that BASIC, while full of ways to poorly right good code is a very fast language to get something up and running in. While JAVA is far more suited to making something stable, plenty fast enough and easily extended( witch is handy when having to deal with customer feature changes and add ons).
I do have some of advise for any language you may choose to use( 7 golden rules ):
1) Use Functions, Procedures, Subroutines or whatever your chosen language provides you to break up your code into managable chunks aka modules.
2) Always take the extra time to do it right the first time. Don't race to a new function becuase you just got this great idea, simply stop codeing, put the idea in a text document and go back to what you were doing. This has the benifit of later letting you look at the idea before spending hours coding it to see if its really such a good idea, or could be done better some other way. You may even need to get up and do something else after putting this to paper so you can get back on track with what you were doing.
3) Always try to define variables ahead of time, in some languages this is a must anyway (C, JAVA, etc) but in most basics its not. I know many BASIC fans think this is a lot of nonsence, but a simple misstyped variable name, or cryptic ones with no comments make debugging a real nightmare in any project of size.
4) Always be aware of the SCOPE of a variable as you define it. Don't just make everthing GLOBAL. Again this can be a real debugging nightmare when you use the same vaiable name in some function 2000 lines later.
5) Never be affraid to ask for help, not even on the easy things. No matter how many years you have been coding you will never know it all. Even though some of us think we do. :)
6) Related to 4, always thank those who help you. It goes along way to getting more help later, especially on those really complex problems, you know like doing reflections with 3 light sources in a simulated fog with lens flair.
7) I also save the most important for last, COMMENT YOUR CODE! I don't care if its a 10 line loop test or what, no comments will kill any project faster than any amount of complexity. The more people who work on the code, the more important the comments become. I tend to go overboard with mine, as I usually include everything from variable and function description to whole sections on why I do what I do and what ideas pop into my head to do it another way. While I like this, some think it breaks up the code too much sometimes. However, having no comments can make the best code nearly impossible to reuse, even by its own creator.
Ok Im sure there are more than 7, but these seem to be the most overlooked in my experiance. :)
While learning your fist language may be harder in the sence of a learning curve, it is often the funnist, and if you are enjoying learning something then there is no amount of complexity you are not willing to endure, as long as it stays fun. You also form preconceptions during this time. You naturally assume things happen this way or that and thats what really hurts people later as thy try to equate new ways of doing things with the ones they know. Example: Many BASIC programmers find C's string manipulations lacking, but in reality its far more versitile than most BASICs at that very thing. While PERL is arguably the best for manipulating strings( a task it was designed to do), many BASIC programmers find it far to complex. This is not that BASIC coders are stupid, they are simply used to the BASIC way of things. Thats the comfort some talk about.
Chatty - Don't let JAVASCRIPT throw you, its not JAVA, not even really all that close now days. If your school is using JACASCRIPT ( a goofed up language that barowed the name JAVA just as a marketing ploy and was, I beleive, created by NETSCAPE) to prepare you for real JAVA programming then I would think about going to another school. There is nothing in JAVASCRIPT that makes leaning JAVA any easier. However, it is a OOP language, so perhaps that is the goal. Still there are far better OOP languages they could have chosen than JAVASCRIPT, many of witch are far more OOP in nature. Perhaps PYTHON or some such.
For me, my favorite language and easiest to use at the time was TURBO C back in the mid 80s. I had learned BASIC as my first language but had been coding in ASM in 6502/6510/Z80/Z8000/TI9900/6800/68000/8080/8088 for so long that I had basicly been cleansed of the hole BASIC way of things, and C was sort of a natural step up from ASM. What made TURBO C my favorite was it was the first IDE I got to use, no more EDIT for coding and DUMP tools for debugging. :)
I sometimes forget how much fun, all be it almost equally frustrting, it was to code in those minimalistic systems where 64K was the cats meow. Now days good code is anything that runs, back then it had to run in less memory than it was possible to put it in. :)
To me, the Atari ST was a fantasic machine, I started with the TI 99/4A and a EAGLE CPM machine. Later got a C64 then a Atari ST, created my first net(over serial) capable game on the ST that used a server based in PBBS ( over dialup modems ) that was a text based galactic game(think old text based Star Treck sim, multiplayer) witch could handle upto 32 people at once, provided the BBS supported that many connections. When I got my first PC in 85, I quickly realized that the other consoles were soon to be dead ends and pretty much stuck to the PC. Hard choice when you went from 256 colors to 16 colors.
Now here we are 20 years later, the languages for me are BASIC and JAVA, I have seen no reason to code in C++ short of meeting requirments by a few customers. My language set is insane now, having to know everything from PERL to ASM to JAVA and be able to work profesionaly in them. Still I stick to Basic and JAVA as much as possible. My beleif is that BASIC, while full of ways to poorly right good code is a very fast language to get something up and running in. While JAVA is far more suited to making something stable, plenty fast enough and easily extended( witch is handy when having to deal with customer feature changes and add ons).
I do have some of advise for any language you may choose to use( 7 golden rules ):
1) Use Functions, Procedures, Subroutines or whatever your chosen language provides you to break up your code into managable chunks aka modules.
2) Always take the extra time to do it right the first time. Don't race to a new function becuase you just got this great idea, simply stop codeing, put the idea in a text document and go back to what you were doing. This has the benifit of later letting you look at the idea before spending hours coding it to see if its really such a good idea, or could be done better some other way. You may even need to get up and do something else after putting this to paper so you can get back on track with what you were doing.
3) Always try to define variables ahead of time, in some languages this is a must anyway (C, JAVA, etc) but in most basics its not. I know many BASIC fans think this is a lot of nonsence, but a simple misstyped variable name, or cryptic ones with no comments make debugging a real nightmare in any project of size.
4) Always be aware of the SCOPE of a variable as you define it. Don't just make everthing GLOBAL. Again this can be a real debugging nightmare when you use the same vaiable name in some function 2000 lines later.
5) Never be affraid to ask for help, not even on the easy things. No matter how many years you have been coding you will never know it all. Even though some of us think we do. :)
6) Related to 4, always thank those who help you. It goes along way to getting more help later, especially on those really complex problems, you know like doing reflections with 3 light sources in a simulated fog with lens flair.
7) I also save the most important for last, COMMENT YOUR CODE! I don't care if its a 10 line loop test or what, no comments will kill any project faster than any amount of complexity. The more people who work on the code, the more important the comments become. I tend to go overboard with mine, as I usually include everything from variable and function description to whole sections on why I do what I do and what ideas pop into my head to do it another way. While I like this, some think it breaks up the code too much sometimes. However, having no comments can make the best code nearly impossible to reuse, even by its own creator.
Ok Im sure there are more than 7, but these seem to be the most overlooked in my experiance. :)