Navigation – Plan du site

AccueilNuméros30-2Undone Computer ScienceGlobal and Local Implications of ...

Undone Computer Science

Global and Local Implications of Computational Artifacts

Pierre Depaz
p. 65-79

Résumés

Cet article étudie la science non faite du passage à l’échelle des logiciels. La recherche en génie logiciel se concentre sur les multiples façons dont les logiciels peuvent passer à l’échelle supérieure, mais jamais sur les possibilités de les faire passer à l’échelle inférieure. En nous basant sur la compréhension géographique de la notion d’échelle, nous émettons l’hypothèse que les échelles sont construites, plutôt que données, et nous soutenons que la conception et l’utilisation d’artefacts computationnels spécifiques – langages de programmation, structures de données et protocoles de communication – participent activement à cette construction matérielle. À travers une série d’études de cas, nous discutons de la manière dont ces artefacts computationnels permettent le calcul informatique tant à l’échelle locale qu’à l’échelle globale.

Haut de page

Texte intégral

1 Introduction

1Software affords scaling: through the combination of data abstraction and process automation, it can perform the same function across an increasing set of inputs. This desirable, ubiquitous property in software engineering posits that a good software application is one which is able to either remain reliable when faced with input variation (concurrent users, traffic, database entries, etc.), or one which can be easily modified in order to handle such change [Northrop, Feiler et al. 2006]. Software scalability is therefore understood as the ability to continue to perform effectively as the workload shrinks or grows. Yet, the underlying assumption about such scalability is that it should only be expected to happen in one direction: up.

  • 1 A concern for the rebound effect was already the cause for programming language des (...)

2The scaling up of software, in part an imperative driven by business logic [Narayan 2022], is correlated with an increased carbon footprint [Simon, Rust et al. 2023], leading researchers to discuss the sustainability of software engineering, and into its responsibility for resource depletion. However, some parts of this science remains undone [Hess 2016], as the research regarding sustainable software focuses on quantified and measurable optimization of hardware resources, such as CPU usage [Pereira, Couto et al. 2017]. While necessary, we nonetheless consider these kinds of investigations prone to enabling a rebound effect, through which efficiency gains are offset by consumption increases.1 Similarly, centralizing computing resources might initially reduce resource use per instance of running software but also tends to support an increase of the use of such software, as per the same rebound effect [York, McGee et al. 2016].

3With regards to the current climate crisis, the mitigation scenarios usually considered in engineering and computer science departments are those where having more technological innovation is part of the solution rather than part of the problem [Maraninchi 2022], [Crozat 2023], effectively addressing only half of the problem space [Boddie 2000], and suggesting more fundamental shifts in our consideration of our relation with technology. In this sense, we situate our argument for rethinking software scalability within a broader shift, in which the local production (of knowledge, goods and practices) is considered to be the antidote to the current global (and harmful) hyper-industrialization of the bio- and noospheres [Stiegler, Sonnenschein et al. 2021].

4This article looks at what contributes to this expandability of software, and at how the scaling down of software applications can be achieved. Scaling down is understood here as giving preference to local, rather than global, solutions, engaging with resources tending towards immediacy, rather than over-mediation, and intending to limit unnecessary growth and expansion. While such scaling down is not uncommon in software, it is rarely made explicit as virtuous behavior and a design goal, and is often confined to being an ad-hoc approach within the productive work of large-scale organizations. To address this question, we will focus on what enables computational artifacts [Turner 2018]—including programming languages, protocols and data structures—to be essential parts in the scalability of software applications [Odersky, Spoon et al. 2008], [Vainier 2016]. We argue that such computational artifacts do not operate on predefined, distinct scales; rather, they participate in making these scales a reality precisely by rendering them usable and tangible, in conjunction with broader use-contexts of infrastructures, discourses and communities.

