On the consequences of capital concentration

1 What is capital?

The term ‘capital’ is used in several senses.

In its most basic sense, ‘capital’ refers to physical goods that may be used in the production of other goods or services. In this sense, something as simple as a box of pencils counts as capital.

In another sense, the term may also include non-material goods, such as patents, proprietary code, or the value of a well-known brand.

In a third sense, the term may refer to those types of capital that, in a given era, would provide an advantage over one’s competitors in the provision of certain goods and services – as tractors did for some farmers, at the expense of others, at the turn of the 20th century, and as network effects did for some social media networks, at the expense of others, at the beginning of the 21st. This sense disregards capital which common to all or most participants in a monetary economy (or sector thereof) in order to focus on those granting distinction to their owners.

In a fourth sense, the term is used to refer to goods that, while not themselves capital in any of the above senses, are goods derived in some way from these more basic ones. Common stock, which signify ownership of the right to provide input concerning the direction of capital in these senses, is capital in this sense. A bank loan, which is a tangible signifier of the goodwill that a borrower has in the estimation of a lender, is also capital in this sense.

Capital may be concentrated by location, as, for instance, New York City has a greater quantity and variety of capital than the entire state of Wyoming. It may also be concentrated by class, e.g. if capital ownership is largely restricted to individuals within a given social or economic group.

2 The initial consequences of capital concentration

In all but the most basic sense, the concept of capital is correlative to that of labor power. While nothing prevents labor from itself being regarded as a form of capital, inasmuch as the capacity to work is exercised in the production of goods and services, it is typically regarded as a separate category. The original reason for this was that since labor is a cause of every produced good, and thus a source of capital in the sense of goods used in production, it itself could not be regarded as capital in the same sense that these goods themselves were. The distinction has remained, though the reason that originally grounded it has been abandoned by most mainstream economists.

A society in which capital is sufficiently concentrated in one class of individuals is one in which labor, rather than contributing for the most part to household production of goods for consumption, instead contributes to the sale of goods in a market economy. This occurs in a society where the use of money is directly or indirectly necessitated by law, e.g. via its collection as taxes for the provision of common goods like national defense. The necessity of the provision of taxes in monetary form itself conditionally necessitates formal participation in buying and selling.

However, when capital in the third of the above listed senses becomes available to some members of society, but not others, such individuals have the capacity to produce goods at greater speed than others. Inasmuch as money is itself a means for securing those external goods necessary for maintaining a life, the capacity to produce goods more quickly, and hence to increase sales where there is demand for those goods, may be used as a way of ‘purchasing’ additional leisure time, as a way of providing goods at a lower price than one’s competitors (thus increasing one’s gross profit by cutting into the number of items a competitor sells, while decreasing one’s profit per item sold), or a combination of both. However, since competition for sale of goods and services is not a one-time event, but one iterated indefinitely many times, any choice to not increase production is simultaneously a bet – and a bet against the odds – that competitors sharing the similar capital advantages will act likewise. Because of this, the prudential decision, at least outside of monopoly conditions, will be to use one’s advantage to increase production and thereby lower prices. These conditions provide an instance of a type of scenario call an iterated non-cooperative game, which is one of several kinds of games studied in a discipline called game theory.

As this process is reiterated, previous businessmen will find themselves unable to compete directly with those who have accumulated greater levels of capital, and may find themselves in a situation where rather than selling goods produced, their own competitive advantage lies in selling their labor, i.e. in working for a capitalist. By doing so, they avoid direct competition with their employer, and partake of the advantages that that capitalist has against other competitors, while those employing them are provided with greater labor power against those same competitors. However, since the remaining capitalists will themselves not be in a situation of equilibrium as long as they have competitors, this process will continue to iterate in such a way as to dispossess previous capitalists of their labor for so long as there is not a monopoly and/or the kind of economy in which economic activity operates remains one where access to goods for production plays a decisive factor in determining the place of individuals within that society.

3 Later consequences of capital concentration

For as long as tangible material goods play an important role in a capitalist economy, those goods will have to be located in some place. As those goods become more concentrated in a given class of individuals, they will also become concentrated spatially. As a result of this, those not in a position of capital ownership will compete with each other by offering their labor to the far fewer number in a position to productively employ them. Since opportunities for sale are limited, some will not be hired, and will become poor. In this way, capital concentration generates the problem of urban poverty.

