Today, I came across a comment asserting that there is no value in considering video games for their artistic value. This is not the first time I have heard this opinion. When the Museum of Modern Art added Pac Man to their design section, they received many comments to the effect that video games should not be exhibits of an art museum, because they are not art (though, MoMA will point out that they added it to their design section, not their art section). The fact, however, is that video games are art. Many video games may even be classified as more artistic than traditional art forms like painting or drawing.
To begin with, let's consider the components of games. The most obvious component of video games is graphics. Graphics in video games are digital graphic art. Nearly every video game has some level of graphic art. Even most text based games draw maps with graphics composed of text characters. The only exception is pure text games where the only feedback is descriptive language text.
The second major component to video games is sound. The oldest video games that used sound used beeps and simple music. While simple beeps may only be considered feedback, even simple music certainly qualifies as art. Not all video games have a sound component, but a vast majority of modern commercial games certainly do.
The third major component of video games is story. Not all games have stories, but most modern games, even the trivial ones, have some sort of story associated with them. On average, video game stories are not as good as those found in novels, but some games have very good stories and even bad stories qualify as art (though perhaps not very good art).
These three components of video games are the most important components. They also all qualify as art. If a collage, a specific music arrangement, or a collection of closely related stories qualify as art, then the combination of these elements of video games should also qualify as art. This is just the simple argument though, and I can imagine that some people would not consider a collage, a music arrangement, or a collection of stories to be art. Video games are much more than a mere collection of different types of art though.
Video games combine different types of art in specific and deliberate ways. In Super Mario Brothers, the game music changes depending on a number of factors. The music for outdoor levels is happy and uplifting. The music in underground levels is a bit darker with a hint of foreboding. The boss fight music is ominous and threatening. When you get a star, the music becomes optimistic and exciting for the duration of the invincibility. Video games are not just collections of different types of art. Video games are compositions of different kinds of art. In this sense, video games are just as much art in themselves as the composition of frame and picture is art (and if you have ever taken an art class using physical media, you will know that the frame is an essential part of the art it encloses).
Video games may be more qualified to be called art than any other art media. This is not just because they are compositions of different types of art either. Writing computer code is its own art form. True, it is more mathematical than traditional types of art, but it is the same type of art as any artisanal (note the root "art") craft, only more so. Crafting code is not an automatable task. It requires human decision making and creativity on at least the same level as any other form of art. It may seem more directed than other forms of art, as any given program probably has specific performance or other requirements directing its coding, but this is not any different than the limitations imposed when a painter is contracted to paint a specific image for a client. In short, even a video game that manages to avoid any other kind of art is inherently artistic because the code itself is a form of art.
Video games are not just art. Video games aspire to be the ultimate form of art. Video games attempt to appeal to nearly all
of the senses. Graphics appeal to vision. Audio appeals to hearing.
Vibrating controllers even appeal to touch. We have not yet figured out
how to generate taste or smell art using computers, but when we do,
they will be used to push video games even further into the realm of
ultimate art. On top of this composition of other arts forms, video games add another unique form of art: coding. Not only are video games art, they are the truest, most complete form of art ever created by mankind.
Friday, October 23, 2015
Wednesday, March 25, 2015
Object Model
There is a common misconception that is taught in almost every object oriented programming course and book. This misconception is that the real world is composed of macroscopic objects. The common example is a car. It has properties, like make, model, year, color, and so on. It has actions, called methods in OOP, like accelerate, brake, blink left, and more. A car is an object.
Object modeling has a strict definition for objects. If it has properties and actions, then it is an object. Essentially, properties are nouns and adjectives, and actions are verbs. By this definition, wind is an object. It has properties like temperature, direction, and speed. It has actions, like changing speed or direction and knocking things down. In real life terms though, wind is not an object. Using the object model, wind is actually more like a method of the air object. It is an action that air takes. The object model used in object oriented programming is not a reflection of real life applied to programming. It is an abstraction of human reasoning and abstraction applied to programming.
In real life, there is no solid definition of what is an object. The Merriam-Webster definition requires physical objects to be detectable with the senses, which eliminates anything microscopic, no matter how well it fits the object model definition. It also includes things, like wind, which most people would not normally consider objects. Besides all of that, it is too vague to be truly useful.
For most intents, physical objects are defined by their chemical bonds. The difference between two 1oz chunks of steel and one 2oz chunk is that one is coherently bonded in its entirety, while the other is two pieces that are coherently bonded but not to each other. The two pieces could be changed from two objects to one object by welding them together. Unfortunately, this is not a strict rule. A car is composed of many coherent but separate pieces, but it is still considered a single object.
We might define an object based on functional coherence. A board game, composed of a board, game pieces, and a pair of dice, is a single object, because all of the parts serve a single functional purpose: to play the game. A car, composed of an engine, wheels, a chassis, and so on, serves a single purpose of transportation, so it is a functionally coherent object. Except, what about the radio? That does nothing for transportation. It is still considered part of the object. It is not chemically bonded to the object, nor is it a functionally coherent part of the object, so why is the radio part of the car? Obviously functional coherence is not the answer.
Maybe we could add that something which is attached to the object is part of it. This could be viewed as a sort of non-chemical physical continuity. The radio is firmly attached to the car, probably with screws or some kind of snap in tabs. Does this mean that if my son puts super glue on my chair, and I sit on it, I become part of my chair (or maybe my chair becomes part of me)? Again, a dead end.
Even containment does not work. I can be inside my car without being part of it. Putting a CD in a computer does not make it become part of the computer (though putting a hard drive in a computer does...). Even this depends on the specifics.
The problem is that the idea of an object is just that: an idea. Objects are not real things. We perceive things as objects, because we perceive some kind of relational continuity between their parts. This is highly subjective. One person might consider the air filter or battery in the car to be part of the car object, while another might consider them to be separate objects that happen to be used in and by the car. Further, all objects are composed of other objects, until they are not anymore. Current science seems to hold that down to a quantum level all particles have properties and methods (as interactions). In reality though, as you approach sub-atomic levels, the idea of particles seems to break down entirely, giving way to matter that acts like particles but seems to be composed entirely of waves (or one giant wave) with complex harmonics. We cannot say with any degree of certainty that the object model can even be applied to particles smaller than atoms.
The point is, the object model does not reflect real life at all. It merely reflects how most humans tend to perceive real life. Now, this is still very useful, but it exposes some limitations. Because perception is subjective, two people may not always agree on how a specific idea should be modeled as an object or collection of objects. If a battery is part of the car, maybe the car should have a "charge" property to track the charge of the battery. If it is not, maybe we need a whole new "battery" object, with its own "charge" property, and then the car can have a property that points to that battery. Both models have value in specific cases, so there is no common-sense solution. In addition, not all ideas even make sense as objects. Many object oriented programs include objects that are totally incoherent collections of properties and methods that just needed to go somewhere. Besides being bad programming practice (though sometimes necessary in languages that force everything to be part of an object, like Java), this violates the entire purpose of objects. We find this sort of thing in real life all the time though. Many households have a "junk drawer" for holding miscellaneous objects that have nowhere else to go.
While the car analogy might make a good start for helping people to understand objects, very early on it would be a wise idea to stop comparing them to real life objects and start describing them as organizational units. The object model is not about modeling real life. Objects are called objects because it helps people understand the coherency that objects should have. Beyond that though, they resemble real life very poorly, and if the comparison with real life is not left behind, it is likely to result in poor programming practices and absurd arguments over design where real life is used as justification for choosing the worst solutions. In the object model, objects are containers. They are organizational units. Poor organization is poor organization, no matter how people choose to do things in real life. The car analogy is great, but when students start thinking they need to make a "FuelTank" object (and don't forget "FuelPump" and "FuelFilter"), when merely keeping track of current fuel level would be sufficient, the analogy has gone too far.
Object oriented programming is powerful and useful, but it is also far more prone to error than procedural programming. The errors found in object oriented programming are not the kind that break the program, however. They are the kind that waste resources and make maintaining the program very difficult. One of the most effective solutions to this problem would be to reveal objects for what they are, organizational units, instead of comparing them to things that they only marginally resemble, real life objects.
Object modeling has a strict definition for objects. If it has properties and actions, then it is an object. Essentially, properties are nouns and adjectives, and actions are verbs. By this definition, wind is an object. It has properties like temperature, direction, and speed. It has actions, like changing speed or direction and knocking things down. In real life terms though, wind is not an object. Using the object model, wind is actually more like a method of the air object. It is an action that air takes. The object model used in object oriented programming is not a reflection of real life applied to programming. It is an abstraction of human reasoning and abstraction applied to programming.
In real life, there is no solid definition of what is an object. The Merriam-Webster definition requires physical objects to be detectable with the senses, which eliminates anything microscopic, no matter how well it fits the object model definition. It also includes things, like wind, which most people would not normally consider objects. Besides all of that, it is too vague to be truly useful.
For most intents, physical objects are defined by their chemical bonds. The difference between two 1oz chunks of steel and one 2oz chunk is that one is coherently bonded in its entirety, while the other is two pieces that are coherently bonded but not to each other. The two pieces could be changed from two objects to one object by welding them together. Unfortunately, this is not a strict rule. A car is composed of many coherent but separate pieces, but it is still considered a single object.
We might define an object based on functional coherence. A board game, composed of a board, game pieces, and a pair of dice, is a single object, because all of the parts serve a single functional purpose: to play the game. A car, composed of an engine, wheels, a chassis, and so on, serves a single purpose of transportation, so it is a functionally coherent object. Except, what about the radio? That does nothing for transportation. It is still considered part of the object. It is not chemically bonded to the object, nor is it a functionally coherent part of the object, so why is the radio part of the car? Obviously functional coherence is not the answer.
Maybe we could add that something which is attached to the object is part of it. This could be viewed as a sort of non-chemical physical continuity. The radio is firmly attached to the car, probably with screws or some kind of snap in tabs. Does this mean that if my son puts super glue on my chair, and I sit on it, I become part of my chair (or maybe my chair becomes part of me)? Again, a dead end.
Even containment does not work. I can be inside my car without being part of it. Putting a CD in a computer does not make it become part of the computer (though putting a hard drive in a computer does...). Even this depends on the specifics.
The problem is that the idea of an object is just that: an idea. Objects are not real things. We perceive things as objects, because we perceive some kind of relational continuity between their parts. This is highly subjective. One person might consider the air filter or battery in the car to be part of the car object, while another might consider them to be separate objects that happen to be used in and by the car. Further, all objects are composed of other objects, until they are not anymore. Current science seems to hold that down to a quantum level all particles have properties and methods (as interactions). In reality though, as you approach sub-atomic levels, the idea of particles seems to break down entirely, giving way to matter that acts like particles but seems to be composed entirely of waves (or one giant wave) with complex harmonics. We cannot say with any degree of certainty that the object model can even be applied to particles smaller than atoms.
The point is, the object model does not reflect real life at all. It merely reflects how most humans tend to perceive real life. Now, this is still very useful, but it exposes some limitations. Because perception is subjective, two people may not always agree on how a specific idea should be modeled as an object or collection of objects. If a battery is part of the car, maybe the car should have a "charge" property to track the charge of the battery. If it is not, maybe we need a whole new "battery" object, with its own "charge" property, and then the car can have a property that points to that battery. Both models have value in specific cases, so there is no common-sense solution. In addition, not all ideas even make sense as objects. Many object oriented programs include objects that are totally incoherent collections of properties and methods that just needed to go somewhere. Besides being bad programming practice (though sometimes necessary in languages that force everything to be part of an object, like Java), this violates the entire purpose of objects. We find this sort of thing in real life all the time though. Many households have a "junk drawer" for holding miscellaneous objects that have nowhere else to go.
While the car analogy might make a good start for helping people to understand objects, very early on it would be a wise idea to stop comparing them to real life objects and start describing them as organizational units. The object model is not about modeling real life. Objects are called objects because it helps people understand the coherency that objects should have. Beyond that though, they resemble real life very poorly, and if the comparison with real life is not left behind, it is likely to result in poor programming practices and absurd arguments over design where real life is used as justification for choosing the worst solutions. In the object model, objects are containers. They are organizational units. Poor organization is poor organization, no matter how people choose to do things in real life. The car analogy is great, but when students start thinking they need to make a "FuelTank" object (and don't forget "FuelPump" and "FuelFilter"), when merely keeping track of current fuel level would be sufficient, the analogy has gone too far.
Object oriented programming is powerful and useful, but it is also far more prone to error than procedural programming. The errors found in object oriented programming are not the kind that break the program, however. They are the kind that waste resources and make maintaining the program very difficult. One of the most effective solutions to this problem would be to reveal objects for what they are, organizational units, instead of comparing them to things that they only marginally resemble, real life objects.
Thursday, February 5, 2015
Inheritance Models
Inheritance models are a controversial subject in Object Oriented Programming language design. The big controversy is multiple inheritance. Python adds a minor controversy on the value of non-public variables and methods.
Multiple inheritance is controversial because multiple parents with methods of the same name implemented can result in naming collisions. Most OOP languages deal with this using priorities. The order of inheritance determines which method is used. The problem with this occurs when the method needs to do different things depending on context. The programmer can always add flexibility, but this is not always desirable. The argument in favor of multiple inheritance is that this is very rare, and when it does occur, it is probably a sign that the program is poorly designed and should be re-factored before continuing.
Java argues that multiple inheritance is rarely necessary, so it eliminates it with a solution that proves that multiple inheritance is indeed frequently necessary. Java solves the multiple inheritance problem by adding a new kind of class to inherit from, called an interface. Any number of interfaces can be attached to a class. Interfaces have some important restrictions. They cannot contain any implemented methods, and all of their methods and member variables must be public. They are essentially fully abstract classes, where all methods are abstract, with a few added restrictions. In reality, Java does support multiple inheritance, it just limits it. Any class can inherit from any number of other classes, on the one condition that only one of those classes is allowed to have implemented code in it. In theory, this solves the naming collision problem. In reality though, it only solves part of it. Two implemented methods with the same name will never be inherited by the same class in Java, so it will never have to determine priority. One implemented method can collide with any number of abstract methods though, and any number of abstract methods can collide with each other. The problem here occurs when two methods with the same name are expected by the interface to do completely different things. This, perhaps the more common problem, is still unresolved. Java not only fails to eliminate multiple inheritance, it fails to eliminate the biggest problem with it.
The evidence that multiple inheritance is necessary and valuable is seen clearly in the fact that Java classes frequently implement one or more interfaces, in addition to inheriting from a parent class. Java's solution to the collision problem does reveal one thing about multiple inheritance: It is probably better to only inherit from one class with implemented methods, and even when violating this, it is almost always better to choose a design that does not require inheriting in ways that cause naming collisions. Java reveals another thing though: There is no reasonable way to entirely eliminate the possibility of naming collisions caused by inheritance. Naming collisions caused by inheritance could be handled by always requiring some kind of prefix for accessing inherited methods and variables, but this would compromise polymorphism, dramatically reducing the value of OOP.
Java's solution to the problems of multiple inheritance is not necessarily bad. It is misleading to claim that it solves all or even most of the problems, but it does solve one, and it encourages the use of naming conventions that are less likely to result in collisions. Overall, it mitigates the problems more than offering a real solution. The problems with multiple inheritance are inherent. They are not related to how it is implemented. Java's mistake was in trying to solve an unsolvable problem, but there is significant learning value in the attempt, so it was not a waste of time or effort.
The value of non-public variables is a different but related matter. What creates the controversy is that it is an entirely artificial limitation. Private and protected variables exist solely to enforce best practices. There is no platform level support for them, and there never will be, because it is already expensive enough to design processors with one protected mode (and sometimes a third access level exists for hardware interrupts). Adding widespread access control to hardware just to enforce good programming practices would be absurd. As such, variable access control in OOP languages is enforced by the compiler or the interpreter. The reason the artificiality matters is that this kind of access control only restricts accessing variables by name. A private variable is no different from any other variable. The only difference is that it can only be accessed by name when it is in scope, and it is only in scope in the methods of the class it belongs to. In any language that allows direct memory manipulation (including through external libraries), accessing private variables directly is fairly simple, if the programmer has a half decent understanding of the object containing it. In reference to the inheritance discussion above, this means that requiring interface methods and variables to be public is merely a semantic thing, not a significant difference between fully abstract methods and interfaces.
The artificiality of variable access restriction by no means devalues it though. Offering programmers some guidance by making it difficult to violate best practices does have value. Access restriction is not the only way to accomplish this though. C++ and Java use access restriction, but Python does not. Nothing in Python is ever strictly private. If you know its name, you can access it. Python does have some ways of making it hard to violate best practices though. A single leading underscore in a variable or method name in Python indicates that it should not be accessed directly, because it is an implementation detail that is subject to change. Two leading underscores, with one or no trailing underscores in Python invokes name mangling that makes direct access from outside the class difficult. Every method or variable reference inside the class definition with the two leading underscores and less than two following will be mangled, which will allow internal references to work properly, but it will break external references. Even this does not make the variable or method private though. The mangling is predictable, so a determined programmer could still access mangled references from outside the class, by using the mangled name. This requires very deliberate action though, and thus will never occur accidentally. A programmer that is willing to go this far to violate best practices would probably also use direct memory manipulation, so the fact that it is easier this way hardly matters.
To be clear, method and instance variable access restriction should never be regarded as a security measure. In any well designed language, there will always be a way around it. Access restriction should be regarded as a means to encourage best practices and provide a warning for attempts to violate them. It should never be treated as anything more than this.
The connection between these two is the fact that access restriction is not a significant difference between two meta data-types. Despite the difference in access restriction between fully abstract classes and interfaces in Java, they are functionally the same thing. Java differentiates to hide the multiple inheritance, and that is it. In fact, considering the value of access restricted variables and methods in fully abstract classes (hint: there is no value), it makes perfect sense to disallow anything but public variables and methods in interfaces. To do anything else would be to restrict or dictate the implementation of the abstract variables and methods, which would directly violate the purpose of fully abstract classes as well as interfaces. This is not a major difference between the two. It is merely another case of the language enforcing best practices.
In the end, Java does not solve the multiple inheritance problem, and access restricted variables and methods are not strictly necessary. In both cases, this does not mean that time or energy was wasted though. They both have value, but they are related in that they are both misunderstood, often even by professionals.
Multiple inheritance is controversial because multiple parents with methods of the same name implemented can result in naming collisions. Most OOP languages deal with this using priorities. The order of inheritance determines which method is used. The problem with this occurs when the method needs to do different things depending on context. The programmer can always add flexibility, but this is not always desirable. The argument in favor of multiple inheritance is that this is very rare, and when it does occur, it is probably a sign that the program is poorly designed and should be re-factored before continuing.
Java argues that multiple inheritance is rarely necessary, so it eliminates it with a solution that proves that multiple inheritance is indeed frequently necessary. Java solves the multiple inheritance problem by adding a new kind of class to inherit from, called an interface. Any number of interfaces can be attached to a class. Interfaces have some important restrictions. They cannot contain any implemented methods, and all of their methods and member variables must be public. They are essentially fully abstract classes, where all methods are abstract, with a few added restrictions. In reality, Java does support multiple inheritance, it just limits it. Any class can inherit from any number of other classes, on the one condition that only one of those classes is allowed to have implemented code in it. In theory, this solves the naming collision problem. In reality though, it only solves part of it. Two implemented methods with the same name will never be inherited by the same class in Java, so it will never have to determine priority. One implemented method can collide with any number of abstract methods though, and any number of abstract methods can collide with each other. The problem here occurs when two methods with the same name are expected by the interface to do completely different things. This, perhaps the more common problem, is still unresolved. Java not only fails to eliminate multiple inheritance, it fails to eliminate the biggest problem with it.
The evidence that multiple inheritance is necessary and valuable is seen clearly in the fact that Java classes frequently implement one or more interfaces, in addition to inheriting from a parent class. Java's solution to the collision problem does reveal one thing about multiple inheritance: It is probably better to only inherit from one class with implemented methods, and even when violating this, it is almost always better to choose a design that does not require inheriting in ways that cause naming collisions. Java reveals another thing though: There is no reasonable way to entirely eliminate the possibility of naming collisions caused by inheritance. Naming collisions caused by inheritance could be handled by always requiring some kind of prefix for accessing inherited methods and variables, but this would compromise polymorphism, dramatically reducing the value of OOP.
Java's solution to the problems of multiple inheritance is not necessarily bad. It is misleading to claim that it solves all or even most of the problems, but it does solve one, and it encourages the use of naming conventions that are less likely to result in collisions. Overall, it mitigates the problems more than offering a real solution. The problems with multiple inheritance are inherent. They are not related to how it is implemented. Java's mistake was in trying to solve an unsolvable problem, but there is significant learning value in the attempt, so it was not a waste of time or effort.
The value of non-public variables is a different but related matter. What creates the controversy is that it is an entirely artificial limitation. Private and protected variables exist solely to enforce best practices. There is no platform level support for them, and there never will be, because it is already expensive enough to design processors with one protected mode (and sometimes a third access level exists for hardware interrupts). Adding widespread access control to hardware just to enforce good programming practices would be absurd. As such, variable access control in OOP languages is enforced by the compiler or the interpreter. The reason the artificiality matters is that this kind of access control only restricts accessing variables by name. A private variable is no different from any other variable. The only difference is that it can only be accessed by name when it is in scope, and it is only in scope in the methods of the class it belongs to. In any language that allows direct memory manipulation (including through external libraries), accessing private variables directly is fairly simple, if the programmer has a half decent understanding of the object containing it. In reference to the inheritance discussion above, this means that requiring interface methods and variables to be public is merely a semantic thing, not a significant difference between fully abstract methods and interfaces.
The artificiality of variable access restriction by no means devalues it though. Offering programmers some guidance by making it difficult to violate best practices does have value. Access restriction is not the only way to accomplish this though. C++ and Java use access restriction, but Python does not. Nothing in Python is ever strictly private. If you know its name, you can access it. Python does have some ways of making it hard to violate best practices though. A single leading underscore in a variable or method name in Python indicates that it should not be accessed directly, because it is an implementation detail that is subject to change. Two leading underscores, with one or no trailing underscores in Python invokes name mangling that makes direct access from outside the class difficult. Every method or variable reference inside the class definition with the two leading underscores and less than two following will be mangled, which will allow internal references to work properly, but it will break external references. Even this does not make the variable or method private though. The mangling is predictable, so a determined programmer could still access mangled references from outside the class, by using the mangled name. This requires very deliberate action though, and thus will never occur accidentally. A programmer that is willing to go this far to violate best practices would probably also use direct memory manipulation, so the fact that it is easier this way hardly matters.
To be clear, method and instance variable access restriction should never be regarded as a security measure. In any well designed language, there will always be a way around it. Access restriction should be regarded as a means to encourage best practices and provide a warning for attempts to violate them. It should never be treated as anything more than this.
The connection between these two is the fact that access restriction is not a significant difference between two meta data-types. Despite the difference in access restriction between fully abstract classes and interfaces in Java, they are functionally the same thing. Java differentiates to hide the multiple inheritance, and that is it. In fact, considering the value of access restricted variables and methods in fully abstract classes (hint: there is no value), it makes perfect sense to disallow anything but public variables and methods in interfaces. To do anything else would be to restrict or dictate the implementation of the abstract variables and methods, which would directly violate the purpose of fully abstract classes as well as interfaces. This is not a major difference between the two. It is merely another case of the language enforcing best practices.
In the end, Java does not solve the multiple inheritance problem, and access restricted variables and methods are not strictly necessary. In both cases, this does not mean that time or energy was wasted though. They both have value, but they are related in that they are both misunderstood, often even by professionals.
Subscribe to:
Posts (Atom)