5Geographers offer a nuanced problematization of scale (e.g., local, regional, global), centered around whether scales exist as ideal concepts, or as socio-material productions [Herod 2010]. For idealists, the local and the global scales (two extremes) are part of a pre-existing conceptual matrix of scales within which social life is lived, distinguished from one another as part of a hierarchy of resolutions. For materialists, scales are socially and materially produced through processes of struggle and compromise. For instance, the national scale is not simply a scale which exists in a logical hierarchy between the global and the regional but, instead, a scale that had to be actively created through economic, technological and political processes, e.g., signing treaties, minting coins and building roads. Starting from a materialist conception of scale, we will show how computational artifacts, as intentional creations with a functional purpose, materialize ideas and embody actionable models through their syntax and semantics, and therefore contribute to constituting different scales.

2 Constituting globality

  • 2 Still, as different levels of abstraction are related across each other, it becomes possibl (...)

6Historically, programming languages have tended to abstract away the physicality of hardware. The advent of modern operating systems contributed to this tendency through portability—the ability for a programming language to be executed as is the case on various hardware platforms. This is particularly salient in the case of C, whose portability both supported and was accelerated by the diffusion of UNIX [Ritchie 1996]. Considering computing through the method of levels of abstraction [Primiero 2016], the execution and machine code operations levels lose relevance as a result of this portability, and the programmer’s focus switches to high-level programming languages and implementation.2 As programs scale up or down, the user’s meaning-making of a program shifts in the same direction across the levels of abstraction [Buda & Primiero 2024].

7The dynamic in which the high-level programming language takes the focus away from the operating system, itself abstracting the hardware, is articulated with the increase in networked software applications resulting in cloud computing—i.e., computing at a global scale [Mell & Grance 2011]. Networked computing relies on requests and responses to disjoin caller and callee in the execution of computational functions—for instance, the Common Gateway Interface (CGI) for websites blurs a client’s understanding of which physical machine would be doing the computation resulting in the display of a customized webpage [Coar & Robinson 2004].

8As programming is fundamentally an information management technique which in turn produces more information, the amount of data to be dealt with also increases, which is best seen in how its storage is referred to, moving from databases to data warehouses and data lakes [Franklin, Helvy et al. 2005]. In order to manage these new orders of magnitude, special tools have to be designed, tools which normalize this new scale of operation.

9One of these tools is GoogleSQL, the programming language of BigQuery, Google’s solution to handling large amounts of data. As a declarative language, it requires an underlying engine (Google’s Dremel) in order to translate its statements into effective operations—enabling abstraction at the expense of additional layering. As a procedural language, it treats SQL queries as statements within statements and operates on them via control flow procedures, making the large scale at which data is created and processed more easily manipulable, with SQL statements recast as quasi-primitives.

10GoogleSQL also does not exist in a void, but in a network of specific dependencies. Its execution environment, the Google Cloud Platform (GCP), is a required dependency with ambivalent implications: it hides the hardware components of running code, but, by offering a kind of pay-as-you-go programming [Mucchetti 2020], it reveals the financial costs involved in executing GoogleSQL queries. By making it possible to perform very-large-scale computing, GoogleSQL participates in the conception of large-scale computing, the globalized exploitation of (corporate) data unifying a network of localized hardware through a single software syntax: global-scale computation is made usable within the (seemingly) local scale of GCP.

  • 3 Not quite a programming language, yet not a software application either.

11MapReduce is another programming technique designed to handle the global distribution of multiple groups of machines across geographic localities. This programming model3 highlights the active, yet ambivalent role of programming in co-constructing a global scale, by aiming to reconcile diverse sources of data. Originally designed for the Google Web search service, a global service if ever there was one, MapReduce operates through a first step of harmonization (mapping the unprocessed inputs to normalized outputs), followed by a second step of conflation, in which diverse inputs are operated on in order to collapse into a single output, effectively reducing the multiple into one [Dean & Ghemawat 2008].

12Interestingly, the MapReduce model only proves to be more effective when multiple machines are involved to complete the computation, solidifying the working assumption of global distribution. In the source code of the original paper describing the model, we can see the modularity and “summoning” of machines, which is always pluralized.

Listing 1: MapReduce enables the large-scale management of machines

