A r t i c l e s
Someone wrote an interesting post about Python (quoted from below URL)
"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
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
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
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!
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."
Please note, that sucks pages can seem negative at times. Please consider that although sucks pages may be negative or aggressive in style, they do point out important considerations.
See also: PERL SUCKS, PASCAL SUCKS, TCL SUCKS, JAVA SUCKS.
Note: This Wiki is outdated, personal views may have changed.
This wiki contains info on life, health, humans, nature, programming, database, fads, paradigms, poems, principles, theories.
Articles may contain statements which some may find helpful and encouraging, or even discouraging.
Beware, I believe in the Grand Justice system.