17.390 communicating software ideas

From: Humanist Discussion Group (by way of Willard McCarty willard.mccarty@kcl.ac.uk)
Date: Sat Nov 08 2003 - 04:10:24 EST

  • Next message: Humanist Discussion Group (by way of Willard McCarty

                   Humanist Discussion Group, Vol. 17, No. 390.
           Centre for Computing in the Humanities, King's College London
                       www.kcl.ac.uk/humanities/cch/humanist/
                            www.princeton.edu/humanist/
                         Submit to: humanist@princeton.edu

             Date: Sat, 08 Nov 2003 08:58:33 +0000
             From: Wendell Piez <wapiez@mulberrytech.com>
             Subject: Re: 17.386 communicating software ideas?

    Willard,

    To what Steve and John have said, I would add that most day-to-day
    communication among programmers happens within a context in which an
    enormous amount of information is already assumed and on the table, in the
    form of a terminology that is relevant to (a) the programming paradigm
    (old-fashioned procedural, OO, declarative, declarative-functional etc.),
    (b) the particular programming language and environment, and (c) and the
    problem domain (what is the program going to *do*?). In practice these
    terminologies can become quite extensive and complex. Accordingly, whether
    it be verbal or pictorial, programmer's talk is already in a kind of ad-hoc
    code (or pseudo-pseudo-code, to distinguish this loose encapsulation of
    concepts in terms from "pseudo-code", which is a semi-formal mockup of an
    algorithm or process in "code-like" language), which draws its vocabulary
    from this mine of terms and its "grammar" from the pragmatics of the
    situation (e.g., we can use English, or perhaps we can use English and we
    also have this whiteboard, or perhaps we've agreed to formalize our design
    methodology with UML and have its notations and concepts to build on).

    So, for example, if I'm giving advice on XSLT, the first thing I have to
    gauge is what level the question is coming from. Given a sufficiently
    experienced questioner, the answer might take the form of "use a named
    template that calls itself recursively, chopping down the string as you go"
    ... when I get a puzzled look I might say "use the substring-before()
    function to grab the first bit you need, and then call the template again,
    passing the remainder back in as a parameter". (XSLT programmers will
    recognize that in this formulation, the words "template" and "function"
    have formal definitions but the word "remainder" does not. If you're not an
    XSLT programmer you won't know this, which is my point.) If I still get a
    puzzled look, then we step back again, maybe to talk about what a
    "template" is in XSLT (as opposed to somewhere else) and how the processing
    model works.

    This isn't fundamentally different from any disciplined discourse, I don't
    think; but since programmers are also always learning about something else
    besides programming (for example, to design a user interface for submitting
    conference paper proposals on line, I have to know both web technologies
    and something about conference paper proposals), and since the world of
    programming itself is so large, various and volatile, programmers (or at
    least the good ones) get to have quite a facility at recognizing the
    arbitrariness of the signifier -- how the same term can mean different
    things, more or less formally, in different contexts, and how you'd better
    get the terms straight if you want to move forward. Programmers are also
    constantly renegotiating definitions among themselves and with their other
    interlocutors. And good programming involves *naming* things well -- if the
    methods in Steve's spiffy new API have good names, he'll have much less
    explaining to do when John tries to use it.

    Likewise, design failures are very often due to failures to deal with
    precisely these challenges in communication. You say "I want it to be a
    radio button" and I say "I can make it a radio button", but we don't mean
    the same thing by "radio button". This is a trivial case, but you get the
    idea....

    Cheers,
    Wendell

    ======================================================================
    Wendell Piez mailto:wapiez@mulberrytech.com
    Mulberry Technologies, Inc. http://www.mulberrytech.com
    17 West Jefferson Street Direct Phone: 301/315-9635
    Suite 207 Phone: 301/315-9631
    Rockville, MD 20850 Fax: 301/315-8285
    ----------------------------------------------------------------------
        Mulberry Technologies: A Consultancy Specializing in SGML and XML
    ======================================================================



    This archive was generated by hypermail 2b30 : Sat Nov 08 2003 - 04:14:49 EST