cadadr | Entries tagged with computing

This post is based on an idea that I randomly had, which I first thought to merely share with friends through a private social media account, but then it exceeded the sensible length for a social media post a bit, and this time round I was sensible enough to turn it into a blog post instead of a long ranty thread that clogs up my mutuals' timelines. This is raw thought: I haven't spent a long time considering this idea, it's potentially flaky, I haven't done any research. It's merely an interesting idea I wanted to put into more words than a pithy social media "take". Enjoy responsibly.

Thinking a thought:

There are throughlines common to orientalism and "AI" slop generators.

In its essence orientalism is about reductionism and about obscuring the "oriental" interlocutor: first create the "Orient" as a monolithic, homogenous Other, and then ascribe words, stories, culture to them that has nothing to do with their reality, saturating the venues through which people of different cultures can get to learn about each other.

Thus, ascribed untruths about the Orient displace actual knowledge of the peoples melded into that chimera.

Now when we look at "AI" bullshit, there, instead of Asia, North Africa, and Eastern Europe, reductionism targets the phenomena of communication and perception in whole. They are all reduced into a computerising model of the mind, that entails a seemingly-but-not-really-oxymoronic positivist metaphysics.

This obscuration then intends to saturate all channels of human communication, detaching the perceived from the perceiver, and the receiver from the sender, in the Jakobsonian sense; in simple English, it displaces and obscures our conversation partners. We no longer talk to someone, or appreciate someone's art, but instead, fabricated, adulterated, "palatable" misrepresentations thereof.

In either case there's not only a common structural pattern in how the abuse and displacement formulates, materialises, and operates itself; but also there is the common thread of dehumanisation: on the "AI" side, the humanity of the interlocutor, the author, the artist, the creator, the performer, are converted into a nondescript and inorganic end product: the Slop. Much like the end product orientalism generates: the pseudo-Orient. A marred, distinct replacement of the original (which is scarcely genuine in itself, as there's neither a coherent and singular Orient nor a computable model human thought and communication can be reduced to), a replacement that's meant to appease the receiver, the listener, the spectator, at all costs, without ever inconveniencing them, turning reality into merely an irrelevant detail, an optional ingredient in a high-sugar, high-salt, high-calorie recipe, much like those crisps that you cannot stop eating once you begin snacking on them.

The most basic, the initial one of these "costs" for enticing the audience of both the Slop and the pseudo-Orient is, to forego knowledge. Interacting with the Slop, much like interacting with the pseudo-Orient, replaces interacting with the people that are trying to communicate with us from behind this false image of themselves. And given that, to send people "AI" Slop of course means forcing them into that position, forcing them to interact with a plastic nonrepresentation of ourselves. In a sense it is like the tourist trap cafés found along the touristy streets and avenues of Sirkeci and Sultanahmet in İstanbul. Nought but a mirage, and not even a misrepresentation.

In either case, these mirages that result from these fraudulent means of interaction of course then affect actions people take. Misrepresentations, misjudgements, mistruths feed into discriminatory outcomes, into bitter interactions when the cushion wall of the swindling intermediary fails to be present to mediate, when the defrauded needs to interact with the Otherised on the basis of the Ersatz-Other they were furnished with in its stead.

As generators of misrepresentation and "prejudice"—so to speak, as a feeble shorthand—, both orientalism and "AI" create easily "consumable", inaccurate, but convenient and—for the consumer, prepared to be—comfortable caricature of the Other, which monopolises its perception by the "user/consumer". Who then acts on the basis of such a caricature, and in the right circumstances, such actions can lead to disaster.

I am thinking of examples, some of which feel like too hyperbolic to just say out loud without thinking about it (I fear trivialising one side of the comparison), but suffice it to say there are active venues in which both orientalism and "AI" come together to do inscrutable harm to humanity. An encounter that is perhaps not coincidental, but instead maybe a sad fruit of the comparison here outlined.

Current Mood: pensive
Current Location: İstanbul