// Tuning parameters: use at most 2000
// machines and 100 MB of memory per task
spec.set_machines(2000);
spec.set_map_megabytes(100);
spec.set_reduce_megabytes(100);
// Now run it
MapReduce result; 
if(!MapReduce(spec, &result)) abort(); 
// Done: `result' structure contains info
// about counters, time taken, number of
// machines used, etc.
  • 4 Paradoxically, such mention of hardware within software is very similar to embedded program (...)

13Listing 1 shows how so-called “cloud” computation at a global scale is made particularly visible by directly specifying the quantity of machines involved, in the source code.4

14Finally, in order to perform large-scale computation, one should also specify which machines should be made available to MapReduce-enabled software applications. Here configuration languages, a specific kind of programming languages, have evolved to accommodate a paradigm of infrastructure as code.

15Chef, Puppet, or Terraform are languages that make the provisioning of large swathes of individual machines connecting to a single piece of software trivial. Infrastructure as code, or rather infrastructure subdued as code, is no longer concerned with mere CPU cycles, but whole ranges of machines become as expendable as code. In other words, the reification of a global scale takes place through making usable the increasing abstraction of increasing amounts of computational resources (no longer CPU cycles but server racks). Still the hardware specifics transpire once again through the source code (see the literal references to Amazon Web Services product offerings in Listing 2 [HashiCorp 2023]).

Listing 2: Terraform renders large-scale material infrastructure programmable

resource "aws_instance" "server" {
   count = 4 # create 4 similar EC2 instances
   ami = "amia1b2c3d4"
   instance_type = "t2.micro"
   tags = {
           Name = "Server \${count.index}"
   }
}
  • 5 In this case, the feature of programming languages to create abstractions could be mapped t (...)

16The examples discussed here illustrate how programming languages take an active part in making globality actionable (that is, enabling activities across the globe and untethered to the specifics of a geographical or material connection). They do this through the general process of abstraction, fundamental to any programming, but also by developing new languages to specifically harness the new problems that emerge with this desire to scale up.5

3 Imaginations of the local

17The local scale is on the other end of the spectrum of ideal scales and can be conceived of as that which is physically or intuitively graspable—a machine within arm’s reach, or an assemblage of machine and software systems which we can represent as a satisfying mental model, have agency over, and be responsible for.

  • 6 The networked is an essential step towards the global, as we discussed above.

18The networking of computers nonetheless complicates this. Within the network, the programmer’s terminal is referred to as —localhost—, a label of locality revealing that the device exists as both a physical device and a network device. —localhost— is a local device that is always part of a Local-Area Network (LAN), a first group of networked devices usually within the same physical vicinity, and defined by opposition to the Wide-Area Network (WAN), equivalent to what is commonly understood as Internet access. It is local, since it has the specificity of looping back onto itself, but it is also networked, and so it blurs the distinction between both local and networked,6 due to the potential to slide into the distant sharing of computational executions mentioned above.

19To distinguish these different scales, we can consider, with Cox, the spaces of dependence which they imply—that is, the identification of, and agreement with, resources and agents which one depends on [Cox 1998]. This approach highlights the relations between individuals, the network they create, and its essential role for the proper functioning of said individuals—local scales having smaller spaces of dependence than global scales. Whenever software has a network requirement, it creates a further-reaching space of dependence, subverting any attempts at better delimiting what constitutes a local kind of computing as compared to its more global counterpart.

20While there is no simple correlation between a computational artifact’s general technical dependencies (e.g., packages and libraries) and its scale(s) of operation, we focus here on network dependency. A most extreme example is Microsoft’s Excel introduction of a Python integration in August 2023. Paradoxically, using Python (a standalone interpreter which comes pre-installed locally on several popular operating systems, yet not on Microsoft Windows) requires a network connection. The official reasoning for creating this kind of dependency on being online is, in fact, to facilitate the management of the dependency tree of Python modules. A wider space of dependency is replacing a narrower one. Network dependency also contributes to the need for scaling up software. If a software product (meaning both its technical and economical components) is to grow, both in users, data and revenue, and if users are to use this product exclusively through sustained online connections, the additional load is borne by the software platform, and ultimately relies on global-scale-making languages such as infrastructure-as-code in order to sustain this model.

