index.html  ‘Being’ and ‘Doing’ as Ontological Constructs in Object-Oriented Programming




Kumiko Tanaka-Ishii and Yuichiro Ishii

University of Tokyo


 


Abstract


In this article the authors argue that an ontology based either upon ‘being’ or ‘doing’ will emerge, depending on which aspect of Peirce’s triadic model of the sign is emphasized: the object or the interpretant. Their argument is based on an analysis of two types of ontology used in object-oriented computer programming: namely, the class and the abstract data type. Among their findings is the observation that the programming ontology is determined by the object-types defined, rather than the inverse. Keywords: Object-oriented programming paradigm, class, abstract data type, Peirce’s sign model.




1. Introduction


The focus of this paper is the ontological dichotomy between ‘being’ and ‘doing.’ An intuitive analogy to this antithesis can be drawn from narratology. Todorov (1977) distinguishes between the ‘being’ and ‘doing’ motivations underlying the actant in a narrative: the ‘psychological,’ and the ‘a-psychological,’ respectively. In a murder story, for instance, the psychological motivation takes the form ‘he kills because he is a killer,’ whereas the ‘a-psychological’ motivation takes the form ‘he is a killer because he kills.’ ‘Being,’ in this paper, refers to the ontological status of an object whose ontic character is established by what it is, while the term ‘doing’ denotes that of an object whose ontic character is specified by what it does and by what can be done to it.


The distinction between ‘being’ and ‘doing’ is seen broadly in philosophy as well as in computer programming. The computer programming community is unique in that it is a complete world consisting only of signs, perhaps without any real-world objects. Yet even here the same contrasting paradigms of ‘being’ and ‘doing’ co-exist. Curiously, among the various computer programming disciplines, this contrast is seen exclusively in the object- oriented paradigm. This suggests that the emergence of the ‘being’ and ‘doing’ schism is due to the way in which objects are described. Within the object-oriented paradigm, an object is modeled by a triplet sign consisting of its name, its features, and its functions. We argue that an ontology of either ‘being’ or ‘doing’ must arise as a direct result of this triadic modeling of the object: an emphasis on features leads to the ‘being’ ontology, whereas an emphasis on functions leads to the ‘doing’ ontology. Object modeling in the object-oriented paradigm is, in fact, analogous to Peirce’s sign model, as discussed in more detail in (Tanaka-Ishii, 2006). Combining this hypothesis with the ‘being’/’doing’ dichotomy, we arrive at a more general hypothesis, namely that the ‘being’/’doing’ antithesis emerges in domains wherever objects are described according to triadic sign modeling. In the case of Peirce’s triadic sign model, the ‘being’ ontology emerges when object relations are constructed according to objects, in Peirce’s sense of the word, whereas the ‘doing’ ontology emerges when object relations are constructed according to the interpretant. Therefore, our hypothesis makes the assumption that an ontology is defined by its sign model.


We frame the beginnings of our main argument by first describing the ‘being’/’doing’ dichotomy existing within the object-oriented paradigm. We then demonstrate and explain two sample software programs, one written according to the ‘being’ ontology, and the other, according to the ‘doing’ ontology. Finally, we discuss how Peirce’s triadic sign model represents the two programs.



2. Class and Abstract Data Type


In computer programs, objects are modeled and described by a data structure utilizing signs. The design of this data structure is critical, since it determines the comprehensiveness, ease of maintenance, extensibility, and, above all, the reliability of programs incorporating the data structure. Badly-designed structures make errors and bugs difficult to identify, and hinder cooperative development by a group of programmers. A bad data structure can often require the rewrite of an entire program from scratch.


Conflicts between ‘being’ and ‘doing’ ontologies are especially likely to occur within the object-oriented programming paradigm. Under this paradigm, programs are based on the interaction of units called objects, where each object is described by an abstract construct that models the object in terms of functions and features (Snyder, 1986) (Meyer, 1988). Using objects as units makes it easier to package data and functionality together. This packaging functionality is usually called encapsulation and represents the fundamental philosophy underlying the object-oriented paradigm. Objects are thus the basis of modularity and structure in an object-oriented computer program.