This post used to be titled «tabocide», but since then I've grown a dislike to that name, and also modified my process a bit, so I renamed the post and edited it a bit to reflect how I do it now. The main difference is I don't keep tabs open anymore, but instead keep them in a bookmarks folder.

Something I do with some regularity is «tabqueueing and tabdequeueing»

Basically, instead of keeping tabs open in my browser, I shove them regularly as they accumulate into a folder called tabqueue, and close them. After, when I have the time, I schedule a tabdequeue session where I process these bookmarks one by one, after opening them all in a fresh new window and deleting the tabqueue folder, and moving the tabs open on my phone there also (for this purpose I use KDEConnect). Of course I don't just throw them away, but they get reviewed, and they have a few fates available to them:

new papers / books / other publications accumulate from reading RSS feeds mostly, they get shoved into my reference manager (Zotero these days) or dismissed;

news or opinion articles, blog posts, and similar, that accumulate over time, get read and/or bookmarked on the spot, otherwise dismissed or shoved into Instapaper;

fediverse posts, mostly my own, which get dismissed or get copied to my digital notebooks;

I'll often have web searches open, usually on DuckDuckGo or Google Scholar&emdash;these usually get turned into to do items if can't be processed on the spot;

and finally a random assortment of stuff that gets treated ad hoc, often Github repositories or other software=y stuff, temporary tabs that got forgotten, etc.

The aim is to do this once every week, but usually it's once or twice every month. As tabs near and surpass a hundred-ish, I get nervous (because even tho I have pretty good backups these days, I don't ever trust Firefox to not bork my session and get me in trouble, something which it has done a lot). Also for this purpose and for keeping the browser performant, I've modified the process to queue the bookmarks in a bookmarks folder, instead of just keeping them open in a browser window.

This way I can keep on top of many tabs.

A question that probably comes to your mind is, why not use a reading list / bookmarks / ... for this purpose. Well, that is probably a better way to do it (not to mention lighter on my computer), but fact of the matter is, something that goes into a list, in my case, tends to stay there, unattended, unless I set up a separate workflow for each list. As in, if I was shoving abstracts into a "check these abstracts later" list, they'd never get looked at. That will lead to all my reading lists overflowing with random stuff I found interesting and gave no proper consideration as to whether I need it or not.

This way, I can keep my reading lists fairly cleaner and I don't end up with thousands of stuff in my Zotero database with a reading list longer than a few bibles worth of pages. That's what tab(de)queueing is about for me: looking at things, judging whether I want to come back to them later, as opposed to just mopping things up as I encounter them.

Just listened to @nasser@merveilles.town's talk on multilingual programming, titled "A Personal Computer for Children of All Cultures" again.

As a (for now) linguistics student I really like this talk and highly recommend it. But also as a linguistics person coming from a programming background, it has me thinking and I have some questions and ideas I want to voice, with the belief that asking these questions early on in a project like Ramsey's will help us design these solutions such that in departing from the domination of English in programming languages and communities, we don't involuntarily find ourselves in another form of inequity's dominion: that of monolingualism, which itself comes from the exact same source as English's global dominance and destructive status.

First of all, I think the next step / next big question here is how to enable bilingual programming, code switching in code.

Code switching is extremely common, and in ways we don't often think it exists. E.g. languages have registers and styles, and we go between these pretty frequently (e.g. formal to informal, programmer jargon to kitchen jargon to just small talk [hehe] vocabulary), besides switching between more major linguistic varieties, like what we call languages and dialects (which are political terms and not linguistically sound, but I'll avoid that discussion here).

Could that happen in code within this framework?

So my languages are Turkish, English, and Italian. With Ramsey's ideas, I can write modules that are in one language or another, and my whole program can be multilingual. But could it be possible for a declaration, say the body of a function to be code switching between Turkish and English? I could of course do that with "local identifiers", using Ramsey's terminology, but could I also do it with keywords and external identifiers? Because it's very common for a bilingual community to do code switching not only at conversation or whole text level, not only between sentences, but even mid-sentence.

So imagine:

int main (void) {
    const char* w = "world";
    puts(sprintf("hello, %s", w));
    return 0;
}