21Data structures are machine-readable, formal representations of data which possess certain properties. Along with physical infrastructure, they are essential to network communication. For instance, an HTTP request is structured so that each request contains all information in order to be acted upon in its entirety. This is unlike a TCP (Transmission Control Protocol) packet, whose design includes information about other, preceding or succeeding, packets. These two data structures are, respectively, self-contained and fragmented, and therefore imply particular configurations of the larger programming systems within which they are used, and of the software applications they support. While the function of both computational artifacts is the same (to transmit information), their difference in structure nonetheless complicates the grasping of their implications. Recalling Turner’s distinction [Turner 2018], we can argue here for a causal, materialist view of function, meaning the structure of a computational artifact will influence its function given a specific context, as it provides affordances for a certain set of functions to be performed both through the intent of the designer and of the user. Particularly, we argue here that some specific structures can have a better functional fit to local contexts, and others to global contexts.

22One computational artifact bridging local and global ends of computing, through an engagement with the network-enabled spaces of dependence, is the Conflict-free replicated data type (CRDT), first proposed by Marc Shapiro and Nuno Preguiça, to allow for the separate modification of a shared resource and the subsequent reconciliation of these modifications into a new canonical version of the resource [Preguiça, Marques et al. 2009]. Practically, they allow separate users to edit their local copy of a document, and ensure that different users’ versions of the same document can be cleanly merged into a consistent result. Consequently, network connectivity shifts from being a required dependency to an optional dependency: the canonical state of the document is resolved without conflict when a client regains network access and receives updates from other clients. Although this kind of design was proposed in multiple scientific articles in the mid-2000s, the concurrent advent of Google Docs in 2006 made the technology obsolete even before being used, according to Shapiro [Shapiro, Preguiça et al. 2011]. This displacement of a scientific innovation by a technical one shows some of the limitations of theoretical work in the face of an immediately performing application.

  • 7 For instance, Jupyter Notebooks, a popular data science app, restored its collaboration too (...)
  • 8 See for instance PushPin, a collaborative multimedia editor.

23Still, the practical efficiency of usable software is put to question as the drawbacks of operating within certain spaces of dependencies become more obvious.7 For software to materially contribute to an alternative scale, it must perform. It is this need for performance which underpinned the development of the Automerge library, a JavaScript implementation of a CRDT by the Ink&Switch independent research lab [Kleppmann & Beresford 2018]. The format of the library is a productive manifestation of an implementation: by being made available as a self-contained package, it can then be used to develop software applications and pre-figure the kind of scale and space of dependencies which are made possible by CRDTs. As software applications are built on top of Automerge,8 we observe a chain of entries, from the formal description of a data structure in a technical document, to its implementation in a library, and its use in a user-face software application, intended to represent a particular conception of connectivity and of local computing, in a manner typical of rhetorical software [Doyle 1997].

24Rhetorical software, software which aims at proving a point, is complemented by more traditional rhetorical means, such as the publication by Ink&Switch of a local-first manifesto, in which the needs for, and the benefits of, reconsidering the space of dependence are clearly stated and in which centers of gravity are reconsidered. In the case of the client-server architecture of the Web, servers turn to a supportive role, and are no longer the single source of truth [Kleppmann, Wiggins et al. 2019]. The function of computational artifacts is thus also framed discursively, arguing that, while networking represents a technical blurring of the line between local and global, these artifacts, or chain thereof (here, the CRDT-Automerge-Pushpin chain), can be used as components in a broader argument for a scaling down software via a local-first approach.

4 Material and social engagements

25Complementing spaces of dependence, Cox also suggests considering scales as spaces of engagement, in which action can be taken by a given actor and agency can be deliberately and meaningfully exerted. A possibility of scaling down should also be considered through this lens of both material and social engagements, at scales that depart from the always-online cloud computing. Materially, this implies travelling down the pyramid of abstraction constructed by computational artifacts, while, socially, it demands consideration of the connection between programming languages and their communities of practice. We can see the interaction of scale, sociality and technology through the material instantiation of a social network based on the SecureScuttleButt (SSB) protocol.

