Like DoomDr said --> "You can always learn."<br>
<br>
Keep in mind that you should always be in "learn mode". I've got a friend who has absolutely no interest in learning anything but COBOL, DB2, etc. He'll always have a job, but they won't be the most interesting ones. He's a nine-to-fiver, and always will be.<br>
<br>
You'll probably run across some language zealots sooner or later (probably sooner). Just remember that each language has it's place. If the language has been around for more than 5 years, then there's likely a niche that it fills. I wouldn't think of programming reports in assembly, nor would I program an OS with RPG.<br>
<br>
Something else to remember is that 75% of all programming problems are actually people problems. A friend of a friend was hired to automate a certain county's welfare office (names changed to protect the innocent). After looking over the design, he discovered there were no primary keys defined for the "person" and "address" database tables. A quick SQL query revealed one address as getting some 80 welfare checks each month. It turns out that a lot of the welfare recipients give false names and addresses, so there was no point in indexing on them. Likewise with using some unique ID number to identify the recipients -- the 'customers' would just make something up, so there was no point to it. But the federal regulations tied to various grants from Washington <i>required</i> a name and address! So, the information in the tables was worthless, but you had to have it anyway. In a situation like this, you shrug your shoulders, and just do what the customer wants.<br>
<br>
Chip H.<br>
<br>