"After looking at Python I believe that COBOL will make it big again,
especially if they keep on calling it Object Oriented COBOL, and
force you to interpret, not compile it.

Let me say that I always recommend interpreted languages to prospective software 
developers.

One big advantage of such languages is, of course, that if you (or your customer) 
runs into a problem you/he will do so at runtime, which may be quite a while after 
you have sold your code (and cashed the check).

Also, since your application will be about ten- to a hundredfold slower than a 
compiled version, you may profitably hook up with a friend selling the newest and 
fastest 128-bit hardware with more than 16GB of RAM or so, so that your customer will 
actually be able to run your 'application' with tolerable performance.

At times it will still feel slow though, since the average interpreter has the habit 
of allowing your app to eat up all of that memory, at which point it will get an out 
of memory hint and will a process called garbage collecting, which will take
about a minute or two for 16GB.

Other advantage is that even if you write a proggie that is about five lines you can 
convince the customer you've done major software engineering by installing the 
colossal interpreter, 'optimized' to do all things from serving secure HTTP pages 
through 3D graphics processing and UI functionality to scientific SIMD calculations.
To do all of this it also comes with about half a terabyte of semi-documented 
'libraries'without which your program will utterly fail irrespective of its 
requirements, and do so with incomprehensible error messages that are fully out of 
your control.

If you make sure that your customer gets face-to-face with these messages a number of 
times early on in the lifecycle it may even land you a support contract. Thus all of 
this should be considered beneficial to the engineer.

But perhaps the best part of an interpreted language is that if your customer notices 
your app's lousy performance you can always blame it on the interpreter. In fact you 
can probably blame the stupidest of your programming errors on the interpreter. And 
then the real fun starts. You mutter "yes but PERLTHON 98.3 is now out, and it is 
free". Your customer will be fascinated. 

Not for long because he will be forced to fork over a whole lot more money on you 
rewriting your application after he accidentally agrees to upgrade his system to this 
'new, better' interpreter. This without you having to add any new functionality 
whatsoever! Rewriting each time some unknown, outside force decides to release a
new 'sorta backwards compatible' interpreter is yet another bigtime advantage of the 
interpreted language to the software engineer in search of cash.

If you haven't screwed up too badly earlier on in the product cycle (ALWAYS blame 
'the interpreter', never yourself!) you can really make big bucks during this stage.

Readability, intelligibility and maintainability are key words for any sofware 
project. The three words conspire to keep a sofware engineer out of a higly paid and 
irreplacable position.  This brings me to free-form languages. They are known to allow 
you to create programs that are virtually meaningless to anybody but yourself - if 
you have a photographic memory - and should considered as prime choices for any 
engineer trying to secure future employment. Some may construe this to mean that I 
prefer PERL over Python. While I do agree that PERL has a plethora of built-in 
features to allow even unskilled engineers to craft absolutely unreadable code, I see 
no reason why you could not create similarly unreadable code with Python! My advise 
to you is: apply yourself, be creative and you may be surpised.
Remember that the Python code may well be slower, too!

For big projects with many tens of thousands of lines of code only the best 
structured object-oriented languages will lead to a manageable project. Thus, for 
such projects Python or PERL are both excellent candidates to maximize cost and 
man-power required.

Allow me to introduce yet another option though. You may have heard of COBOL. Back in 
the sixties I did some punchcard programming and was forced to look at COBOL. I was 
not impressed at the time. You could create a working program with just a dozen 
punchcards. However time has passed.

We are 2005 today. We can now have all the disadvantages of COBOL without any of the 
benefits. Try interpreted COBOL. You will fill half a moderate-sized harddisk with 
just the libraries. With COBOL, as with Python, you can enter keystrokes as fast as
you can type them - just make sure that you are not forced to debug them. 
Alternatively, an arcane sequence of rarely executed if-then-else statements will 
allow you to get away with an almost limitless quantity of erroneous code, an 
especially attractive characteristic for those paid by lines of code written.

THE great advantage of COBOL is that is a brand name. Your client will have heard of 
it. Just like Coca Cola, it may have a bad taste but it rings a bell. Quite unlike 
Python which sounds as if it could strangle, or at least bite, a prospective client 
later on during the product lifecyle. Just ask your client, I suggest COBOL for this, 
but if would you rather have me implement this in PYTHON... Ten-to one he will agree 
to let you do it in COBOL. 

The kicker here is that some engineer here or there might still be interested to look 
into Perl or Forth or LISP or Python, but there ain't a soul in the world looking 
forward to doing some COBOL. Meaning that you will be quite sure of prolonged 
employment if you convince somebody to implement anything critical in COBOL.

Ask for very little money up-front. Your customer is bound to come back to you. Do it 
in interpreted COBOL and your pay will go through the roof!

Conclusion.

I applaud Eric Raymond on his article. When it comes to writing interpreted and 
unmaintainable code, Python like PERL has lot going for it. Now with Python we have 
the choice. But when it comes to get money off of prospective customers I think you 
will soon realize the value of Brand Names! IMHO Object Oriented Interpreted COBOL is 
the way forward."