At the same time, as barriers to sales across large distances decrease, certain entire areas will find themselves required and unable, in the absence of deliberate protective measures, to compete with those in possession of greater capital. Since this will be practically impossible, those in possession of sufficiently in-demand skills will leave their areas. The areas they leave will then lack not only the resources, but also the talent to compete with those businesses in the city. In this way, capital concentration generates the problem of rural poverty.

This situation then conditions several further shifts in the economy of the city. In order t secure the advantages of greater production in a situation where buyers of the goods are increasingly scarce, programs are developed to ensure that the poor have at least some purchasing power. In other words, the problem of urban poverty has, as one of its possible, albeit temporary solutions, the creation of the welfare state. This grows government itself as a sector of employment, on the one hand, and –  as these programs come to count the employed among their users – artificially lowers worker wages on the other, since it lowers the price of labor by providing for basic necessities that had earlier been secured by a wage. In this way, welfare provisions then act as an indirect subsidy to employers,  further accelerating the process of capital concentration.

Those workers who find work in the city will find themselves among others who lack work. Some of these will have recourse to participation in the sale of illegal items as a way to provide for their wants and needs. Others will have recourse to theft, sometimes violent. In this way, capital concentration should lead to a relative increase in criminal activity wherever it is located amidst sufficient poverty – which, given the draw of excess labor towards capital will be everywhere capital is located.

As capital becomes sufficiently concentrated in a small number of citizens in a small number of cities, those same citizens come to wield sufficient power that local economies come to depend on them. In this situation, those economies will be less able to extract taxes from them at a rate less advantageous to them than those of neighboring locales. That is, localities, then states will find themselves in the same sort of iterated non-cooperative game with respect to taxation that capitalists themselves were initially in with respect to conditions of leisure. In this way, capitalism, which arises within the context of strong states in great part out through forced participation in the monetary economy in the form of monetary taxation, ultimately inhibits the collection of taxes, and removes the capacity for meaningful self-governance from local political communities .

Correspondingly, those governmental bodies that are capable of exercising taxing power will be those relatively far removed from local communities. As a necessity of counteracting large capital accumulations at sufficient scale, government decisions will begin to be increasingly concentrated at the highest levels, leaving it both unresponsive to the greater mass of its citizens and susceptible to corruption by those parts of society it initially sought to regulate.

Given the absence of sufficient numbers of buyers for the kinds of goods typical of an early market economy, the constant fierce competition for those buyers among existing firms, and the relatively large accumulations of capital by those firms, economies develop to serve not consumers in the traditional sense, but those companies, whose consumption is itself ordered toward the augmentation of their own competitive advantage. These conditions of the lack traditional demand, large capital accumulations, and competition for scarce buyers provide the precondition for the outsized role played in today’s economy by ad revenue and data mining.

The need to ensure a market of buyers for goods that are consumed multiple times requires that buyers not create products that undermine their own demand. Within fields like medicine, the form this will naturally take is a preference for repetitive care on a subscription-like basis over one-time solutions, as instanced in a focus on the development of drugs for repeated use over the cures, and on the very notion of health-care – which emphasizes a concept of care as constant superintendence over the emphasis on recovery from sickness emphasized in the notion of medicine. In other sectors it will take the form of a lower product quality to ensure that users return to buy a given product in a sufficiently short amount of time to make good the money spent in securing one’s competitive advantage. In this way, capital concentration leads to the generation of excessive pollution and landfill.

This list of negative consequences of capital concentration is incomplete. In the following days, I intend to discuss ways not to address these problems, then better methods for doing so.

Author’s picks, May 5-11, 2019

I’ve included three posts I particularly like in this week’s summary:

The first, ‘On semantic ambiguity in Anselm of Canterbury’s argument for God’s existence‘, asks the question ‘just how many readings of St Anselm’s ontological argument for the existence of God are there’. Based on ambiguities in the argument’s minor premise alone, I show that there are at least ten.

The second, ‘On logical fallacies employed in the philosophical use of the term ‘tautology’‘ shows that philosophical invocations of the term play on two ambiguities in the term itself. The first justifies the fallacious inference from a statement’s being true by meaning to its being uninformative. The second justifies the mistaken conclusion that claims of existence and claims of meaning are distinct in kind, and hence not inferrable from each other.

