Humanist Discussion Group, Vol. 35, No. 608.
Department of Digital Humanities, University of Cologne
Hosted by DH-Cologne
www.dhhumanist.org
Submit to: humanist@dhhumanist.org
[1] From: Gioele Barabucci <gioele.barabucci@ntnu.no>
Subject: Re: [Humanist] 35.604: 'No-code' AI (151)
[2] From: Willard McCarty <willard.mccarty@mccarty.org.uk>
Subject: trustworthy AI? (14)
--[1]------------------------------------------------------------------------
Date: 2022-03-17 10:36:20+00:00
From: Gioele Barabucci <gioele.barabucci@ntnu.no>
Subject: Re: [Humanist] 35.604: 'No-code' AI
On 17/03/22 06:42, Humanist wrote:
> In essence, large collections of data, especially in images, audio
> files, or structured text (e.g., spreadsheets), or even unstructured
> text can now be used in new A.I. software that doesn't require
> programmers to write new code to reach conclusions about what that data
> contains.
Dear Robert,
allow me a slightly verbose reflection (rant?) on the words "no-code"
and "programming".
My take:
a) "to program" is just a synonym for "to explain", and
b) "no code" is, therefore, impossible.
## To program == to explain
The whole point of a program is to lay out instructions on how a machine
should perform a task to achieve a desired output/state given an input.
We cannot use the usual human-to-human communication channels to explain
to a machine the task nor the desired output.
Writing machine code (numbers) is the only way we know to instruct a
machine to perform certain tasks. Because we don't like writing machine
code we wrote some machine code (bootstrap assemblers) that turned
letters (assembly code) into machine code, and then we wrote many more
letters (compilers) to turn more complex words (programs in C,
Javascript) from an artificial language (programming language) into
other machine code.
We are so used to think that writing in a programming language is what
defines programming, that we often forget that the whole point of
writing a program in the first place is to _explain_ what we want.
The encoding of our desires and instructions in a programming language
is just an artifact that arises from the constraints that define
human-to-computer communication.
Similarly, the fact that I am encoding my thoughts as a written text in
English is an artifacts of the constraints of this conversation. I could
very well encode my thoughts in German. Or as a recording Italian.
But then I could not "program" your brain to the state I desire, namely
"you get what I mean".
After this introduction, let's move to the next point...
## "No code" is impossible
Just after the concept of _sequence_, the second most basic building
block of programming is the _if_ construct. We want something to happen
in certain situations.
Depending on your choice of language, you can encode this in many
different ways.
* English: "Could you please do this when this happen"
* BASIC: "IF condition THEN action"
* Ternary operator: "condition ? action1 : action2"
* Prolog: "foobar(condition) :- action1 / foobar(X) :- action2"
* Flowchart/Labview: a rhombus
Everybody agrees, I hope, that all these are "instructions in a
programming language".
No-code platforms promise you that you will not need to learn how to
program. Then how will I explain to the machine what is the desired
output/state? Do I just dream of it and the machine makes it happen?
How is the action of marking, say, an image in a dataset with "yes" and
another one with "no", not a form of programming?
The marking is the programming; running the "no-code AI" is the
compiling; the result is the compiled program.
If the compiled program "has a bug" (it answers "no" when it should have
answered "yes), what do you do? You go through your markings, try to
understand why the no-code tool may have come to a certain conclusion,
and make some changes to your markings so that the no-code tool behaves
better next time. How is that different from debugging a program?
One claim is that marking a piece of data in a dataset is fundamentally
simpler than programming in a conventional programming language.
To me that sounds like saying that speaking is easier than explaining.
True, but not relevant. One is strictly mechanical act, the other one
requires an understanding of the problem at hand as well as some sort of
intentionality.
Marking a couple of data points in a pretty UI is indeed easy, but that
is the equivalent of "PRINT hello world". That's also no-code, that's
plain English.
The issues arise when you try to make the machine behave in the way you
want. At that point you need much more that marking data points. You
need to know _which_ data points to mark and _how_ to mark them. You
need experience to forecast how the machine will react to changes in the
markings.
What is this if not programming? What is that series of markings if not
a program in a programming language?
Yes, you don't see the text that we usually associate with programming
languages. But all the concepts (and experience requirements) are there.
If no experience is needed on a no-code platform, then every user should
be just as expert as the creator of the no-code platform. What are the
tutorials for, then?
No-code cannot possibly exist. At best, users will engage in
domain-specific or task-specific programming via specialized UIs. But
that is and remain programming. With Visual code perhaps. Nothing new.
I understand that people are scared of the word "programming". In my
opinion the right approach is not to tell people "no programming needed"
but rather "programming is not hard" while, at the same time, improve
the ergonomics of programming. Similar discussions have been held for
decades in mathematics. People are scared of mathematics, but resorting
to the no-code equivalent "learn how to split the bill without math" is
not the solution.
Let me close this rant with an historical perspective. SQL was born as a
database interface for the masses. A no-code tool of its time. The boss
will generate the sales report they need by typing a few instructions at
the terminal. No more discussions with the IT department and the
programmers in the basement. This is reflected in the abstract of the
original 1974 SEQUEL publication [1] by Chamberlin and Boyce:
> In this paper we present the data manipulation facility for a
> structured English query language (SEQUEL) which can be used for
> accessing data in an integrated relational data base. [...] A SEQUEL
> user is presented with a consistent set of keyword English templates
> which reflect how people use tables to obtain information. [...]
> SEQUEL is intended as a data base sublanguage for both the
> professional programmer and the more infrequent data base user.
Regards,
[1] https://dl.acm.org/doi/10.1145/800296.811515
--
Gioele Barabucci <gioele.barabucci@ntnu.no>
--[2]------------------------------------------------------------------------
Date: 2022-03-17 05:47:39+00:00
From: Willard McCarty <willard.mccarty@mccarty.org.uk>
Subject: trustworthy AI?
Thanks to Robert Amsler for the notice of the NYT article on 'No-code
AI'. My question is this: how reliable is the translation from what I
write and the actions taken? Would it not be foolish to assume that the
translation is perfect? And one other thing. Let's suppose the
translation is perfect. Would not the outcomes of such a facility be
analogous to all those three-wishes stories?
Yours,
WM
--
Willard McCarty,
Professor emeritus, King's College London;
Editor, Interdisciplinary Science Reviews; Humanist
www.mccarty.org.uk
_______________________________________________
Unsubscribe at: http://dhhumanist.org/Restricted
List posts to: humanist@dhhumanist.org
List info and archives at at: http://dhhumanist.org
Listmember interface at: http://dhhumanist.org/Restricted/
Subscribe at: http://dhhumanist.org/membership_form.php
