> Current AI does not "understand" the information it holds, nor does
it have a concept of "truth".

So it's like a CEO. Good to know.

On Thu, Feb 22, 2024 at 6:13 PM Joel C. Ewing <jce.ebe...@cox.net> wrote:

> One needs to understand that today's Large Language Model AI tools like
> ChatGPT, etc. are essentially driven by huge statistical databases
> created from processing huge volumes of digital text using some
> knowledge of sentence structure and words. Those tools can accept
> English-language queries and use words and phrases in the query to
> generate related-information responses with complete sentences and
> paragraphs that have a high probability of of being relevant to the query.
>
> Current AI does not "understand" the information it holds, nor does it
> have a concept of "truth".   Even if you program the AI using books on
> COBOL grammar and semantics it won't "understand" COBOL.   Even if you
> feed it millions of lines of COBOL code it won't be able to deduce the
> underlying purpose of the code.  If there is an accurate description of
> what the code does accompanying the code, it can associate that
> description with a code segment; but if the description is inaccurate,
> AI may also associate the code with that bad description.   Inevitably
> some of the code you might use to program the AI tool will contain bugs,
> and AI will be equally content to supply buggy code examples.
>
> If your object is to generate optimized Assembler code which accurately
> replicates the behavior of a COBOL program, the best tool for that for
> the foreseeable future is an optimizing COBOL compiler for your target
> machine.  Such compilers are already doing flow analysis just to
> optimize loops and register usage, but I wouldn't call that "AI" in the
> usual sense of that term. Perhaps a well-programmed AI tool would
> suggest using a COBOL compiler if asked to convert a COBOL program to
> assembler -- in fact that is basically the response given by the MS
> Copilot tool when asked to perform that task for z-architecture;
> although you can see hints of its lack of understanding in that in
> includes in its response "IBM provides cataloged procedures (such
> as*IEBCOMPR*and*IEBCOPY*) to simplify JCL coding for COBOL compilation",
> where it includes gratuitous PROC examples that have nothing to do with
> COBOL rather than giving the names of actual COBOL compiler PROCs.
>
>      Joel C. Ewing
>
> On 2/22/24 11:09, Robley Lutz wrote:
> > I guess my question is, do we expect AI to look at COBOL code, and not
> > simply compile it, but analyze the flow, and output optimized Assembler
> > code?  Will AI become the highly skilled Assembler programmer that I
> never
> > became?
> >
> > On Thu, Feb 22, 2024 at 11:54 AM Tom Harper <
> > 000005bfa0e23abd-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Dave,
> >>
> >> I was told the same thing 54 years ago when I starting working at
> >> CalTrans. Managers would just be able to code in COBOL PROFITS = SALES -
> >> EXPENSES and we would all be out of a job.
> >>
> >> ...
>
> --
> Joel C. Ewing
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to