[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: COBOL compiler



On Fri, 2003-08-29 at 17:13, Bijan Soleymani wrote:
> On Tue, Aug 26, 2003 at 04:35:04PM -0800, Britton wrote:
> > 
> > On Tue, 26 Aug 2003, Bijan Soleymani wrote:
> > 
> > > On Tue, Aug 26, 2003 at 11:25:55AM -0500, Ron Johnson wrote:
> > > > Some time after I left the COBOL job, I was employed writing C
> > > > in an app that screamed for COBOL.  I'd say that 1/5th of the
> > > > SLOCs, and most of the bugs, were of the form:
> > > >
> > > >   strncpy(really_long_variable, another_long_variable,
> > > >           sizeof(another_long_variable));
> > > >
> > > > By commercial, I meant record-oriented "data processing" type
> > > > software, not programs sold in stores and catalogs or by sales
> > > > people.
> > >
> > > I find that Perl is a very nice language that avoids such low-level
> > > problems. There's a whole family of such scripting languages that begin
> > > with the letter P. Perl, Python, Php, Pike,...
> > >
> > > The advantage here is that the main (only?) implementation of each of
> > > these languages is an excellent free software implimentation designed
> > > for Linux/Unix and ported to every imaginable OS (from VMS to Windows to
> > > Plan 9).
> > >
> > > Other advantages include the fact that these languages are general
> > > purpose and can pretty much handle all kinds of problems. And also the
> > > fact that they are easily extensible through C.
> > 
> > This just isn't true.  Perl at least is brought to its knees by a variety
> > of problems that C has no trouble with whatsoever.  I've had simple
> > pixel-crawling image processing algorithms take a day to run in Perl, when
> > I rewrote in C about 30 seconds.  And that's with PDL (admittedly PDL call
> > overhead was I think the major thing slowing perl down, but that's hardly
> > reassuring).  The scripting languages just aren't anywhere near as fast as
> > the older, simpler, compiled ones.  Its not that I don't still write first
> > drafts of many codes in perl, its just that now I budget time to rewrite
> > them in C if I need to (its still usually faster overall to prototype
> > first in perl, even if you know you are doomed speed-wise).  I don't know
> > if perl and cobol have the same relationship, or if there are common
> > business tasks that still need the speed, but it seems like a definite
> > possibility.
> 
> Please note that he was complaining about bugs caused by low-level
> string copying in C. Look at his example with strncopy() above. Perl
> (and other scripting languages) don't have this type of problem at all.
> Image processing and handling textual records are two completely
> different problems. I wouldn't recommend perl for processing images, and
> I wouldn't recommend C for dealing with textual strings.

Absolutely.  And guess what?  DP/MIS apps have lots of strings (names,
addresses, descriptions, etc) and numeric calculations where floats
are *not* acceptable...

-- 
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA

"Fair is where you take your cows to be judged."
Unknown



Reply to: