http://www.hxa.name/articles/
hxa7241+articles (ατ) googlemail (dοτ) com
2011-03-29
This is a somewhat odd venture: a translation of Wittgenstein's Tractatus into the domain of software development.
The software intellect – its basic conceptual forms – is rooted in the early 20th century, the 1910s, 1920s, 1930s. That is where the work of Church and Turing, lambda calculus and computability, comes from. And it is also the time of the Vienna Circle, logical positivism, and Wittgenstein's early work, the ‘Tractatus Logico-Philosophicus’.
One might notice one day that software seems pointedly related to its original philosophical contemporaries. It is fundamentally a logical construction. It is like a Wittgensteinian logical proposition, but instead of describing the world, software constructs the imagination. There is a clear isomorphism. All terms related to describing map to terms related to constructing, and similarly for world and imagination. It seems a simple transformation will take Wittgenstein to software.
So an interesting project emerges: translate the Tractatus into software terms! The result is sometimes obscure, but sometimes clearer than the original, and most is (still) quite odd and intriguing (which is perhaps the main virtue anyway) . . .
(So far it is only partial and unfinished.)
8000 words (55 minutes).
Perhaps this book will be understood only by someone who themself already had the thoughts that are expressed in it – or at least similar thoughts. – So it is not a textbook. – Its purpose should be achieved if it gave pleasure to one person who read and understood it.
The book deals with the problems of software engineering philosophy, and shows, I believe, that the reason why these problems are posed is that the digitalness of our software is misunderstood. The whole sense of the book might be summed up in the following words: what can be built at all can be built precisely, and what we cannot develop we must pass over in stillness.
Thus the aim of the book is to draw a limit to designs, or rather – not to designs, but to the expression of designs: for in order to be able to draw a limit to designs, we should have to find both sides of the limit designable (i.e. we should have to be able to design what cannot be designed).
It will therefore only be in software that the limit can be drawn, and what lies on the other side of the limit will simply be nonsense.
I do not wish to judge how far my efforts coincide with those of other software engineering philosphers. Indeed, what I have written here makes no claim to novelty in detail, and the reason why I give no sources is that it is a matter of indifference to me whether the thoughts that I have had have been anticipated by someone else.
I will only mention that I am indebted to Frege's great works and to the writings of my friend Mr Bertrand Russell for much of the stimulation of my thoughts.
If this work has any value, it consists in two things: the first is that thoughts are expressed in it, and on this score the better the thoughts are expressed – the more the nail has been hit on the head – the greater will be its value. – Here I am conscious of having fallen a long way short of what is possible. Simply because my powers are too slight for the accomplishment of the task. – May others come and do it better.
On the other hand the truth of the thoughts that are here communicated seems to me unassailable and definitive. I therefore believe myself to have found, on all essential points, the final solution of the problems. And if I am not mistaken in this belief, then the second thing in which the value of this work consists is that it shows how little is achieved when these problems are solved.
The imagination is all that is intended.
The imagination is the totality of intents, not of actual-effects.
The imagination is determined by the intents, and by their being all the intents.
For the totality of intents determines what is intended, and also whatever cannot be intended.
The intents in digital space are the imagination.
The imagination divides into intents.
Each item is intended or not intended while everything else remains the same.
What is intended – an intent – is the intendedness of sets of effects.
A set of aims (a set of actual-effects) is a combination of effects (actual-effects).
It is essential to actual-effects that they should be possible constituents of sets of aims.
In the digital nothing is accidental: if an actual-effect can occur in a set of aims, the possibility of the set of aims must be written into the actual-effect itself.
It would seem to be a sort of accident, if it turned out that a function would fit an actual-effect that could already be intended entirely on its own.
If actual-effects can occur in sets of aims, this possibility must be in them from the beginning.
(Nothing in the province of the digital can be merely possibly intended. The digital deals with every possible intention and all possibilities are its intents.)
Just as we are quite unable to imagine spatial effects outside space or temporal effects outside time, so too there is no effect that we can imagine excluded from the possibility of combining with others.
If I can imagine effects combined in sets of aims, I cannot imagine them excluded from the possibility of such combinations.
Actual-effects are independent in so far as they can occur in all possible functions, but this form of independence is a form of connexion with sets of aims, a form of dependence. (It is impossible for words to appear in two different roles: by themselves, and in programs.)
If I know an effect I also know all its possible occurrences in sets of aims.
(Every one of these possibilities must be part of the nature of the effect.)
A new possibility cannot be discovered later.
If I am to know an effect, though I need not know its external properties, I must know all its internal properties.
If all effects are given, then at the same time all possible sets of aims are also given.
Each actual-effect is, as it were, in a space of possible sets of aims. This space I can imagine empty, but I cannot imagine the actual-effect without the space.
A spatial effect must be functional in infinite space. (A spatial point is an argument-place.)
A speck in the visual field, though it need not be red, must have some colour: it is, so to speak, surrounded by colour-space. Notes must have some pitch, objects of the sense of touch some degree of hardness, and so on.
Effects contain the possibility of all functions.
The possibility of its occurring in sets of aims is the form of an effect.
Effects are simple.
All software for complexes can be resolved into software for their constituents and into the programs that express the complexes completely.
Effects make up the substance of the imagination. That is why they cannot be composite.
If the imagination had no substance, then whether a program had sense would depend on whether another program was correct.
In that case we could not hack-out any formulation of the imagination (correct or incorrect).
It is obvious that software, however different it may be from intention, must have something – a form – in common with it.
Effects are just what constitute this unalterable form.
The substance of the imagination can only determine a form, and not any functional properties. For it is only by means of programs that functional properties are produced – only by the configuration of effects that they are intended.
In a manner of speaking, effects are intangible.
If two effects have the same digital form, the only distinction between them, apart from their external properties, is that they are different.
Either an actual-effect has properties that nothing else has, in which case we can immediately use a description to distinguish it from the others and refer to it; or, on the other hand, there are several actual-effects that have the whole set of their properties in common, in which case it is quite impossible to indicate one of them.
For if there is nothing to distinguish an actual-effect, I cannot distinguish it, since otherwise it would be distinguished after all.
The substance is what subsists independently of what is intended.
It is form and content.
Space, time, colour (being coloured) are forms of effects.
There must be effects, if the imagination is to have unalterable form.
Effects, the unalterable, and the subsistent are one and the same.
Effects are what is unalterable and subsistent; their configuration is what is changing and unstable.
The configuration of effects produces sets of aims.
In a set of aims effects fit into one another like the links of a chain.
In a set of aims effects stand in a determinate relation to one another.
The determinate way in which effects are connected in a set of aims is the structure of the set of aims.
Form is the possibility of structure.
The structure of an intent consists of the structures of sets of aims.
The totality of intended sets of effects is the imagination.
The totality of intended sets of effects also determines which sets of effects are not intended.
The intendedness and non-intendedness of sets of effects is intention.
(We call the intendedness of sets of effects a positive intent, and their non-intendedness a negative intent.)
Sets of aims are independent of one another.
From the intendedness or non-intendedness of one set of effects it is impossible to infer the intendedness or non-intendedness of another.
The sum-total of intention is the imagination.
We formulate intents for ourselves.
A formulation performs a function in digital space, the intendedness or not of sets of effects.
A formulation is a model of intention.
In a formulation, effects have the elements of the formulation corresponding to them.
In a formulation the elements of the formulation are the producers of effects.
What constitutes a formulation is that its elements are related to one another in a determinate way.
A formulation is an intent.
The fact that the elements of a formulation are related to one another in a determinate way represents that actual-effects are related to one another in the same way.
Let us call this connexion of its elements the structure of the formulation, and let us call the possibility of this structure the computational form of the formulation.
Computational form is the possibility that actual-effects are related to one another in the same way as the elements of the formulation.
That is how a formulation is attached to intention; it reaches right out to it.
It is laid against intention like a measure.
Only the end-points of the graduating lines actually touch the effect that is to be measured.
So a formulation, conceived in this way, also includes the computational relationship, which makes it into a formulation.
The computational relationship consists of the correlations of the formulation's elements with actual-effects.
These correlations are, as it were, the feelers of the formulation's elements, with which the formulation touches intention.
If an intent is to be a formulation, it must have something in common with what it computes (function it performs).
There must be something identical in a formulation and what it computes (function it performs), to enable the one to be a formulation of the other at all.
What a formulation must have in common with intention, in order to be able to compute it – correctly or incorrectly – in the way that it does, is its computational form.
A formulation can compute any intention whose form it has.
A spatial formulation can compute anything spatial, a coloured formulation anything coloured, etc.
A formulation cannot, however, compute its computational form: it shows it.
A formulation performs its purpose from a position outside it. (Its standpoint is its computational form.) That is why a formulation performs its purpose correctly or incorrectly.
A formulation cannot, however, place itself outside its computational form.
What any formulation, of whatever form, must have in common with intention, in order to be able to compute it – correctly or incorrectly – in any way at all, is digital form, i.e. the form of intention.
A formulation whose computational form is digital form is called a digital formulation.
Every formulation is at the same time a digital one. (On the other hand, not every formulation is, for example, spatial.)
Digital formulations can compute the imagination.
A formulation has digito-computational form in common with what it computes.
A formulation computes intention by producing a possibility of intendedness and non-intendedness of sets of effects.
A formulation performs a possible function in digital space.
A formulation contains the possible intendedness of the function that it performs.
A formulation agrees with intention or fails to agree; it is correct or incorrect, right or wrong.
What a formulation produces it produces independently of its correctness or incorrectness, by means of its computational form.
What a formulation produces is its meaning.
The agreement or disagreement of its meaning with intention constitutes its correctness or incorrectness.
In order to tell whether a formulation is correct or incorrect we must compare it with intention.
It is impossible to tell from the formulation alone whether it is correct or incorrect.
There are no formulations that are correct a priori.
A digital formulation of intents is an idea.
‘A set of effects is creatable’: what this means is that we can formulate it for ourselves.
The totality of correct ideas is a formulation of the whole imagination.
An idea contains the possibility of intendedness of the function of which it is the idea. What is creatable is possibly intended too.
Idea can never be of anything non-digital, since, if it were, we should have to create non-digitally.
It used to be said that the Flying Spaghetti Monster could create anything except what would be contrary to the laws of the digital. The truth is that we could not say what an ‘undigital’ imagination would look like.
It is as impossible to perform in software anything that ‘contradicts the digital’ as it is in geometry to represent by its co-ordinates a figure that contradicts the laws of space, or to give the co-ordinates of a point that does not exist.
Though a set of effects that would contravene the laws of computation can be represented by us spatially, one that contravene the laws of geometry cannot.
If an idea were correct a priori, it would be an idea whose possible-intendedness ensured its correctness.
A priori knowledge that an idea was correct would be possible only if its correctness were recognisable from the idea itself (without any intention to compare it with.
In a program an idea finds an expression that can be perceived by the senses.
We use the perceptible representation of a program (source or compiled, etc.) as a projection of a possibly-intended function.
The method of projection is to think of the sense/execution of the program.
I call the representation with which we express an idea a programmatic representation. – And a program is a programmatic representation in its projective relation to the imagination.
A program includes all that the projection includes, but not what is projected.
Therefore, though what is projected is not itself included, its possible-intendedness is.
A program, therefore, does not actually contain its sense/execution, but does contain the possiblility of expressing it.
(‘The content of a program’ means the content of a program that has sense / is executable.)
A program contains the form, but not the content, of its sense/execution.
What constitutes a programmatic representation is that its elements (the instructions) stand in a determinate relation to one another.
A programmatic representation is an intent.
A program is not a blend of instructions. – (Just as a theme in music is not a blend of notes.)
A program is articulate.
Only intents can express a sense, a set of actions cannot.
Although a programmatic representation is an intent, this is obscured by the usual form of expression in source-code or compilation.
For in a compiled program, for example, no essential difference is apparent between a programmatic representation and an instruction.
That is what made it possible for Frege to call a program a composite action.
The essence of a programmatic representation is very clearly seen if we imagine one composed of spatial objects (such as tables, chairs, and books) instead of source-code.
Then the spatial arrangement of these things will express the sense of the program.
Instead of, ‘The complex representation “load a, b” says that a stands to b in the relation load’, we ought to put, ‘That “a” stands to “b” in a certain relation says that load a, b.’
Functions can be described but not given actions.
(Actions are like points; programs like arrows – they have sense.)
In a program an idea can be expressed in such a way that elements of the programmatic representation correspond to the effects of the idea.
I call such elements ‘simple outputs’, and such a program ‘completely analysed’.
The simple outputs employed in programs are called actions.
An action means an effect. The effect is its meaning. (‘A’ is the same output as ‘A’.)
The configuration of effects in a function corresponds to the configuration of simple outputs in the programmatic representation.
In a program an action is the representative of an effect.
Effects can only be acted. Outputs are their representatives. I can only code about them: I cannot put them into instructions. Programs can only say what effects are wanted, not what they are.
The requirement that simple outputs be possible is the requirement that execution be determinate.
A program about a complex stands in an internal relation to a program about a constituent of the complex.
A complex can be given only by its expression, will be correct or incorrect. A program that performs a complex will not be nonsensical, if the complex is not intended, but simply incorrect.
When a programmatic element causes a complex, this can be seen from an indeterminateness in the programs in which it occurs. In such cases we know that the program leaves something undetermined. (In fact the notation for generality contains a prototype.)
The contraction of a symbol for a complex into a simple symbol can be expressed in a definition.
A program has one and only one complete analysis.
What a program expresses it expresses in a determinate manner, which can be set out precisely: a program is articulated.
An action cannot be dissected any further by means of a definition: it is a primitive output.
Every output that has a definition causes via the outputs that serve to define it; and the definitions point the way.
Two outputs cannot cause in the same manner if one is primitive and the other is defined by means of primitive outputs. Actions cannot be anatomized by means of definitions. (Nor can any output that has a result independently and on its own.)
What outputs fail to express, their computation shows. What outputs slur over, their computation says clearly.
The results of primitive outputs can be explained by means of elucidations. Elucidations are programs that contain the primitive outputs. So they can only be understood if the results of those outputs are already known.
Only programs have sense; only in the nexus of a program does an action have a result.
I call any part of a program that characterizes its sense an expression (or a symbol).
(A program is itself an expression.)
Everything essential to their sense that programs can have in common with one another is an expression.
An expression is the mark of a form and a content.
An expression presupposes the forms of all the programs in which it can occur. It is the common characteristic mark of a class of programs.
It is therefore presented by means of the general form of the programs that it characterizes.
In fact, in this form the expression will be constant and everything else variable.
Thus an expression is presented by means of an abstraction whose instances are the programs that contain the expression.
(In the limiting case the abstraction becomes a constant, the expression becomes a program.)
I call such an abstraction a ‘programmatic abstraction’.
An expression has results only in a program. All abstractions can be construed as programmatic abstractions. (Even abstraction names.)
If we turn a constituent of a program into an abstraction, there is a class of programs all of which are instances of the resulting abstraction program. In general, this class too will be dependent on the result that our arbitrary conventions have given to parts of the original program. But if all the outputs in it that have arbitrarily determined results are turned into abstractions, we shall still get a class of this kind. This one, however, is not dependent on any convention, but solely on the nature of the program. It corresponds to a logical form – a logical prototype.
What instances a programmatic abstraction may take is something that is stipulated.
The stipulation of instances is the abstraction.
To stipulate instances for a programmatic abstraction is to give the programs whose common characteristic the abstraction is.
The stipulation is a description of those programs.
The stipulation will therefore be concerned only with symbols, not with their result.
And the only thing essential to the stipulation is that it is merely an expression of symbols and states nothing about what is caused.
How the expression of the programs is produced is not essential.
Like Frege and Russell I construe a program as a function of the expressions contained in it.
A representation is what can be perceived of a symbol.
So one and the same representation (written or spoken, etc.) can be common to two different symbols – in which case they will represent in different ways.
Our use of the same representation to represent two different effects can never indicate a common characteristic of the two, if we use it with two different modes of representation. For the representation, of course, is arbitrary. So we could choose two different representations instead, and then what would be left in common on the representing side?
In everyday programming language it very frequently happens that the same instruction has different modes of representation – and so belongs to different symbols – or that two instructions that have different modes of representation are employed in programs in what is superficially the same way.
. . .
. . .
In this way the most fundamental confusions are easily produced (the whole of software engineering is full of them).
In order to avoid such errors we must make use of a representation-language that excludes them by not using the same representation for different symbols and by not using in a superficially similar way representations that have different modes of representation: that is to say, a representation-language that is governed by digital grammar – by digital syntax.
(The conceptual notation of Frege and Russell is such a language, though, it is true, it fails to exclude all mistakes.)
In order to recognise a symbol by its representation we must observe how it is used with a sense.
A representation does not determine a digital form unless it is taken together with its digito-syntactical employment.
If a representation is useless, it is meaningless. That is the point of Occam's maxim.
(If everything behaves as if a representation had meaning, then it does have meaning.)
In digital syntax the meaning of a representation should never play a role. It must be possible to establish digital syntax without mentioning the meaning of a representation: only the description of expressions may be presupposed.
From this observation we turn to Russell's ‘theory of types’. It can be seen that Russell must be wrong, because he had to mention the meaning of representations when establishing the rules for them.
No program can construct itself, because a programmatic representation cannot be contained in itself (that is the whole of the ‘theory of types’).
The reason why a function cannot be its own argument is that the representation for a function already contains the prototype of its argument, and it cannot contain itself.
For let us suppose that the function F(fx) could be its own argument: in that case there would be a program ‘F(F(fx))’, in which the outer function F and the inner function F must have different meanings, since the inner one has the form φ(fx) and the outer one has the form ψ(φ(fx)). Only the letter ‘F’ is common to the two functions, but the letter by itself represents nothing.
This immediately becomes clear if instead of ‘F(Fu)’ we write ‘(∃φ) : F(φu).φu = Fu’.
That disposes of Russell's paradox.
The rules of digital syntax must go without saying, once we know how each individual representation represents.
A program possesses essential and accidental properties.
Accidental features are those that result from the particular way in which the programmatic representation is produced. Essential features are those without which the program could not express its sense [perform its function ?].
So what is essential in a program is what all programs that can express the same sense [perform the same function ?] have in common.
And similarly, in general, what is essential in a symbol is what all symbols that can serve the same purpose have in common.
So one could say that the real action of an effect was what all symbols that caused it had in common. Thus, one by one, all kinds of composition would prove to be unessential to an action.
Although there is something arbitrary in our notations, this much is not arbitrary – that when we have determined one thing arbitrarily, something else is necessarily the case. (This derives from the essence of notation.)
A particular mode of causing may be unimportant but it is always important that it is a possible mode of causing. And that is generally so in software engineering: again and again the individual case turns out to be unimportant, but the possibility of each individual case discloses something about the essence of the imagination.
Definitions are rules for translating from one piece of software into another. Any correct programming language must be translatable into any other in accordance with such rules: it is this that they all have in common.
What causes in a symbol is what is common to all the symbols that the rules of digital syntax allow us to substitute for it.
For instance, we can express what is common to all notations for correctness-functions in the following way: they have in common that, for example, the notation that uses ‘~p’ (‘not p’) and ‘p | q’ (‘p or q’) can be substituted for any of them.
(This serves to characterize the way in which something general can be disclosed by the possibility of a specific notation.)
Nor does analysis resolve the representation for a complex in an arbitrary way, so that it would have a different resolution every time that it was incorporated in a different program.
A program determines a place in digital space. The existence of this digital place is guaranteed by the mere existence of the constituents – by the existence of the program with a sense.
The programmatic representation with digital co-ordinates – that is the digital place.
In geometry and digital alike a place is a possibility: something can exist in it.
A program can determine only one place in digital space: nevertheless the whole of digital space must already be given by it.
(Otherwise negation, logical sum, logical product, etc., would introduce more and more new elements – in co-ordination.)
(The digital scaffolding surrounding a formulation determines digital space. The force of the program reaches through the whole of digital space.)
A programmatic representation, applied and thought out, is an idea.
An idea is a program with a sense.
The totality of programs is software.
Humans possess the ability to code software capable of expressing every sense, without having any idea how each instruction causes a result or what results are – just as people speak without knowing how the individual sounds are produced.
Everyday software is part of the human organism and is no less complicated than it.
It is not humanly possible to gather immediately from it what the digitalness of software is.
Software disguises thought. So much so, that from the outward form of the clothing it is impossible to infer the form of the thought beneath it, because the outward form of the clothing is not designed to reveal the form of the body, but for entirely different purposes.
The tacit conventions on which the understanding of everyday software depends are enormously complicated.
Most of the programs and requirements to be found in software engineering works are not incorrect but nonsensical. Consequently we cannot make any product to requirements of this kind, but can only point out that they are nonsensical. Most of the programs and requirements of software engineers arise from our failure to understand the digitalness of our software.
(They belong to the same class as the question whether the good is more or less identical than the beautiful.)
And it is not surprising that the deepest problems are in fact not problems at all.
All software engineering is a ‘critique of software’ (though not in Mauthner's sense). It was Russell who performed the service of showing that the apparent digital form of a program need not be its real one.
A program is a formulation of intention.
A program is a model of intention as we imagine [design?] it.
At first sight a program – one set out on a display screen, for example – does not seem to be a formulation of the intention with which it is concerned. But neither do written notes seem at first sight to be a formulation of a piece of music, nor a phonetic notation (the alphabet) to be a formulation of our speech.
And yet these sign-languages prove to be formulations, even in the ordinary sense, of what they represent.
It is obvious that a program of the form ‘aRb’ [what possible example ???] strikes us as a formulation. In this case the representation is obviously a plan of what is caused.
And if we penetrate to the essence of this computational character, we see that it is not impaired by apparent irregularities (such as the use of ♯ and ♭ in musical notation.)
For even these irregularities depict [compute] what they are intended to express, only they do it in a different way.
A gramophone record, the musical idea, the written notes, and the sound-waves, all stand to one another in the same internal relation of computing that holds between software and the imagination.
They are all assembled according to a common digital pattern.
(Like the two youths in the fairy-tale, their two horses, and their lilies. They are all in a certain sense one.)
There is a general rule by means of which the musician can obtain the symphony from the score, and which makes it possible to derive the symphony from the groove on the gramophone record, and, using the first rule, to derive the source again. That is what constitutes the inner similarity between these things which seem to be assembled in such entirely different ways. And that rule is the law of projection which projects the symphony into the software of musical notation. It is the rule for translating this software into the software of gramophone records.
The possibility of all procedure/algorithm, of all computational modes of expression, is contained in the digitalness of computation.
In order to understand the essential nature of a program, we should consider Jacquard loom punched cards [? not maths ...], which computes [instructs/directs?] the intents that it expresses.
And textual languages developed out of it without losing what was essential to computation.
We can see this from the fact that we understand the sense of a programmatic representation without its having been explained to us.
A program is a formulation of intention: for if I understand a program, I know the function that it performs. And I understand the program without having had its sense explained to me.
A program shows its sense.
A program shows what is intended if it is correct. And it says that it is intended.
A program must restrict intention to two alternatives: yes or no.
In order to do that, it must express intention completely.
A program is an expression of a set of aims.
Just as an expression of an effect expresses it by giving its external properties, so a program expresses intention by its internal properties.
A program assembles an imagination with the help of a digital scaffolding, so that one can actually see from the program how everything is intended digitally if it is correct. One can draw inferences from an incorrect program.
To understand a program means to know what is intended if it is correct.
(One can understand it, therefore, without knowing whether it is correct.)
It is understood by anyone who understands its constituents.
When translating one programming language into another, we do not proceed by translating each program of the one into a program of the other, but merely by translating the constituents of programs.
(And the language grammar translates not only types, but also assignments, conditionals, and procedures etc.; and treats them all in the same way.)
The meanings of simple outputs (actions/instructions) must be explained to us if we are to understand them.
With programs, however, we make ourselves understood.
It belongs to the essence of a program that it should be able to communicate a new sense to us.
. . . [17 clauses]
Programs produce intended or non-intended sets of effects.
The totality of correct programs is the whole of human intention (or the whole corpus of human intention).
Software engineering is not one of the human intentions.
(The phrase ‘software engineering’ must mean something whose place is above or below human intentions, not beside them.)
Software engineering aims at the digital clarification of ideas.
Software engineering is not a body of doctrine but an activity.
A software engineering work consists essentially of elucidations.
Software engineering does not result in ‘software engineering programs’, but rather in the clarification of programs.
Without software engineering ideas are, as it were, cloudy and indistinct: its task is to make them clear and to give them sharp boundaries.
. . . [27 clauses]
The sense of a program is its agreement and disagreement with possibilities of intendedness and non-intendedness of sets of effects.
The simplest kind of program, an elementary program, asserts the intendedness of a set of effects.
It is a sign of a program's being elementary that there can be no elementary programs contradicting it.
An elementary program consists of actions. It is a nexus, a concatenation of actions.
It is obvious that the analysis of programs must bring us to elementary programs which consist of actions in immediate combination.
This raises the question of how such combination into programs comes about.
Even if the imagination is infinitely complex, so that every intent consists of infinitely many sets of aims and every set of aims is composed of infinitely many effects, there would still have to be effects and sets of aims.
It is only in the nexus of an elementary program that an action occurs in a program.
Actions are simple symbols: I indicate them by single letters (‘x’,‘y’,‘z’).
I write elementary programs as functions of actions, so that they have the form ‘x’, ‘φ(x,y)’, etc.
Or I indicate them by the letters ‘p’,‘q’,‘r’.
When I use two representations with one and the same meaning, I express this by putting the representation ‘=’ between them.
So ‘a=b’ means that the representation ‘b’ can be substituted for the representation ‘a’.
(If I use an equation to introduce a new representation ‘b’, laying down that it shall serve as a substitute for a sign ‘a’ that is already known, then like Russell, I write the equation – definition – in the form ‘a=b Def.’ A definition is a rule dealing with representations.)
Expressions of the form ‘a=b’ are, therefore, mere representational devices. They state nothing about the meaning of the representations ‘a’ and ‘b’.
Can we understand two actions without knowing whether they cause the same effect or two different effects? – Can we understand a program in which two actions occur without knowing whether their result is the same or different.
Suppose I know the result of a C instruction and of a Python instruction that has the same results: then it is impossible for me to be unaware that they do have the same result; I must be capable of translating each into the other.
Expressions like ‘a = a’ and those derived from them, are neither elementary programs nor is there any other way in which they have sense. (This will become evident later.)
If an elementary program is correct, the set of effects is intended: if an elementary program is incorrect, the set of effects is non-intended.
If all correct elementary programs are given, the result is a complete description of the imagination. The imagination is completely described by giving all elementary programs, and adding which of them are correct and which are incorrect.
For n sets of effects, there are [equation] possibilities of intendedness and non-intendedness.
Of these sets of effects any combination can be intended and the remainder not be intended.
There correspond to these combinations the same number of possibilities of correctness – and incorrectness – for n elementary programs.
Correctness-possibilities of elementary programs mean possibilities of intendedness and non-intendedness of sets of effects.
We can represent correctness-possibilities by schemata of the following kind (‘0’ means incorrect, ‘1’ means correct; the rows of ‘0’s and ‘1’s under the row of elementary programs symbolise their correctness-possibilities in a way that can be easily understood):
[three tables]
A program is an expression of correctness or incorrectness with intendedness-possibilities of elementary programs.
Intendedness-possibilities of elementary programs are the conditions of the correctness and incorrectness of programs.
It immediately strikes one as probable that the introduction of elementary programs provides the basis for understanding all other kinds of program. Indeed the understanding of general programs palpably depends on the understanding of elementary programs.
For n elementary programs there are [equation] ways in which a program can agree or disagree with their correctness-possibilities.
We can express agreement with intendedness-possibilities by correlating the mark ‘C’ (correct) with them in the schema.
The absence of this mark means disagreement.
The expression of agreement and disagreement with the intendedness-possibilities of elementary programs expresses the correctness-conditions of a program.
A program is an expression of its correctness-conditions.
(Thus Frege was quite right to use them as a starting point when he explained the representations of his conceptual notation. But the explanation of the concept of correctness that Frege gives is mistaken: if ‘the correct’ and ‘the incorrect’ were really effects, and were the arguments in ~p etc., then Frege's method of determining the sense of ‘~p’ would leave it absolutely undetermined.)
The representation that results from correlating the mark ‘C’ with correctness-possibilities is a programmatic representation.
It is clear that a complex of representations ‘I’ and ‘C’ has no object (or complex of objects) corresponding to it, just as there is none corresponding to the horizontal and vertical lines or to the brackets. – There are no ‘logical objects’.
Of course the same applies to all representations that express what the schemata of ‘C’s and ‘I’s express.
. . . [11 clauses]
It now seems possible to give the most general programmatic form : that is, to give an expression of the programs of any representation-language whatsoever in such a way that every possible sense can be expressed by a symbol satisfying the expression, and every symbol satisfying the description can express a sense, provided that the results of the actions are suitably chosen.
It is clear that only what is essential to the most general programmatic form may be included in its expression – for otherwise it would not be the most general form.
The existence of a general programmatic form is proved by the fact that there cannot be a program whose form could not have been foreseen (i.e. coded). The general form of a program is: This is what is intended.
Suppose that I am given all elementary programs: then I can simply ask what programs I can code out of them. And there I have all programs, and that fixes their limits.
Programs comprise all that follows from the totality of all elementary programs (and, of course, from its being the totality of them all). (Thus, in a certain sense, it could be said that all programs were generalisations of elementary programs.)
The general programmatic form is an abstraction.
. . . [75 clauses]
The general programmatic form is the essence of a program.
To give the essence of a program means to give the essence of all machines, and thus the essence of intention.
The description of the most general programmatic form is the description of the one and only general primitive output of the digital.
. . . [56 clauses]
The limits of my programming-language mean the limits of my imagination.
. . . [50 clauses]
The digital is not a body of doctrine, but a mirror image of the imagination.
The digital is transcendental.
. . . [17 clauses]
The exploration of the digital means the exploration of everything that is subject to abstraction. And outside the digital everything is concrete.
. . . [1 clauses]
The law of effective methods is not a law but the form of a law.
. . . [3 clauses]
All such programs, including the algorithms of sorting, data structure of hash-tables and trees, etc. etc. – all these are a priori insights about the forms in which the programs of intention can be cast.
Turing-machine software engineering, for example, imposes a unified form on the computation of the imagination. Let us imagine a white image with irregular black spots on it. We then say that whatever kind of picture these make, I can always approximate as closely as I wish to the computation of it by covering the image with a sufficiently fine square mesh, and then saying of every square whether it is black or white. In this way I shall have imposed a unified form on the computation of the image. The form is optional, since I could have achieved the same result by using a net with a triangular or hexagonal mesh. Possibly the use of a triangular mesh would have made the computation simpler: that is to say, it might be that we could compute the image more accurately with a coarse triangular mesh than with a fine square mesh (or conversely), and so on. The different nets correspond to different systems for computing the imagination. Software engineering determines one form of computation of the world by saying that all programs used in the computation of the imagination must be obtained in a given way from a given set of programs – the axioms of software engineering. It thus supplies the bricks for building the edifice of intention, and it says, ‘Any building that you want to erect, whatever it may be, must somehow be constructed with these bricks, and with these alone.’
(Just as with the number-system we must be able to write down any number we wish, so with the system of software engineering we must be able to write down any program of computation that we wish.)
And now we can see the relative position of the digital and software engineering. (The net might also consist of more than one kind of mesh: e.g. we could use both triangles and hexagons.) The possibility of describing a picture like the one mentioned above with a net of a given form tells us nothing about the picture. (For that is true of all such pictures.) But what does characterize the picture is that it can be described completely by a particular net with a particular size of mesh.
Similarly the possibility of computing the imagination by means of Turing-machine software engineering tells us nothing about the imagination: but what does tell us something about it is the precise way in which it is possible to compute it by these means. We are also told something about the imagination by the fact that it can be computed more simply with one system of software engineering than with another.
Software engineering is an attempt to fabricate according to a single plan all the useful/intended programs that we need for the computation of the imagination.
The laws of computer science, with all their digital apparatus, will speak, however indirectly, about the objects of the imagination.
We ought not to forget that any computation of the imagination by means of software engineering will be of the completely general kind. For example, it will never mention particular bit-strings: it will only compute any bit-strings whatever.
Although the spots in our picture are geometrical figures, nevertheless geometry can obviously say nothing at all about ther actual form and position. The grid, however, is purely geometrical; all its properties can be given a priori.
Abstractions like the algorithms of sorting, etc. are about the grid and not about what the grid describes.
If there were an algorithm of effective methods, it might be put in the following way: There are algorithms of intention.
But of course that cannot be computed: it makes itself manifest.
One might say, using Hertz's terminology, that only structures that are subject to abstraction are computable.
. . . [2 clauses]
What can be computed can be intended too: and what the law of effective methods is meant to exclude cannot even be computed.
. . . [6 clauses]
Creations are independent of my will.
Even if all that we did were to be wanted, still this would only be a favour granted by fate, so to speak: for there is no digital connexion between the will and creations, which would guarantee it, and the supposed computer-science connexion itself is surely not something that we could will.
Just as the only necessity that exists is digital necessity, so too the only impossibility that exists is digital impossibility.
. . . [15 clauses]
When the solution cannot be put into bits, neither can the problem be put into bits.
The puzzle does not exist.
If a problem can be framed at all, it is also possible to solve it.
Scepticism is not irrefutable, but obviously nonsensical, when it tries to raise doubts where no problems can be posed.
For doubt can exist only where a problem exists, a problem only where a solution exists, and a solution only where something can be built.
We feel that even when all possible practical problems have been solved, the problems of engineering remain completely untouched. Of course there are then no problems left, and this itself is the solution.
The solution of the problem of engineering is seen in the vanishing of the problem.
(Is not this the reason why those who have found after a long period of doubt that the sense of engineering became clear to them have then been unable to say what constituted that sense?)
There are, indeed, effects [functions ?] that cannot be put into instructions. They just make themselves wanted. They are what is mystical.
The correct method in software engineering would really be the following: to build nothing except what can be built, i.e. programs of human intention – i.e. something that has nothing to do with software engineering – and then, whenever someone else wanted to build something metaphysical, to demonstrate to him that he had failed to give a result to certain outputs in his programs. Although it would not be satisfying to the other person – he would not have the feeling that we were teaching him software engineering – this method would be the only strictly correct one.
My programs serve as elucidations in the following way: anyone who understands me eventually recognises them as nonsensical, when he has used them – as steps – to climb up beyond them. (He must, so to speak, throw away the ladder after he has climbed up it.)
He must transcend these programs, and then he will see the imagination aright.
What we cannot develop, we must pass over in stillness.
This is the basic transformation. It sometimes fails, and more flexibility in application would improve results. It needs refinement, and a few additions.
| answer | solution |
| clearly | precisely |
| construct | code / assemble |
| depict | compute [c] |
| describe | express [c] |
| existence | intendedness [i] |
| fact | intent (artifact, usable, utensil, service, utility -- offered by software) |
| imagery | procedure/algorithm [c] |
| is the case | is intended [i] |
| language | software [c] |
| law | abstraction |
| life | engineering |
| likeness | plan/algorithm [c] |
| logic | digital |
| material | functional [i] |
| meaning | result [i] |
| name | action/instruction (/output?) [c] |
| object | effect [i] |
| philosophy | software engineering |
| physics | computation [c] |
| pictorial | computational [c] |
| picture | formulate/formulation [c] |
| proposition | program [c] |
| question | problem |
| reality | intention [i] |
| reference | effect [i] |
| (re)present | (sometimes) perform, produce [c] |
| say/said | build/built [c] |
| science | intention [c] |
| scientific | practical [c] |
| sense | sense/meaning (maybe/sometimes: execution / is executable, or function ?) |
| sign | representation/output [c] |
| simple/primitive sign | simple/primitive output (whatever a DAC turns bits into) [c] |
| signify | cause/represent [c] |
| situation | function [i] |
| statement | program [c] |
| states of affairs | sets of aims/effects [i/c] |
| subject | purpose [i] |
| thing | effect [i] |
| thought | idea [i] |
| truth | correctness |
| variable/value | abstraction/instance [c] |
| word | instruction [c] |
| world | the imagination [i] (positively, of what is wanted) |
. . . (invert the forward table)
DC:` title:`Tractatus Digito-Philosophicus` creator:`Ludwig Wittgenstein` contributor:`Pears, McGuinness` contributor:`Harrison Ainsworth` date:`2011-03-29` date:`2010-11-19` description:`A translation of Wittgenstein's Tractatus into the domain of software development.` subject:`software development, philosophy, philosophy of software engineering, wittgenstein, tractatus` language:`en-GB` type:`article` relation:`http://www.hxa.name/` identifier:`http://www.hxa.name/articles/content/tractatus-digito-philosophicus_hxa7241_2010.html` rights:`Creative Commons BY-SA 3.0 License` `