Note that the term object here has a different meaning from that of Peirce. Peirce’s sign consists of the well-known triad: the representamen, the object, and the interpretant. An object is characterized by Peirce as ‘a sort of idea’ (Peirce, 1931 : 2.228) about the that which is represented by the sign; thus, it can be considered to correspond to the immaterial representation of an object.1 Footnote In this paper, we use the term object to denote an object in the sense of the object-oriented programming paradigm, while consistently referring to Peirce’s object as such. We do not refer again to Peirce’s object until Section 5, however, so for the time being any use of object refers to the current programming definition. According to Meyer (1988), a set of objects can be described in two ways: by class, or by abstract data type.




 

Class

Abstract data type

Ontological character

‘being’

‘doing’

Java (Section 3, Section 4)

class

interface

Code-sharing

yes

no

Task-sharing

hard

easy


Table 1: Contrast between class and abstract data type: a typology in Meyer (1988)



 ❐ A class is a collection of objects that have exactly the same internal structure; that is, the same instance variables, the same body, and the same functions.

 ❐ An abstract data type is a collection of objects that have the same functionality. An abstract data type provides an interface describing what actions can be applied to objects.


These two conceptions of object sets lead to completely different notions of the underlying ontological constructs, as compared in Table 1.


In programs based on class, every object deriving from a class has the same internal structure (i.e., features and functions). Thus, a programmer using a class is assumed to be well acquainted with that structure. This assumption increases the programmer’s responsibility to know about objects with respect to ‘what they are’ and how to use them consistently. Under such circumstances, it is difficult for many programmers to work cooperatively. This is a ‘being’ sort of object construction, in which the ontological relation is formed according to what the object is.


Programs based on abstract data types have exactly the opposite property. An abstract data type is a set of declarations regarding the functionalities of a collection of objects. Objects are typed only according to which abstract data type is adopted. Thus, an abstract data type provides a protocol for another object as a user, explicitly showing what can be done to the object. All communication with such objects is conducted via this interface. Under such circumstances, cooperative programming is relatively easy, because the knowledge needed by a programmer is limited to knowledge of the abstract data type. This is a ‘doing’ kind of object construction, in which the ontological relation is formed according to what the object can do or what can be done to the object.


The object-oriented paradigm initially accommodated only the ‘being’ concept but then gradually incorporated the ‘doing’ functionality in response to needs for more complex, larger-scale programs. The first successful object-oriented languages, such as Simula (Dahl and Nygaard, 1966) (Poorley, 1986) and Smalltalk (Goldberg and Kay, 1976), allowed object design only via a class. The more recent C++ language has the implicit/limited functionality of the abstract data type (Stroustrup, 1986) (Stroustrup, 1994). Very recent languages, such as Java (Arnold et al., 2000), incorporate the abstract data type as a major part of the language’s design.


This historical development does not imply that ‘being’ type paradigms are no longer used. In current programming language design, ‘being’ and ‘doing’ are balanced between code sharing and task sharing. Usually, criteria are drawn up concerning the separation requirements in design and implementation. In actual coding, when a single programmer develops a small-scale program, the ‘being’ ontological framework is preferred. In contrast, the ‘doing’ framework is adopted when the scale is large and the project involves many different programmers and multiple tasks (such as when building a language library). Still, the question of which ontological framework should be used in various situations is controversial, and there is an ongoing argument on a fundamental level as to how to incorporate the ‘doing’ concept into programming language design (Arnold et al., 2000). This is confirmed by the fact that the term abstract data type, which we have used thus far to indicate the ‘doing’ construct, is still not well-established. America and van der Linden (1990) use another simple term, type, defined as ‘a collection of objects that share the same externally observable behaviour,’ but the usual meaning of the term type is different. Snyder (1986) calls it a ‘deferred class’ (which is again ambiguous within the context of this paper, because here we consistently use the term class to represent the implementation of ‘being’). Again, in this study, we use the term abstract data type. Such classes and abstract data types are implemented as classes and interfaces, respectively, in Java. In the next two sections, we consider two actual examples: one of the ‘being’ type, and one of the ‘doing’ type.