26SSB formalizes gossip-like, machine-mediated, social interactions. Its design relies on social and technical requirements (respectively user-first and LAN-first) and is based on models of rumor distribution, or epidemics—a pseudo-random selection of proximal peers to whom the information will spread. The aim is to define a technical protocol as a simulation of natural phenomena, based on the principle that information will have social patterns within it, and that such simulation can have both local and global properties, the way epidemics and rumors spread [Tarr, Lavoie et al. 2019].

  • 9 Tarr, the designer of the SSB protocol, lives on a boat off the coasts of Oceania.

27As a protocol, SSB replicates the experience of life at sea-a very specific experience of scale-by allowing synchronization between two peers only if they are connected to the same LAN network, mimicking the sharing of news once one docks at a port.9 Its starting axiom is thus offline availability, as the protocol and its applications must be usable when not connected to the Internet: all data storage and access takes place locally, and the synchronization of data takes place when, and if, there is a connection to another member of the network. As synchronization occurs between two peers on a LAN, the design of the protocol implies that there would never be a requirement to scale beyond the reach of the local connection.

  • 10 A social network is seen to be more useful and more valuable according to the amount of (...)
  • 11 “We aim to return (cloud) computing back into our homes and local communities in a way whic (...)

28However, in order to mediate between the local requirements and the global aspect of what the network effect requires,10 SSB introduces the concept of pubs, which are special SSB clients facilitating the exchange of messages across regular clients—just like humans might go to bars to get their fill of the latest rumors. Pubs can be deployed through cloud computing infrastructure, and made accessible anywhere and at any time as a regular website but, as a protocol where politics and ethos are strongly intertwined with technical decisions, this approach of relying on global infrastructure has seemed at odds with the core values of the project [Depaz 2024]. The PeachCloud project is an alternative pub intended to manifest what a value-aligned network infrastructure would look like. To do so, it bundles the SSB software necessary to run a pub into an easy-to-use, all-in-one hardware solution, rooting their technical design and development in a dual material and social engagement.11

  • 12 For an another example of this kind of engagement, see Low Tech Magazine, a website hosted (...)
  • 13 “We chose Rust because it gives a nice feeling of presence, that I feel I had lost, or even (...)

29As a response to renting cloud-scale computing, PeachCloud uses affordable RaspberryPi hardware and the Rust programming language—an embedded systems language—to run an SSB pub anywhere. The goal was to implement the full SSB server, easily installable on a small device, itself fitted with buttons and an OLED screen as a way to favor direct material engagement with the kind of hardware that is usually stored in data centers—but which could now be set up in a living room.12 Additionally, the choice of Rust, beyond its embedded programming features, involved the need for a different kind of connection, focusing on the social as well as the technical dimension.13

  • 14 See: https://www.planetary.social.

30The PeachCloud team originally had the choice between two original implementations: a wrapper around the Go implementation of the SSB protocol, or an adaptation of an existing Rust implementation, with both of these implementations having different implications. On one hand, the Go implementation tended towards having large-scale Web systems, that were developed by a social network whose name, Planetary, echoes dreams of global-scale computing, which are the same as the employers of the Go designers—Google.14 On the other hand, the choice of Rust provided access to a different kind of community, one “working on solarpunk social protocols with Scuttlebutt” [glyph 2023], explicitly referencing a specific kind of techno-optimistic fiction, solarpunk, in a further interweaving of technical aspects and culture, and of action and fiction.

31This entanglement of the social and the technical dimensions is manifest in programming language communities, in the values put forth by the different programmers involved in using, improving and sharing the language. In the case of Rust, this language was originally designed by the Mozilla foundation, a community-oriented non-profit foundation, communicating values of social inclusion and human-centeredness. This linguistic community of practice translated to the SSB foundation itself, as it funds tutorials written in Rust, in order to onboard and empower people to make it their own [glyph 2022]. PeachCloud justified its adoption of the language for reasons that are equally social and technical and, as a result, adjusted the technical scaling to the scope of their communities of programmers.

