Alan Kay's Quora dialogues and the philosophical dilemma of Systems thinking

General
1

Over the last seven years or so, Alan Kay has been answering questions on Quora ( https://www.quora.com/profile/Alan-Kay-11 ). There’s now a book-length amount of text there from Kay on his philosophy of programming and what he sees as the current big challenges for the Internet and for computer science.

Since Quora is an annoying platform to browse, a few months ago I downloaded all of Kay’s dialogues up to that time and put them on Archive.org as a PDF ( Alan Kay Quora 2023 11 : Free Download, Borrow, and Streaming : Internet Archive )

I’ve been reading through them since (in chronological order - you have to start at the end of the PDF and go backwards, unfortunately), and pondering over the very conflicted feelings I get from Kay. Trying to understand just what his vision of object oriented programming is, and whether I think it’s a good idea or a bad idea, because I’m not really sure.

Here’s an example of that deep sense of philosophical conflcit that I’m chewing on at the moment, from 6 years ago ( https://www.quora.com/If-you-had-to-teach-‘Computer-Science-101’-how-would-you-begin-your-first-lecture ) :

How far and large can we go before things get out of hand and we lose our way in too
much abstraction? I’ve always been partial to the characterization of Alan Perlis — the
first Turing Award winner and who perhaps coined the term “Computer Science” —
who said in the 60s: “Computer Science” is the “science of processes”. All processes. For
Quora, let’s not try to pound this further or make it into religious dogma. Let’s just
happily use Al Perlis’ idea to help us think better about our field. And especially how
we should go about trying to teach it.

…

Another reason for Al Perlis’ choice of definition is because computing in the large is
much more about making systems of many kinds than it is about algorithms, “data
structures”, or even programming per se. For example, a computer is a system,
computations are systems, the Ethernet and Internet are systems, and most programs
should be much better systems than they are (old style programming from the 50s
has lingered on to the point that it seems to many that this is what “programming” is
and should be — and nothing could be farther than the truth).

Okay. So far so good. Alan Kay likes systems more than he likes data structures and algorithms. I get that. As a philosophy, it sounds good. The real world (especially the biological and social world) is made up of systems, not data. Therefore, let’s make everything live, reactive, autonomous. Make everything out of small computers, sealed boxes, exchanging information and control through messages. We started to do this in the 1970s, but we got distracted by early and partial results like the Macintosh, C++, and HTML, so let’s finish the job and build out JCR Licklider’s original ARPA computational utopia. It’s a very romantic, stirring, dream. The Internet’s version of Manifest Destiny.

But!

We now live in an Internet which is an extremely hostile environment. The freedom we once took for granted from the 1990s through 2000s is under attack from multiple angles: from trillions of dollars of speculative venture capital forcing ever more complex and ever more centralized systems. From militaries and governments trying to turn our personal automation into surveillance devices. From weaponised hacking groups, often as part of active shooting wars, trying to deliberately destroy and subvert our automation. From machine learning and generative AI, tools which are fundamentally incapable of being understood even by their creators and are adding vast amounts of opacity and complexity and centralization onto an already frayed social fabric. Because of all this, we now have a massive crisis of trust, and an increasing sense of depression and fear that this already bad situation can now only spiral down into something even worse.

And all of this toxicity and damage - in my opinion - is enabled by the Internet increasingly being about systems and NOT being about algorithms and data structures. Because data structures and algorithms can be stopped and analyzed and checked for safety in ways that live, interactive, always-on systems just can’t be.

This is the conflict I’m feeling right now, reading Alan Kay’s words and trying to parse out his vision. He wants programming to be more about systems, but I’m already afraid that we’ve built too many systems that now have lives of their own and are not under sane human control. And that perhaps the way to win back some small element of control and trust, before it’s too late, can only come from moving away from live systems and back to “dumb” data structures and fully exposed algorithms, completely separated from both data and network.

In other words, I worry that we should not imagine a global network of active closed biological cell-like systems exchanging messages. Rather, we should imagine a global network of dumb data structures that we exchange as data, not as messages. And then local, detached algorithms completely under our control that we apply to those data structures.

This is a very different vision from Kay’s. So I worry that Kay’s unfinished ARPA/PARC vision, exciting as it is, would move us in precisely the wrong direction if anyone were to try to pick it up and implement it.

Here’s another example of Kay’s vision, this time in the words of another old ARPA AI veteran, Carl Hewitt. Hewitt’s words - against the backdrop of the Cloud of 2024 - fill me with a sense of utter bleakness and dread:

Project Liftoff: Universal Intelligent Systems (UIS) by 2030

Universal Intelligent Systems (UIS) will encompass everything manufactured and every sensed activity. Every device used at home and work will be included as well as all equipment used in recreation, entertainment, socializing, and relaxation including clothing, accessories and shoes.

Information will be integrated from massive pervasively inconsistent information from video, Web pages, hologlasses (electronic glasses with holographic-like overlays), online data bases, sensors, articles, human speech and gestures, etc. Information integration will enable an intelligent system to be used by other intelligent systems without having to start over from scratch. Information inference will be robust taking into account multiple sources and perspectives and counterbalancing many interests and perspectives. UIS will largely overcome the current reuse pain point that there is no effective inference for information that is balkanized in applications. An Intelligent System will be educable so that it can interactively adapt in real time (instead of relying exclusively on passively attempting to find correlations among inputs.

An Intelligent System will be self-informative in the sense of knowing its own goals, plans, history, provenance of its information. Also, it will have relevant information about its own capabilities including strengths and weaknesses. When overload or other internal trouble is inferred, an Intelligent System will be able to reach out as appropriate to people and other systems.

Security will be paramount for an Intelligent System so that it is not easy to penetrate or to deceive into taking inappropriate action.

Project Liftoff™ to develop and deploy UIS in this decade stands to be a huge development effort comparable to the Apollo Project. Education will be crucial to the success of Project Liftoff because there is an enormous talent shortage.

US has yet to commence Project Liftoff, but there is a growing consensus that a large effort is required to address issues of universal Integrative Intelligent Systems. China is racing to develop its own indigenous universal secure intelligent systems as rapidly as possible [Liu, 2020, Cheng, Feifel, and Shuia 2019, Xin and Chi-yuk 2018, China State Council 2017, Lewis and Litai 1988. Evan Feigenbaum 2003].

The goal of Project Liftoff is to achieve universal Integrative Secure Intelligent Systems by 2030. Project Liftoff is a development effort comparable to the Apollo Project. Education will be crucial to the success of Project Liftoff because there is an enormous talent shortage.

To which I can only say: good lord, no. Do not build this Project Liftoff thing. Don’t even joke about this. If the USA tries to do this, it will go so, so bad, in so many terrifying ways. In fact, it doesn’t even need to go bad - just from reading this text, I can tell it’s already bad.

Yet “Project Liftoff” is also exactly the old ARPA/PARC vision, which sounds so uplifting. The lost Internet we didn’t build, but could! It sounds so hopeful, so awe-inspiring. And here we are on the threshold of achieving it, and it’s one of the most scary things I can imagine. Because you know these “intelligent systems” will be built by and for the military and billionaires, not by and for people, and their idea of “security” will be about stopping ordinary users from having any effect at all. The result will be cataclysmically bad.

Do any of you feel this deep philosophical conflict in Kay’s ideas too? If so, how should we resolve it?

6 Likes
2

I’m certainly partial to the argument I first heard from Richard Feldman that Alan Kay’s “hard OO” view of the world turns every problem into a distributed computing problem. Which feels counterproductive!

1 Like
3

Yep, and not just turning all algorithms into distributed computing, but all data into Turing-complete algorithms. Which also feels similarly counterproductive, on a slightly different axis. Both distribution and Turing-completeness introduce infinities and unpredictability where none existed before.

These are perhaps “just technical” issues but they also play into and amplify the (in my mind) scarier social axis of the user of a sealed Turing-complete box no longer being in control of any systems they interact with, and which have now flipped to controlling our lives.

Here’s another example of the dilemma, adding Richard Stallman to the mix:

In order for a user to be fully in control of their automation (and therefore enjoy Safety, Security, and Privacy), I believe they NEED the ability to, at any time, request and update the current source code and state data of all of the objects/systems they are interacting with. Without this, they have no guarantee that the system is working for them and not against them. Or even doing anything at all.

However any user of a shared system/object being able to request/update source code and state data also explicitly violates guarantees of Safety, Security, and Privacy made to other users, not to even mention commercial availability, confidentiality and intellectual property. Doing so not only violates Kay’s vision of Object-Oriented programming but often these days comes with strict, real-life, legal penalties.

A move to strictly hosting our own services is one possible answer, yet the loud legal demands for Safety, Security and Privacy are pushing people away from this and toward centralized services, where they give up all actual Safety, Security and Privacy in the name of Safety, Security and Privacy Theatre. Nobody thinks this is great, but it absolves the users from legal responsibility.

And even without the legal penalties, it’s hard for the users to manage their own security, even if we could somehow build a trustworthy VM which didn’t need constant security updates.

This is quite a difficult dilemma, I think.

(To his credit, I think Kay’s vision of OO includes the user being able to debug it, which is what I’m asking for here. But how does debugging interact with “encapsulation”? And when we have an entire global network of systems/objects, where do we draw the line of who does and doesn’t have debugging/root access to each one?)

“Safety” these days is a particularly worrisome quality for distant designers to engineer into a system of automation. I can very easily see an interpretation of Isaac Asimov’s Three Laws of Robotics where the First Law is interpreted as:

No automation shall do anything on behalf of a user which can be construed by the Worldwide Safety Committee to cause Harm. Nor shall any automation, by inaction, cause Harm by refusing to implement any directive of the Worldwide Safety Committee.

And with that one Law, whoever sits on the Safety Committee owns the world.

1 Like
4

One mitigating factor on the security issue: if you had an object that can only compute, you don’t need to analyze it. It can’t do anything to you. So the level of exposure is proportional to available side effects or capabilities. You can have as much complexity in 99% of objects as you want, as long as you control the capabilities in a few simple objects that you understand thoroughly.

4 Likes
5

That’s a good point, especially if you can somehow control even the computation that a message send / function application does. Eg by enforcing hard limits on CPU cycles, stack, storage and network traffic, at the call level; or by a kernel that really does preemptive hard-realtime multitasking, and doesn’t just nod and wink in the general direction of the idea, like Windows currently does when a web page goes rogue and starves the whole system of resources.

And on the other hand, I do get very conflicting emotional responses from Kay. His heart is definitely in the right place here:

Libraries made their way in the US partly because they provided something not easily
found otherwise. Still, it’s sobering to realize that about half of all the libraries in the
US by about 1920 were there because they were funded by a single philanthropist
(Andrew Carnegie). He was an immigrant child laborer from Scotland and started his
climb to immense wealth in his early teens because his first boss opened his house
library to his laborers on Saturdays.

Most “Carnegie Libraries” had open stacks (apparently the idea originated with these
grants), and almost always a special room for children, and another special room
where reading was taught in the evenings.

In the ARPA-Parc work in the 60s and 70s on personal computing and pervasive
networking, two of the most compelling images for the future were to take ideas like
the Carnegie Libraries (with their special children’s rooms and rooms where you could
learn to read) and the Whole Earth Catalog (with its perspectives and interlinked
“systems of systems” of ideas) to the next levels that computers would make possible
— not just to imitate them and make them more convenient, but to extend what
literacy, reading, writing, understanding could be.

Today, libraries are on the decline, along with bookstores. -Something- is more
convenient for some people, and whatever this is has started to displace the old
resources and venues. As with many things in the age of electricity and electronics, the
displacement is not being done by replacement with media of similar value, but by
subsets, sometimes disastrous subsetting. For example, especially for good readers,
none of the screens available now are as good to read from.

Something I did not know about Carnegie, which gives me a faint glimmer of hope that we might yet be able to climb back out of the pit of our New Gilded Age.

1 Like
6

And as long as you don’t have so many of these simple objects that you get unpredictable emerging behavior.

1 Like
7

Maybe his concern is about the scale and opacity of the current systems?

1 Like
8

I’ve been reading through since I woke up this morning, and I don’t have thoughts on this yet, but thanks nate for putting it all together and downloadable like this.

image

4 Likes
9

I very much like that distinction between “serious engineers” and “scientists”. I worry that software “engineering” today has become more about “yay we learned something from that crash, let’s make another one”, and this idea is now carrying through to, say, SpaceX. And I don’t think that goes very good places when public infrastructure is built on that principle. I’m glad Kay is pointing this out.

I guess the question at the back of my mind, which has taken years to try to work its way out and still remains partly unformed, is this:

Systems thinking is good, and I agree that being able to treat a system of parts as a single element is an important part of “chunking” complexity to make it graspable by human minds.

But as far as I can see, a system is held together, and maintains its identity, not by messages but by relations between its parts.

A relation is a much stronger concept than a message. A relation is something that holds regardless of how the situation alters. A relation might be implemented by sending messages, but a message alone is not enough to guarantee or enforce a relation. A message can only implement a relation if the meaning of the message - its full semantics or behaviour - is predictable and known to the sender in advance. If, as in OOP, the receiver of a message is mutable, has hidden state (including a hidden list of other mutable objects it knows) and can send messages to any of these other objects, the scope of “behaviour” that a single message send can cause is staggering. If this behaviour is neither predictable nor constrained, then this is very dangerous. (Still not as totally existentially destructive as, say, a rogue pointer in a single shared memory-map machine. But in practice, almost as dangerous.)

One way of characterising the relations that raw message-sending gives us, is to say that each message sent to each class of object (assuming that we know what class an object is; knowing this, ie, enforcing a “truth” relation between “what class are you” and the answer, again requires something more than just message sending), is actually its own individual relation. Ie, “add” sent to an instance of class Integer is one relation. “add” sent to an array is a completely different relation that just happens to (confusingly) have the same name. This isn’t very helpful - it seems that we would really like all messages called “add” to have “the same semantics” in some clearly defined sense. But it’s raw message-sending even with enforced class-identification can’t give us this. At best, it can tell us that “the result will be of a known type” or “this code implements the method, good luck analyzing it yourself”.

Another problem with message-sending as the only construct for building systems, is one often pointed out by Lisp people: message-sending “dispatches only on the type of a single receiver”. That is, the meaning / semantics / behaviour of a message depends on one value. But it turns out that we often want the semantics of an operation or relation to depend on more than one value. “Multiple dispatch” can be done in message-sending if the values are part of a message sent to an object representing the relation, rather than the relation being a message sent to the first value. So message-sending itself might not be the problem here, but rather the one-sided “always send the operation to a value” tradition in which messages have been interpreted, for Smalltalk and the OOP languages that follow the Smalltalk tradition. CLOS in Lisp, and C++'s generics I think escaped from this trap, but they did it at the cost of complexity.

However, message sending, despite not in itself being enough to implement relations and therefore structure systems, is still a very powerful concept because it is so simple, and because it maps very well onto communications systems.

Another paradigm that competes with message-passing is functional programming. A function is a kind of relation, but it’s not the only kind and functions alone are not enough to define a software system. (You can do computation with just functions alone - but a software system is much more than just naked computation. Software contains data, which lambda calculus doesn’t define, and it contains human-meaningful names, and mechanisms to limit unbounded recursion.) That’s why functional languages are often extended with “types”, which are another kind of relation. But even types are not the only kind of relation. Rather, type theories and type systems are constructed from relations.

However, this process of construction, and the underlying relations that build functional languages and their associated type theories, are not normally exposed to the programmer. This is because functional programming languages have to enforce the relations defined by their type theories somehow, and this is usually done by the process of “compilation”: an algorithm which defines a privileged process which is able to create privileged artifacts in the system (often large artifacts, whole systems themselves) which (theoretically) can’t be forged or altered so as to violate the relations that are supposed to hold between their components. This “privileged black box” approach doesn’t have to lead to the kernels of functional languages being large, or the process of their construction being hidden from the programmer - but in practice, in the current academic tradition deriving from ML (and Fortran/Algol before it - compilation wasn’t invented by functional programming), it tends to do so.

Despite the trust placed in the black-box compiler, however, compiled modules can be altered. The compiler really only makes suggestions. It’s actually the raw binary machine code, the filesystem, and the operating system kernel API, which together decide what really happens. The result is usually that any binary code, anywhere, inevitably can trigger security exploits. That’s why corporate “cybersecurity experts” are now trying to ban compilers from corporate workstations, which doesn’t seem like it will lead to good places in terms of human freedom, or even prevent security intrusions.

So both message sending, and compilation - at least if compilation is seen as a “large black box” that operates within an equally large black box of an operating system API - both feel like not quite the future of software. There’s something important missing, and imo it has to do with recognising relations as an almost invisible structuring piece.

What I’m looking for, and have been looking for for many years now, is a way of looking at programming that starts with raw relations as the simplest organizing principle, and then builds everything - algorithms, types, objects, messages, even data itself - out of very small and simple relations that somehow a very small and simple language/VM kernel can enforce.

Whether this would end up implemented as a form of message sending, I’m not sure. It just feels like there’s a very important and very simple paradigm there that even languages like Prolog and Kanren have only vaguely touched and that we haven’t yet seen its full force. By “full force” I mean something much smaller and simpler and more obvious, rather than larger and more complicated and obscure, than our current logic programming, proof assistant, or symbolic AI systems.

2 Likes
10

As additional support for my rant about relations, this very recent conversation about “the missing datatype”:

https://tylerhou.com/posts/datalog-go-brrr/

and Hacker News thead: The "missing" graph datatype already exists. It was invented in the '70s | Hacker News

But I have to say, no, non-Turing-complete Datalog still isn’t what we need, what we need is a full-featured relational programming language.

Edit: Working my way through Alan Kay’s dialogues and… he seems to be thinking about relations too.

I don’t think that “real OOP” as we thought of it then, is the way to go in the future (and didn’t then). Consider Sketchpad, and that it is programmed in terms of constraints that the system solves to guarantee a very close fit between what was desired and what is manifested. This is an early glimpse into “requirements-based programming”. It has something like objects — hard to get away from the main idea — but is “relational” rather than message-based (the messages are implicit, etc.) Sketchpad was a tour de force in many ways, including its solvers. But they didn’t go far enough to handle general requirements. Today I think this is doable via a half dozen new techniques plus enormously larger machine capacities.

1 Like
11

image
image1290×1854 106 KB

2 Likes
12

Mmm. Trying to find a way out of our current Very Bad Future (where the part that I think is bad is the centralisation and lockdown; I hope this is also the part Alan Kay thinks is bad) is why I’m interested in minimalist VMs and minimalist language kernels. I like Forth-like systems for their simplicity, but I don’t like that they don’t give any protection against running code taken from other people. I want a VM that can safely run any code whatever, where “evil code” is simply not a thing, so that code (even bytecode / machine code) can really become a legitimate form of speech and not be seen as a kind of inherently dangerous “weapon” that needs to be regulated and controlled. But I also want the VM itself to be simple to understand and implement.

This is where I’m struggling right now (and have been for years) to crystallize my intuition. OOP gives a little bit more protection than a raw memory dump, yet Object Oriented principles feel extremely hard to distill down into their simplest form, because everyone has a different idea of what the simplest form of OOP is. I noticed this gap between theory and practice around 20 years ago, and we still don’t seem any closer to having a consensus. The only thing that’s happened is that Functional Programming and minimalist computing have both become a little more mainstream than in 2004; but the industry remains even more divided than before on what the core principles of software engineering even are. We remain heavily dependent on very large, corporately-backed kernels and runtimes whose design doesn’t seem guided by any particular principles.

And I feel a deep sense of time pressure bearing down on us. Silicon Valley is trying to 1) run everyone’s servers, 2) make everyone’s endpoints depend totally on servers, and 3) as a result, intercept and control everyone’s information. To escape this, we need endpoints that don’t depend on centralised servers to run, and security that doesn’t depend on constant updates from a centralised trusted authority. To get there, it seems like we need an inherently safe, yet low-overhead, home-buildable and home-deployable language VM / OS kernel, that doesn’t impose central policy on what’s built or how it’s deployed. And yet despite 33 years of Linux, and hundreds of open source languages, it seems like we don’t yet have much in the way of simple all-in-one solutions that fills this particular gap.