3. A ‘Being’ Program Sample


Consider the simple example of shapes (such as rectangles and ellipses). Suppose that the computation objective is to calculate the areas of shapes and print the area of each instance of a shape. Because a class requires designing the internal structure (i.e., features as well as functions), we use a simple design modeling a shape as having the features of width and height.








Figure 1: An object hierarchy


A possible class hierarchy is shown in Figure 1. Here, all shapes are placed under the class named Shape, with features of width and height, as well as a function to calculate the area. The ontology according to classes is constructed as class B being the parent of A when the relationship, ‘A is a B,’ holds (Meyer, 1988). For example, a rectangle is a shape, and an ellipse is a shape. More formally, the is a relationship can be mathematically interpreted as a set-theoretic relationship with all instances of class A being included in class B. Since ‘a circle is an ellipse’ but ‘an ellipse is not necessarily a circle,’ the class Circle is placed as a child of the class Ellipse. Such an inter-class relationship, ‘A is a B,’ is called inheritance (Meyer, 1988), and it guarantees that classes A and B have the same features and functions, while the child can have additional features. For example, a circle has the additional feature of its width equaling its height.



1: class Shape {

2: double width, height;

3: Shape(double w, double h) { width=w; height=h; }

4: public double area() { return width*height; }

5: }

6:

7: class Rectangle extends Shape {

8: Rectangle(double w, double h) { super(w,h); }

9: }

10:

11: class Ellipse extends Shape {

12: Ellipse(double w, double h) { super(w,h); }

13: public double area() { return Math.PI*width*height/4.0; }

14: }

15:

16: class Circle extends Ellipse {

17: Circle(double r) { super(r*2,r*2); }

18: }

19:

20: void run() {

21: Rectangle r = new Rectangle(5,8);

22: Ellipse u = new Ellipse(3,4);

23: Circle v = new Circle(3);

24:

25: Vector<Shape> fs = new Vector<Shape>();

26: fs.add(r); fs.add(u); fs.add(v);

27: for (Shape f : fs) { print("area: " + f.area()); }

28: }


Figure 2: A sample program based on the ‘Being’ ontology



This type of object design can be applied to generate an executable program in Java (Figure 2). In the following program, the classes Shape, Rectangle, Ellipse, and Circle are defined in lines 1, 7, 11, and 16, respectively. These are connected by the keyword extends, which establishes the is a relationship among the classes. In Java, the connection of classes A and B by ‘A extends B’ introduces the following two effects.


 ❐ Instances of class A have the same extended internal structure (features and functions) as instances of class B.

  ❐ Instances of class A can be handled as if they belong to B.


The first effect means that instances of class A have all of the same features (called member variables) and functions (called member functions or methods) as those of any instance of class B. Therefore, in our sample program, classes that extend the class Shape inherit the features width and height declared in line 2 and the function area in line 4. Thus, all classes defined in this program adopt these features and the function. For example, neither the variables width and height nor the function area is declared in the class Rectangle in lines 7 to 9. Still, the features and the function are usable for all instances of Rectangle.


The member function area is defined to calculate the area as the width multiplied by the height (line 4): this is the default way to calculate the area. As this calculation applies to rectangles, the class Rectangle inherits it from Shape. In some cases, such as Ellipse, this formula is incorrect and must be changed. In this case, the function area is redefined (overridden) in line 13; this definition is in turn inherited by the class Circle. Similarly, while inheritance enhances code sharing, it can also lead to chains of redefinitions within a class hierarchy.


The second effect of the Java keyword extends is that all instances deriving from the class Shape can be handled as instances of the same type. This is possible because instances deriving from the class are guaranteed to have the features of width and height and the function area. Three instances (a rectangle assigned as r, an ellipse u, and a circle v) are newly allocated in lines 21 to 23. A vector of type Shape is allocated in line 25, shape instances are added to this vector in line 26, and their areas are printed in line 27, all together in a uniform manner.