The final post, ‘Object-oriented programming objects aren’t objects‘, argues that a common analogy used to compare the objects of programming languages like C# and Java to real-world objects breaks down rather quickly. Instead, I show that programming objects are actually closer to to the philosophical account of objects found in Leibnizian monads than they are to objects as commonly understood.

Object-oriented programming objects aren’t objects

Object-oriented programming is a computing paradigm implemented in widely used programming languages like Java and C#. It is often described colloquially in terms of the following intuitively plausible ideas:

  • The most basic beings in the universe are particular objects
  • Objects belong to kinds, mathematically represented as classes
  • Objects have states and behavior, which are represented mathematically by fields and methods.

States and behavior can only belong to things, which themselves belong – in a different sense – to kinds. To enforce this, object-oriented programming requires fields and methods for kinds of objects to be attached to an associated class. This is usually achieved by placing the code for the methods and fields an object of a given class may have within brackets {} that give the code for the class as a whole. When this happens, fields and methods are said to be encapsulated in their class.

Since objects belonging to one class can belong to a second class by virtue of belonging to the first, as e.g. whatever is a chihuahua is thereby a dog, objects in one class are able to inherit the behavior of other classes – if there are any behaviors or characteristics that all dogs have in common, chihuahuas will also have them.

The principles specifying the above general ideas in ways appropriate for programming languages are called encapsulation and inheritance, and these are two of the basic principles of every object-oriented programming language.

Datei:CPT-OOP-objects and classes - attmeth.svg

1 Object-oriented programming objects aren’t objects

Once one gets past the analogies, however, one realizes that very little object-oriented programming actually conforms to the pre-theoretical explanation given above. To explain this, it will be useful to take a look at a very simple class from an object-oriented language, Java.

class Bicycle {

    int cadence = 0;
    int speed = 0;
    int gear = 1;

    void changeCadence(int newValue) {
         cadence = newValue;
    }

    void changeGear(int newValue) {
         gear = newValue;
    }

    void speedUp(int increment) {
         speed = speed + increment;   
    }

    void applyBrakes(int decrement) {
         speed = speed - decrement;
    }

    void printStates() {
         System.out.println("cadence:" +
             cadence + " speed:" + 
             speed + " gear:" + gear);
    }
}

The above is an example of a bicycle class taken from the Java Tutorials, a series of tutorials for learning the Java language put out by Oracle, who have held the rights to the language since their acquisition of Sun Microsystems, the language’s creator, in 2010. The class’ fields are cadence, speed, and gear. In this case, the fields do seem to fit into a (non-exhaustive) list of properties that a bicycle can have.

The class’ methods, however, don’t reflect the pre-theoretical intuition at all. Instead of representing behaviors of the object itself, these methods represent ways that the fields of an object can themselves be changed or acted on: the changeCadence() method, for instance, doesn’t reflect an action performed by the bike itself, but one that the bike’s rider could perform to it. Worse, the printStates() method, which prints the bicycle’s cadence, speed, and gear to a terminal, doesn’t reflect anything that someone could do with an actual bicycle. Instead, it represents a task that a program or user can perform on an instance of the bicycle class understood precisely as a digital object in digital space.

Playing Cards Deck

In short, real-world objects have states and behavior. Objects in object-oriented programming (OOP) have analogues to these called fields and methods. The fields of object-oriented objects parallel the states of real-world objects more or less faithfully. But the parallel between the methods of object-oriented objects and the behavior of real-world objects breaks down relatively quickly, for two reasons. The first is that more often than not, the methods of object oriented objects do not represent things the object can do, but things that can be done to the object. Second, objects in object-oriented languages don’t neatly distinguish between methods that act on the object in accordance with the nature of the object it is intended to represent (e.g. as pedal() method might work on a bicycle object), and methods that act on the object precisely as a bundle of code within a computer program. Instead, there is a blending together of larger reality that the object is meant to represent with that which it is, as a piece of code, actually a part of.

2 What are OOP objects?

What, then, are OOP Objects? Better yet, what is it that makes such objects unified in some way, rather than random bundles of code? And accordingly, what is it that makes some OOP objects better conform to the ideal of an OOP object than others?

To answer this question, let’s look at one more example:

public class Card {
    private final int rank;
    private final int suit;

    // Kinds of suits
    public final static int DIAMONDS = 1;
    public final static int CLUBS    = 2;
    public final static int HEARTS   = 3;
    public final static int SPADES   = 4;

