Methods, Family Resemblances, and Rules of Reference

'Object Oriented Programming' is a structured programming approach adopted by software designers, and which is supported in fairly disciplined (although somewhat varying) ways by certain programming environments (e.g. Java, C++, Visual Basic, and others).

In these contexts, an 'object' can be thought of as a collection of data items, and a set of methods for accessing and manipulating them.  Each object has its own private set of data, and that data can only be accessed by calling on one of its methods - and not, for instance, through a public structure of variables or constants.

The power of this structure is that once an object, or rather an object 'class' - a type of object - has been constructed and tested, it can be relied upon in a large number of different contexts.  Because its methods and data are 'private' to it, their operations will not be interfered with in unexpected ways by other processes in the system, because the disciplines of the environment, or the structure of the software, prevent this.

What I want to say a little bit more about here is the concept of a 'method' borrowed from this environment.

Imagine (as in a classical example given in other expositions) that your objects are simulacra of vehicles in, say, a traffic network simulation.  Each of these vehicles will have methods associated with the kinds of things that vehicles do - we may want to feed them instructions about speeding up, slowing down, turning, stopping etc.  In interactions between them (collisions, collision avoidance etc.) we will want to define the ways that they will behave and calculate the outcomes.

For some instructions, the vehicles will react in different ways.  For instance, the instruction 'open the throttle 10%' initiates a method, with an argument, to a vehicle simulacrum.  The 'open the throttle' method of each vehicle type will tell it how to respond, and that response will be mediated by, and will alter, its internal data states.  A lorry, for example, will accelerate more slowly than a sports car.  A vehicle that already has its throttle fully open will not change its behaviour.  A vehicle with its engine switched off will not change its behaviour.  Some vehicles in certain icy conditions might lose adhesion.

Once we have constructed the classes of objects required (different types of vehicle) and instances of the classes (actual vehicles, with initial data states) the fact that all objects from certain classes have an 'open the throttle' method, simplifies the simulation.  We can, for instance, see what happens if everyone on the M6 between 7:30 and 8:30 in the morning were to open their throttles by 5%.

The relevance of this example is in the fact that there is no disciplinary or structural reason why methods with the same name should execute in commensurate ways over objects.  There is no reason why the method 'open the throttle' in some object classes would not produce bizarre behaviour (driving off into a field, deleting itself from the programme, sending a recording of  'Yankee Doodle' to the sound card ...).

Clearly the programme will be much easier to understand if different objects executed similar sounding methods in commensurate ways, but what counts as 'commensurate' for this purpose will be a feature of the programmer or of the reader and user, not of the objects or methods.  If these interlocutors find the ways that different object classes executed homonymal methods commensurate, then they are commensurate.

We might give a 'family resemblance' (after Wittgenstein) account of why a group of methods seemed commensurate.  This kind of semi-descriptive account can give the extension of a class, but at the expense of rendering membership decisions, themselves, in terms of methods which vary with the objects subject to the decision.  In other words, 'family resemblance' accounts really tell us no more about the way that methods are commensurate than the fact that they share a name does, since they, themselves, may depend upon a set of methods which we can only show to be commensurate by referring to some further family resemblance a little higher up the hierarchy of accounts.

Object oriented programming, then, has done something very odd.  In pursuit of reliability and predictability, it has created a place for natural language categories that it is hard to give a formal account of.  It has done this by allowing these to be coded in a variety of different ways, depending upon the objects they are to be applied to.  It has placed the decisions about how to organise these in an intelligible way in the hands of the programmers and users, so that this intelligibility is an aspect of the playability of the language game in which they are interlocutors, and not of structural features of the methods themselves.

It is sometimes useful to keep this model in mind when considering some of the 'hinges' of intelligibillity in general - hinges upon which anything that counts as a language must turn.