Classes and their relations defined by extends thus enhance code sharing through the inheritance feature. This is an important feature in programs: if the same sequence of code is reproduced throughout a program, a programmer has to modify each occurence of that same code when a bug is found within it; with inheritance, the code is kept in a unique location, so errors are easily fixed.


On the other hand, the relationships created among classes by inheritance are narrow, since all structural information is shared among the classes. This can create difficulties since we often need to add a new class to a previously developed program. The relaxed original class design of our sample program might be able to describe new figures such as trapezoids or rhombi, but first we have to know the complete structural design deriving from Shape in order to determine where to add such shapes as the trapezoid and the rhombus.


Such strict sharing of the internal structure also makes it difficult to know which feature is declared where. For example, the whole structure of class Circle is unclear until we move up the class hierarchy as far as Shape: area is declared in the class Ellipse, and the features width and height are declared in the class Shape. Under such circumstances, it is difficult for many programmers to work cooperatively because it is impossible to share the class design, especially when the class hierarchy becomes deep. Thus, class-based object-oriented programs are often unsuitable for task sharing. In addition, extending two classes to a single class is disallowed (the multiple-inheritance prohibition) in many object- oriented programming languages. This is because multiple inheritance amalgamates all features and functions, leading to inheritance of some unwanted features or even confusion, such as that caused by a feature being adopted from different parents.



1: class Shape {

2: double width, height;

3: Shape(double w, double h) { width=w; height=h; }

4: }

5:

6: class Rectangle extends Shape{

7: Rectangle(double w, double h) { super(w,h); }

8: }

9:

10: class Ellipse extends Shape{

11: Ellipse(double w, double h) { super(w,h); }

12: }

13:

14: class Circle extends Shape{

15: Circle(double r) { super(r*2,r*2); }

16: }

17:

18: double area(Rectangle f) { return f.width*f.height; }

19: double area(Ellipse f) { return Math.PI*f.width*f.height/4.0; }

20: double area(Circle f) { return Math.PI*f.width*f.height/4.0; }

21:

22: void run() {

23: Rectangle r = new Rectangle(5,8);

24: Ellipse u = new Ellipse(3,4);

25: Circle v = new Circle(3);

26:

27: print("area: " + area(r));

28: print("area: " + area(u));

29: print("area: " + area(v));

30:

31: print("vertices: " + vertices(r));

32: }


Figure 3: Another sample program based on the ‘Being’ ontology



Consequently, class-based programming is used to describe objects according to what an object is. Referring to a class hierarchy based on extends an ‘is a’ relationship also demonstrates the way in which class design can be based on the ‘being’ concept. Such ‘being’ constructs are essentially based primordially on having common features rather than common functions. A similar, but more primitive, ‘being’-type program in Java is shown in Figure 3, in which the whole is defined as a class. Here, the instances are related only by features, and functions are placed outside the classes (lines 18 to 20). The opposite approach, that of leaving functions inside the class and placing features outside, is not possible, because objects are defined primordially by their features. The function side defines which functions apply to which class of objects. For example, the function that applies to instances of Rectangle has the form of double area(Rectangle f) (line 18), indicating that this function is uniquely defined for instances of the Rectangle.


Even when functions are placed outside classes, the ontological relations are still based on ‘being,’ and the discussion so far holds in exactly the same way. This is because features are primordial with respect to the being of an object, i.e., an object cannot exist without initializing features, after which functions can then be applied. When such a primordial, essential structure is shared by using the keyword extends, objects naturally become tightly related, which prevents task sharing by multiple programmers. Thus, ‘being’ refers to a way of being in which an ontological relation is established essentially according to features.






Figure 4: Another object hierarchy class



                                                 


4. A ‘Doing’ Program Sample


