## Programming Language Misfeatures With Little Comment

(An incomplete and unordered list)

1. inheritance
2. !=
3. ===
4. not in  from python
5. .. and ... (flip-flop operators)
6. implicit type coercion
1. (except arguably short -> long style)
7. null
8. case fallthroughs
9. non-exhaustive case statements
10. the switch/case construct in general
11. lambda‘s restrictions in python
12. ruby having 3 (? maybe more?) types of function objects
13. memory-location equality comparisons
1. ok, these are sometimes fine, but should never be the default
14. arguments that can be either positional or named when called
15. anything that exposes the difference between co- and contravariance because of a type error (lookin’ at you, Java arrays)
16. constructs whose behaviour is partly controlled by the parser (e.g. php’s instanceof)
17. constructs that affect the runtime behaviour of the interpreter (e.g. php’s __halt_compiler or ruby’s __END__)
19. compiler warnings
1. ESPECIALLY warnings that cannot be turned into errors
20. function scoping
21. closing over variables
22. closing over values
1. why is it never the one i want!!
23. hygienic macros
24. unhygienic macros
1. why is it never the one i want!!
25. raw-text replacement as “macros” (e.g. the C preprocessor)

## A Lighthearted Preamble

I have, of late, you’ll notice, been trying to find a date. In said pursuit, I have also begun using Tinder in an effort to hopefully delude some young woman into believing I am worth spending time with*.

I recently went on a nice date with a a nice young woman. Unfortunately, she… either doesn’t like talking to me, or is the world’s worst texter. We set up a tentative date, and I said “I can be there at 6?” — the question mark indicates that I was opening it up for her to confirm, deny, or choose a different time. She didn’t respond! When it came time for me to leave work, and I had to choose whether to go to the train or home, I finally had to follow up** and ask if that worked — and she quickly responded yes, we met at the decided-upon time, and had, I think, a nice evening.

So the next day, I followed up, saying I had a good time and asking about something she had mentioned she was working on while we were out. She didn’t reply! For over a whole day, she has not replied. Normally, I would take this as a clear sign that she was not interested, and in fact was doing what those damn Millennials call “ghosting.” But, as I said, she is already a forerunner for the World’s Worst Texter trophy. So maybe she did have a good time — she actually said as much while we were out! — and just does not reply to texts in a timely manner. Or, sometimes, at all.

## A Bitter Aside

Dating sucks. Texting sucks. Finding oneself strategizing about texts to send hours or days in advance sucks. Everything sucks. Eat Arby’s.

## Getting Towards My Actual Point, Insofar As There Is One

I was talking about all this with a friend of mine who has also been dipping her feet intermittently into the online dating game. I also mentioned that one time, after a date that I had enjoyed, I sent a similar followup text to the one described above, along the lines of: Hey, I enjoyed meeting you last night, would you like to hang out again sometime? <insert reference to a thing we talked about here***>. And she replied with something like: Hey, it was nice meeting you, but I’m not really feeling it, sorry. And I was all, Okay cool thanks for letting me know; good luck going forward!

And my friend here — the one at the beginning of last paragraph — was taken aback that a woman actually said that! It’s like getting a rejection letter after applying to a company. Nobody does that! She even thought that, hey, maybe she should try doing that too, when she’s not interested in someone, rather than ghosting.

But for a woman to actually straight-up turn a man down is often unpleasant, and sometimes even dangerous. When should a woman give a date an “official rejection” versus just ghosting on them? It’s clear that the woman should protect her own safety and wellbeing first of all, so texting a man who she did not feel safe with to begin with is a bad idea compared to disappearing. And giving a gentle but clear let-down to a man who is nice enough but you’re not interested in seeing again is a pretty clear good: you get to feel benevolent for being up front, and he gets to know where he stands and not to waste his energy pining over you. The advice seems natural: Err on the side of caution, but give a straightforward rejection whenever it feels safe.

## Do You Even Remember The Title By This Point?

I started thinking about exactly what to do here. I started wondering what the correct course of action would be based on my poorly understood, utilitarian philosophy of morality. There’s two variables here: the woman’s (henceforth Alice) and the man’s (henceforth Bob) suffering****. We assume some things:

