Re: New Cobol compiler written in Cobol

From: Donald Tees (donald_tees_at_sympatico.ca)
Date: 01/30/05

  • Next message: R.Freitag: "Re: New Cobol compiler written in Cobol"
    Date: Sun, 30 Jan 2005 13:57:56 -0500
    
    

    Robert Wagner wrote:
    > In 1962 (or so) IBM released the 1401 computer system. The dominant
    > machines at the time were the IBM 7090 and similar 7040. Next to them,
    > the 1401 looked like a toy. It couldn't address more than 16K of
    > memory and had no operating system. Its strongest feature was a 600
    > lpm printer. Mainframers brushed it aside as a computer, thinking of
    > it as a programmable off-line I/O device, which is the role it played
    > in big companies. For medium-sized companies, it was the first
    > computer they could afford. By 1965, when it morphed into the IBM-360,
    > the 14xx line had grown to become the dominant business computer.
    >
    > IN 1982 IBM released the PC. The doinant business machines at the time
    > were the IBM 370. Next to them, the PC looked like a toy. It couldn't
    > address more than 640K and had a rudimentary operating system: MS-DOS.
    > It didn't support tape drives, which were still important in the
    > mainframe world, had a 10M disk and was slow. Its strongest feature
    > was a memory-mapped screen. Mainframers brushed it aside as a
    > computer, thinking of it as a programmable terminal, which is the role
    > it still plays in big companies. For small companies and home
    > businesses, it was the first computer they could afford. By 1995, when
    > it morphed into the Wintel box, the PC had grown to become the
    > dominant computer line.
    >
    > In 2002 Microsoft released the XBox. The dominant machines at the time
    > were Windows boxes and Unix servers. Next to them, the XBox (and other
    > game machines) looked like a toy. It couldn't run 'real' software,
    > only games. It didn't have a visible operating system. Its only strong
    > feature was high-speed floating point. Big whoop. Programmers brushed
    > it aside as a computer, thinking of it as a programmable consumer
    > electronics entertainment device. Kids got it because their parents
    > didn't trust them with a 'real' computer having internet access (they
    > didn't notice the XBox also had internet access).
    >
    > Note the regularity of timing -- twenty years between generations, by
    > coincidence the same as human generations. Note the similarity of
    > low-profile introduction and initial scorn by the computing
    > mainstream. Note the rapid growth of hardware capacity, which quickly
    > surpassed mainstream systems.
    >
    > I think we have a pattern.
    >
    > If I were writing a Cobol compiler, I wouldn't look at today's market.
    > That's myopic. I'd target the market 5 years hence. It won't be
    > Microsoft/Windows or Sun/Java; it will be a fat XBox or Playstation
    > running Linux. It will have multiple CPUs, blazing speed and huge
    > storage. TV-like graphics and sound will be the norm rather than an
    > add-on.
    >
    > What will a programming language need to be successful in that world?
    > Ease Of Use. Programmers won't put up with cryptic languages like C++
    > and Java. They'll use a language they can understand at a glance.
    > Bingo -- that's Cobol's strength. They'll expect database to be
    > integrated, not an add-on. They'll expect a polished navigation in the
    > IDE -- more like Acrobat than a fancy text editor.
    >
    > What will a programming language need to fail in that world?
    > Antequated concepts like binary and packed numbers, string handling
    > that's incompatible with other languages, difficulty communicating
    > with OO languages and libraries, flat files (they belong in a library,
    > not a language).

    Aye, and the way to supply that is not in the traditional
    compiler/linker/loader model, at least not visibly, up front.

    If you are going to take OOP seriously, then basics like a "program", A
    sybroutine" and "a method" should be defined in cobol at the source
    level. In other words I should be able to code some thing like:

    move "MY-PROGRAM-ID" TO PROGRAM-ID-PARAGRAPH OF standard-cobol-object.
    INVOKE STANDARD-COBOL-OBJECT "COMPILE".
    INVOKE STANDARD-COBOL-OBJECT "RUN".

    The pubic domain "compiler" then, does not translate COBOL source into
    object at all. It translates the code into some form of platform
    indepent Cobol source that exists as Cobol readable data, readable by
    itself, that it can re-write in the local cobol dialect. One you can do
    the above on the local platform, you should be able to bootstrap the
    system for each platform.

    Donald


  • Next message: R.Freitag: "Re: New Cobol compiler written in Cobol"

    Relevant Pages

    • Re: Wang COBOL alive and well as Wang VS makes a comeback
      ... I fought to the last to keep COBOL at least peripherally in the ... will be the next language du jour... ... This contributes to the stability of programming efforts ... level of COBOL to another can be as big a deal as migrating across platforms ...
      (comp.lang.cobol)
    • Re: 7E7 Flight Controls Electronics
      ... was just good thing that that localization was not too easy - it would ... Please don't confuse abstraction skills of typical COBOL programmer (that ... I pointed at the current programming "biblioware" for commercial data ... > language was because I learned all the workarounds. ...
      (comp.lang.ada)
    • Re: Structured Coding
      ... more visual, some are more conceptual, some are more language oriented. ... I had major problems struggling with OO COBOL when it was first released. ... programming language ever written; light hearted, witty, amusing, ... Later I had to run some courses in Java Web programming and ...
      (comp.lang.cobol)
    • Re: Gartner on Assessing the Age of Software Languages and Tools
      ... It's doing some Romero-level twitching, ... We have a lot of customers with no mainframe COBOL at all, ... COBOL.NET does everything that any other .NET language does. ... And of course the whole *point* of the CLI/CLR is that it simplifies mixed-language programming, so it's trivial to use one .NET language for the bulk of an application, and drop into another if it is better suited for some particular aspect. ...
      (comp.lang.cobol)
    • Re: eWeek: "Save Me from Cleverness" - One more reason I love Delphi
      ... To call C a toy language is to misunderstand both it's place in computer ... There are many kinds of programming, ... the low level operating system and low level ...
      (borland.public.delphi.non-technical)