Programming can be approached in a completely different manner by designing objects through the use of an abstract data type. This structural design is illustrated in Figure 4. Unlike Figure 1, this figure shows two interfaces (indicated by the dashed circles). An interface declares a set of functions, which only indicate how objects are accessed. The interfaces are adopted by classes, indicated by the solid circles. The functionality of a class is of the ‘being’ kind, but adopting an interface changes it into a ‘doing’ kind by having the protocol declared within the interface. An interface only declares functions; the actual implementation of each function is up to each class. The interface Measurable declares the function area(), while the interface Polygon declares a function that returns the number of vertices in a polygon. All three shapes (i.e., rectangles, ellipses, and circles) are measurable, but among them only rectangles qualify as polygons.


It is not our intention to assert that classes based on the ‘being’ ontology lack functions, nor that one based on the ‘doing’ ontology lacks features. Any object should have features that define its existence, and actions should be applied to the object. An interface simply has the role of relating objects by sharing functions.


This illustration can be represented in another sample program, as shown in Figure 5. First, we see two interfaces, Measurable and Polygon, in which functions are declared (lines 1 and 5). Interfaces may include multiple function declarations but not their actual implementations. This differs from the previous program, in which the area function of the Shape class was included in the actual implementation. Also, features are part of the implementation, so they cannot be described within the interface. All such actual implementations occur inside classes.


There are three classes, as in the previous program. Here, the functionality of a class is the same as that described in the previous section, so it is inherently of the ‘being’ type.



1: interface Measurable {

2: double area();

3: }

4:

5: interface Polygon {

6: int vertices();

7: }

8:

9: class Rectangle implements Measurable, Polygon {

10: double width, height;

11: Rectangle(double w, double h) { width = w; height = h; }

12: public double area() { return width*height; }

13: public int vertices() { return 4; }

14: }

15:

16: class Ellipse implements Measurable {

17: double width, height;

18: Ellipse(double w, double h) { width = w; height = h; }

19: public double area() { return Math.PI*width*height/4.0; }

20: }

21:

22: class Circle implements Measurable {

23: double radius;

24: Circle(double r) { radius = r; }

25: public double area() { return Math.PI*radius*radius; }

26: }

27:

28: void run() {

29: Rectangle r = new Rectangle(5,8);

30: Ellipse u = new Ellipse(3,4);

31: Circle v = new Circle(3);

32:

33: Vector<Measurable> fs = new Vector<Measurable>();

34: fs.add(r); fs.add(u); fs.add(v);

35: for (Measurable f : fs) { print("area: " + f.area()); }

36:

37: Vector<Polygon> ps = new Vector<Polygon>();

38: ps.add(r);

39: for (Polygon p : ps) { print("vertices: " + p.vertices()); }

40: }


Figure 5: A sample program based on the ‘doing’ ontology



When classes implement interfaces by using the Java definition ‘A implements B,’ however, with A being a class and B being an interface, instances of class A are transformed to the ‘doing’ type. Precisely, ‘A implements B’ has the following effects.


 ❐ A should define the functions declared in B.

 ❐ Instances of A can be handled as instances of type B.


This second effect is common to the case of extends. As for the first effect, because implements has no inheritance effect, it has to be guaranteed that the actual code exists somewhere.


All classes implement the interface Measurable, so in each class we see the function area within the actual code (lines 12, 19, and 25). Also, Rectangle implements Polygon, so the function vertices is implemented only in this class (line 13).


The actual use of objects is seen in the function run from lines 28 to 40. Instances of three shape types are allocated in lines 29 to 31, the areas of the measurable types are printed together in line 35, and the number of vertices of the rectangle, as a polygon, is printed in line 39.


As seen in this program, because implements has no power of code sharing, programming only with implements tends to result in the same code being scattered in different parts of a program. For example, the function area is similar for Ellipse and Circle, but it cannot be shared only through the use of implements.


On the other hand, programming based on implements separates the design and implementation. The interface only provides the design by declaring what actions can be applied to objects. The actual implementation, however, is left to the actual classes. For example, if another object type, such as rhombus, is needed, it can be designed by looking only at two interfaces and can be added without being related to the other classes, Rectangle, Ellipse, and Circle. Also, the implementation of two interfaces at the same time is allowed, as in the case of the Rectangle class. Implementation of multiple interfaces causes no problems, because no implementation occurs inside an interface. Consequently, the abstract data type changes a class from the ‘being’ type to the ‘doing’ type. An abstract data type represents objects by means of what can be done to them.


