David's Blague

If you are Ed, and you are reading this post: no it isn't the post I promised (yet).  But it is a precursor, and you should read it before you read the subsequent one in the series.  Not that you have any choice, since I haven't actually written the next post yet.

I had a nice conversation with a coworker yesterday, in which she asked me a question I hear a lot in library-land: "Is it an identifier for the abstract thing, or just for this manifestation of the thing?"  I reminded her that I don't understand what "abstract thing" means in that context.

Contingent on the acceptance of "thing" as a valid concept, an identifier either identifies that thing or does not.  We can (and at libraries, often do) argue about whether a particular identifier goes with a particular thing, but this is a specific argument rather than an abstract one.  It is an argument about language design for some particular identifier.

If I substitute "word" for "identifier" it brings the problem with my way of thinking into stark relief.  A word either identifies a thing, or it does not.  If my coworker and I agree about the association between the word and the thing, there's no problem.  But if we disagree, we are not using the same word (even though it is spelled the same and pronounced the same).  We are faced with a multiple dispatch scenario: if she understands what I mean by my word and I understand what she means by her word, we need some way to disambiguate which one we are using when we speak.  We sometimes do that by adding other words: pen-in-the-sense-I-mean-it versus pen-in-the-sense-she-means-it.  If we often need to perform this kind of disambiguation, we probably develop a lingo or some jargon that people outside our small subgroup might not immediately grok.

In this way, we are pragmatic language designers.  We are using words to communicate about things, and a word is an identifier for all the things it identifies.  This is a definition, in the words of my brother Daniel, that probably "dissolves into mush" if examined too closely.

But I'm convinced it's right, despite its fragility.  I think it's even more right in library-land.  When we use identifiers, we need clear criteria for what they do-and-do-not identify.  When we get close to the edge of the definition, we should discuss whether a particular thing is in or out rather than trying to speak in abstracts.  And when it becomes evident we need to disambiguate the-thing-that-I-mean from the-thing-that-you-mean, we should carefully consider adding some words (identifiers) to help us with that task.  If we do it repeatedly, we should design them into our language.

And every once in a great while, we should go over the whole language and see if it could benefit from a little refactoring.  See if there are similarities in the places where jargon and lingo are cropping up, see if we can't make it into something that's easy for us all to remember.

Labels: language design, libraries

Memory tricks us humans into thinking like empirical beings.  We stumble around, babes in the dark, until we bump into a light switch.  Let There Be Light! and we see it, and it's good, and we remember.  The next time we stumble into it, when there is light, we remember, and we also recall.  We form a hypothesis, good scientists we are, and we test the hypothesis against the light switch.

Over time, the hypothesis becomes habit.  Memory, like a stream, carves out a groove, and the hypothesis itself is no longer needed.  Habit alone suffices to Separate the Light From the Darkness, and to call the light "on" and the darkness "off."  Habit outlives memory.  It persists even beyond life.  It is passed from person to person, from animal to animal, it is written on the world around us as paths and canyons and places, and even into our very genes.

Eventually, like Eve in the Garden, we ask why.  Memory persists to habit, now habit gives way to reason.  Patterns emerge.  We notice there is a pattern to the patterns.  These we call law.

One of my favorite writers is a guy who is currently in the midst of writing a specification for a programming language.  He recently made some changes to the first synopsis of Perl 6, and I am replicating some of it here, because I think it's a useful exhortation.  I hope he doesn't mind:

• The language designer is neither omniscient nor omnipotent, and never will be, despite requests for those particular features. Therefore the design process will be spiral, cooperative, and convergent. The rate of convergence is an emergent property, and cannot be forced, only encouraged. As long as anyone is hacking on any implementation of Perl 6 to make it conform to the test suite, or hacking on the test suite to make it reflect consensus of specification, the rate of convergence will be deemed to be positive. If you are unhappy with the current rate of convergence, please cooperate more with someone else you think is interested in convergence.
• The spec will not be frozen prematurely, but will continue to solidify as various aspects of it are proven (or disproven) in various implementations. Many parts of the spec are already effectively frozen, or are in a slushy state. "The future is already here, it's just unevenly distributed."
• All specced features that have not been proven in an implementation should be considered somewhat conjectural, even if not so marked. As implementations start to agree on what is practical and what is not, do not be surprised if some features that are currently specced may be deferred to future versions; these should still be considered long-term direction in the evolution of Perl 6 over time, and the short-term design should be conservative in preserving that long-term evolution. Note that we are not in a hurry to defer any sections of the spec, even if that would give the illusion of progress. Convergence of specs and implementations will happen naturally as we get implementations that are closer to the spec. It is quite likely that the first practical implementation will largely determine which features are considered to be required in 6.0.0.
• Everyone is allowed to panic once. However, continual panic will be deemed poisonous. Nobody gets special treatment, even if they think special treatment is necessary for success. This means you.

This was added to the synopsis with the log comment: "take another lap around Mt Sinai..." Since it's possible the intended message did not get across, even with this addition, I'd like to remind everyone that the next line in that song is, "'til you've learned your lesson."

Labels: perl, perl6, software

My new year's resolution for 2010 is to share my best ideas.  I noticed a while back that some of my best ideas were inadvertently becoming stuck in my head, which turned out not to be a great place for them to develop.  As such, my first idea: anyone may take anything I do at davidbrunton.com and use it for any purpose, with no promises exchanged.

This means, I make no promises to do anything useful or helpful, you make no promise to give me credit or share what you d,o or even use what you take.  We may also, of course, decide not to keep these un-promises.

Any code, images, text, audio, etc. of mine may be used as if it were in the public domain.  Anything belonging to someone else, is subject to their terms.  Many of the images, for instance, are from the Wikimedia Commons, and subject to their licensing terms.

Labels: meta