[Software Philosophy] The Hegelian Triad of Software Development

One question that was pretty interesting to think about in recent days was to try and explain what could be an expression of Hegel's Triad (the anti-thesis, thesis and synthesis of ideas or more directly the "Abstract - Negative - Concrete") as it pertains to development/engineering of software.

How to Stomach Hegel's Triad 

Hegel was a ground breaking philosopher who thought up ways to explain our own experience of fundamentally experiencing consciousness and these beasts called "conscious structures" - hyper organizations of collective consciousness experience.

He, in other works not only critiqued history with regards to how it paints a picture of our own experience of conscious structures (allows us today to ask questions in a very enlightening way for instance: "is anonymity the same as it was in ancient rome?" "did the mayans have a concept of privacy- is it different ours" etc etc) - but is credited by inventing the very idea of it as well. In a kind of Newtonian move he basically came up with the approach and produced a profound application of this method direct to core ideals that construct our experience of consciousness.

For instance was "freedom" defined (and therefore expressed/actuated by extension) the same in Plato's time as now? Do we think about freedom like Plato did? You might be tempted to say "why yes he partly defined our idea of it" but of course a thorn in the side of that smooth assumption is that Plato actually kept slaves! He not only kept slaves he ran away and free-d his slave going against many of the definitions in his own philosophy. So one can say he founded the Republic and therefore by extension any machination of freedom else where in his writing on the basis of being able to own slaves ironically enough and before dying completely about faced on this notion! He actually emancipated himself from his own definition of freedom in another wording  - the rest of stayed perhaps enslaved to certain expressions of it lol

Perhaps a more direct example would be in physics for instance Plank one of the pioneers of quantum physics not only was subject to reflecting on his own idea of a physicists before he could become one (if he only digested other peoples ideas of being a physicist he might have made a fine... non-physicist!). Even more striking in his history his own rejection of one of the fundamental ideas in establishing quantum mechanical investigation. He wasn't exactly happy producing completely differentiated results with theory - those days people would resort to ad hominem attacks on scientists if they were too edgy and hipster with their results.

Reflecting on history of science; people often assume very ground breaking physicists or science idea has ushered in on someone kind of awe inspiring golden holy dish for intellectuals to consume. But actually what happens is real actual mind-blowingly profound pioneers are hatefully lambasted called lunatics and mad people they then die and then later someone with insight digs up their ideas and realized everyone was completely incorrect (someone called Einstein benefited from this while he was alive), this process is common in physics because of how intellectually aggressive a field it is - one can trace every great physics movement as coming after an embittered battle between a couple of directly opposed stances on a subject. It as though in a nauseatingly big sample of such intellectual advances throughout all known history,  these disagreements are not only common but almost required and more naturally occurring than any non-opposed states and reflections of truth. Is the very process of reflecting on an idea not a process of creating a negation with an idea - in and of itself? Hegel's deconstruction of idea deconstruction exposes that this move is not one "made" or luxuriously at the patient whims of the person experiencing it - but an inevitable movement in understanding ideas.   

Now that means every object of conscious experience in history must be partly subject to more than just its own static , context-free definition, but also perhaps is perturbed by its context, by its "moment". Just like seeing a given painting, in a given mood; completely changes its experience or perhaps more directly - maybe a whole lifetime of feelings experienced as a given moment when viewing a painting of a given kind. There seems to be some component of how an experience is internally consumed that defines its fundamental nature as a conscious phenomenon. By extension we can recognize that we experience ideas as well - so these things apply of course to how we digest and make sense of ideas. This internal digestion process is critical in ensuring you do not have a dead completely distanced and dead experience of ideas - Slavoj Zizek likes to play on the parallels where with Food and how we consume ideas.

For instance we know there are stages that food goes through when you enjoy it as food.

  1. First there is the unconsumed state of the food - it is pretty and smells nice and seems incredibly appetizing. 
  2. Second there is a consumption of the idea, a break down of it into smaller digest-able and retainable parts which can be incorporated into a body built and maintained by a recombination of these digest-able parts. And metaphysically the process of breaking down by extension. Your body is "built" by how it breaks down things.  
  3. Third there is the last phase of the idea its digested dead form, stripped of its previous attractions, consisting only of its extracted core experience. 
To think this extends again only into ideas is reductionist. Its not so simple for instance; your perception of an idea is subject to reflection - further, your reflection of your reflection of perception* is subject to reflection itself and so on ad infinitum (its almost like a "context-free" grammar no?) . Digestion then, either in the body or the mind is not a process that stops at a given point - unless you die. Once the body consumes an idea, that idea in turn it actually takes part in embodying the body itself and affects further how other ideas are digested! For instance someone who eats too much sugar cannot taste the fine levels of sugar in other things, to such a person a "sweet" flavor is a completely different experience to someone who eats little sugar. The saying goes of course "you are what you eat" but recursively speaking you "you are then also what you perceive fundamentally as eating and therefore what you eat as well" extending this is basically an application of the other old saying "you eat with your eyes first" - this means with your idea of perception fundamentally as well! "You eat with your eyes first" becomes "You eat firstly, with what you first perceive is your eyes". 