• Alice has already decided not to see Bob again.
• Bob would like to see Alice again.
• Bob’s suffering is reduced by getting an explicit rejection as compared to being ghosted.
• Alice’s suffering is reduced by offering an explicit rejection.
• Alice’s suffering is, after deciding to offer the rejection or not, exclusively controlled by Bob’s response
• If Bob replies in a positive or neutral manner, her suffering does not change (after the bump from magnanimously being straightforward)
• The more negatively Bob replies, the more Alice’s suffering increases

I don’t think any of those assumptions are controversial: The first two are just an exposition of our hypothesis, and the rest seem straightforward.

For the purpose of getting anywhere, I am going to posit a final constraint that moves us into the world of spherical cows:

• Alice has no priors to help predict Bob’s reaction

I think the idea holds up fine even if we allow Alice to have priors, but let’s assume she doesn’t for now. Bob is a spherical cow.

## Maybe I’ll Present A Model Under This Header

Our assumptions let us assume fairly naturally that that Alice’s suffering will be increased by the value of some simple function*****.

The x-axis is the negativity of Bob’s response, and the y-axis is the effect on Alice’s suffering. So if he is positive or neutral, there’s no effect, then as he ramps up from “Okay, thanks” to “Wow, rude,” through “Fuck you, you’re ugly anyway” and on up to “You think you can just turn me down? I’ll fucking kill you,” her suffering increases. It’s not linear, its shape is not well known in general except that it is non-decreasing, but we can assume that it is “known” insofar as for any given response from Bob, we know the exact amount of suffering it causes in Alice.

But this function is not the end of the story. Because, see, what we actually have here is a probability distribution! Bob, for any given value of Bob, will only have one of these reactions. Over a large population of Bobs, however, we will find ourselves with some probability distribution over negativity of responses.

## The Much-Awaited Conclusion

Once we have this probability distribution, we can wave our hands****** and come up with an expected value of Alice sending out a rejection text. The formula looks something like this:

Where S stands for suffering. So the total change in suffering, which is the sum of Alice and Bob’s changes in suffering, is equal to the suffering decrease of giving a rejection, plus the suffering decrease in receiving a response (these two are constants for our purposes), plus the suffering change based on the response that Bob gives.

Our setup gets us to this:

Which is to say: the expected suffering from Bob’s response is equal to the sum of suffering deltas of all responses times the probability of that response, multiplied by some normalization factor. So all we need to know is, given some suffering function from Alice and some probability distribution over possible responses from all Bobs, if

then Alice should send a rejection text. If the inequality is false, she should not.

To wrap up, I’d just like to say that I think it’s interesting that (for some model, anyway) a woman’s choice to do a rejected suitor the courtesy of actually telling him he’s rejected depends on two things: her own sensitivity to negative replies, and the probability distribution of how negative young men in the online dating world are when faced with rejection. That is to say, it is quite possible that today it is immoral to send a rejection text, but tomorrow the world will be a brighter place and men won’t be so fucking crazy, and it will become moral to reject them properly.

* It is not going great, so far. Thank you for your concern.

** Double-texting, despite being the Ultimate Sin of Thirst and Neediness, was my only option here besides giving up, so I reluctantly went with it.

*** I always worry that if I just say “hey let’s hang out again” I sound like I just wanna hook up, when, I mean, that’s something that’s totally cool, but not my primary goal, so I try to provide some sort of evidence that I was paying enough attention to be interested in my date as a person and not just a body, you know? I have no idea if this is effective; there are too many confounding reasons a woman might not want to go on a second date with me.

**** Suffering can be negative (what laymen refer to as “happiness”) but it’s easier to work with just one name for the quantity.

***** Simple here meaning: continuous, non-negative, real valued.

****** Do some calculus.☨

☨ I should really format my endnotes better.

Posted in math, morality | 2 Comments

## On Speed Dating

I went Speed Dating this week. I utilized the services of this company.

The event’s location was moved the morning of.

I left my apartment half an hour before the event. I noticed I felt very nervous during the cab ride. I arrived at the event 20 minutes early. They told us to be fifteen minutes early to check in. No organizers were there when I arrived. No one was there to check anyone in until five minutes before the event started. The event started late.