32PeachCloud as a hardware project was ultimately put on pause, due to funding limitations and lack of free labor often essential to the sustainability of open-source projects. It is nonetheless an attempt to choose a language for two deliberate reasons; to engage materially with an infrastructure which felt too remote (as seen with the embedded programming fit) and, to engage socially with other people writing in the same language (as seen in linguistic communities).

5 Conclusion

33Given the encouragement for software to scale up, this article has investigated the role of computing artifacts both in enabling this scaling up and alternatives aimed at scaling down. Starting from the geographical position that scales of operations are made and not given, we argued that computational artifacts—programming languages, data structures and protocols—are actively involved in co-constructing those scalar realities.

34In discussing the languages that enable global cloud computing, we have shown a paradoxical relationship to the materiality of computing. Programming languages tend towards ever-increasing level of abstraction and a supposedly greater distance from the computing hardware, but large-scale data manipulation and infrastructure-as-code nonetheless reveal a renewed engagement with machines, albeit on a quantitative, rather than qualitative, basis.

35The network requirement for effective software applications blurs the line between global and local. The discussion of the CRDT and its implementations, as the Automerge library and the PushPin multimedia editor, illustrate how software artifacts can be part of a techno-discursive rhetorical process of scaling down, articulating a local-first scale of computing. Similarly, the PeachCloud project approaches scale as a space of engagement, both materially and socially, through a programming language which engages with low-level embedded systems, as well as linguistic communities. This last point leads us to consider the role of ownership structures in the scaling of computational artifacts: a centralized, vertical entity (a private corporation or a public institution) might more easily deploy hardware and software resources at a large scale, while horizontal, decentralized communities might need to scale up their very organization before scaling up the computational artifacts they employ.

36The role of science and the context of industrial productivity in scaling up software should not go unquestioned, both for intrinsic epistemological reasons and for the extrinsic ecological consequences of an ever-increasing material footprint. In this perspective, we have suggested that computational artifacts should be considered as not only handling scales, but also contributing to their co-construction and, by extension, to our socio-economic realities.

Haut de page

Bibliographie

Boddie, John [2000], Do we ever really scale down?, IEEE Software, 17(5), 79, 81, doi: 10.1109/52.877871.

Buda, Alessandro G. & Primiero, Giuseppe [2024], A pragmatic theory of computational artefacts, Minds and Machines, 34(1), 139–170, doi: https://doi.org/10.1007/s11023-023-09650-0.

Coar, Ken A. L. & Robinson, David [2004], The Common Gateway Interface (CGI) Version 1.1, Request for Comments RFC 3875, Internet Engineering Task Force, doi: 10.17487/RFC3875.

Cox, Kevin R. [1998], Spaces of dependence, spaces of engagement and the politics of scale, or: Looking for local politics, Political Geography, 17(1), 1–23, doi: 10.1016/S0962-6298(97)00048-6.

Crozat, Stéphane [2023], Low-technicisation et numérique, Séminaire de recherche.

Dean, Jeffrey & Ghemawat, Sanjay [2008], MapReduce: simplified data processing on large clusters, Communications of the ACM, 51(1), 107–113, doi: 10.1145/1327452.1327492.

Depaz, Pierre [2024], Critiques protocolaires d’Internet: comparaison des projets IPFS et SecureScuttleButt, tic&société, 18(1), 90–118, doi: 10.4000/12nsg.

Doyle, Richard [1997], On Beyond Living: Rhetorical Transformations of the Life Sciences, Stanford: Stanford University Press.

Franklin, Michael, Halevy, Alon, et al. [2005], From databases to data­spaces: A new abstraction for information management, ACM SIGMOD Record, 34(4), 27–33, doi: 10.1145/1107499.1107502.

glyph [2022], lykin_tutorial, https://git.coopcloud.tech/glyph/lykin\_tutorial.

glyph [2023], Solarpunk (social) hardware with Scuttlebutt, https://opencollective.com/peachcloud/updates/april-2022-june-2023.

HashiCorp [2023], The count Meta-Argument—Configuration language, https://developer.hashicorp.com/terraform/language/meta-arguments/count.

Herod, Andrew [2010], Scale, London: Routledge, doi: 10.4324/9780203641095.