An example might be made, here, of reference and naming.  It's clear (although perhaps a more formal argument to this effect should be constructed) that it is necessary to be able to refer and to name in order to be able to speak at all.  Powerful instances of this suggest themselves - in particular the case of referring to interlocutors, but also cases of referring to and identifying the great range of  'objects' which are projected from nominal grammatical forms.  'Me', 'my pig', 'pig' and 'Piggy' (the name of my pig) all seem to need 'content'.

In the empiricist tradition, some of these contents have been sought in the world, and so the 'reference' relationship has seemed to have a special epistemological and linguistic significance.

If we think, instead, of 'reference' and 'naming' as being essential grammatical or semantic categories requiring contextual methods (as throttle manipulations might be to a traffic simulation), we can see that all this requires is that thes methods are adequately defined for the objects they are relevant to, and that this 'adequacy' is no more than that they are intelligible for, i.e. usable by, interlocutors.

It may still make sense to ask how reference works, or how naming works, but the answer to this question will be provided by an examination of the way the related methods are implemented with respect to specific linguistic 'objects', or computational contexts.  Any commonality would be provided by the grammatical and conversational needs, not by relationships between the methods (except in so far as these shed light on the conversational needs they might be meeting).

It is not surprising, perhaps, that specific 'methods' of naming (e.g. causal chain accounts) can seem very compelling in specific contexts.  References to actual historical figures must, after all, guarantee some narrative of this kind - so that where the narrative fails, the reference fails also.  References to fictional figures must, however, work in some quite different way, with different associated failures.  And there can be many differences of detail between methods - is Gilgamesh a fictional character in just the same way as are Zeus, or Mrs. Bennet, for instance?

Similarly, we can be tempted into a misleading simple mindedness about whether a proper name can function as a description - cases can vary, so long as the consequences of variation don't threaten local intelligibility.  We don't need to give a further account of how intelligibility in general is maintained, as this is guaranteed by our ability to request and give accounts.

This kind of mistake is a consequence of expecting some epistemological or metaphysical significance of a grammatical category, simply on the grounds that it 'works':  we think that because it works there must be a unifying underlying mechanism, when in fact grammatical necessity generates the requirement for mechanisms, for methods, which then may vary between classes of object/contexts.

A general demonstration that such methods must fail would be a demonstration that we could not render ourselves intelligible in a language which required reference, but this is not the same as demontrating that there must be some general method (however complex or conjunctive its definition).  It does have the consequence that we must be able to produce a method when one is needed, but that is a much weaker conclusion, and unlikely to have much fundamental significance.

An aim of the object oriented approach, after all, is computational robustness, not formal elegance.  The discovery that a method implementation is incoherent only affects the class of objects which incorporate that implementation.  Other classes sharing a 'commensurate' method (one which does something similar for those classes, and has a similar name) may not be affected at all.

References, and so referential failures, are accomplished in a variety of ways in order to achieve a grammatical object.  These 'methods' are defined in the contexts for which they are constructed, and exist to bring these contexts within the scope of a particular grammatical category.  It makes no more sense to ask how naming really works, outside of these contexts and this category, than it does to ask what 'open the throttle' really means outside the scope of the traffic simulator and the conversation of the programmers (and ourselves).

We can be confused by the grammatical necessity of reference within any language in which we might want to interrogate our theories and concepts (including the concept of reference) into thinking that we have found a special link between language and the world.  What we should see, instead, is the necessity of constructing links of this kind in some way or another in order to bring the world within the scope of our articulated interrogations.  (And this may be done tacitly, as well as explicitly.)

Obviously, an account of any one of these links cannot, itself, depend upon the link being accounted for; nor can a comprehensive dictionary of these accounts depend upon any subset of them for its intelligibility.  This means that the grammatical concept of reference, the only one that is 'necessary', cannot be accounted for in terms of the methods, even though it is only the methods which do the 'work' we require to be done, by setting out definite computational or narrative approaches to fulfilling the grammatical requirement.

Our story about the relationship between language and the world is not essentially different from other stories in language about the world.  It can't depend upon its own account of its possibility or integrity.