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: firstname.lastname@example.org  From: William Pascoe
Subject: Re: [Humanist] 33.777: the 'secret' of a programming language (109)  From: Michael Piotrowski Subject: Re: [Humanist] 33.788: evidence for the linguistic relativity of programming languages? (72) -------------------------------------------------------------------------- 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 -------------------------------------------------------------------------- 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: email@example.com 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.