From Newsgroup: comp.ai
Terry Porter <
techman001@eternal-september.org> writes:
(Context: I'm Terry, a 72-year-old electronics technician rCo fifty years
of soldering, circuits and oscilloscopes, Forth since the 90s. I dictate
my notes and an AI helps me write them up clearly, but the actual bench
work rCo the registers, the LEDs, the clocks, the measurements rCo is mine, done live.)
While itrCOs true that the text above this remark (some of which IrCOve
quoted below) is pretty clear, itrCOs also pretty obviously AI, and it has
a certain characteristic that is widespread in AI-generated texts which
is pretty offputting: it frequently exaggerates to the point of
falsehood in a sort of slick salesman way, which inspires distrust in
the sort of people who think about things.
Specifically:
Why does a tool that checks your code against a real microcontroller as
you type rCo over a debug wire, live, in the editor rCo only work with
Forth, and not C? This episode answers that question, and the answer is
not what you'd expect. It's not a language snobbery. It's physics.
The answer isn't physics.
Then the project that broke him: an automatic truck lubrication
system, very profitable if it worked rCo and it didn't. The hardware was sound; the software let him down.
The truck lubrication system didnrCOt break you. You're still
functioning.
C is cross-compiled and flashed rCo the feedback loop is tens of
seconds. And that difference is the whole ballgame, because of
*context*.
ThererCOs more to embedded development than fast feedback loops; although theyrCOre important, theyrCOre not the whole ballgame.
A slow feedback loop kills context. It kills the human developer's
train of thought, and it kills an AI's context window the same way rCo
make a change, flash, wait thirty seconds, and the AI has forgotten
what it was doing.
AIsrCO context windows do not evaporate in 30 seconds; typical on-GPU
cache lifetimes are measured in minutes, not seconds, and even when the
context window has been evicted from the cache, itrCOs not lost. The AI
company just bills you for extra tokens.
This episode explains exactly why you'll never see a LiveCheck for C rCo
You might someday see a LiveCheck for C. C interpreters exist. It
probably wonrCOt be called LiveCheck, but itrCOs obviously possible to
provide the same functionality for C. ItrCOs just very hard.
and why that's not a limitation, but the point.
LiveCheck not working with C is, in fact, a limitation, almost by
definition.
*****
The usual norm of etiquette is that itrCOs rude to show AI output to
people. (<
https://distantprovince.by/posts/its-rude-to-show-ai-output-to-people/>)
I think the usual reasons for this norm of etiquette do not in fact
apply to your use of AI; you put a lot more effort into this than just a
quick prompt and sharing the resulting essay. Here are the usual
reasons, from the above URL:
ThererCOs nothing wrong with _using AI_. When you do, you know what
yourCOre getting. The transaction is fully consensual. But whenever you _propagate AI output_, yourCOre at risk of intentionally or
unintentionally legitimizing it with your good name, providing it with
a fake proof-of-thought. In some cases, itrCOs fine, because you did
think it through and adopted the AI output as your own. But in other
cases, it is not, and our scrambler brain feels violated.
I think I have an insight about how to use LLM AIs for this kind of
thing that can only be shared by, unfortunately, publicly exhibiting
some of their output, and it's an insight that may be of use to you,
because it will keep people from mistaking your hard-won experience for
random AI slop.
If you want, you can get LLM AIs to not sound like this. You may have
to hammer on them a bit when they fall back into their default slick
salesman persona and introduce obvious falsehoods like the ones I listed
above. But generally theyrCOre pretty good at imitating the voice of any persona they have a good corpus of training text for.
HererCOs an example where I asked GPT-5.4 Mini in Reasoning mode to
rewrite your text in the voice of George Carlin, a request it partly
refused. It seems dramatically less exaggerated:
Why does a tool that checks your code against a real microcontroller
while you type only work with Forth and not C? Because the whole issue isnrCOt taste, and it isnrCOt ideology. ItrCOs timing.
Back in 1984, the work started the hard way: raw machine code, hex
digits punched in by hand on an Intel 8085. That was a fine way to
punish a technician and a terrible way to build anything. Then came an assembler for the 6800, and suddenly there was at least some
relief. Later came PIC microcontrollers and a simple C-like language
that got a few products out the door. Then came the project that went sideways: an automatic truck lubrication system. The hardware was
fine. The software blew it. If Forth had already been in his toolkit,
things might have gone differently.
ThatrCOs the whole trick. Forth lives on the chip as a resident
interpreter. You type, it responds almost immediately. C doesnrCOt do
that. C gets cross-compiled, flashed, reset, and dragged through a
long little bureaucratic ritual before you find out whether you were
right. That delay is where the trouble starts.
Because slow feedback is poison. It breaks the developerrCOs
concentration, and it does the same thing to AI: the thread gets
stretched, then frayed, then lost. You change something, flash it, wait,
and by the time the result comes back, the model has half-forgotten why
it cared in the first place. ItrCOs not that the command was wrong. ItrCOs that it arrived after the party was over.
So yes, LiveCheck only works with Forth. Not because C is inferior, and
not because someone has a language preference, but because the tool
needs a tight loop, and Forth gives it one. C in embedded systems gives
you a slow, stupid little parade of compile, flash, reset, wait,
repeat. Forth gives you a conversation. And if you want a tool that
thinks alongside the silicon, you need the conversation.
My prompt (aside from your text) was the following:
Please remove all the exaggerated claims from the following text, then rewrite it in the voice of George Carlin, removing all the negative parallelism and glib oversimplifications. It's okay if it has new exaggerated claims and negative parallelisms as long as they're the
ones that George Carlin would have put in there.
I asked Claude Haiku to rewrite it in the style of G. K. Chesterton, and
the result certainly doesn't sound like stereotypical AI, but I'm not
sure it's an improvement in terms of accuracy the way the Carlin version
was:
The Forth Paradox, or Why the Machine Must Talk Back
There exists a curious tool that whispers to a microcontroller through a debug wire while you work, receiving answers in millisecondsrCoand it
exists only for Forth. Why should this be? The answer, I confess,
surprised me as much as it surprises everyone else. It is neither a
matter of fashion nor of linguistic prejudice. It is, in fact, a matter
of physics; or perhaps I should say, a matter of how the human mind
conducts its peculiar commerce with silicon.
The story, like all good stories, begins with a man at work. In 1984, a technician sat before an Intel 8085, typing hexadecimal digits by hand
upon a keypadrCoa tedious business, certainly, though not without its own grim dignity. Then came an assembler for the 6800, which restored to him
some measure of grace. Simple languages followed, and simple
products. But then arrived the task that tested him: an automatic truck lubrication system, which promised great profit but delivered only
failure. The hardware was honest. The software, alas, was not. Had he
known ForthrCohad he discovered that remarkable languagerCothe tale might have concluded otherwise.
And herein lies the matter entire.
Forth runs upon the chip as an interpreter; you speak a line, and the
silicon answers you at once. C must be compiled and flashed to memoryrCoa process consuming thirty seconds or more. Between these two facts stands
the great gulf: the human mind requires continuity of thought. A long
delay does not merely interrupt; it severs. One forgets not only where
one was, but why one was there. An artificially intelligent mind, it
seems, suffers the same affliction. The debugging becomes like operating
a rover across the Martian distancerCoyou observe a crater, you transmit
your correction, but by the time the signal returns, the machine has
already tumbled into the abyss. The command is not wrong. It is merely
too late.
This is why LiveCheck dwells only in Forth. It is built, not for speed
as such, but for continuityrCothat most precious commodity in the work of thought itself.
I used the same prompt except for changing the author name. Then I did
the same thing with Gemma 31B and Richard Feynman:
Now, here is a funny thing. You have this tool that lets you check
your code against a real microcontroller as you're typingrCoright there
in the editor, live over a debug wire. But you notice it only works
for Forth and not for C. You might think that's just some programmers
being picky about their favorite language, but it's actually a matter
of how the information moves.
Imagine a fellow back in 1984 trying to program a bottle-filling
machine. He's typing hexadecimal digits by hand into an Intel
8085. It's a tedious process. Then he moves to an assembler for the
6800, which makes things a bit easier. Then come the PIC
microcontrollers and a simple C-like language. But eventually, he hits
a wall with something like an automatic truck lubrication system. The hardware is fine, but the software is a mess, and he can't figure out
why. If he had used Forth, he would have seen the problem immediately.
The secret is in how the language actually sits on the chip. Forth uses
a resident interpreter. You type a line, and the silicon responds in a
few milliseconds. Now, C is different. You have to cross-compile the
code and flash it onto the chip. That feedback loop takes tens of
seconds.
This delay is a big deal because of what I call the "context" of the
problem. When the feedback is slow, you lose your train of thought. It's
the same for an AI. If you make a change and then have to wait thirty
seconds for a flash and reset, the AI has essentially lost the thread of
what it was trying to achieve. It's a bit like trying to drive a rover
on Mars from Earth. You see a crater on your screen, you send the
command to stop, but by the time the signal travels across space and
back, the rover has already driven straight into the hole. The command
was correct, but it arrived too late to matter.
That's the reason LiveCheck is built for Forth. If you want an AI to
hold a coherent thought about what's happening inside the silicon, you
need a fast feedback loop, and only an interactive on-chip language can provide that. It's not a limitation of the tool; itrCOs just how the machinery of the process works.
I think this is also significantly more accurate than the original.
These are all one-shot translations with no back-and-forth. It probably wouldnrCOt be difficult to coach the AI to sound less AI and be still more meticulous about veracity.
I invite commentary on whether these are better or worse than the
original.
Another way to use AI to clarify your writing, a way which doesnrCOt
expose you to charges of posting AI slop at all, is to give your writing
to an AI and ask it questions about the subject yourCOre talking about.
Note, privately, what it got wrong in the process. The things AI misunderstands are also likely to be things that people misunderstand.
Revise your writing, without using AI, to clarify the confusing parts:
remove things that misled it if you can, reorder parts to provide better context when it becomes apparent that context was lacking, or add more
material if those donrCOt work. I canrCOt demonstrate that in this case,
but if you try it, I think yourCOll see that it works.
Kragen
--- Synchronet 3.22a-Linux NewsLink 1.2