2 Likes
13

I agree, it’s quite a dark timeline at the moment, it’s nice to imagine how things could have gone.

1 Like
14

I’m a broken record about this, but I don’t think you’ll ever be able to use a program without concerning yourself with its author and their intentions. Even that desire has some of the stink of globalization about it.

It is indeed a dark timeline, but I tend to focus on climate there. Computation is a minor evil compared to everything else we have going on. A perfect VM isn’t going to move the needle much even if it was possible.

15

That’s certainly a point of view. Would you say the same about “reading a sentence” or “thinking about a mathematical formula”?

Because when I say “code”, I’m thinking about things that could be, say, the size of a single sentence or formula. Or the size of a book. Might even be books. How careful do you think we should have to be? How much alertness do we have to keep pushing to the user, and blaming them when something goes wrong? When does a “sentence” or a “book” (what we now think of as a somewhat safe thing) become a “program” (a dangerous thing that many now believe is inherently impossible to reason about or control, and therefore should be treated like a weapon)?

I mean, sure, we should be thinking about where all media we encounter comes from, who made it, what their agenda is. I agree with this much. But, should we then decide that literacy and self-publishing could then be equally as dangerous as programming, and so that we should prevent people from accidentally reading sentences from unknown people?

Because we’re entering a world where “running non-officially sanctioned code on our own computers” is starting to be seen as a dangerous act, bordering on criminal - very similar to how literacy was seen a few centuries ago - and complacency about this idea among computer professionals worries me. A few decades ago, I didn’t get this sense that programs must always be inherently dangerous from people in the “hacker” community; yet I’m now hearing sentiments like this very often in the last few years. Something seems to have subtly changed in the community’s values.

