A recent conversation on Mastodon reminded me of some old JavaScript history.
When promises were relatively new and the Promises/A+ spec was being
developed, there was a request from people with backgrounds in functional
programming to incorporate monads and category theory. This issue generated
a heated debate, the two sides so diametrically opposed that they both believed
their position was so obviously correct that they could not fathom why anyone
could believe anything else. Historically I have tended to side with the spec
authors in opposing this request, but I recently ran into a case where it would
have been useful for things to go the other way, which is a good prompt for
re-evaluating your positions.
Last month I decided to revive my long-neglected MP3 collection after relying on
Spotify for many years. This meant using Apple Music for the first time since it
was called iTunes, and in the course of ripping a few hundred CDs I found a
great many bugs. One particularly fun one was that sometimes, the application
will just stop accepting new artwork; you will drag an image into the file info
dialog as usual but the window then displays a placeholder image instead of the
one you just tried to save. The only way I have found to stop this happening is
to completely restart the computer.
Today I’m publishing version 0.4 of Canopy, my PEG parser compiler for
Java, JS, Python and Ruby. This is long overdue and fixes a number of key
usability problems, as well as adding a few new features.
In type theory for named arguments we developed the idea of named
arguments as a distinct type whose desired behaviour differs from that of
records, which are the usual way of modelling polymorphic objects. We
determined that for record types, it’s fine for a caller to pass an object with
fields the called function does not use, but for named arguments this should be
considered an error. Conversely, a function with named arguments should be able
to add new option names without breaking existing callers, but callers should
not be allowed to pass unrecognised names. In this article we’ll explore how
to realise these semantics in JavaScript, whose object model leans more towards
record semantics and doesn’t provide strong support for named arguments.
One of the big challenges in maintaining open source software, or
service-oriented systems, or indeed any program where a function and its callers
can evolve independently and be maintained by different sets of people, is that
of maintaining compatibility. When we ship a new release of a package, we
usually want users to be able to upgrade without their programs breaking as a
result. This is especially tricky when the language we’re using does not have a
direct representation of a computational concept we’re using, as it leaves room
for a function’s author and its users to have different interpretations of what
the function does and how it should be used.