Python is like COBOL! was: Re: Getting Python Accepted in my Organisation

[Magnus Lycka]

Steve Holden wrote:
>> To put things into perspective, it's important to get beyond the very
>> broad categories of programming languages. It's pointless to judge
>> Python on the merits of Perl or AWK, just because a certain label is
>> sometimes applied to all three. That would be like saying that Java
>> is more or less like COBOL. (OO COBOL?)
>>
> Quite. People have said exactly that, you know ;-)

Anyone else besides you? ;^)

Seriously, it really depends on what aspects of Java and COBOL
you compare. As you noted, COBOL is better in some ways...

>   http://www.artima.com/weblogs/viewpost.jsp?thread=42242

Well, I've never coded a lot in either language, but I've worked
fairly intimately with COBOL and Java developers in some projects,
and my exposure to COBOL made me understand a lot about the bugs
that haunt mainframe systems. (I actually wrote a Python program
that generated COBOL and JCL for database export/import.)

It's one thing that it's so verbose: We had one architect who
wrote enough pseudo code and SQL statements to keep around 10
COBOL coders fully occupied (and we still had a team with as
many testers as coders, so it wasn't that the coders spent
half their time testing).

Still, the really distinguishing factor I saw in COBOL on
mainframes wasn't bloat, but this completely static world
view.

For other programmers, COBOL programmers appear as inhabitants
in flatland, who haven't discovered that there is actually a
third dimension. They still view memory as a punch card. They
constantly run into things like: "We didn't think anyone could
possibly have more than 20 employments during a month, and it
turns out that his whole category has, but we've upped it to 30,
and that seems to work so far." As a non-COBOList, the natural
response is obviously to write code that works with any number
of employments, and doesn't allocate the same amount of memory
for those with one employment as for those with 25. In COBOL
this seems to be prohibitly complex in many cases. Heck, they
even determine the full size of files when they create them. We
had some special (probably very expensive) software system that
allowed us to dynamically allocate new space to files as data
was added, but that was considered black magic, that only a few
wizards understood.

 From this perspective, Java is much closer to Python than to COBOL.
Still, Python is more dynamic than Java. I'd say that going from
Java to Python is similar to going from COBOL to Java. Maybe scary
at first, but an eye-opener that makes you feel more powerful. A
bit like a journey to a foreign continent. I do think the step
from COBOL to Java is bigger then the step from Java to Python though.

In one way, COBOL and Python are the similar languages, and Java is
the odd one: While COBOL is archaic, and appears retarded for
modern programmers, it's easy to learn--at least if you haven't
programmed before... It was designed to be easy for non-programmers
to use. Python is a great newbie language. Java has tried to avoid
a lot of the traps of C/C++, but it's still much more difficult
to get started there, than with Python or COBOL.

COBOL has been very successful. It's still used a lot today, after
all these decades, and while it lacks a lot of the abstractions in
modern languages, it has for instance numeric types that don't give
the kinds of surprises that floats do.

While the perfect modern successor to COBOL would probably have some
features that are lacking in Python 2.x, I think we're pretty close.
With datetime and decimal, we have the fundamental types that were
missing before. OO is available but not forced upon us. The initial
threshold to become productive is low, but we won't hit the ceiling
as we evolve. Sure, there isn't full standardized support for all
things we need, such as message queueing systems or distributed
transactions, but that's not too hard to fix. There are C APIs...