Hess, David J. [2016], Undone Science: Social movements, mobilized publics, and industrial transitions, Cambridge, Mass.: The MIT Press, doi: 10.7551/mitpress/9780262035132.001.0001.

Jahns, Kevin [2021], How we made Jupyter notebooks collaborative with Yjs, https://blog.jupyter.org/how-we-made-jupyter-notebooks-collaborative-with-yjs-b8dff6a9d8af.

Kleppmann, Martin & Beresford, Alaistair R. [2018], Automerge: Real-time data sync between edge devices, https://mobiuk.org/abstract/S4-P5-Kleppmann-Automerge.pdf.

Kleppmann, Martin, Wiggins, Adam, et al. [2019], Local-first software: You own your data, in spite of the cloud, in: Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, New York, NY, USA: Association for Computing Machinery, Onward! 2019, 154–178, doi: 10.1145/3359591.3359737.

Maraninchi, Florence [2022], Let us not put all our eggs in one basket, https://cacm.acm.org/magazines/2022/9/263806-let-us-not-put-all-our-eggs-in-one-basket/fulltext.

Mell, Peter & Grance, Tim [2011], The NIST definition of cloud computing, Tech. Rep. NIST Special Publication (SP) 800-145, National Institute of Standards and Technology, doi: 10.6028/NIST.SP.800-145.

Mucchetti, Mark [2020], Managing BigQuery costs, in: BigQuery for Data Warehousing: Managed Data Analysis in the Google Cloud, edited by M. Mucchetti, Berkeley, CA: Apress, 61–71, doi: 10.1007/978-1-4842-6186-6_4.

Narayan, Devika [2022], Platform capitalism and cloud infrastructure: Theorizing a hyper-scalable computing regime, Environment and Planning A, 54(5), 911–929, doi: 10.1177/0308518X221094028.

Northrop, Linda, Feiler, Peter, et al. [2006], Ultra-Large-Scale Systems: The software challenge of the future, Tech. Rep. ADA610356, Software Engineering Institute, Carnegie-Mellon University, https://apps.dtic.mil/sti/citations/ADA610356.

Odersky, Martin, Spoon, Lex, et al. [2008], Scala: A scalable language, https://www.artima.com/articles/scala-a-scalable-language.

PeachCloud [2019], Introduction, https://mixmix.github.io/peach-devdocs/chapter\_1.html.

Pereira, Rui, Couto, Marco, et al. [2017], Energy efficiency across programming languages: How do energy, time, and memory relate?, in: SLE 2017: Proceedings of the 10th ACM SIGPLAN International Conference on Software Language Engineering, 256–267, doi: 10.1145/3136014.3136031.

Preguiça, Nuno, Marques, Joan Manuel, et al. [2009], A commutative replicated data type for cooperative editing, in: 2009 29th IEEE International Conference on Distributed Computing Systems, 395–403, doi: 10.1109/ICDCS.2009.20.

Primiero, Giuseppe [2016], Information in the philosophy of computer science, in: The Routledge Handbook of Philosophy of Information, edited by L. Floridi, Routledge, 90–106, doi: 10.4324/9781315757544.

Ritchie, Dennis M. [1996], The development of the C programming language, in: History of programming languages—II, edited by T. J. Bergin & R. G. Gibson, New York: Association for Computing Machinery, 671–698.

Shapiro, Marc, Preguiça, Nuno, et al. [2011], Conflict-free replicated data types, in: Stabilization, Safety, and Security of Distributed Systems, edited by X. Défago, F. Petit, & V. Villain, Berlin; Heidelberg: Springer, Lecture Notes in Computer Science, 386–400, doi: 10.1007/978-3-642-24550-3_29.

Simon, Thibault, Rust, Pierre, et al. [2023], Uncovering the environmental impact of software life cycle, in: 2023 International Conference on ICT for Sustainability (ICT4S), IEEE Press, 176–187, doi: 10.1109/ICT4S58814.2023.00026.