There were more women than men. The men sat and the women moved between spots. I sat on a couch and women sat next to me. There were two groups of friends. One group was all medical students. One group was all mental health volunteers. Everyone was nice.

I was very tired by the end. I was less interesting in my last dates. Being nervous is very tiring. So is talking to strangers. The event was on a weekday. Speed Dating after work is even more tiring.

I turned in my match card after the dates. This matches people who match each other. The organizers never emailed me. People who match each other get introduced in an email. If you match no one they do not email you.

## The Moral Calculus Of Suicide

From some sort of (poorly-understood) utilitarian standpoint, suicide (like anything) is immoral iff it increases the total suffering in the world. Presumably a person who is suicidal is experiencing significant suffering, and thus killing themselves is reducing total suffering for at least one person, from some high value to zero. Particularly, a young person with some very serious mental disorder (severe chronic depression, type II bipolar, etc) has many years of heavy suffering to weigh. However, that person’s life may well be reducing suffering (bringing happiness!) to others around them; many suicidally depressed people are superficially happy and exert a positive influence on the people who love them.

Committing suicide both reduces the happiness you bring to those around you and also adds some grief, sadness, guilt, etc to same. It might well also reduce suffering in smaller ways (e.g. people no longer have to worry about you or be stressed about caring for you, etc), but overall it’s going to be negative. Not only is any joy you could have brought anyone for the rest of your life now gone, you’ve also introduced a lot of sadness (that will, presumably, taper off as time goes on; there’s some weighing of futures here).

So, from a very shallow understanding of utilitarian morality, and as supported by quotes such as:

Even if a person has some duty to others, say, family members, the suicide can still be morally acceptable provided the distress to others caused by the suicide does not outweigh the distress to the person who refrains from committing suicide. No person is obligated to undergo extreme distress in order to save others from a smaller amount of distress. [source]

my understanding is that this is roughly where the analysis generally leaves off. Kill yourself if it reduces suffering; don’t if it doesn’t.

But, let’s consider a hypothetical scenario where someone I love very much and who has no impact on anyone else in the world is contemplating suicide. Wave your hands and assume the calculus shows that the person’s suicide is a small net negative: thus it is immoral for this person to commit suicide; the suffering she ends in herself (integrated over her expected life, etc, etc, blah blah blah) is slightly less than the suffering increase in mine.

Now in this case I can choose, to some degree*, to be less sad about it. To believe that the end of my dearly beloved friend’s suffering is so important to me that my gladness that she is no longer in pain reduces my total suffering to the extent that the moral calculus changes: now my friend committing suicide slightly reduces the net suffering in the world, and is thus the more moral act.

What does this mean? I somehow have control over whether or not others’ acts are moral? If I tell my friend, “I will be glad to see your suffering ended, if that is what you choose, even though it will break my heart to lose you,” and she correctly infers that the moral calculus has changed to the point that it is now moral for her to commit suicide, and she is some wacky alien perfectly-rational-actor caricature, then she goes ahead and does commit suicide, have I effectively killed her? Was I right to? Can I choose, after the fact, to embrace others’ decisions to reduce their own suffering and thus retroactively justify a suicide as a moral act? Does any of this argument even make sense?

As to that last question: who cares; morality isn’t objective anyway, I get to weigh things for myself.

*Haha! Just kidding, free will is a lie. But acting as though it’s not (which of course we all must), one in fact does have some control over one’s reactions and emotions, or rather is at least able to if one tries.

## Encryption & Pronoun Games

You should use encryption for everything you do online. All websites should be https only, even if there’s nothing to secure. All email should be sent over encrypted protocols. All chat clients should support encryption. Etc, etc. The reason for this is that if only sensitive data is encrypted, then attackers (read: the NSA) needs only to look at and inspect (and decrypt) encrypted transmissions. Further, if most “normal people” don’t encrypt most “normal communications,” then there is the possibility for a sort of social pressure along the lines of “you wouldn’t be using encryption if you didn’t have something to hide,” which, despite popular opinion, is a powerful way for authorities to put pressure on people and break in where they don’t belong. I’m not going to go into detail on why the “nothing to hide” argument is toxic, but if you don’t already agree with me I recommend doing your reading.

