On Apr 28, 10:13=A0am, "Pete Dashwood"
<dashw...@[EMAIL PROTECTED]
> wrote:
> "Richard" <rip...@[EMAIL PROTECTED]
> wrote in message
>
>
news:505bcb44-9b7c-4a26-b662-c3e08f6f24fb@[EMAIL PROTECTED]
>
> > From:
>
>
>http://www.pythonthreads.com/news/latest/python-is-the-truly-object-o...
>
> > I was amused by this:
>
> > """If we take a look at the top 10 programming languages, not much has
> > happened the last five years. Only Python entered the top 10,
> > replacing COBOL. """
>
> > This doesn't =A0actuallysay that 'Python replaced COBOL', only that
> > COBOL dropped off the top 10 list and Python is now on it.
>
> > 4 or 5 years ago =A080% of my programming was still COBOL, now it is
> > about 80% Python.
>
> From a cursory inspection carried out some time ago, I have to say that
> Python looks more viable than Perl.
>
> Some questions, Richard:
>
> 1. Are you undertaking actual application development in Python, as you
> would have in COBOL? (I thought it was more for scripting...for me, that
> would be "gluing" components together, rather than actually building
> components with it.)
Most of what I do in Python is 'middleware'. Though I just did an
order system frontend to a COBOL accounting system. It uses Glade for
the UI and SQLite for the database and runs on Nokia N800 tablets
(pocket sized), ASUS eee, Linux, and Windows with no code changes. To
run stand alone for the reps in the field, who may be out of cell
phone area, it takes extracts from the main system and sends back the
orders that have been taken. It takes up 360Mbyte on the disk, but
most of that is the catalogue images it shows.
> 2. Can you write less of it than an equivalent in COBOL? (Does it save
on
> code lines?)
Everything is less than COBOL. One can do in a few lines what would
take pages in COBOL, or even in C.
I tend to write stuff that is table driven, even in Cobol, but with
Python it tends to be configuration file driven. For example the
config file contains a description of the extract file from the Cobol
system, including a name, type and size, and a list of the fields
required to be stored in the SQLite. The program automatically creates
and updates the tables without any line of code having the name of a
field, it builds the SQL code in flight.
The UI has field names based on the names used in the SQL tables. So I
can take DB rows and cycle through the fields looking for a match to
set the UI. A dozen or two lines will populate an enquirey screen.
Change the screen layout in Glade, no change required in code.
for (name,...) in dbrownames:
if ( window has 'o' + name ):
data =3D dbrow[name]
(type, size, formt, ..) =3D fieldDictionary[name]
if ( type =3D 'X' ):
windowfield.setText(data)
elif (type =3D 'N' ):
format ...
...
Of course it does need to know about price, discount and quantity
stuff, but mostly the program is ignorant about the data fields and
has no reference to them outside the tables and dictionaries created
from the configuration files.
> 3. =A0Do you have a full IDE for it, like Eclipse or VS?
You can use those, but I don't like IDEs, I never found one that
worked the way that _I_ wanted. I use Midnight Commander, Setedit and
make files.
|
