Re: Microsoft admits 30% of code not written by humans

On Thu, 5/1/2025 6:06 AM, Farley Flud wrote:

On Wed, 30 Apr 2025 19:27:20 -0400, knuttle wrote:
 

>

 

That has been obvious since the DOS days
>

 
This is true.
 
Anyone who has ever "programmed" with Visual Studio knows that automated
code generation is present throughout.
 
Example.  Invoke a window or other graphical object and a huge mass of code
is automatically dropped in place.
 
Another example.  Write some short statments within ASP.NET and a huge
mass of javascript appears from nowhere.
 
In fact, most "programming" of any kind is simply stringing together standard,
pre-built modules to achieve an overall goal.
 
AI can easily do the same thing.

Actually, it can't. It can do an approximation.

The amount of data used for training, is much much larger
than the size of the model file storage. There isn't room to
store verbatim copies of anything in there. But it is OK for the
AI to spot trends or in a sense, contain a precis of what goes on
within that preamble code.

   https://en.wikipedia.org/wiki/Neural_network_%28machine_learning%29

A long time ago, there were complaints from outside programmers,
about the amount of code required to make a window appear on the screen.
These were programmers who were prolific individuals, they
wrote code like Steven King writes novels. It would take on
the order of "12 pages of code", to open a window. That was
the exaggeration of the difficulty of it.

The inclusion of template code in Visual Studio, is an attempt to
answer that complaint. It does not particularly reduce the code to
nothing, but it does put a copy of it, plus the prototype event handler
loop, into your source. And that's a good thing, for the average
copy/paste programmer (that's me). I think I have one HelloWorld
version here, that consists of nothing more than that template code :-)

It's no problem for the AI to write an equivalent module
(subject to model token limits). The AI training process
will have captured the idea than an HWND is being opened,
and that there is an event loop to make the "monitoring"
facility in Windows happen. If a process does not "eat"
a test event sent to it, then the Windows "busy cursor"
appears which tells you the program is "un-responsive".
As long as the event loop eats events, it is assumed
the program is running OK. Programs quite frequently
appear unresponsive, because the event loop is not
in a run-able state (blocked by some internal activity).
Poorly written programs will show the busy cursor, when
it should not be shown.

   Paul