But the point is that if it becomes standard for everyone to encrypt everything, then not only do we have all our communications secured, but we also all, as a group, benefit from not doing anything suspicious. Otherwise, when you find you suddenly do have something to hide, and switch to encrypting your communications, that’s a signal. If everyone does it, there’s no signal.

I think we should choose information-minimizing strategies in other situations where we can protect others or ourselves. The example I chose here, as you can tell from the title, is playing the pronoun game. If only people in — I don’t know what to call them that doesn’t sound condescending, maybe “nontraditional”? — relationships (basically anything besides monogamous heterosexual partnership between two cissexual people) play the pronoun game, then any time someone starts subtly dodging naming their partner’s sex, you have a very strong signal that person is in some sort of “nontraditional” — ugh, again, I don’t like that word, what should I use instead? — relationship. That’s exactly what they were trying to avoid signalling!

Since I think both that people should be able to be in whatever the fuck kinds of relationships bring them joy, who cares, and also that a person’s relationships are the business of absolutely no one except people that person decides to share them with*, I think it’s a shame that merely dodging pronoun usage might expose someone. So I play the pronoun game too! Every time someone plays the pronoun game and then it turns out their identity-unspecified partner is the sort of “norm” that you would expect, that makes the “pronoun game” signal a little weaker. Every time I dodge using terms like “girlfriend” or “she” and stick to “my partner” and phrase things to say “we,” etc, it makes someone in a nontraditional relationship less likely to be “caught” by people who might disapprove.

So, go forth! Encrypt all your data. Play the pronoun game. Hide any nonessential information that might cause someone pain if it were exposed. I have nothing to hide – I’m a boring ol’ cishet man who has, thus far, dated only boring ol’ cishet women – and it’s people like me who need to jump on the pronoun game bandwagon.

One assumes there are many other places where we should all be doing this as well. If you have to take a day off to go to the doctor, just say “I have a doctor’s appointment,” not “oh it’s just a cold,” because that means someone dodging the subject because of a protected medical status doesn’t get looked on suspiciously, for example. I can’t think of others at the moment, but I think the same idea applies across a wide range of fields of discourse.

*I mean, I don’t think people should be in like abusive or pedophilic relationships, and perhaps in some circumstances your relationship is people’s business even if you’d rather it not be (say, you have a child by a past partner or something). But come on, who am I even writing these disclaimers for on all these posts? It’s like I’m assuming the worst of myself and feel compelled to get down on paper that I don’t believe the literal worst interpretation of everything I write.

## A Poem (of sorts)

Once upon a midday sunny, while I pondered nothing funny,
Over many a quaint and curious man page of forgotten lore—
While I angered, nearly snapping, suddenly there came a bad ping,
As if LVS was napping, napping though it knew the score.
“’Tis just upstart,” I muttered, “napping; i’ll give it what for—
            sudo service keepalived restart.”
Posted in jokes, software | 1 Comment

## NIH, Developer Infantilization, and Motivations

I recently read about the new face of NIH syndrome, and after sharing and discussing it with some coworkers (Hi, John!) I had some thoughts about how NIH (or what Freeman calls NPF) comes to be, and what it means about an organization.

For the uninitiated, NIH stands for “Not Invented Here,” and refers to the inclination of some development organizations to avoid third party tools at all costs, because there’s some sort of vague FUD (fear, uncertainty, doubt) around using anything that our developers haven’t written. Maybe it won’t work, maybe it won’t work *well*, maybe it will stop being supported, etc, etc. Freeman argues that the software industry has, by and large, rid itself of NIH syndrome, but it has done so mostly through word policing and social mores, and developers still do roughly the same thing, only in the form of what he calls NPF: Not a Perfect Fit syndrome. The symptoms are the same, more or less: sure, this software works, but we realllly need X feature, and no one else does that. Or, yea, that works, but do we really want to deploy a JVM on our wiki box? why not just write our own? Or, etc. Same symptoms, same cause, different name — because saying “we can’t use that, we didn’t write it” doesn’t work anymore, you need a plausible-sounding justification, however thin it may turn out to be.