16

I don’t think the change has been in my values, it’s been in deeper understanding of the implications.

You can certainly write programs that are like sentences. They just can’t have side effects. The moment a program can read/write state (local disk, remote network), you lose that prose-like nature.

Tech like capabilities can help, of course. I think it’ll just never ever obviate the need for some savviness. If you want to bring out a pentacle and make deals, it’s on you to make sure your counterparty isn’t the Devil.

It doesn’t seem that hard. I trust the core of Linux, and Lua, and LÖVE, and I think those 3 go a long way. What they lack is the aesthetics of an elegant VM. It’s quite possible somebody can improve there. They aren’t the only trustworthy projects in the world. But I’ll still evaluate a new VM on the trustworthiness of its purveyors.

I don’t think this particular battle is that grim. There are lots of people trying to do the right thing, and I find new ones everyday. We all just need to do our part by trying to adopt them, giving them our support.

You’re right about the danger, but it’s not inevitable. We all have to be more careful about how we vote with our feet. I’ve been having a conversation with someone about how it takes a thousand-dollar device these days to access basic services in much of the developed world. It happened because most of us were naive and not alert to implications. I’m culpable as well. I want to try to do better for the next battle. For example, I don’t want to give somebody fodder to say less than 1% of our users use the website, let’s retire it. That feels like the first step in preserving subversive software.

