With the iOS 14 update, Apple has introduced more fine-grained capabilities in its operating system. When I tried sharing an image on Twitter after the update, I got a system message saying that I could now choose to only share some specific photos with the application, rather than having to give Twitter control over my entire photo library.

For once I was actually enthusiastic about a phone OS update. “Fine-grained capabilities? On my phone? Why, yes, that’s the thing I’ve been waiting for all this time!”

Apple: “We have capability-security at home!”

Of course I tried the more restricted sharing option at once. First it asked me to select the photos from my library. I picked the one photo I wanted and clicked done. That opened another photo selection screen with only the photo I had already selected. “Weird UX. Did they even test this feature?” I picked the photo again and this time it got attached to my tweet. Great! Now Twitter shouldn’t have any powers of snooping around my things!

With my tweeting done, I moved to happily performing other things, living in the blissful future where we actually get to control our privacy, trust, and security (a person can dream) in computer systems.

After much time had passed, I was back on Twitter to share a different image. So I clicked the button to attach a photo, and… it showed me a grid containing only the photo I had previously selected. “Weird. Maybe it remembers your previous selections? Who would want that?” Recovering from my brief state of confusion I looked around for any button that would allow me to go to my photo library and select one (1) new photo to share. No luck.

“Wait? That’s it? How do I grant more capabilities??? Did… did they think this through?????”

So I went to the OS settings to check what’s happening with Twitter’s photo capabilities… and found out that there is the only place you can grant or revoke photo capabilities. The capabilities you grant are granted indefinitely. And there’s no way of changing this at the actual usage context. Disappointed, I changed the setting back to forfeiting all my mortal (photo) possessions to the Twitter gods.

Now. This seemed like a good example of the issues one can have with capability-based security when thinking only about the technology part of things. Security is primarily about humans, and you have to think about people first. So let’s have a look at where things went wrong, and how things could have been made better.

Having recently finished reading the Bloom Into You manga (and the second volume of the Regarding Saeki Sayaka light novel), it seemed like a good idea to collect my thoughts on the series. And in doing so I realised, “Oh! I’ve been blogging on Twitter all this time! The pain I’ve inflicted upon those who were naïve enough to follow me…”

I mean, it’s not like I would write everything on Twitter. I write technical articles on my main website. I post my art on Instagram. I’ve published shorter pieces on sociology-adjacent topics on Medium…

But I don’t really have a blog.

And so it seemed like a good opportunity to start one, too. How much having another different place to publish thing can hurt anyway, when you already have too many of them?

But I digress. Let’s get back on the topic of the Bloom Into You manga.

Note that there will be some spoilers here.

Are dynamic languages just as good as compile-time static type languages for large, complex projects?

Yes. Kinda. But it’s a tad bit more complicated than “static vs dynamic languages” here.

Note I’ll answer this question from my own experiences with maintaining large projects—mostly language implementations and web services—, as I haven’t really read much literature on this topic. I have no idea how much this generalises to other people/kinds of projects.

This was originally written as a Quora answer

There are a few things I’m really concerned about when maintaining large projects:

• I’ll never know everything about the code-base. There are some aspects of it that I’ll know nothing about. There are many aspects I’ll only have a very superficial understanding;
• Whenever I make a change, I want to be able to do it with the confidence that I’m not breaking other parts;
• I want to be able to communicate ideas and concepts in the code precisely and concisely with all developers working on the code-base. Here I mean that this extends beyond my own team, and encompasses past and future developers as well;
• I want to be able to explore the code and its relationships without having to read the entire thing;
• Decisions made in the past are often overruled by decisions in the present, which cause large ripples of changes in the code-base. I want to be able to do these extensive changes with as little pain as possible—as otherwise tech-debt keeps accumulating forever, and the cost of changes increase substantially;

So, if I were to capture these concerns in a few words, I could go with the following: “confidence”, “exploration”, “communication”, and “evolution”. I’ll expand on each of these in the following sections, and my experiences with dynamic and static languages.