So I was reflecting on all this and chatting with John, who is a wonderful sounding board and generally a thoughtful person, and I mentioned that I have basically no vulnerability to NIH, at which he looked slightly surprised. Upon further thought I have come to think it is because I don’t find all that much joy in writing code. Sometimes it’s fun, and certainly the feeling of solving interesting problems is always rewarding, but I am much more motivated by delivering value to customers than by just the raw act of implementing things. I’m currently really excited about an upcoming project at work because I had spent a while worrying that it would turn out to be frustrating and difficult for customers to use, but after some recent discussion I realized that we have the opportunity to turn it into something that customers will really like. That is so much better of a motivator for me that I can’t imagine slowing down the time to get that feature out to customers by banging out a proprietary form validator or whatever.

And so now I come to my main point: many developers in many companies are basically not permitted to have the kinds of motivations that I have, the ones that supersede the mere technical challenges. Many organizations silo off their development teams, both from the business and, often, even from each other. They are handed feature requests from the business, largely devoid of context, with little idea who they benefit or what the underlying goal is. I consider this a form of infantilization, honestly: the only reason to do this is because you think developers need insulation from the scary business types that poor nerdy coders can never figure out how to interact with effectively. They can play in their little sandbox while the adults gather requirements and decide what to have them do. In this environment — and, actually, I have worked in conditions like this, although not for long — it’s easy to see why someone would develop NIH syndrome. If your job is to do context-free drudge work updating some winforms or CRUD app or whatever day in and day out, and you don’t see customers loving it or understand why anyone would need it, of course you’d make up any excuse to do more interesting work. If the only motivation you’re allowed to have is “for the love of the code,” then the best you can do to keep yourself interested is to work on more interesting code, since you’re not allowed to help solve more interesting business-related problems. Given that the only tool I have for working on an interesting problem is telling someone who wants me to work on a boring problem that there are important prerequisites to it, and that none of the existing solutions to those prerequisites will work for our special snowflake case, I am going to use that tool constantly. If my choices are “write a Django clone” or “write an intranet CRUD app in Django,” I’m going to choose the former every single time.

I am lucky enough that those are not my choices. First of all, no one I work with would dream of letting me write a Django clone, thank god. Secondly, and more importantly, my choices are more like “work on this feature to help customer X” or “work on another feature to help customer Y.” I’d rather do either of those things than write a Django clone! I’ve talked to our customers, I know the pain they feel, and I know the value they can get out of using our product, and helping them is great. Creating a product that I can feel good about giving to customers is a much better feeling that knowing I’m capable of writing some tricky library from scratch.

(Hopefully unnecessary disclaimer: some developers are more motivated by the writing of tricky libraries than the helping of customers. This is totally fine and I don’t mean to deride it in any way. I’m talking about the developers who are like me but not given the freedom to work on projects that would be interesting to them)

There are obviously other reasons an NIH mentality can take over a dev team. “Job security” is a shitty reason people might do this, a feeling of fear that we either can’t implement what we need to or don’t know what we need to implement is a much-less-shitty reason. But I think this explanation explains a lot of the organizations that get taken over by NIH syndrome, and I think it’s a particularly pernicious reason.

It’s pernicious for two main reasons. The obvious one being that you’re wasting your developers’ time, or rather letting them talk you into wasting their own time. That’s just an unnecessary inefficiency in your organization: you would literally be better off firing them.* The second one is that this kind of environment is only appealing to developers who are happy just hacking out code without caring about the business. Engineers who do have any interest in being an active part of helping your customers are going to be frustrated and leave, and the only ones left will be incompetents who can’t find another job and ones who only care about technical chops and have no qualms about crying NIH constantly in order to scratch that itch.

Do you really want that? I mean, empirically, the answer is yes, a lot of companies do want that, because they choose to infantilize their engineers. But you can do so much better! You can get feedback from intelligent, knowledgeable parties, constantly. You can motivate engineers by introducing them to the customers they’re going to solve problems for. You get everyone more involved and more motivated! And you don’t have to constantly fight with your developers if you treat them as grown ups; they won’t constantly scramble to justify NIH tendencies because they’re engaged in their work, and they’ll get more done, and they won’t be incentivized to bullshit you about what can or will get done, and everything is just so much nicer.

