Showing posts with label Computer Power and Human Reason. Show all posts
Showing posts with label Computer Power and Human Reason. Show all posts

Sunday, June 21, 2026

Generative Artificial Intelligence: As Big as it is, it is only a Program

We ignored the warnings from Mary Shelly, Thea von Harbou, Karel Čapek, and Colossus: The Forbin Project (1966) by Dennis Feltham Jones. The Hegelian dialectic predicts that the terror of the artificial human must have created its own contradiction and it did: the Apple Macintosh 1984 Super Bowl Commercial and everything it validated from Thomas Edison (“All I ask of my body is that it carry my brain around.”) to Alan Turing (he, him, G), Grace Hopper (0111), and the nerds of Silicon Valley. 

We made everyone a computer programmer. Some of us started earlier than others. We made it as easy as possible. 


For the people who never learned to program before, the user interface is as easy as a Google search or a Word document. Just ask. The program (measured against 1985) is an extremely large and complex compiler with a natural-language interpreter as the primary user interface. 


The Mercedes Maybach S 680 Brabus 
will not make coffee. It only does
extremely well what it was programmed to do.


The integrating truth which unites the two sides of the AI Dialectic to create the Synthesis which will result in a new Thesis, is that we all have been programming machines all of our lives. Aristotle never tuned a radio. Even given the wonderful opportunity, Plato would not get his hands dirty lubricating the powertrain of a steam engine. (Granted, there was Archimedes and it is a thin hypothesis that he built the Antikythera Device.) From learning to ride a bicycle, playing with Erector Sets, TinkerToys, and Legos and then learning to drive a car (and change a tire), we grew up interacting with machines.

I answered an ad from Murrary Resources, technical recruiters,
for a technical writer. "You do not look all that human to me,"
the human resources applicant tracking AI said to me.

A cogent comment on LinkedIn.
However, I replied:

"When the devil tempts you he will not come with fire and claws.
He will ask you to comprise a little bit just this once.  
Aaron Altman to Jane Craig in Broadcast News
."
Because of Clippy, people stopped learning to write letters.

The Antikythera Device ran for a century or so, three lifetimes: created, admired, and never to be repeated. Scholars who study the device wonder and discuss whether and to what extent this was the work of one person. It has no simpler precursors, no antecedent subassemblies. The common informed wisdom includes the fact that this wonderful astronomical computer also, incidentally, was used to set the dates of religious ceremonies, which for the Greeks necessarily included stadium games. 


I ask: What if civic religion and social rituals were the purpose; and the path to that solution included the attendant abilities to track the planets? 


I suggest: It took a lifetime to build (three generations: one brainiac with minions), ran for a lifetime, and was lost in transport, falling into the sea for 2000 years. Would the loss of a single sword have benchmarked the existence of swords and how to make them? Many people could make swords. Not-many people built the Antikythera.


For 2000 years, the standard calculator was the abacus: no gears, no sundial, no pointers. It does have an accumulator and a register but no one ever called them that. 