    // Kinds of ranks
    public final static int ACE   = 1;
    public final static int DEUCE = 2;
    public final static int THREE = 3;
    public final static int FOUR  = 4;
    public final static int FIVE  = 5;
    public final static int SIX   = 6;
    public final static int SEVEN = 7;
    public final static int EIGHT = 8;
    public final static int NINE  = 9;
    public final static int TEN   = 10;
    public final static int JACK  = 11;
    public final static int QUEEN = 12;
    public final static int KING  = 13;

    public Card(int rank, int suit) {
        assert isValidRank(rank);
        assert isValidSuit(suit);
        this.rank = rank;
        this.suit = suit;
    }

    public int getSuit() {
        return suit;
    }

    public int getRank() {
        return rank;
    }

    public static boolean isValidRank(int rank) {
        return ACE <= rank && rank <= KING;
    }

    public static boolean isValidSuit(int suit) {
        return DIAMONDS <= suit && suit <= SPADES;
    }

    public static String rankToString(int rank) {
        switch (rank) {
        case ACE:
            return "Ace";
        case DEUCE:
            return "Deuce";
        case THREE:
            return "Three";
        case FOUR:
            return "Four";
        case FIVE:
            return "Five";
        case SIX:
            return "Six";
        case SEVEN:
            return "Seven";
        case EIGHT:
            return "Eight";
        case NINE:
            return "Nine";
        case TEN:
            return "Ten";
        case JACK:
            return "Jack";
        case QUEEN:
            return "Queen";
        case KING:
            return "King";
        default:
            //Handle an illegal argument.  There are generally two
            //ways to handle invalid arguments, throwing an exception
            //(see the section on Handling Exceptions) or return null
            return null;
        }    
    }
    
    public static String suitToString(int suit) {
        switch (suit) {
        case DIAMONDS:
            return "Diamonds";
        case CLUBS:
            return "Clubs";
        case HEARTS:
            return "Hearts";
        case SPADES:
            return "Spades";
        default:
            return null;
        }    
    }

    public static void main(String[] args) {
    	
    	// must run program with -ea flag (java -ea ..) to
    	// use assert statements
        assert rankToString(ACE) == "Ace";
        assert rankToString(DEUCE) == "Deuce";
        assert rankToString(THREE) == "Three";
        assert rankToString(FOUR) == "Four";
        assert rankToString(FIVE) == "Five";
        assert rankToString(SIX) == "Six";
        assert rankToString(SEVEN) == "Seven";
        assert rankToString(EIGHT) == "Eight";
        assert rankToString(NINE) == "Nine";
        assert rankToString(TEN) == "Ten";
        assert rankToString(JACK) == "Jack";
        assert rankToString(QUEEN) == "Queen";
        assert rankToString(KING) == "King";

        assert suitToString(DIAMONDS) == "Diamonds";
        assert suitToString(CLUBS) == "Clubs";
        assert suitToString(HEARTS) == "Hearts";
        assert suitToString(SPADES) == "Spades";

    }
}

The above provides an example of a Card class, again taken from Oracle’s Java tutorials. Let’s walk through it.

After the name of the class and an initial curly brace, two fields are declared: rank and suit. After this follow all the kinds of suits, then the kinds of ranks. This is followed by a special kind of method, called a constructor, which may be used by other objects to generate an instance of the Card class, then a pair of methods getSuit() and getRank(), which respectively provide, or return, the value of the suit and rank of a card object to whatever object makes use of, or calls, these methods. This pair of functions belongs to a larger class of methods called getters, whose naming and functionality follow a longstanding coding convention. This is followed by two Boolean methods isValidRank() and isValidSuit(), the methods suitToString() and rankToString(), and the main() method. The Boolean methods, named after the logician George Boole, are so-called because the values they return are ‘true’ and ‘false’, which are represented by the numbers 1 and 0 in the two-valued Boolean number system all computers use. The ToString() methods convert an integer data type to a corresponding string of letters. For instance, when provided the number 2, the rankToString() method returns the string ‘Two’. Common best practice for real-world Java applications places the main method in its own, separate Main class, so we’ll leave that method aside for now.

In short, the Card class above consists of two fields, representing common properties of a card object, a makeshift identification of the card ranks and suits with integers that makes them easier to functionally manipulate, and a set of methods that perform various operations on the card’s fields. Related classes are bundled together into a package, which are to Classes what a file folder is to files.