Coming back to the theory on thoughts/thinking and why thinking and internalizing an idea is just like eating food. You are almost required to digest an idea before making calls on what it is outside of you* - this means you could eat excrement or not but this depends on whether you can digest the idea well enough. If you can't, all you ate was literally nice tasting things that only turn into excrement - as grand as the taste is this is all it means internally an incomplete experience that must induce a kind of hypnosis to complete its experience (hypnosis meaning a bare evidence/logic lacking incorporation of an assumption or deduction from one).  Essentially an empty internal experience only able to express itself as bare nutrient devoid mass outside the body - it can only escape its ontological nature as excrement (BEFORE digestion) by a false assumption on its undigested, non-understood, unanalyzed, unknown state. Which is basically like saying it seems good to eat until you actually eat it - which then means it cannot ontologically be called "food" at all. 

The main point of the analogy of course is to say: What is not "digested" by the brain then is what is not understood. What is outside of the brains digestion is potentially excrement from theirs until you are fairly allowed to digest. (There is also an interesting expansion here in the use of the word "digest" we also only consider a digest in cryptography a fair digest if it fully expresses the uniqueness of the input in another domain - so if each "hash"-digested form of an idea isn't unique enough (as reflected in expressed output) it can violate the entire credibility of the digestion operation - you must now completely doubt all the other digestions it produces). 

*unless you turn a critical eye to how you see and not see things, it could potentially mean you are blind always. Unable to lift the fold over how you actually see things. Doctors take advantage of this logic in treating folks's eye balls or -seeing integrated systems- when they complain of sight problems. They are addressing what is their perception of how someone else perceives things. 

* (we don't eat poison and pretend to each other that it is good for us, we report on its internal experience as a poison fundamentally - its outside presentation doesn't escape it from its experience)

So coming to the main question of the post "how do we Hegelianistically speaking digest software as a phenomenological experience?"

The Hegelian Triad and Software Development

Do we as both developers and user's not need to digest our experience of programs and programming by extension then in order to differentiate to the rest of the nonsense in the universe? People seem to get trapped in thinking of software as single exchange with the user i.e. The developers write the code ship it to the user and then the story is done - later they develop more features perhaps and improve the software. But its not such a simple exchange there is an Hegelian dialectic at work, here's how I would analogize this:

  1.  THESIS (ABSTRACT) Developers form an ideal for a solution - a plan for what in an idealistic sense will solve a given problem. This is BEFORE pseudo-coding happens even.
  2. ANTI-THESIS (NEGATIVE) The developers write an algorithm that reflects some aspect of that ideal but never fully expresses it (for instance writing a program that computes a function on an assumption of an output space on all the Real numbers in the universe -  can never be done a Turing Machine) - sometimes the expression betrays the ideal and doesn't actuate it. But there is a concrete set in actuating whatever cooked up idea you have for solving a certain problem.
  3. (SYNTHESIS) (CONCRETE) The developers add changes to the software that incorporates the mistakes incurred by actuation of the design and produces a recombination of the THESIS idea and its ANTI-THESIS on order to complete the solution.
But again this is a in my view a realistic application of the traid but as the traid goes its not so simple, it happens on the user's side of the experience as well!

  1. THESIS (ABSTRACT) The user's are told that a given program does a given thing. The assume a given teleology or story for how the software actuates this.
  2. ANTI-THESIS (NEGATIVE) The user's interact with the actualization of the program which produces a negated definition its intended expression - user's notice that a when they click a button it does more or less than they assume but of course never exactly other wise the developers are telepathic.
  3. SYNTHESIS (CONCRETE) User's interact with the program incorporating its differences with their assumptions of its behaviour.
And of course even further recursing the definition again - developers thesis of a problem is subject to not only the history of the perception of the problem, but perturbed by the fundamental view they have of the problem. The bounds that define its solution space as well - they must depart from that as a basis to solve the problem, a pure assumption of the contexts in which the solution will apply and work and within that an assumption of the applicable sub-cases of which to solve for a given problem - since any problem that solves a given problem doesn't also automatically solve every single instance of that problem in the universe at the same time, as the universe expands every time you run the program it is run inside an entirely new universe - both potentially in the view the kernel gives it of the operating system AND literally because of the universes expansion lol. Maybe a contrived example? Do you know we collect entropy from events in the real outer space universe? sometimes those collections fail to collect entropy - its not because the universe is always producing the same amount of entropy lol 

All of these are again unescapable stages in both the development and use of a program. What is more important to realize here is that developers as privileged as they are in whatever view of whatever code they develop are either imprisoned by the negation of their code (in users and directly by themselves) - or enhanced by it! You either cripple your ability to address problems as a developer by ignoring perturbations users can make on your program OR are empowered by it, by incorporating them into your development processes - and by extension empowered that you can incorporate such things due to exposure of the dialectic it depends on.

In closing

Many theory of computation fanatics understand the flimsy duality between input/instruction of a Program/Automata. Its almost as though here in the definition of what is input and instruction (what defines their existence as a duality) we require a strong reference to a given "moment" of their definition as well.  Its like you can only say that Easy MP3 Player* accepts some stuff as input if in a given context of its usage - in other contexts suddenly the input is literally treated as instruction. Why? This is because again what mediates between these two definitions is program itself treating the input -and by extension the processes producing the input, which is the user. There is actually no means to define what is input and instruction except by its moments in a programs definition. 

Closing question here - how do developers and users perform negation and digestion of code that is closed source? Can they actually "digest" what is happening in the code, or must they build their already crippled assumptive basis by pretending such assumptions on closed code can produce realistic solutions for users - who also cannot see the code?