GOSUB coffcoff. Despite their pretenses, programmers (now “devops”; formerly “data processing"), are just another class of users, like clericals and sales. They have other interfaces and presentations. Programmers will not tell you this, but they write with an “Application Development System” or “Program Developer Kit” which is a spellchecker for code. It is all colorized and color coded. If the programmer makes a mistake, the colors show that. Sometimes, the line itself will not accept an <Enter> if there is a bug on the line. That sure makes life easy. They now have “no code application development.” The programmers get to <quote> focus on higher level problems </quote> (ahem, coff-coff). RETURN.

Two hundred years ago, Charles Babbage built the Differential Engine and Lady Ada Lovelace programmed it. It took another lifetime for the world to catch on and catch up. The MIT “hackers” of the 1950s built model railroad switching systems from donated Bell Telephone racks. A hundred years ago, it had been suggested that in theory you could use your telephone to select and listen to a symphony orchestra in a distant city. 


Instead, we had broadcast radio—with commercials—an ethereal instantiation of newspapers, themselves an invention from only one previous century. 

Mathematicians complain about AI.

“First, it points out how AI models can “produce plausible but unreliable (or even incorrect) arguments which are difficult to distinguish from correct mathematical proofs.” Such developments put reviewers under increasing pressure and are “jeopardizing our ability to implement traditional standards for the correctness, transparency, and independent verifiability of proof,” the declaration warns.”

 — https://arstechnica.com/tech-policy/2026/06/mathematicians-warn-of-ai-threats-to-profession-as-industry-encroaches/

https://arstechnica.com/tech-policy/2026/06/mathematicians-warn-of-ai-threats-to-profession-as-industry-encroaches/#:~:text=“Mathematicians should find it quite,College London, in a statement.

However, no one spoke out against human mathematicians when Andrew Wiles announced his proof of Fermat's Last Theorem on 23 June 1993 at a lecture in Cambridge titled "Modular Forms, Elliptic Curves and Galois Representations". As it was told in Fermat’s Enigma: The Epic Quest to Solve the World’s Greatest Mathematical Problem by Simon Singh (New York: Walker, 1997; Anchor Doubleday, 1998), it was just another conference, but at the end of day one, the science journalists in the hall began calling their colleagues and by day three the place was packed. Andrew Wiles had proved Fermat’s Last Theorem. 


Or did he?


Again from the Singh work, closer inspection later by mathematicians at Wiles’s level revealed flaws in the proof. Wiles went back to work with a ream of white paper and a cup of sharp pencils. It took him three years. No one blamed him or his school or his parents. Instead, they gave him a medal. 

LET WORDS = 1024

The essential error in using AI (or a calculator) is seeking to avoid responsibility for choice and therefore not accepting responsibility for the consequences of your actions. Imagine that for an algebra class, you bought the instructor’s edition and copied out the answers to turn in for your homework. We recognize that as cheating. 



What if the book is wrong? Typos happen. The answer in the back can be wrong. A friend of mine had a math teacher who could not accept that the book was wrong. The kids did the problem correctly. Her book said that they were wrong. They met her after school (in the classroom, not the parking lot) and walked her through the answer. As it was told to me, the teacher refused to budge: the book could not be wrong. (She also called integers “intriguers”  perhaps indicating the challenge she found in high school maths.) So, AI can be wrong. Where is the surprise in that? 

Silicon Valley by Michael Rogers (Simon and Schuster, 1982).

"[Burt] Mathias is a self-made businessman who built the computer firm Solitron into a multimillion-dollar corporation. His college friend and partner, Alan Steinberg, is the computer genius of the operation, who explores the farthest reaches of computer intelligence while Mathias manages the finances. But Mathias stands on the brink of personal and professional ruin, about to lose both his wife and his business. To save Solitron from bankruptcy, he must gamble everything on whether Steinberg can perfect the first computer ever to simulate human consciousness. And once the job is complete, there is only one way to prove this remarkable ability to the incredulous world: the Turing Test..." (from the cover). 

As I remember the story, Mathias gamed the game by choosing as the human contestant, one of his own programmers, because who else would talk like a computer?



Big Bang Theory, NUMB3RS, NCIS,
Bones, Grey's Anatomy, replacing 
Leave it to Beaver, I Love Lucy, Lassie,
and Happy Days.

Clippy only does what it is programmed to do. The kids could prove their case, not just by working the problem but, had they chosen, via other paths. One of my physics professors, Dr. Alan Saaf at Lansing Community College, was answering homework questions at the blackboard. “I don’t understand number 3. …. How do you do number 5?... What equation do you use for number 1?...” He was going along and then he stopped. “You people would go out in the backyard and shoot hoops for 45 minutes and not make a single shot and still say you had a good time. How long did you spend on number 4? How many ways did you try to solve it?” 

There are over 300 proofs for the Pythagorean Theorem (one by Pres. James Garfield). The kids knew that the book was wrong because it contradicted known, provable truths. Clippy and Claude and the folk lack judgment.



This is an old problem among humans. In Computer Power and Human Reason: from Judgment to Calculation (1976), Joseph Weizenbaum warned of hackers whom he compared to compulsive gamblers. Driven by the superstition that one more patch will fix their problems, they stay up late, bleary-eyed and disheveled, working ever more frantically on a program they began without any reference to the substantive literature in the field in which they claim to be working. They are like gamblers who compulsively build complex rituals to control the game. 


Gamblers and Programmers


On the Cloudy Nights discussion board, which is mostly dedicated to chat about observational astronomy, in the forum for “Science! Astronomy, Space Exploration, and Others,” a topic title was the question “What can’t artificial intelligence do?”  The introductory post started: “We have made machines that can play chess better than we can. We are close to making machines that can write novels better than we can. Threshold question. Is there a limit? I can see no reason that there should be. The interesting question. What happens when we can make machines that can do everything better than we can?” In 100 replies, I was the only person who pointed out that while an AI could write a better novel, the novel itself was an invention. I received just one "like" for the comment. 

In a machine shop, there was a sign wrapped along the top of the walls: Good judgment comes from experience. Unfortunately, experience comes from poor judgment.  


For Cloudy Nights, I wrote: "(As far as we know) only humans can invent something new. You can say that an AI can write a novel better than a human, but the novel is an invention. As a form of narration and history, the novel is relatively recent. Poetry - epic poetry - was first. And before poems were invented, people made lists of things. ... Painting as we know it evolved in a series of quantum leaps. By the 4th century BCE graphical realism had achieved what we regard as modern techniques. The "Renaissance Masters" of Holland painted in a hyper-realistic style that violated "natural" vision. See The Arnolfini Portrait by Jan Van Eyck.  If you were in the room where the painter stood, you would not see the image in the mirror at the back the way it is presented in the painting. It is hyper-real. Impressionism, Expressionism, Abstract, ...  Performance Art.... That is the essential distinguishing characteristic that explains the difference between human intelligence and machine intelligence."

https://necessaryfacts.blogspot.com/2023/06/invisible-cheating-and-visible-rights.html

PREVIOUSLY ON NECESSARY FACTS

Documentation is Specification 

Denise Schmandt-Besserat: Accounting for Civilization

Denise Schmandt-Besserat: Art as Ordered Narrative

Love, Loss, and Redemption in Atlas Shrugged 

Atlas Shrugged Part 3: Who is John Galt

Remote Work Before Covid 

The Antikythera Device



Monday, September 24, 2012

Documentation is Specification

Good software design begins with documentation.  Write the user manual first.  The design documents specify the desired outputs, and the inputs, actions, and processes that cause them.  The library of design documents will include the experience interface, the online helps, the installation guide, training manuals and tutorials, and, of course, the programmer’s references.  

One of several bad designs discussed here
Overwhelmingly, that is not how software is designed; and that is why so much of it is unsatisfying. Even programs that we find useful have annoying bugs, quirky features, and unhelpful demands. It is true that software is complicated. It is an easy claim - sort of like Goedel’s Proof - that every non-trivial program has one bug. But that is not the problem. The pain we all endure - from impatience and annoyance to angst and anger -  comes from the overarching pride - hubris - of programmers at all levels who believe that they know better than you what you want and need.

This is an old problem. In Computer Power and Human Reason: from Judgment to Calculation (1976), Joseph Weizenbaum warned of hackers whom he compared to compulsive gamblers. Driven by the superstition that one more patch will fix their problems, they stay up late, bleary-eyed and disheveled, working ever more frantically on a program they began without any reference to the substantive literature in the field in which they claim to be working. They do not know first-hand the daily lives of their users.

Typically, a project manager or systems analyst finds out from meetings what the customer wants. They even “jad the users” referring to JAD the Joint Application Development process that is supposed to bring the customer into the process. The manager or analyst prepares “design documents” of a sort that define data structures, and meta-dictionaries, language requirements, interfaces, and many other nice things, none of which actually describes how the customer will engage the system.

Even 25 years ago, Dan Bricklin - the inventor of VisiCalc - created a rapid prototyping tool called Demo. Today, RoboHelp has competitors; but RoboHelp and its competitors are not perceived as design tools. They are add-ons, paste-ins, superstitious rituals that hackers in suits (“account executives”) call upon to cure problems caused by a fundamental ignorance of the goal.  The goal was never explicitly stated. 

The user experience, the installation guide, the training materials, the online helps, those define the goal. Without them, the best we have is a good guess by an insightful and benevolent technician who imagines what they would want if they were you... which they are not.

A strong design process begins with JAD sessions, of course. In our time, it is very easy to let a customer’s own design team drive the process of creating the user interfaces, menu and dialog choices, and the building of queries and reports. Our own development team brings to this their expertise based on hard-won wisdom. User experience design and user interface design are key skills in the creation of any system. Moreover, we know that experts working alone do better than peer groups of novices.  But "better" at what? And measured how?

No silver bullet solves the problem. The process of creating information systems that meet the actual needs of the client community requires the cooperation of all contributors at every stage. Among those contributors are the documentation experts who most often are called in only when the product is ready for shipment.    

Start the Presses! Typeface by Justin Nagan and Helvetica by Gary Hustwit

Programmers Night Before Christmas
I found this on a blog by Michael Boyd Clark (here) dated 10 December 1997, 1:56 pm. However, it goes back at least to the 1970s if not the 1960s. I edited some bugs.

'Twas the night before implementation and all through the house
not a program was working, not even a browse.
The programmers hung round their cubes in despair
with hopes that a miracle soon would be there.
The users were nestled all snug in their beds
while visions of inquiries danced in their heads.
When out of the tube there arose such a clatter
I sprang from my desk to see what was the matter.
And what to my wandering eyes should appear
but a super contractor with a six pack of beer.
His resume glowed with experience so rare.
He turned out great code with a bit-pushers flair.
More rapid than eagles, his programs they came -
He whistled and shouted and called them by name:
“on UPDATE, on ADD, on ENQuire, on DELete!On batch jobs,
on closing, on function complete.”
His eyes were glazed over, fingers nimble and lean
from weekends and nights spent in front of the screen.
A wink of his eye and a twist of his head
soon gave me to know I had nothing dread.
He spoke not a word but went straight to his work
turning specs into code; then he turned with a jerk
and laying his finger upon the enter key,
the system came up and worked perfectly.
The updates updated, the deletes they deleted,
the inquiries inquired, the closing completed.
He tested each whistle, he tested each bell,
and with nary an ABEND, all had gone well.
They system was finished, the tests were concluded,
the client’s last changes were even included.
And the users exclaimed with a snarl and taunted,
"IT’S JUST WHAT WE ASKED FOR, BUT NOT WHAT WE WANTED.”