3 Objects as monads

Thus, object-oriented programming classes are integrated into a larger whole, and have methods that act reflexively on their states, where these methods may treat the things they act on either in accordance with the nature of what they represent or in accordance with their nature as objects in an program. Because of the first condition, classes themselves serve as abstract parts in an abstract whole. When a program using these classes is run, objects which are instances of these classes are created and their methods are used in accordance with user input and the instructions in the code itself.  Because of this, objects can, in turn, exist in other objects.

Philosophy has a name for an object which may exist in another object, has behavior which is reflexive upon its own state, and responds to the behavior of other objects through its own spontaneous behavior, such that all these beings exist as part of a harmoniously working whole: a monad. The term goes back to Gottfried Leibniz, who introduced the concept to provide a unified solution  to the problems involved in explaining both interactions between different bodies and the relation of the body to the soul. On Leibniz’s account, objects don’t genuinely change each other’s states. Instead, God so closely harmonized these various objects in their nature at the beginning of creation that a change in one object would automatically result in a corresponding, albeit spontaneous, change in others. Object-oriented objects act on their own states, exist as parts in a harmonious whole and are all ordered by one dominant method called the main method, just as Leibniz’s monads act reflexively on themselves in a harmonious world ordered perfectly by God from creation.

4 Conclusion

Though object-oriented programming objects are often presented as being strictly analogous to real-world objects, this analogy breaks down fairly quickly. While OOP fields are similar to the static properties of real-world objects, the dynamic behavior of OOP objects is fundamentally different from that of real-world objects: OOP methods don’t explicitly distinguish instances of classes as representations from those same objects as instances of code, and the methods bundled together in a class are bundled with that class (rather than another) because of the manner in which they reflect on, utilize, or otherwise manipulate the object’s more basic states. OOP classes are parts in a whole package, and the methods listed for a given class will depend on the role it plays in that whole (or a similar one). When a program is run, the exact order in which various objects act is given by a master method called the main method, usually set off in its own class. In these ways, objects which instantiate classes in packages are closer to the philosophical account of objects found in Leibniz’s account of monads as parts of a harmonious world which act reflexively on their own states in a manner God coordinates, than they are to objects as commonly understood.

 

 

On logical fallacies employed in the philosophical use of the term ‘tautology’

File:Cosine fixed point.svg

The term ‘tautology’ is ambiguous between two closely related meanings.

In the stricter sense, it refers to a statement that is both true by definition and grasped immediately — similar to how the term ‘axiom’ was understood in Euclidean mathematics.

In the broader sense, it refers to a statement that is true by definition, regardless of whether it is grasped immediately. In this latter sense, nearly the whole of mathematics is tautologous.

When something is called a tautology, the above ambiguity is played on by implying that something is tautological in the stricter sense, i.e. that it states something obvious and uninformative, when it is merely tautological in the broader sense. But the fact that something is contained in the meaning of a term implicitly does not imply that it is contained in the meaning of the term explicitly.

The notion of a tautology further suffers from being part of a longstanding, albeit false dichotomy between claims that are true by meaning, or analytic, and those that are statements of empirical facts. Particularly, claims of existence are thought to belong to the latter category, while claims that bear on the meanings of things are thought to be irrelevant to questions of whether something exists.

But every relevant proof of any conclusion relies on predicating meaningful descriptive claims of objects mentioned in those arguments. When those things exist, meaningful truths about those existing things are deduced from non-empirical claims. Furthermore, not all existence proofs are themselves empirical. Proofs of the existence of fixed points in mathematics, for instance, are non-empirical. Likewise, the existence of the planet Neptune was first implied by a proof from irregularities in the orbit of the planet Uranus, and then confirmed by observation.

On semantic ambiguity in St. Anselm of Canterbury’s argument for God’s existence

Benediction Of God The Father, Painting, Canvas, Oil

1 An 11th century benedictine monk’s argument for the existence of God

In the second half of the 11th century, St. Anselm of Canterbury, then a benedictine monk at Bec abbey in northern France, formulated what would become perhaps the most famous argument in all of medieval philosophy. It goes like this.

  1. God is that than which nothing greater can be thought.
  2. That than which nothing greater can be thought really exists.
  3. Therefore, God really exists.