2 Likes
17

Yep, I think that’s what I’m trying to get at. There’s a continuum of how much state various languages or VMs allow programs to modify, and there’s different approaches to delimiting that state. The disk and the network both seem to be boundaries where a lot of the pain and danger occurs. If we can avoid letting programs get arbitrary read/write disk and net access, a lot of danger goes away.

I can see why “fantasy consoles” are popular: because they restrict very severely what a game “ROM” can do, and that makes them very safe. Same with tiny minimalist Forth systems. If a VM can only ever read/write to a single file as its “disk”, then it’s about as safe as old 1980s cassette or floppy based computers were. The trick comes when we want to do more computing at once than will fit inside a single 8-bit machine, or if we want to link several VMs together. Suddenly we need a kind of “meta-VM” to track changes and do isolation of our multiple VMs. At that point we’ve basically reinvented an OOP language… of some kind. But what kind? It would be nice if we didn’t accidentally reinvent the complexity of Java, the Web, Kubernetes, or even Squeak/Pharos. Most of the complexity in those systems seems to be caused by the core VM/kernel not having the right set of abstractions for the task it’s inevitably called upon to manage.

I need to play with Lua and LÖVE more, and see how easy it is to transfer my current Javascript tinkering base over to it.

18

I think there isn’t any intrinsic technical barrier to combining an unlimited memory footprint with strict permissions on disk/network. Capabilities seem orthogonal to programming language and so on. As best I can tell it seems to have to do with what we’re willing to put up with. Languages and programs without network feel broken to our coddled minds. Fantasy consoles are at least partly a hack to get around that. As one extreme idea, somebody should invent a platform that strictly provides only screen/keyboard/mouse/touchscreen/joystick and no file system/network.