How could we allow, then:

sayma_s baş (boş) {
    sabit harf* m = "il mondo";
    puts(sprintf("ciao, %s", m)); 
    ritorna 0;
}

which starts out with Turkish but outputs and ends with Italian, and has some English identifiers in the middle. (There's also the %s in there which is a complicating factor, as it definitely comes from the English string, but that can be completely replaced with something like string interpolation probably.)

This is a toy example of course, but there can be real-world situations where this becomes a cultural question. Imagine me collaborating with an Arabic/Armenian/Greek/Kurdish-speaking programmer on a given module as a speaker of Turkish. There's a cultural domination/injustice relationship there, and every time we decide on a module's language, that'll come into play as I'm relative to them, privileged. And it's not only a me-question, as it's likely that this decision takes place in Turkish-dominated spaces in Turkish-dominated conurbations and political settings.

And then a related question is of course what linguistic varieties get access to being a "language" versus a "dialect" versus an "argot/jargon/style/slang" and similar. None of these categories are scientifically sound, they are all political. Which is why we invent terms like "variety", "register" and similar in linguistics, because the structural properties are seldom what political properties capture.

This of course leads us on to the question of how we encode linguistic varieties, how do we decide which linguistic variety is active for a given snippet of code at each level, and how do we do this without making it difficult so that the devised solutions don't lead English or some other lingua franca to take over all other practical uses of the solution. Yes we have international codes for languages, but they are also centrally gatekept by institutions of the Western world, and they carry the same (de)politicising linguistic ideologies that today govern the statuses and the status quo regarding which varieties get to be called languages and which dialects, which get representation and which are devalued, which are kept around and which are left to wither.

⁂

Another question is how this maps to existing ways of combining multiple programming languages, because it poses both opportunities and challenges.

E.g. we readily use the ironically named FFI's to communicate across programming-linguistic boundaries, so using extern "C" or it's analogue in many programming languages, you can combine them at some level. And there are other facilities, like RPy, Pymacs, and similar. I think reworking these a little bit should actually really help with going beyond human-linguistic boundaries in programming too.

For example new ABIs can be developed for existing libraries that do not use the English names, but some other identifiers, hashes or otherwise. I believe (as a fairly inexperienced programmer when it comes to anything beyond small stuff and scripting, but still) that there should be ways to incorporate the existing codebase the world has developed into an emergent multi-human-lingual paradigm of programming without simply having to rewrite it all.

But also we have other ways of multi-programming-lingual combination, or code switching, if you will. These manifest themselves in the likes of Knuth's literate programming or Emacs' Org Mode's and Rmarkdown's similar-but-not-exactly-the-same mechanisms. Could we exploit these systems' ideas in developing programming environments that can combine multiple human languages and multiple programming languages? Why shouldn't that be possible?

Because in Org mode, which is the system I'm most familiar with at this point, the programming languages bit is at least possible, practical, and also highly useful. For example consider this setup script I have for my Raspberry PI which combines Emacs Lisp and Bourne Shell programming languages liberally, using Org Mode's mechanisms for doing so. (You can search for begin_src in the file to explore how the two very different languages are used and combined in the literate script.)

These literate programming environments could easily be used for any compiler for a multi-human-lingual programming language/environment, that's pretty straight-forward, but what's food for thought is how such a sytem can take advantage of the ideas and tools developed by the said literate environments over the last ~50 years, despite relative obscurity among especially professional programmers.

⁂

This is all I have for now. I am really excited for a future where programming becomes customarily multilingual in both human and programming language dimensions, because as someone who is advancing towards a career in academic scholarship and as a long-time hobbyist programmer, and as a non-native speaker of English, I have personally experienced how limiting it can be when programming tools are exclusively targeted at English-speaking professionals, and what sort of things become possible once we start breaking those barriers.

I believe Ramsey's doing god's work in breaking some of these barriers with thinking about how to make programming work for all human linguistic varieties, and hope that this text here contributes some questions/ideas to consider in such efforts. Really, thank you Ramsey!