The first premise listed is called the minor premise: it provides the term that will be the subject term in the conclusion, namely ‘God’. The second premise is called the major premise: it provides the term that will be the predicate in the conclusion, namely ‘exists’. Both terms are linked to each other by a common middle term, namely ‘that than which nothing greater can be thought’. The major premise itself is supported by an argument moving from an elucidation of what is implied in this middle term to the conclusion that anything that truly answers to that description must, in fact, exist. That argument, stated informally, is as follows:

Suppose, for the sake of argument, that that than which nothing greater can be thought does not exist. Call this non-existent entity than which nothing greater can be thought a. Now an entity, call it b, can be thought, which is in every way like except that it really exists. But really existing is better than not really existing. Therefore if two entities are alike with respect to all qualities except existing, that which exists is greater. Therefore, is greater than a. Therefore, there is something greater than that can be thought. Therefore, there is something greater than that than which nothing greater can be thought that can be thought. Therefore, since is greater than it, that than which nothing greater can be thought is not that than which nothing greater can be thought. Thus, the assumption that that than which nothing greater can be thought doesn’t really exist leads to a contradiction, and thus must be denied. Therefore, that than which nothing greater can be thought really exists. Therefore, God really exists.

In what follows, I only intend to point out the various ambiguities in the key term of the argument. There are thus multiple different readings of the main premise.

2 Ambiguities in the argument

2.1. Predicative and attributive readings of the argument’s middle term

The first ambiguity is that between what modern linguistics calls predicative and attributive readings of the minor premise.

In a statement of the form ‘A is BC’, where A is the subject term and B and C are adjectives, ‘A is BC’ is predicative if it implies both ‘A is B’ and ‘A is C’. Thus, since ‘Clifford is a red dog’ implies both that Clifford is red and that Clifford is a dog, ‘red’ and ‘dog’ are both predicated predicatively of Clifford. If such an inference cannot be made, then the reading of the predication is attributive. Thus, ‘Rashad is a good quarterback’, is read attributively, since it doesn’t imply anything about him being good as an individual.

In the ontological argument, the predicative reading takes the attributions of God’s thinkability and nothing being greater than him as separate: God is thinkable, and nothing is greater than him. In the attributive reading, these are not separated: this reading states that nothing can be thought to be greater than God – leaving aside whether anything, in fact, is.

2.2 Ambiguities in the domain of the term ‘nothing’

The second ambiguity is in what the term ‘thing’ in the compound word ‘nothing’ ranges over. On the weaker reading, the term ranges over existing things: nothing that exists can be thought to be greater than god – this reading leaves aside whether something that merely could exist can be thought to be so. On the stronger reading, the term encompasses not merely things that do exist, but also things that can exist, used to exist, will exist, or even can be thought to exist: no possible or conceivable thing greater than god can be thought.

2.3 Ambiguities in how the term ‘God’ is taken

The third ambiguity arises for the attributive reading, in whether the term ‘God’ is taken for the thing it refers to, or for the thing it refers to in the manner it refers to it. In the DC comic, Lois Lane believes that Superman is Superman. Since Superman is Clark Kent, she thus believes that the thing that answers to the name ‘Clark Kent’ is Superman. But since glasses are such a great disguise, she doesn’t believe the term ‘Clark Kent’ actually refers to Superman, and thus, doesn’t directly believe that Clark Kent is Superman. In like manner, someone may hold that nothing can be thought to be greater than x, where x is the thing that we call ‘God’, described in some fashion. For instance, one can believe that nothing can be thought to be greater than the creator of the universe. But one can also hold that nothing can be greater than God, taking the term ‘God’ to carry the full weight of its proper meaning – e.g. that if the proper meaning of the term is ‘an all-knowing, all-good, all-powerful being’, than nothing can be greater than that. For short, I will say that when a sentence is assessed by taking a term for what it refers to, but not under the description that the term gives, that term is read objectively; when a sentence is read by taking the object referred to by a term as the term describes it, that term is read descriptively.

2.4 Ambiguities in how the term related to god by the ‘greater than’ relation is taken

The same ambiguity arises for the second related term in the attributive reading. On one reading, nothing x can be thought to be greater than God under its proper description. On another, nothing can be thought to be greater than God, regardless of its description.

3 Summary and conclusion