It might even be easy to rip out some code from LÖVE to get this. For example, it already has some restrictions on what directories games can read/write. Unfortunately it also includes all of Lua, whose standard library is more powerful. Perhaps their calculus was that removing things from the Lua standard library would introduce frictions to adoption…

3 Likes
19

I like the idea of sandboxing at the VM level, sometimes social APIs will request certain user permissions from some 3rd party website, I like that model a lot, I wish my operating system were the same, I have more space than I can make use of, so I’d be happy if apps didn’t require to access anything outside of their sandbox. That’s how I designed varvara, but I’d love to see that practiced more generally.

image
image585×641 71.2 KB

3 Likes
20

I’d like that too, but I don’t like the particularly way Android (and other mobile OSes) implement the concept of app data sandboxing.

I want to be able to separate apps from data, so that my data can outlive multiple apps, and so that I can import, export and backup my data without needing to involve a company or server (which might be in a different country, even). But the Android model generally wants to bind data into the app as a sealed module in such a way that no other app can see that data. This means that my data is lost when the app is deleted, and control over that data is now handed directly (by the architecture of my device’s operating system / VM runtime) to the company that runs the app.

This situation is just as suboptimal for the user as all apps having unrestricted access to all of the device.

The interesting “philosophical dilemma” I see here is that this idea of binding data into an app – which I think is very damaging to the user – seems to be implied directly by the Object Oriented model (even Alan Kay’s personal idiosyncratic definition of OOP which the rest of the industry doesn’t share). The idea that data should be only ever manageable by a linked program, and should not be accessible without that program, has finally come to the desktop… and the results are, frankly, terrifying. We jumped straight from “data must be controlled by a class” to “data must be controlled by a corporation”. And OOP guided us there.