Stiegler, Bernard, Sonnenschein, Carlos, et al. [2021], Anthropocene, exosomatization and negentropy, in: Bifurcate: There Is No Alternative, edited by B. Stiegler & The Internation Collective, Open Humanites Press, 45–63, https://www.openhumanitiespress.org/books/titles/bifurcate/.

Tarr, Dominic, Lavoie, Erick, et al. [2019], Secure Scuttlebutt: An identity-centric protocol for subjective and decentralized applications, in: Proceedings of the 6th ACM Conference on Information-Centric Networking, New York: Association for Computing Machinery, ICN ‘19, 1–11, doi: 10.1145/3357150.3357396.

Turner, Raymond [2018], Computational Artifacts: Towards a Philosophy of Computer Science, Berlin; Heidelberg: Springer, doi: 10.1007/978-3-662-55565-1.

Vainier, Mike [2016], Scalable computer programming languages, https://web.archive.org/web/20170214042027/http://users.cms.caltech.edu/~mvanier/hacking/rants/scalable\_computer\_programming\_languages.html.

Wirth, Niklaus [1995], A plea for lean software, Computer, 28(2), 64–68, doi: 10.1109/2.348001.

York, Richard & McGee, Julius Alexander [2016], Understanding the Jevons paradox, Environmental Sociology, 2(1), 77–87, doi: 10.1080/23251042.2015.1106060.

Haut de page

Notes

1 A concern for the rebound effect was already the cause for programming language designer Niklaus Wirth’s call for “lean software” [Wirth 1995], as he worried improvements in hardware would only lead to bloated software—a worry that materialized.

2 Still, as different levels of abstraction are related across each other, it becomes possible to consider how the structural affordances of a lower level can affect a higher level—a programming language affecting the implementation of an algorithm, itself informing a posteriori the specification of an intention.

3 Not quite a programming language, yet not a software application either.

4 Paradoxically, such mention of hardware within software is very similar to embedded programming, the kind that is focused on specific hardware architectures.

5 In this case, the feature of programming languages to create abstractions could be mapped to the abstracting processes of global business intelligence.

6 The networked is an essential step towards the global, as we discussed above.

7 For instance, Jupyter Notebooks, a popular data science app, restored its collaboration tools using CRDTs after Google got rid of the cloud service it had previously depended on. As an abstract specification with no legal or economic ties, a CRDT therefore reconfigures the space of dependence of a given software, and redefines the local’s relationship to the global [Jahns 2021].

8 See for instance PushPin, a collaborative multimedia editor.

9 Tarr, the designer of the SSB protocol, lives on a boat off the coasts of Oceania.

10 A social network is seen to be more useful and more valuable according to the amount of users who are part of it, whether or not they are in immediate interaction.

11 “We aim to return (cloud) computing back into our homes and local communities in a way which fosters increased trust in one another and the socio-technical systems we inhabit” [Peach & Cloud 2019].

12 For an another example of this kind of engagement, see Low Tech Magazine, a website hosted on a solar-powered computer, at https://solar.lowtechmagazine.com.

13 “We chose Rust because it gives a nice feeling of presence, that I feel I had lost, or even never really had when I was writing Python Web apps” (personal correspondence of the author with developer @maxpicks).

14 See: https://www.planetary.social.

Haut de page

Pour citer cet article

Référence papier

Pierre Depaz, « Global and Local Implications of Computational Artifacts »Philosophia Scientiæ, 30-2 | 2026, 65-79.

Référence électronique

Pierre Depaz, « Global and Local Implications of Computational Artifacts »Philosophia Scientiæ [En ligne], 30-2 | 2026, mis en ligne le 01 mai 2026, consulté le 11 juin 2026. URL : http://journals.openedition.org/philosophiascientiae/5351 ; DOI : https://doi.org/10.4000/16955

Haut de page

Auteur

Pierre Depaz

Universität Basel (Switzerland)

Haut de page

Droits d’auteur

CC-BY-NC-ND-4.0

Le texte seul est utilisable sous licence CC BY-NC-ND 4.0. Les autres éléments (illustrations, fichiers annexes importés) sont susceptibles d’être soumis à des autorisations d’usage spécifiques.

Haut de page
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search