Post navigation

Weapon Systems II: The Abstract (Philosophy Time!)

In my last post I said that it’s fair to ask whether a shield should be called a weapon.

I think this really gets into the heart of what proper design is, and the question of what level of abstraction is the best. One aspect of programming is abstracting things into lower levels of detail. Otherwise you’re just working on same Matrix-Level Simulation shit. So, here, the question is “how detailed do I get when it comes to making these things?” Part of abstraction is categorization, grouping things together into certain sets that make sense for them to share. In that sense, the concept of “weapon” is abstracted to a higher level than just something that goes PEW and does damage to an external object. The question then becomes: Is “weapon” even a proper name? Is there some other term I can use to convey that abstraction (and in the process, allow for more open ended interpretation of those capabilities of things I currently call “weapons” and perhaps something else will come along and cause me to rethink them not as weapons but as some other type of object.

And interestingly this gets into some computer science type stuff, because what you then start to deal with here is the very idea of categorization and typing systems. Whenever you make something in a class, you are making a category. Whenever you place something into that class, you are having it partake of that which defines that class. This is basically what a “type” is in computer lingo. You have a defined set of rules specifying something, and all entities that can return “true” upon comparison to those rules indicate that it is a member of that set, and thus, of that given type of object.

What I *call* an object is irrelevant, I could call the “weapon system” a “potato system”. That’s all syntactic… It doesn’t really fucking matter to the computer what I call it. It matters to me, but in the end, that’s just because of the function of the human mind to map words to exterior entities outside of itself and into its realm of experience, and it makes it easier (and thus more efficient) to map the words onto constructs I already know. In fact, the ABSTRACTIONS of the objects I am trying to represent. There is a level of congruency between the physical world that one is attempting to model in such cases, and the language we use to understand that world.

To finish up the point, we have a syntactic interface to a mental model which is a link or a map to an external entity. We abstract things so as to not have to deal with irrelevant information that does nothing but complicate the essence of what we are trying to convey. What we are trying to convey then, is a semantic, meaningful representation between these things, such that together they form a unified whole. Ideally, it will present itself elegantly to the user such that they themselves can form a similar mental model as the one that the programmer is creating.

That is to say, the programmer is speaking a language, transcribing thought into specific language/code that the computer can understand and interpret. This interpretation is then “run” and the end user has access to the output of the programmer. The more accurately and expressive the programmer (and designer, programming by itself alone is only part of the equation – the language of design is yet another layer to this story) is able to convey what they are attempting to do, the more refined the process of the user to “intuit” what is happening, the more easy a system becomes to use.

But because everything is abstracted to some degree, there will always be a missing element to these interfaces. It means that we can never create a truly “intuitive” interface, because one is always removing dimensionality from the mental model one places on the world.