Today over at #swift-lang, a lively debate ensued over a hypothetical. What if Swift added arbitrary infix operators including Unicode. Would development be better served with operators like the intersection operator (“∩”) over the current camelCode approach?
Some advantages are self evident. ∩ is a standard, mathematical representation. It’s widely accepted, widely used, and you’ll encounter it in most math textbooks. Plus it’s generic. It avoids mentioning a specific collection type, which would be required for selectors.
Despite this, I found myself arguing against (or at least against the overuse of) generic Unicode operators. While I welcome Unicode support in Swift, I see it best used to enable native language development. Unicode creates localized variables that make better sense than forced anglicizations. (Admittedly, I don’t see the point of cute dog-cow variables that show off language capabilities rather than enhance day-to-day development.) Even though this operator is a decided win in the specific merits, I felt Unicode operators failed in the more general case.
I still experience occasional APL flashback nightmares. The language wasn’t just a horrible experience in tracking down the right characters to create code. Once written, it was virtually unintelligible even to those who had created those routines. Having experienced write-only code in the classroom, I’m not eager to return there in the app store.
Using Unicode operators incurs costs. As ∩ is not part of the standard first-level keyboard access, there’s a creation cost — both the mental overhead of remembering the operator to use as well as the hunt to find the character to enter.
Second, there’s a cost to readability from a cognitive recall/recognition standpoint. I admit the cost here is small since this particular operator is so well defined mathematically. But recognizing “intersectionWithSet” surely will map better to some people than recalling what the ∩ operator does, even if you end up having to create a suite of specialized selectors. This example really depends on the individual’s training. As operators become more self-defined or esoteric, this cost will rise.
Third, there’s a symbolic representation cost. Outside of standard mathematical representations, there’s an organizational overhead involved in choosing and managing representation elements that camel case text avoids. While the intersection operator is well defined, more general operators won’t be. (One shudders at the possibilities of the “Pile of Poo” operator — except perhaps for release calls.)
Finally, there are sharing costs. Any non-ascii code places a burden on documentation and web sites, especially those that don’t offer copy-paste support. You might be especially proficient with & and similar, but not everyone in your organization will be
It’s not that these costs are unreasonable or that some operators aren’t natural fits, it’s that I’m not sure the benefits outweigh those costs when implemented as a whole. While I can argue the other way (put it into the hands of developers who surely will use this parsimoniously and appropriately), I find myself preferring the more textual solution even if both are available.