A frequent metaphor used in teaching programming languages is that classes connected by extends create a family system, whereas abstract data types defined by implements create a license system (Arnold et al., 2000). This metaphor provides an intuitive contrast similar to that between ‘being’ and ‘doing,’ as illustrated by the analogical contrast of ‘being,’ for ‘he kills because he is a killer,’ and ‘doing,’ for ‘he is a killer because he kills’.



5. ‘Being’ vs. ‘Doing’ and the Triadic Sign Model


We next examine how such a ‘being’ versus ’doing’ opposition can be related to Peirce’s sign model. In philosophy, the ontological framework and sign models are usually considered as issues on different levels, deeply rooted in a transcendental problem. The computer programming domain is unique, however, in that objects are modeled and described by signs so that they can be used in calculation. In computers, there is little or nothing other than signs. Even under such extreme circumstances, however, the ontological distinction still arises between ‘being’ and ‘doing.’






Figure 6: ‘Being,’ ‘doing,’ and Peirce’s Triadic Sign Model



The dichotomy between ‘being’ and ‘doing’ does not appear in all programming paradigms, but exclusively in object-oriented programming. Thus, there must be a key to explain why this contrast occurs only in terms of how objects are described within object-oriented programming. This key is now clear: the triadic modeling of objects that separates features and functionality.


In a previous paper (Tanaka-Ishii, 2006), we discuss the way in which the object-oriented programming paradigm is particular in its triadic modeling of signs, which is especially analogous to Peirce’s model.2 Footnote The theme of that paper was to clarify the correspondence between dyadic sign modeling and triadic sign modeling. Traditionally, it has been thought that Peirce’s interpretant corresponds to Saussure’s signified (Constantin, 1993), and that Saussure’s model lacks Peirce’s object (Noth, 1990) (Eco, 1988). The first author of this paper raised a different hypothesis based on semiotic analysis of two computer programming paradigms: object-oriented, and functional. We showed how Peirce’s object formally corresponds to Saussure’s signified, and that Saussure’s sign model is obtained when Peirce’s interpretant is located outside his model in the language system. Here, the class name corresponds to the representamen, features to Peirce’s object, and functions to the interpretant. For example, the representamen corresponds to names such as Shape, Rectangle, and Circle; Peirce’s object corresponds to features such as width and height; and the interpretant corresponds to functions such as area()and vertices(). This correspondence is illustrated in Figure 6.


As summarized in the figure, we have now described two correspondences:


 ❐ between the focus on features/functions, and upon ‘being’/’doing’ ontologies;

 ❐ between Peirce’s object, representamen and the interpretant, on the one hand, and the name, features, and functions of a class, on the other.


We then derive the following hypothesis:


 ❐ ‘Being’ is an ontic state in which the ontological relation is established based on an object comparable to Peirce’s object.

 ❐ ‘Doing’ is a state in which the ontological relation is established based on a concept comparable to Peirce’s interpretant.


In other words, the hypothesis of this paper is that the ontological difference between ‘being’ and ‘doing’ emerges depending on which side of the triadic sign model is emphasized in constructing an ontology. In other domains, where objects are described by a model analogous to that of Peirce, the same contrast of ‘being’ and ‘doing’ will emerge, as in object-oriented programming.


It is important to remark that our hypothesis does not imply that both ‘being’ and ‘doing’ are dyadic ways of being. The ontology is formed through the relation of beings; the question is, what is utilized to form the relation. Practically speaking, in object-oriented programming language, both ‘doing’ and ‘being’ are based on triads. Our argument is that ‘being’ is a way of being whose ontological relation is constructed based on Peirce’s object, whereas ‘doing’ is a way of being whose ontological relation is constructed based on the interpretant. This does not mean that no other relata are used to construct the ontological relation.


