| Home | About | Subscribe | Search | Member Area |
Humanist Discussion Group, Vol. 33, No. 789.
Department of Digital Humanities, King's College London
Hosted by King's Digital Lab
www.dhhumanist.org
Submit to: humanist@dhhumanist.org
[1] From: William Pascoe
Subject: Re: [Humanist] 33.777: the 'secret' of a programming language (109)
[2] From: Michael Piotrowski
Subject: Re: [Humanist] 33.788: evidence for the linguistic relativity of programming languages? (72)
--[1]------------------------------------------------------------------------
Date: 2020-04-22 04:14:07+00:00
From: William Pascoe
Subject: Re: [Humanist] 33.777: the 'secret' of a programming language
50 Words For (i = 0; i < snow.length; i++)
The 'reality' that conditions or is conditioned by language is not so much the
hardware but the problem domain (often very fuzzy and ill defined). Usually in
quotidian practice the problem domain determines the language. You want it
public, with people updating all over the world? A data driven website. Are you
at a Uni or commercial? Uni? so something link, Linux, Apache, PHP, Mariadb.
Sometimes it is determined by staff available. You have a lot of cheap Python
developers because the bachelor degree teaches Python, and they are religiously
opposed to PHP, you use Django instead of Laravel for your web dev. So mostly -
the reality determines the language. EXCEPT when language determines, such as
when you have that one person, or an expert in their field and they only know
one language. Then the conventions of that language come into play. Eg: I worked
with engineers who knew Fortran. Everything they did was old school turing
machine procedural. They didn't do anything object oriented. That made it very
difficult to convert their research work into reusable desktop software
application. Sometimes also you get someone from one programming background
programming in a style that is not suitable in this other language, or for the
problem domain. Eg: a C programmer, working in Java for a desktop app, built in
the 'chaining' paradigm everywhere which made it exceptionally difficult for
other programmers to figure out what was going on stepping through the debug.
However, I have to say - all these problems would be hidden from the end user,
and I don't think affected the research question. Our job as developers was to
work around all those problems and just make it work - the user clicks an icon
that does something. In that sense it's perhaps fortunate that the user and the
researcher didn't understand development so well, otherwise the programming
language constraints might have determined the research and the user
requirements more.
In any case it's very much a negotiation and a cyclic process, rather than one
thing determining the other. It's how it works and spirals as an interactive
feedback system that needs analysis, and which can lead research down one path
or another.
But let's look at the hardware 'reality' and the question of how hardware might
constrain our languages, and approaches, etc, or if it is vice versa, whether
languages determine hardware.
This also can work both ways. One example of where hardware and languages might
have been different is parallelism - because our languages are at bottom,
serial, parallelism is very limited and clumsy. (I'm not mathematical enough to
understand properly, but I think I've heard of some continuous math problems
that are intractable, or at least extremely awkward because you always reach the
point at which computation being discrete makes a difference to the outcome, but
they are rare.)
This is a two way thing, hardware and software began as very close
implementations - binary literally is a physical switch. It turned out to work
very well, so languages are built on discrete binary hardware, so we improve
that hardware on that assumption, and the software proceeds on that assumption,
leaving alternatives way way behind in development so they can't compete. Which
is to say language conditions hardware (better discrete serial hardware to run
our better discrete serial software) *and* hardware conditions software (better
discrete serial software to run on our discrete serial hardware).
Parallel computing is very clumsy and simple. Compared to our massively parallel
brains, you might use just a few chips in terms of hardware and you tend to have
to specially design software to make best use of them, otherwise your software
is still serial anyway, though the OS can speed things up a bit by spreading it
across chips. Software 'threading' seldom uses more than a few, or even a few
hundred is still 'small', and it is always tricky trying to write code for
threading - it always seems, even if in some cases it might really be parallel,
that it's a *simulation* of parallelism built out of, or on top of, serialism.
The main question for me is - does it make any difference? And if so what is the
difference? Everything emergent on a macro scale can be reduced to something
else - minds are 'just' brains, brains are 'just' atoms, etc. So does it matter
if parallelism is 'just' reducible to serialism? I figure there is a point to
which it matters and a point beyond which it doesn't, and it's mainly about
time. Eg: Let's say it takes 1 second to run one process. In a simple case let's
say in parallel we can run 2 of these processes in one second, but in serial it
takes 2 seconds to run 2. Let's say output to input of a parallel system runs at
100 processes a minute - if you have a serial system, that runs 100 times
faster, and performs all the functions of the parallel system, but just one
after the other - then the serial v. parallel implementation makes no
difference.
In summary:
- It is more generally the problem domain that determines language choice and
language improvements, such as whether you choose a language that is more for
web, that is more object oriented, that is superfast for HPC, that is
functional, that is more declarative, etc.
- But sometimes, pragmatic and social concerns mean you end up with a programmer
working in a language that is not the best for the purpose, or using a style
that doesn't suit that language, but the consequences are more a headache for
the developer rather than visible to the researcher or user anyway. (If you are
all three, you probably have a very big headache or blissful ignorance.)
- If the language doesn't do something you need you add functions, you *change
the language*, which is the whole point of software development: 'structure'
itself is the medium we mould. (Or often yes, you say, 'we can't do that in
budget', which does constrain research and functionality and leads to a
negotiation.)
- Sometimes it's a good thing if researchers and users don't understand
software, because these naive or ludicrous requests can drive developers to
develop functionality but as often as not it is a negotiated trade off dependent
on budget, but through that negotiation we at least understand what is in the
software and what is not.
- It's not that the reality of problem domain or hardware structures language,
but that they are all part of a system of feedback loops, which head in a
direction that is likely to constrain, determine and direct possible research,
discourse, consciousness and reality (which I guess you can say of most things
anyway - and since I'm talking about a mutually determining feedback loop
between 'reality'/environment, language and consciousness, yes I guess you can
call this eco-critical stance).
Bill Pascoe
--[2]------------------------------------------------------------------------
Date: 2020-04-21 16:07:21+00:00
From: Michael Piotrowski
Subject: Re: [Humanist] 33.788: evidence for the linguistic relativity of programming languages?
Dear Willard,
On 2020-04-20, Willard McCarty wrote:
> The fact of such funding from such a source supports my suspicions,
> based on prowling the Internet for the past several days, that there's
> not been much beyond emotive handwaving in response to this question
> and studies of peripheral relevance (e.g. Fedorenko et al).
I agree.
> My primary findings include the following:
>
> 1980. Kenneth E. Iverson, "Notation as a tool of thought". 1979 ACM
> Turing Award Lecture.
> 1982. Edsgar Dijkstra, "How Do We Tell Truths that Might Hurt?" (EWD498).
> [...]
>
> Add to the above list -- or swipe it away and replace it with something
> more promising?
I think there are even earlier relevant papers (some of which explicitly
refer to Sapir–Whorf), such as
1972. F.B. Thompson and B.H. Dostert, “The future of specialized
languages.” https://doi.org/10.1145/1478873.1478913
1975. Peter Naur, “Programming languages, natural languages, and
mathematics.” https://doi.org/10.1145/512976.512991
1977. Jerry R. Hobbs, “What the nature of natural language tells us
about how to make natural-language-like programming languages more
natural.” https://doi.org/10.1145/800228.806936
1980. Richard L. Wexelblat, “The consequences of one's first
programming language.” https://doi.org/10.1145/800088.802823
What you may also find interesting is work going in the “opposite”
direction, i.e., on programming languages that correspond more closely
to natural languages:
1979. Bruce Wilson Ballard and Bruce W. Ballard, “Programming in
natural language: ‘NLC’ as a prototype.”
https://doi.org/10.1145/800177.810072
2005. Graham Nelson, “Natural Language, Semantic Analysis, and
Interactive Fiction.”
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.2870
Some variation of Sapir–Whorf obviously also underlies all work on
non-English-based programming languages, but most of these attempts
remain more or less curiosities.
While the Chicago project is certainly interesting, one issue one
frequently sees is that the programming language is understood as
“given” rather than as a human-designed modeling framework for a (more
or less) specific purpose. In order to work with this framework you
have to adapt your thinking to match its modeling approach—but this is
intentional! This is admittedly less obvious with so-called
general-purpose languages (especially in an educational setting), but
becomes very clear when you consider domain-specific languages.
Best regards
--
Prof. Dr.-Ing. Michael Piotrowski
Professeur en humanités numériques · Université de Lausanne
Co-directeur académique du Centre UNIL-EPFL en humanités numériques
☎ +41 21 692-3039 · Quartier Chamberonne, bât. Anthropole, bureau 3137
OpenPGP public key 0x926877BF1614A044
_______________________________________________
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.