1. Forum
  2. Fidonet
  3. COMP.LANG.C++

  • Re: =?UTF-8?B?4oCcQnJpYW4=?= Kernigan speaks. 83 and still =?UTF-8?B?dG

    From Lawrence =?iso-8859-13?q?D=FFOlivei@3:633/10 to James Kuyper on Mon Sep 8 08:40:04 2025
    XPost: comp.lang.c
    From: ldo@nz.invalid

    On Fri, 5 Sep 2025 17:34:34 -0400, James Kuyper wrote:

    I've heard that one of the concepts behind the design of COBOL is that
    it should allow managers to write programs, obviating the need for specialized programmers.

    There was a specific focus on “business” needs, as opposed to “scientific”
    needs. So no transcendental functions, for example. And then what happens
    in derivatives trading? You need transcendental functions, of course. Is
    that not a “business” need?

    Another feature omitted was dynamic string handling. And what comes along
    but SQL databases, which quickly became an essential “business” need? But it turns out that the best way to interface to a relational database is to generate SQL query strings. Which COBOL could, even to this day, only do
    badly.

    --- SoupGate-Linux v1.05
    * Origin: Dragon's Lair ---:- Fido<>Usenet Gateway -:--- (3:633/10)
  • From Louis Krupp@3:633/10 to All on Wed Sep 10 01:21:40 2025
    XPost: comp.lang.c
    From: lkrupp@invalid.pssw.com.invalid

    On 9/8/2025 2:40 AM, Lawrence D’Oliveiro wrote:
    On Fri, 5 Sep 2025 17:34:34 -0400, James Kuyper wrote:

    I've heard that one of the concepts behind the design of COBOL is that
    it should allow managers to write programs, obviating the need for
    specialized programmers.
    There was a specific focus on “business” needs, as opposed to “scientific”
    needs. So no transcendental functions, for example. And then what happens
    in derivatives trading? You need transcendental functions, of course. Is
    that not a “business” need?

    Another feature omitted was dynamic string handling. And what comes along
    but SQL databases, which quickly became an essential “business” need? But it turns out that the best way to interface to a relational database is to generate SQL query strings. Which COBOL could, even to this day, only do badly.

    From what I've read, COBOL was designed for business needs as they were understood in November of 1959. While early versions of the language
    didn't implement transcendental functions, I can do this today in GNU COBOL:

        compute e = function exp(1.0).
        display e.

    and get 2.7182818.

    As far as dynamic string handling goes, if the lack of this feature is
    the reason why you don't code SQL queries in COBOL, I totally get it.
    Some COBOL compilers support EXEC SQL, some don't, and life is too short
    to waste time trying to cram square pegs into round holes.

    Louis

    --- SoupGate-Linux v1.05
    * Origin: Dragon's Lair ---:- FidoNet<>Usenet Gateway -:--- (3:633/10)