In the end, my point is basically just “treat everyone in your company like an adult,” which seems like it should not be controversial enough to say nor rampant enough to break down into sub-categories of infantilization. Unfortunately we do not live in the best of all possible worlds.

*They would probably be better off if you fired them, too! Imagine a person who develops an internal bug-tracking tool because Jira is “not a perfect fit.” Now imagine that person works full time on this Not-Jira, or, say, full time for 3 months and then ~20hrs/wk indefinitely. Let’s say you don’t fire them: you’re wasting ~half of this dev’s salary (half of their salary – a monthly Jira subscription), and this dev is wasting half their time on non-transferable skills that will get them nowhere in their career and severely limit their job opportunities moving forward. Or don’t imagine it: I have seen this exact situation transpire, maybe you have too.

## Users and Accounts in Swift

(This will eventually be published on the SwiftStack blog)

Preface: I am a developer at SwiftStack, where we work with Swift, which is in this context an open source distributed object storage engine, not the Apple language of the same name (which is also pretty cool, tbh, even if the compiler was a piece of shit when I was playing with it). Anyway, people who interact with Swift frequently run into trouble understanding the distinction between users and accounts (and for good reason; it’s quite confusing for the neophyte); so frequently, in fact, that I wrote up this blog post in order to have something to point people to.

This is written from the perspective of a SwiftStack developer to a SwiftStack customer, so it will sound somewhat odd appearing on this blog. When reading, I advise you to imagine yourself as a SwiftStack customer.

On a welcome rainy day not so long ago, I was sitting in the SwiftStack office and ruminating over how best to communicate with one of our valued customers about a feature said customer was interested in us implementing. In the course of coming to a more complete understanding of what was needed to fulfill this customer’s desires, I realized that I was having communication troubles as a result of the confusion between Users and Accounts in Swift. In addition to this already difficult terminology — people are often used to saying “user account” in the context of other software, which leads them to (not irrationally!) misunderstand the crucial distinction inside of Swift — there is also the extra level of indirection of the fact that you yourself are a SwiftStack user!

Note: I will be using bold text for User and Account throughout when they refer to the concepts in Swift. If you see either term unbolded, it is being used to some other purpose.

So to start off with, I am going to indulge in some unbearable pedantry in the form of terminology.

• Swift UserSwift has a concept of users which are tied to authentication and authorization. A Swift User does not, on its own, provide any access to the storage engine. Instead, it is a way to take credentials from a client and allow Swift to recognize that, yes, indeed, I am aware of this user, and if they continue to make other requests, I have the means to authorize (or refuse to authorize) those requests.
• Swift Account — An Account, on the other hand, is simply the top-level namespace for storage inside Swift. An Account may have many Containers, each of which may have many Objects, as you are no doubt aware. However, an Account is not necessarily tied to a Swift User.
• SwiftStack User — This is your identity on the SwiftStack Controller, which is in no way connected to your or anyone else’s Swift user (or Account, of course!)

The last of these is fairly easy to understand as separate from the others, and is generally confusing because of sloppy terminology when speaking about it (in particular, the fact that our auth system for Swift is called SwiftStack Auth, thus necessitating at times the phrase “SwiftStack Auth Swift User” to wholly disambiguate from a SwiftStack Controller user). I thought it was worth calling out explicitly if only to explain that I’m not going to be discussing what a SwiftStack user is.

On the surface, the concepts of User and Account seem fairly easy to distinguish between: a User represents a human (or maybe an automated service), who “logs in” to Swift and then has permissions to see various things. An Account is sort of like a folder, in that you can put Containers in it and then Objects in those Containers. So what’s the problem?

Well, I think the problem comes from a few things. The primary two are:

1. Simple bad pedagogy and sloppy language on the part of Swift experts, and
2. The fact that Accounts are, in many auth middlewares, auto-vivified per user.

Problem 1 is something that I myself am guilty of. When talking with other developers and people immersed in Swift, if I slip up and say “user account” when I mean “user” or similar, my colleagues have no difficulty in translating it within context to whatever I actually meant. However, in letting such imprecise language slip into conversations where I’m trying to understand a problem a customer is having, I only create more confusion for both of us.

