Issue 11  17th June 2022

Why Duck Typing Is Safe

Yes, you can have an accidental foot gun with duck typing. No, it’s not likely enough to worry about, and certainly not likely enough to hobble other people’s designs.

People understand this in security (or rather, they understand that they don’t want to be told they can’t do something cool because of security, so will wail that the security person is being Chicken Little). But in programming, current trends are toward exclusionary language designs that require strong maths backgrounds to understand and use correctly, that forbid this kind of once-in-a-career bug.

Cryptocurrencies have broken almost all of their major promises

I am very here for the tone of this article: negative on evaluation but open-minded on possibility. Unfortunately I often feel that this is tilting at windmills: I often encounter viewpoints of the form “this did not work, therefore it is inherently evil and anyone who does not loudly signal their antipathy must also be evil”. Particularly on software engineering techniques and practices, this is a weird category of hill to die on: we do not generally agree on how to evaluate software engineering work, and yet you can find the notion of a blockchain, or a story point, or inheritance, abhorrent?

Computers are an inherently oppressive technology

I disagree with the premise of this article, but it's still a very interesting area to think about. Hugo Landau is actually arguing not that computers are oppressive, but that bureaucracy is oppressive and that computers are used to automate bureaucracy. A system that condemns someone to slavery as soon as they fail to meet a rent payment is a system of oppression: that system was built out of people wielding pen and paper in the industrialising Britain of the 19th century.

A small number of visionaries have positioned computers as instruments of personal liberation and empowerment: Seymour Papert, Alan Kay, Mac-conception-to-NeXT-era Steve Jobs spring to mind. So does Bret Victor. It'd be beneficial to have a larger and more diverse pool of people thinking that way.

When Good Codenames Go Bad

This tale from 2006 (which got re-shared to HN this week) is really a wholesome tale of when people take a good codename and run with it. I tend to be down on codenames:

• it creates an "us vs them" culture within your organisation, because people refer to their projects by their codenames when some employees were not at the one meeting where the project->name mapping was ever made explicit.
• because of this private mapping nature, you will find different code names used within the organisation for the same purpose, adding to the confusion. Is Mac OS X 10.4 Tiger, Merlot, Atlanta, or Chardonnay? The answer is "yes".
• it will get leaked, which can be problematic. One puerile team at a former employer tried to pick words with a sexual or pornographic connotation that would not get banned by the engineering director.
• it will get used in documentation, which is a problem because you never told the public what the codename meant. In Apple's fork of the GNU Assembler, we find that Rhapsody (a public "codename") needs build settings for "Hera" and "Teflon".
• speaking of "Teflon", using registered trade marks is particularly problematic.
• that file also lists "Gonzo", "Bunsen", and "Beaker": are you calling your users muppets?
• once they do get into the wild, people will want to use them. I once used a naming convention of characters and places from Norse mythology. I thought good because a fairly large pool of names: turned out bad because I would get calls from English people trying to say "I have a problem with Jotúnheimr".

But for all of that, codenames can be a source of camaraderie and humour, as evinced by this article.

Sunsetting Atom

Just a quick guide to how open source software works: Github are not sunsetting Atom, they are planning to stop working on it and to stop sharing their version of it. If you still want to use Atom then its MIT licence gives you the freedom to take a copy of the source code and do any of these things:

• use the software, for any purpose.
• study how the program works, and change it so it does your computing as you wish.
• redistribute copies so you can help others.
• distribute copies of your modified versions to others.

Github is not by nature an open source company (their main product, Github, is a proprietary web application) so it perhaps isn't surprising that they think about their products as if they are the only people who can work on them.

The collapse of complex software

I'm currently teaching a course on structured data with XML and JSON. People don't like the complexity of XML and its allied standards, so switched to JSON: but then they find they need to reinvent the same wheels over and over and define shared standards for doing so. So now we have JSON-Schema for validating documents, XSLT/XPath for transforming JSON(!), JSON-LD for semantic metadata…we're back where we started.

Someone, somewhere will say "screw this, JSON is too complex, I'm going back to basics". They'll start vending hand-rolled TOML from their web services. JSON Feed—which incompletely replaced RSS—will be incompletely replaced by TOML Syndication. And so the cycle will continue.

It's saddening that it's so predictable.

About iPads and Developers

As a software engineer I'm not only using and targeting new technologies, I'm building up knowledge and experience to improve my capability and efficiency. These two attributes come into conflict: with new technologies come changed expectations, but with changed expectations come inefficiencies and uncertain workflows.

This article is about that. Andre is strawmanning the following argument:

1. I am invested in a docker, kubernetes, react, pgsql way of writing software.
2. I cannot run those applications on iPad.
3. Therefore iPad sucks for developers, urr.

And that's true. If the way you look at software development is "how do I run my three-tiered web app better", then iPad is going to be for "test three-tiered web app…on iPad". But there are plenty of developer and software engineering tools for the platform, and they can be incredibly useful. If you're not yet using them you would have to adopt an open mind to changed approaches, not just incremental enhancements.

This is what Alan Kay was talking about with blue plane, pink plane. You can have incremental ideas that make the current way of working slightly better, and you will get incremental improvements. You can have paradigm-shifting ideas that enable entirely new ways of working, and you may get quantum improvements. But to get that, you have to be open to seeing what the new thing is and how to use it in this entirely new way.

I imagine that what developers are seeing with iPad now is what developers saw with NeXT back in the 1980s, though I wasn't there and didn't see NeXT until Mac OS X already existed. If what you knew was UNIX workstations, NeXT had a comparatively expensive UNIX workstation that wasn't very compatible ("industry standard for directory services is YP, what's this NetInfo about?"). But if you were willing to take a punt on Objective-C, Project Builder, Distributed Objects, you saw an entirely different system, and the people who saw that—the Ken Cases, Wil Shipleys, Jonathan Schwartzes of the world—had a lot of fun and made their dents in the universe.