There are thus, minimally, 10 readings of the claim ‘God is that than which nothing greater can be thought’.

  1. The predicative reading with narrow domain for the term ‘thing’: No existing thing is both thinkable and greater than God.
  2. The predicative reading with a wide domain for the term ‘thing’. No possible or conceivable thing is both thinkable and greater than God.
  3. The attributive reading with narrow domain for the term ‘thing’, with both terms taken objectively: there is no existing thing such that it can be thought to be greater than the being y, where x happens to answer to some description and y to the description ‘God’. In particular, no existing thing can be thought to be greater than that than which nothing greater can be thought – which is a description of God.
  4. The attributive reading with narrow domain for the term ‘thing’, with the term ‘God’ taken descriptively and ‘thing’ taken objectively. There is no existing thing which can be thought to be greater than god, understood as god, irrespective of any description a.
  5. The attributive reading with narrow domain for the term ‘thing’, with the term ‘God’ taken objectively and the term ‘thing’ referring descriptively: No existing thing a can be thought, as a, to be greater than y, where y is God under some description b.
  6. The attributive reading with narrow domain for the term ‘thing’, with both terms taken descriptively. There is no existing thing which can be thought, as a, to be greater than God, as God.
  7. The attributive reading with wide domain for the term ‘thing’, with both terms taken objectively: there is no possible or conceivable thing such that it can be thought to be greater than the being y, where x happens to answer to some description and y to the description ‘God’. In particular, no conceivable thing can be thought to be greater than that than which nothing greater can be thought – which is a description of God.
  8. The attributive reading with wide domain for the term ‘thing’, with the term ‘God’ taken descriptively and ‘thing’ taken objectively. There is no possible or conceivable thing which can be thought to be greater than god, understood as god, irrespective of any description a of x.
  9. The attributive reading with wide domain for the term ‘thing’, with the term ‘God’ taken objectively and the term ‘thing’ referring descriptively: No conceivable or possible thing a can be thought, as a, to be greater than y, where y is God under some description b. For instance, nothing can be thought, as what it is, to be greater than the God worshipped by Abraham.
  10. The attributive reading with wide domain for the term ‘thing’, with both terms taken descriptively. There is no conceivable or possible thing which can be thought, as a, to be greater than God, as God.

In his argument, Anselm uses several of these different readings. He clearly makes use of reading 2, which implies reading 1, when he says an existing that-than-which-nothing-greater-can-be-thought is better than a non-existing one. He also makes use of an objective reading of ‘God’ in the attributive reading of the predicate ‘can be thought greater than’ when he substitutes the description ‘that than which nothing greater than be thought’ itself for the term in the greater than relation. Anselm doesn’t, however, clearly distinguish these different interpretations from each other. Anselm’s argument thus relies on several closely linked, but different, interpretations for its force. The strength of the argument as a whole is dependent on the independent plausibility of the various interpretations of its key phrase which it invokes.

An introduction to the idea of an object in object-oriented programming, 3

Playing Cards Deck

In previous posts, we established the following:

  • Real-world objects have states and behavior. Objects in object-oriented programming (OOP) have analogues to these called fields and methods.
  • The fields of object-oriented objects parallel the states of real-world objects more or less faithfully. But the parallel between the methods of object-oriented objects and the behavior of real-world objects breaks down relatively quickly, for two reasons:
    • The first is that more often than not, the methods of object oriented objects do not represent things the object can do, but things that can be done to the object.
    • Second, objects in object-oriented languages don’t neatly distinguish between methods that act on the object in accordance with the nature of the object it is intended to represent (e.g. as a ‘pedal’ method might work on a bicycle object), and methods that act on the object precisely as a bundle of code within a computer program. Colloquially, one might say there is a blending together of larger reality that the object is meant to represent with that which it is, as a piece of code, actually a part of.

What are OOP objects?

What, then, are OOP Objects? Better yet, what is it that makes such objects unified in some way, rather than random bundles of code? And accordingly, what is it that makes some OOP objects better conform to the ideal of an OOP object than others?

To answer this question, let’s look at one more example:

public class Card {
    private final int rank;
    private final int suit;

    // Kinds of suits
    public final static int DIAMONDS = 1;
    public final static int CLUBS    = 2;
    public final static int HEARTS   = 3;
    public final static int SPADES   = 4;