Cause 2, however, is not something I can label a problem on its own. It’s actually quite a convenient thing! It would be more difficult to get started using a Swift cluster if you had to not only create a User, but then also explicitly create an Account for that User (or perhaps give them permissions to create their own Account). However, people often just start using Swift without ever being taught about the distinction between Users and Accounts, and so the lines get blurry because, in many people’s experiences, there’s a tight one-to-one correspondence between Users and Accounts.

So let’s talk first about the way many people interact with Swift, which leads to most of the confusion, and then we’ll get into other aspects of Accounts in general. When you authenticate with Swift using your username and password, you get back a response that includes, among other things, a Storage URL. This Storage URL is nothing but a link to the default Account that your User has access to. For example, in SwiftStack Auth (our auth system for Swift, not for the SwiftStack Controller), if you authenticate as User “Alexander”, you’d get back a storage URL that looks like http://swift.example.com/v1/AUTH_Alexander. That last bit, the AUTH_Alexander, is the name of my Account! In this case, it was automatically created for me by SwiftStack Auth, which by default creates an account for each User, and gives that User full ownership of the Account. Now, if I make a request to that Storage URL, I get back a fairly bland response; I have no objects and no Containers. But I am free to change that – this is my Account, after all!

On the other hand, what if I try to request a similar URL, but with a different final segment; that is, try to access a different Account? Well, when I try to access the account AUTH_Brenda, I get back a 403 Forbidden error response, because I do not have access to Brenda’s data.

Now let’s briefly talk about superusers. If you’re using SwiftStack Auth to create Swift Users, you’ll notice there is a checkbox for making a user a superuser. A superuser has access to all data inside the Swift cluster. If I created a new User named Superman for my cluster, and had Superman set up and authenticated as a superuser, I would be able to see I would be able to see all of Alexander’s or Brenda’s data.

In fact, I can go ahead and outright delete Alexander and Brenda’s Swift Users, so that it is no longer possible to authenticate using their credentials, and Superman will still be able to see and act upon any data that either of them had put in the cluster!

Superusers are not the only way to access Accounts other than the one your User implicitly has ownership of; you can also set up what are called Access Control Lists (ACLs) on Accounts and Containers, for example. This post is already quite long enough without going into detail on other ways to divorce Users and Accounts, though!

I hope this helped you understand a little bit better the difference between Users and Accounts in Swift. The takeaway is that the two are not closely tied together except by convention and for your convenience.

## An Intuition On Why Teaching Is Hard

There are some things that are very difficult to teach. For example, nobody has really figured out how to teach programming yet. Many people are pretty good at teaching calculus, but nobody has a 100% success rate, and it’s never easy. Etc, etc.

Some things are not difficult to teach, of course: it is relatively easy to teach someone facts: water weighs 1 g/ml, John Lennon was born in 1940, the sky is blue.

What’s the difference? Well, I think the major difference is that teaching static facts is easy, while teaching things that require some sort of integration is hard. For example, teaching someone the straightforward formula: $\frac{d}{dx}x^{n} = nx^{n-1}$ is actually not very hard, assuming they have a decent understand of algebra. Getting someone to understand what the derivative is, in a general sense, is very hard. Similarly, we have things like Codecademy, which do the equivalent of teaching you formulae and no integration, because it’s not hard to tell someone to copy some text, but it is hard to teach someone how to write programs.

The intuition I had about this the other day is that you cannot transfer knowledge via language; you can only transfer serialized forms of knowledge. Facts like “John Lennon was born in 1940” serialize very well. Integrations between ideas, understanding processes, etc – these things serialize poorly. Have you ever tried to get directions from someone who has lived in the same place their whole life? Their brain understands the terrain at too deep a level to serialize it, and since they rarely need to communicate that issue in language, they have no intermediate forms to serialize for you. They literally cannot advise you as well as someone who is still learning the territory, because that person still has ready access to all the serialized forms of knowledge (“go a mile down First street”, etc).

This might be obvious or well-known, but I thought it was interesting, anyway!