The same applies for signs, where ‘aliquid pro aliquo’ (Noth, 1990) is reversed. Before Peirce or Saussure, it was thought that signs are names attached to objects, but Peirce and Saussure reversed this so that signs define objects. Similarly, an ontological hierarchy is thought of as being defined by actual relations existing between objects. Our discussion shows, however, that it is actually the other way around: the sign model is what defines the ontological framework. This is also clear from the fact that in computer programming, the contrast of ‘being’ and ‘doing’ emerges exclusively when applying triadic modeling of signs. In other words, the sign defines the ontology.



6. Concluding Remarks


We have argued that the ‘being’ and ‘doing’ ontologies derive from Peirce’s triadic sign model. We assume that either the ‘being’ or ‘doing’ ontology emerges depending on which side of the triadic sign model is emphasized in constructing object relations. In closing this paper, we present two remarks related to our argument. The first is related to Heidegger’s statement suggesting that the ‘doing’ relation is primordial with respect to the ‘being’ relation (Heidegger, 1926) (Gelven, 1989). In contrast, Peirce says that his object is the secondness and the interpretant is the thirdness within his universal categories (Peirce, 1931). Therefore, Peirce and Heidegger offer different opinions as to which type is primordial. Our opinion, however, is that Heidegger’s primordiality derives from outside the object, whereas Peirce’s primordiality derives from inside the object. In any programming project, it should definitely be known how an instance is to be used from the outside, whereas knowledge of the internal structure is not necessarily needed. This suggests that from the programmer’s viewpoint, the ‘doing’ relation is more fundamental than ‘being.’ Peirce, in contrast, takes a viewpoint from within the sign. Indeed, when constructing an object, the allocation of features is more fundamental than that of the functions, because without allocating features, no actions can be applied to the object. Therefore, for Peirce, his object is on a lower order of being as compared to the interpretant.


Our second remark concerns ‘complexity.’ Maruyama, the political scientist, has identified the shift from ‘being’ to ‘doing’ as a symbol of modernity (Maruyama, 1961). According to Maruyama, the dynamics of modernity is the deconstruction of the social hierarchy rooted in ‘being,’ by filtering away all kinds of ineffective dogma and authority. Such deconstruction is generated from a shift of value from ‘being’ to ‘doing’ that occurred because of the increased social complexity resulting from advances in communication and transportation technologies. According to Maruyama, the question for the modern world is ‘to do or not to do,’ rather the question of whether ‘to be or not to be’ in Shakespeare’s Hamlet. In programming languages, too, the abstract data type has become more important as software complexity has increased. This shift is related to complexity, because when many different objects must be handled, they can no longer be understood through a deep knowledge of what they are. The solution is to define a simple interface, or communication protocol, and then to limit the relations between objects according to that interface. Under the ‘being’ ontology, the programmer had the total responsibility to know what they were using; today, under the ‘doing’ ontology, the programmer’s knowledge can be limited to the predefined communication protocol, or interface.


The ‘being’ relation has not been totally replaced, however, by ‘doing.’ Given today’s complexity in both computers and in general, the question arises as to whether ‘to be or to do.’ Maruyama warns that the distinction between ‘being’ and ‘doing’ is poorly understood, on a widespread scale. Domains of knowledge that should be evaluated in terms of ‘what is done’ are often evaluated in terms of ‘what is,’ and vice versa. Indeed, both classes and abstract data types exist within any object-oriented paradigm, but software quality is determined by how they are used.


Appropriate criteria for deciding between these ontologies might emerge as we learn how to properly incorporate ‘doing’ into programming languages in the future. For example, we have seen that one key strategy is to achieve a balance between task sharing and code sharing. To answer the question of ‘to be or to do,’ it is important to investigate the nature of the contrast between ‘being’ and ‘doing’.


This semiotic discussion of programming theory has sought to explain certain aspects of the way in which programming has converged to its current status, and the manner in which computation is fundamentally related to human semiosis. In programming language courses, many of the concepts and notions are taught simply as facts, without any reasoning as to why these concepts and notions are the way they are. For example, the contrast of abstract data type and interface, as related to a sign model, is unlikely to be explained during a lecture; instead, it is generally just mentioned as part of the fundamental logic underlying descriptive languages. These concepts should be organized and understood, however, not only from a logical viewpoint but also from a broader view as part of human signs. Semiotics provides a good framework for such a discussion. This paper is such an attempt, in which an approach based on both the programming language domain and that of semiotics lends itself to increased understanding in both disciplines.




