Grain Of The Language

Languages are like wood. They have a natural way of working. Some languages have several. But if you try to do, say, OO in VB, or AI in Fortran, or parsing in COBOL (but see below), or reflection in C++, you're going against the grain. The language will suddenly seem weak and full of knots and splinters. Use languages only in ways that they make easy - and if you want to do something else, pick a language that's better for that.

Sometimes you can't switch languages, especially if you've already invested a lot in that language. Say written most of the system in C++ before you realized you need a parser. C/C++ have horrid I/O/parser technologies.

Solution: Know many languages and paradigms. Learn how to emulate them as you need them. Write a regular expression interpreter/parser in C++. Some languages are better than others at emulating different languages, like Scheme to make object-oriented programs. Bonus!

The more languages you know, the more likely you will PickAnOkToolForTheJob.

"How does it go .. real programmers program FORTRAN in any language !!" :)

It should be noted that the ability to emulate other languages in a given host language does not replace the need to understand the host language completely first. It is only through knowledge of the language that one knows when and how to extend it.

Some Java Zealots insist that there's no other way.

Or to all of the emacs zealouts, or VI zealouts, or Unix zealouts, or NT zealouts, or C++ zealouts, or ...

(Is this a typo or are they really combinations of zealots and louts? Having met some, I like the combination idea.)

Since LearningMeansMakingMistakes, the way you find out the GrainOfTheLanguage is by going against the grain. If you are wise, you'll only make that particular mistake once. But maybe you just didn't implement that inference engine properly, and if you used backward chaining instead then FORTRAN would be just fine for AI. Life would be better if we documented what tools are NOT good for, as well as what they are good for. What is Java bad at?

Hard real-time
bare metal programming (device drivers, etc.)

Nit pick

'Parsing in COBOL'

One of the better COBOL's I've used was written in COBOL, by a student, back in the 70's. A straight forward top-down recursive-descent piece of code. However COBOL syntax isn't particularly recursive so the neither was the code! Readable:

PERFORM COMPILE-IDENTIFICATION-DIVISION. PERFORM COMPILE-ENVIRONMENT-DIVISION. ....

The lexer was the tough bit... and coded in assembler.

--DickBotting

What do you do when "the way" sucks. Case in point, perl doesn't do nested arrays. To have an array element be an array you have to do a lot of HocusPocus with "references."

Like the initial statement on the page says, go with the flow. Talk to someone else and see how he solved a similar problem within the restrictions of the language. If perl doesn't do nested arrays, can you solve the problem without nested arrays?