Home About Subscribe Search Member Area

Humanist Discussion Group

< Back to Volume 34

Humanist Archives: May 23, 2020, 9:43 a.m. Humanist 34.50 - software, mathematics and views from the humanities

                  Humanist Discussion Group, Vol. 34, No. 50.
            Department of Digital Humanities, King's College London
                   Hosted by King's Digital Lab
                Submit to: humanist@dhhumanist.org

    [1]    From: Henry Schaffer 
           Subject: Computing Languages and the digital humanities - a retrospective look (61)

    [2]    From: C. M. Sperberg-McQueen 
           Subject: [Humanist] 34.27, 34.31, 34.37: punctuation in the assignment statement (40)

    [3]    From: Manfred Thaller 
           Subject: Re: [Humanist] 34.48: software as applied mathematics (213)

        Date: 2020-05-22 13:51:34+00:00
        From: Henry Schaffer 
        Subject: Computing Languages and the digital humanities - a retrospective look


  In the early days of computing the major (only?) applications were
mathematical. There was a major emphasis from the military for such
applications as computing trajectories. Most programs/codes were written in
machine language (or wired in boards) and then in assembler language. Then
came "higher level languages", and the most common one was FORTRAN (FORMula
TRANslator) which clearly was oriented to mathematical/arithmetical
applications. Development of FORTRAN started in 1954
While technically it could work with text ("strings", using the A format,
as opposed to numerical values) but only with awkwardness and difficulty,
so was quite unsuited to the bulk of applications in the humanities.

  The very common higher level language C was developed in the 1972-3 time