References

 

America, P. and van der Linden, F. (1990). “A parallel object-oriented language with inheritance and subtyping.” In ECOOP/OOPSLA ‘90 proceedings, pages 161-168.

Arnold, K., Gosling, J., and Holmes, D. (2000). The Java Programming Language. Pearson Education.

Constantin, E. (1993). 3e Cours de Linguistique Générale (2e partie : la langue) de Ferdinand Saussure. Pergamon.

Dahl, O.-J. and Nygaard, K. (1966). “SIMULA | an Algol-based simulation language.” Communications of the ACM, 9(9), 671{678.

Deledalle, G. (1979). Théorie et pratique du signe : introduction à la sémiotique de Charles S. Peirce. Payot.

Eco, U. (1988). Le Signe. Histoire et analyse d’un concept, adaptée de l’italien par Jean- Marie Klinkenberg. Editions Labor.

Gelven, M. (1989). A commentary on Heidegger’s Being and Time. Northern Illinois University Press.

Goldberg, A. and Kay, A.E. (1976). “Smalltalk-72 Instruction Manual.” Tech. Report SSL-76-6, Xerox Palo Alto Research Center.

Heidegger, M. (1926). Being and Time. Blackwell Publishing, first English version published in 1962.

Maruyama, M. (1961). Thoughts on ‘To be’ and ‘To do,’ pages 153-180. Iwanami.

Meyer, B. (1988). Object-Oriented Software Construction. Prentice Hall.

Noth, W. (1990). Handbook of Semiotics. Indiana University Press.

Peirce, C. (1931). Collected Papers. Harvard University Press.

Poorley, R. J. (1986). An Introduction to Programming in SIMULA. Blackwell    Scientific, Oxford.

Snyder, A. (1986). “Encapsulation and inheritance in object-oriented programming languages” in OOPSLA ‘86 Proceedings, pages 38{45.

Stroustrup, B. (1986). The C++ Programming Language. Addison-Wesley.

Stroustrup, B. (1994). The Design and Evolution of C++. Addison-Wesley.

Tanaka-Ishii, K. (2006). Dyadic and triadic sign models. Semiotica, 2006: 1-20.

Todorov, T. (1977). The Poetics of Prose. Cornell University Press.




Endnotes

1. More precisely, Peirce’s object in this article indicates Peirce’s immediate object, i.e., ‘as the Sign itself representsit, and whose Being is thus dependent upon the Representation of it in the Sign’ (Peirce, 1931, (4.536)), as opposed to his mediate object, i.e., an ‘Object outside of the sign,’ or ‘the Reality which by some means contrives to determine the Sign to its Representation’ (4.536). For a more detailed discussion of this separation, see Tanaka-Ishii (2006).

2. It has been controversial whether the main parts of Peirce’s sign theory can be attributed to Peirce himself. Many haveshown how parts of Peirce’s major lines of thought originate in the philosophy of Aristotle, and how Peirce’s philosophy on signs is deeply rooted in Stoic philosophy. For example, (Deledalle, 1979, p.193) shows how triadic sign modeling, the distinction between the representamen, interpretant, and objects, and other important concepts in Peirce’s sign theory already existed in the language philosophy of the Stoics. Clarification of the originality and newness of Peirce’s theory is all the more complicated because of inconsistencies seen in his writings. The uncertainty over the originality of Peirce’s academic contribution, however, is outside the scope of this paper. We have mainly applied his theory here, because his approach to representing sign theory is modern and easily applicable to programming languages from our viewpoint based in computer science. This is because of when Peirce lived (just before the first important theories on computation were developed and established), and because of Peirce’s background in logic and mathematics.











index.html




E-mail the editors
Pour écrire à la rédaction



© 2008, Applied Semiotics / Sémiotique appliquée