This is confusing to me because I love some parts of the 1970s OOP vision (particularly the Smalltalk desktop where there aren’t any apps, just objects), but other parts of the exact same 1970s OOP vision appear to lead straight towards the things I think are disastrous in our current environment. Why is there such a cognitive dissonance in one of computer science’s crown jewels? Shouldn’t a philosophy be coherent? If OOP isn’t a coherent philosophy of programming, shouldn’t we be looking hard for a better one?

I think a “functional” approach to application sandboxing might be slightly closer to what I want. This would suggest that a program should be something like a function: the user should be able to interactively “apply” it to a set of objects or rights (say, a folder on disk) - represented as an object in the OS/desktop/GUI - and the result of such an “application” operation should also be a “function” (program) itself. So eg we ought to be able to take a web browser and bind it to a single site or set of sites; or a file explorer or text editor and bind it to a single folder; then when we’re running that particular “app” (or mode) we’d know that we can’t accidentally do something beyond the scope we set for it. So the user being able to create new apps interactively just by binding, would seem to be a core language-like element that we need to have in an OS or user interface.

There’s no reason particularly why we couldn’t get such a “functional” desktop/app system even in a Smalltalk environment… except, that Smaltalk classes have to be named, while second-order functions don’t. And “interactively binding an app to a folder to create a new app” doesn’t seem like it’s a case of conventional Smalltalk subclassing. Of course, Alan Kay doesn’t like subclassing, or even classes, so… that wall of cognitive dissonance, again.

4 Likes