frame (https://en.wikipedia.org/wiki/C_(programming_language) ) and it
could handle strings well. To me, its main drawback is that it was barely a
higher level language. One had to do a lot of the "housekeeping" details
which were a burden to programming and error prone, but it gave access to
the computer internals which were often needed for some tasks, especially
if one was concerned about the efficiency of computation.

  But I want to discuss another computer language which handled
strings/text extremely well and so was well suited to the digital
humanities. That was SNOBOL4 (dating to 1967, although SNOBOL development
started in 1962- see "Programming languages: history and fundamentals" Jean
E. Sammet. Prentice-Hall, 1969.] It had a capability analogous to regular
expressions (IMHO not as good) but did a very nice job of processing text,
and I used it for this purpose to generate homework problems which were
superficially different, so students couldn't copy from each other, but
which were equivalent in coverage and difficulty. ("The Use of Computers in
Teaching Genetics:  Computer Generated Homework Problems". J. Heredity, 69
347-351, 1978),

  Not too long after that, I discovered the higher level language "Perl"
(some would call it a "scripting language", but that makes no difference
for our purposes.) See, e.g. "Learning Perl" Randal L. Schwartz, et al
O'Reilly press. It had the modern regular expression (regex) capability
built in and so I moved to using it, and have found it to meet my needs for
processing both numbers and text. Neither SNOBOL4 or Perl was oriented to
extreme efficiency (e.g. compared to C), but the increasing capabilities of
computers over time led to less worry about efficiency of the computation
and more concern about efficiency of the programmer.

 Getting back to the very early use of computers in the digital humanities.
Stephen Maxfield Parrish is the name of a well known American painter
(whose name is shown in several varying ways). It is less well known as an
Professor of English who published "A Concordance to the Poems of Matthew
Arnold" Cornell University Press 1959. The book has a January 1959 date, so
the actual work must have been done in 1958 and earlier. This may be the
earliest item in the digital humanities catalog. The book says that the
computer used was an IBM 704 (its active elements were vacuum tubes) and
that a program was written. It does not say what programming language was
used. My guess, considering the date and the large amount of processing
needed, is that assembly language was used. I knew Professor Parrish, but
never discussed his digital humanities work with him and so didn't ask him
about the computer language used.


        Date: 2020-05-22 13:13:31+00:00
        From: C. M. Sperberg-McQueen 
        Subject: [Humanist] 34.27, 34.31, 34.37: punctuation in the assignment statement

 [This message seems to have gone into the black hole of Humanist both
 when originally sent to Humanist and when re-sent direct to the editor.
 I take the liberty of re-sending it, with a cc to the editor, since
 some readers of Humanist appear to be laboring under misapprehensions
 about the role of keypunch machines in guiding the choice of basic
 symbols in Algol 58 (that is, none) and about the characters available
 on keypunch machines at the time (which would have supported neither
 the choice of := nor the choice of - or <-).  I have added a
 postscript with some material originally part of a different posting to
 Humanist that also went into the oubliette.]

 In Humanist 34.31 and 34.37, various people make some useful comments
 on Willard's question about the := notation for assignment, but some
 of them rouse in me the spirit of contradiction and some that of
 pedantic dispute.  And in the process of writing about them, I have
 argued myself out of my original position, so that I no longer know
 how to respond to Willard's original question, beyond being
 satisfied that no one has yet provided a good answer.

 In 34.31, Henry Schaffer writes, inter alia:

>     The state of the technology available at the time also has an
>     effect. E.g.  why not write A <- B + C instead of A = B + C ? One
>     very good reason is that there was no <- character available in
>     the ASCII set of characters used at that time. So instead = was
>     used and it was *defined* in FORTRAN, Basic and elsewhere as put
>     the value of what is on the right into the variable whose name is
>     on the left. It's not at all a question of what the symbol means
>     in a different context such as math, it's the definition of what
>     it means in this context.

 With the first sentence, I am inclined to agree; it summarizes very
 well the bulk of my private response to Willard.  But see below.

 With the middle part of the paragraph, I partly agree.  That is, I
 think it eminently plausible to believe that the choice of notations
 in Fortran may have been influenced by the character sets available at
[message truncated]

        Date: 2020-05-22 10:26:54+00:00
        From: Manfred Thaller 
        Subject: Re: [Humanist] 34.48: software as applied mathematics

Dear Michael, Dear Willard,

a few scratches on the problems' surface from me.

When you look into the toddler's stage of ALGOL's childhood you come
across Backus' 1959 paper "The Syntax and Semantics of the Proposed
International Algebraic Language of the Zurich ACM-GAMM Conference"
lovingly preserved at

In the relatively loose description, the assignment operator appears
indeed already as in later ALGOL, "x := a + b". If you look at the more
formal syntax, the definition is:

Original definition of assignment statement [see attached image]

As you see in the graphic, Backus had not yet learned to write proper
BNF, alternation being written as or with overstrike instead of "|" and
the "defined as" as a colon followed by three horizontal lines, instead
of the familiar "::=". Somehow it is very hard not to get the suspicion,
that at least the later change was due to the convenience of a notation
which did not require hand-written symbols. (Courtesy of Wikipedia
(https://en.wikipedia.org/wiki/List_of_mathematical_symbols) I learn, by
the way, that the three horizontal lines - without the leading colon -
are used in mathematics to express equivalence; unfortunately it does
not say when the notation appeared.)

I am no historian of science, but my historian's suspicion, that the
trivial explanations are usually correct, leads me to the thesis, that
Backus carried the "defined as" from his "metalinguistic formulas" which
seem to have been central to him at the time, over into the object
language, though in a simplified form.


Mathematics and programming.

At the University of Göttingen, possibly not quite as much the center of
accademic excellence as it usually sees itself, but undoubtedly one of
Germany's finer ones, has an institute of Computer Science, which was
founded in 2002. (In case anyone wonders: the university goes back to
1737.) That it was the last major university in Germany to acquire such
an institute is related to the fact that the local divine of the then
faculty of Mathematics maintained stubbornly right into the nineties,
that computer science was something totally unfit for the mind of a
proper sage of mathematics, if worthy of academia at all. (That the
start of Computer Science in Germany a few decades earlier was crippled
by the fact that it was frequently used as an excuse to employ
researchers with a background in numerical analysis for whom chairs at a
mathematics department could not be found and some of which proclaimed
loudly later that "as professor of Informatik I hope never to have to
see a computer close up" is another matter. Ralph Griswold (Snobol,
Icon) confessed to me once that one such specimen from Germany managed
to be one of the few people he found really personally offensive. But I

On a less anecdotal level, I think that the relationship between
Mathematics and Computer Science ..., make that Mathematics and Software
Engineering, is one of the more complicated ones. Undoubtedly, there are
quite a few problems where the application of a formal mathematical
calculus is responsible for the solution of a problem. But in many cases
heuristics - defined by a computer scientist I cannot trace anymore as
"any dirty old trick which will make an algorithm do what you want it to
accomplish" - are at least as important. If you look into the working of
the JPEG algorithm, e.g., you will find that some of the passes
successively applied to the image data are strictly formally defined,
while at least one of them consists of bit shuffling which is basically
based upon empirical findings.

A nice object in case is actually the handling of graphs. I had my first
- or rather: only - class in graph theory in 1977. At that time the
majority of mathematics guys I had access to were quite disdainful of
the "alleged" proof of the four color theorem of 1976 [any map can be
colored with four colors in such a way that no two adjacent areas have
the same color]. Reason: That proof was accomplished by purpose built
software. Somehow I doubt that the mathematical hardcore has changed its
opinion, just because in 2005 another proof was accomplished by a
generalized theorem prover.

I mention graphs as this domain provides a quite interesting example,
which shows how different the emphasis in a nominally identical field of
research can be in mathematics and in software engineering.

Within the literature on knowledge-graphs you will find quite some
interest in "nested graphs". [ A graph containing relationships between
a set of concepts, which as a whole are contained within a single node
of a superordinated graph. ] As a result - without any claim of
completeness - nested graphs are provided for in major graph markup
languages, allowing the exchange between graph based software systems,
as GraphML (http://graphml.graphdrawing.org/primer/graphml-primer.html)
or GEXF (https://gephi.org/gexf/format/).

Within the mathematical literature on graphs at least to my admittedly
amateurish knowledge of graph theory, I find scarce traces of that
concept. The 2017 edition of Reinhard Diestel's "Graph Theory"
(Springer, Graduate Texts in Mathematics) knows about various types of
nesting problems within graphs, but does not acknowledge the existence
of a "nested graph" as a distinct animal. Balakrishnan and Ranganathan
"A Text Book of Graph Theory" (Springer, Universitext, 2012), which is
somewhat closer to software technology, does not know about nesting at all.

There ARE some traditions, however, which speak strongly for the
equation "software = 'applied mathematics' ". These are some strands in
the development of the application of information technology to
Humanities problems. The one I a most familiar with is that of the
application to (not exclusively, but frequently social-)historical
problems. Here statistical software was frequently seen not so much as
an enabling tool for statistical techniques which could in principle
have been applied by hand, but as an application of "computer science".
But I have always assumed this enthusiasm for "statistics"  among IT
using historians in the seventies and eighties as somewhat impure, as
the huge majority in my experience used statistics simply as an answer
to the eternal question how to come to grips with classes of source
material, where the individual entry is meaningful only, if you observe
it in the company of a few thousand similar entries.  Which is why
statistics was replaced as guide fossil of IT applications within the
(historical) Humanities by databases in the later eighties / nineties,
where you did not have to bother about these annoying problems of
(statistical) encoding.

And this tendency to mistake the application of an instrument (a
statistical package) by itself as a formal approach in computer science,
seems to propagate itself ever since from hype to hype.

Which is why I agree with Michael that the equation "software = 'applied
mathematics' " is wrong; but also agree with Willard, that it is common
and frequent.

Kind regards,

Am 22.05.2020 um 08:00 schrieb Humanist:
>                    Humanist Discussion Group, Vol. 34, No. 48.
>              Department of Digital Humanities, King's College London
>                     Hosted by King's Digital Lab
>                         www.dhhumanist.org
>                  Submit to: humanist@dhhumanist.org
>          Date: 2020-05-22 05:49:19+00:00
>          From: C. M. Sperberg-McQueen 
>          Subject: software as applied mathematics
> Willard writes:
>> A common move is to call software 'applied mathematics',
> Perhaps we just hang around with different groups of people, but I
> haven't encountered this move before.  Whom are you talking about?  And
> what do they mean?  If what they mean is that software is applied
> mathematics and 'applied mathematics' is another name for software as a
> field, I can only advise you to keep smiling, make no sudden moves, and
> back slowly but firmly away. If what they mean is that software
> development is a field in which mathematics can be applied, then I
> agree:  software development is an activity in the known universe. But
> I don't understand why you are hanging around with people who make
> portentous statements which, when their meaning is ciphered out, turn
> out to be tautologies, and not very surprising ones at that.
> I confess to being mildly disappointed by your decloaking.
> The question "where did the := of Algol 58 assignment statements come
> from?" is fairly interesting, and I have learned some things I found
> worth my while, from thinking about it and from what posters to
> Humanist have said about it and from attempting to confirm or falsify
> various possible answers.
> The most promising line of inquiry at the moment appears to me to be
> Herbert Wender's observation that := is used in set theory (and, I have
> learned, in mathematics more generally) to mark a definition and to
> stress that the relation is asymmetric and a matter of definition, in
> contrast with the equals sign and the identity or triple-barreled
> equality sign, which describe symmetric relations which are matters of
> fact about independently defined objects.   (See for example [1] and
> [2].)
> [1] https://mathworld.wolfram.com/Defined.html
> [2]
> https://math.stackexchange.com/questions/182101/appropriate-notation-equiv-
> versus
> If one could establish that := was in use in this way by the 1950s (and
> preferably earlier, when those sitting on the Algol working group had
> received their mathematical training), it would be very difficult to
> resist the conclusion that the Algol symbol was adopted from its
> mathematical usage, like a number of other symbols in Algol 58's
> reference language.  Unfortunately, the only history of mathematical
> notations on my shelf appears not to have an index of symbols.  I can
> hardly blame the author, but still it makes it difficult to know
> whether he discusses the origin of this particular bit of notation or
> not.
> If the origin of := is in mathematical notation, then things look bleak
> for the proposition that the function of yoking the colon to the equals
> sign is to signal that software is mathematics with a difference.
> The question "what is software in relation to mathematics?", on the
> other hand ... well, if I think of it as a sort of koan, I can just
> about see a point in the question, but most of the time I cannot.  So
> the only answer I can suggest is one you will I fear find painfully
> obvious:  two French hens and a bathtub full of brightly colored
> machine tools.
> Michael

Prof. em. Dr. Manfred Thaller
Zuletzt Universität zu Köln /
Formerly University at Cologne

BackusAssignment.png: https://dhhumanist.org/att/98759/att00/ 

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

Editor: Willard McCarty (King's College London, U.K.; Western Sydney University, Australia)
Software designer: Malgosia Askanas (Mind-Crafts)

This site is maintained under a service level agreement by King's Digital Lab.