Darren New <dne### [at] sanrrcom> wrote:
> nemesis wrote:
> > Warp <war### [at] tagpovrayorg> wrote:
> >> nemesis <nam### [at] gmailcom> wrote:
> >>> 70-80%?  I thought COBOL was pretty much dead after SQL.
> >>   Is SQL even Turing-complete?
> >
> > No.  But my point is that COBOL was the language to write your business in when
> > there was:
> > 1) no standard databases
>
> You got it backwards, actually. The CODASYL database standard is what led to
> needing a business language to access databases, a la COBOL. SQL replaced
> CODASYL only some 10-15 years later (depending on how you define "replaced").

I vaguely remember about mentions to CODASYL.

> > 2) no easier language
>
> No business-oriented language that was easier, yes. There was basically
> assembler, fortran, cobol, LISP, maybe APL and/or BASIC. COBOL's definitely
> the best of the bunch for business/database apps.

I'd say Assembler and Fortran would be ruled out for business purposes right
away.  LISP was too imature at the time (60s) and was a hog meant for research
on AI and language design.  APL I don't really know, but BASIC is just that,
basic.  So, yeah, right language for the job, *back then*.

> > Even Perl+SQL database via DBI offer a far more robust and easier solution than
> > COBOL.
>
> Disagreed. Perl has no decimal money type, for example.

It was just an extreme example, perhaps not quite accurate, but the point is
that even a scripting language coupled to a RDBMS could do the job today, let
alone performant scripting languages leveraging from fast, robust VMs, like
Scala on JVM.

anyway, is it much of a hassle to use double to represent monetary values?

> Plus, why in the world would you run an interpreted Perl program to do
> things like (say) payroll, that you're going to compile once and run 100,000
> times over the lifetime of the application?

Perl is a glue language:  it's main purpose like should be all scripting is to
integrate different systems and route data between them.  Perl "slowness"
doesn't really get into account when it is expecting data from the RDBMS to
feed the PDF generator.

At workplace, at least, SQL responds pretty much for about 80% of the code, the
rest being forms and reports in Delphi to either enter or extract data to/from
the RDBMS.  Business rules validation on persistence is done by SQL stored
procedures.

> > So, I believe that 70-80% figure sounds highly overrated unless it's counting
> > SQL out.
>
> I don't think SQL counts as a programming language you write programs in, at
> least in the eyes of the author.

SQL alone, no.  But stored procedures get you many new abilities.

Post a reply to this message