    // Kinds of ranks
    public final static int ACE   = 1;
    public final static int DEUCE = 2;
    public final static int THREE = 3;
    public final static int FOUR  = 4;
    public final static int FIVE  = 5;
    public final static int SIX   = 6;
    public final static int SEVEN = 7;
    public final static int EIGHT = 8;
    public final static int NINE  = 9;
    public final static int TEN   = 10;
    public final static int JACK  = 11;
    public final static int QUEEN = 12;
    public final static int KING  = 13;

    public Card(int rank, int suit) {
        assert isValidRank(rank);
        assert isValidSuit(suit);
        this.rank = rank;
        this.suit = suit;
    }

    public int getSuit() {
        return suit;
    }

    public int getRank() {
        return rank;
    }

    public static boolean isValidRank(int rank) {
        return ACE <= rank && rank <= KING;
    }

    public static boolean isValidSuit(int suit) {
        return DIAMONDS <= suit && suit <= SPADES;
    }

    public static String rankToString(int rank) {
        switch (rank) {
        case ACE:
            return "Ace";
        case DEUCE:
            return "Deuce";
        case THREE:
            return "Three";
        case FOUR:
            return "Four";
        case FIVE:
            return "Five";
        case SIX:
            return "Six";
        case SEVEN:
            return "Seven";
        case EIGHT:
            return "Eight";
        case NINE:
            return "Nine";
        case TEN:
            return "Ten";
        case JACK:
            return "Jack";
        case QUEEN:
            return "Queen";
        case KING:
            return "King";
        default:
            //Handle an illegal argument.  There are generally two
            //ways to handle invalid arguments, throwing an exception
            //(see the section on Handling Exceptions) or return null
            return null;
        }    
    }
    
    public static String suitToString(int suit) {
        switch (suit) {
        case DIAMONDS:
            return "Diamonds";
        case CLUBS:
            return "Clubs";
        case HEARTS:
            return "Hearts";
        case SPADES:
            return "Spades";
        default:
            return null;
        }    
    }

    public static void main(String[] args) {
    	
    	// must run program with -ea flag (java -ea ..) to
    	// use assert statements
        assert rankToString(ACE) == "Ace";
        assert rankToString(DEUCE) == "Deuce";
        assert rankToString(THREE) == "Three";
        assert rankToString(FOUR) == "Four";
        assert rankToString(FIVE) == "Five";
        assert rankToString(SIX) == "Six";
        assert rankToString(SEVEN) == "Seven";
        assert rankToString(EIGHT) == "Eight";
        assert rankToString(NINE) == "Nine";
        assert rankToString(TEN) == "Ten";
        assert rankToString(JACK) == "Jack";
        assert rankToString(QUEEN) == "Queen";
        assert rankToString(KING) == "King";

        assert suitToString(DIAMONDS) == "Diamonds";
        assert suitToString(CLUBS) == "Clubs";
        assert suitToString(HEARTS) == "Hearts";
        assert suitToString(SPADES) == "Spades";

    }
}

The above provides an example of a Card class, again taken from Oracle’s Java tutorials. Let’s walk through it.

After the name of the class and an initial curly brace, two fields are declared: rank and suit. After this follow all the kinds of suits, then the kinds of ranks. This is followed by a special kind of method, called a constructor, which may be used by other objects to generate an instance of the Card class, then a pair of methods getSuit() and getRank(), which respectively provide, or return, the value of the suit and rank of a card object to whatever object makes use of, or calls, these methods. This pair of functions belongs to a larger class of methods called getters, whose naming and functionality follow a longstanding coding convention. This is followed by two boolean methods, isValidRank() and isValidSuit(), the methods suitToString() and rankToString(), and the main method.

Tomorrow, I’ll continue to explain how to understand objects and classes in object-oriented programming.

A short note on being, being true, and existence

Some statements describe states of affairs that can never occur. An example is the statement ‘2+2=5’, assuming the terms ‘2’, ‘+’, ‘=’, and ‘5’ retain their standard meaning. Another example would ‘John owns three dogs, but no canines’.

Other statements describe states of affairs that can occur, but can never be stated truly. The medieval logician John Buridan gives ‘no statement is negative’ as an example. Other examples include ‘I am not here’ and ‘I am not speaking’.

In other words, there is a difference between something being impossible on account of what it is and its being impossible because its existence or obtaining would entail a contradiction.

Therefore, there is a difference between essence and existence.