Sunday, July 7, 2013

Intelligibility and technical definitions: explanation vs. explanatory theory

Although there are methodological similarities, engineering is not science (see the previous post). But there's an important methodological artifact that science and engineering share.

In science, theories must be intelligible. You want to explain something to other people, so they can understand it. This is true in many human endeavors, and it's true in engineering as well. 

But there's more: we program within the context of what seems to be an 'explanatory theory' of a computational model, one we have implemented as a development environment on the machine. It's not a theory about some universal principles in the natural world ... it's a 'theory' about something that we have created. In an important sense, it is not a theory ... it's an explanation of our construction. 

This explanation is similar to an explanatory theory in an important way: technical terminology only makes sense, and is only intelligible, in the context of the explanation.

So, the practice within technological work -- defining highly restricted terms within the context of an intelligible explanation -- uses the same criteria of intelligibility that scientists use, when explaining results in terms that are understood only within an explanatory theory!

No wonder science and engineering can seem so similar! Both have a need for precise jargon, in the context of a long explanation!

But one is a theory, because it attempts to explain, not something we've built, but something that we believe is going on in nature. The other, I'm sad to say, is just an explanation.

That's my pre-theoretical guess about a factor involved in the human organism's common confusion between engineering and science. There are many other factors, but no terminology, and no theory ... because there's no scientific work on this topic.

Thursday, July 4, 2013

The application of feeling

Most engineering, most science, most art, and most problem-solving, involves operations of the mind that we are rarely even dimly aware of. This is through no fault of our own: most "conscious activity" is unconscious, and we have no access to it. 

Over the millennia, we've identified a few kinds of thought, but we're quite far from understanding them, and there are clearly many other kinds of thought, mostly very far from our conscious awareness, which enter into our every living moment.

One of these the is the application of feeling. This is described in Christopher Alexander's four volume The Nature of Order, but essentially, in order to tap into our ability to create really good structure, which resonates deeply with people, we need to follow a process where we ask ourselves whether choice A or choice B has deeper feeling. I would put 'deeper feeling' in quotes, but in order for this technique to have good results, you need to ask it, of yourself, with as little interference as possible, and as honestly and simply as possible.

So, what might be going on here?

This technique seems to allow us to recognize (I almost said 'resonate') with structures effectively shaped by natural laws: the still poorly understood biophysics of living organisms. The conscious mind, and hence much of the subconscious mind, can interfere with our ability to see coherent, well-balanced, natural geometry. But 'the shortcut', an honest response to the question 'which has more feeling?', seems capable of resolving many issues like 'which of these is most profound?' This can be very useful for an artist trying to unleash their full human potential, and for an engineer trying to create a really good machine, program or user interface. It even enters into scientific work: which is the best way to represent a theoretical or experimental result? The one which has the most feeling, the one which is simple, lucid, elegant, and beautiful. This can be a guide to improve your work as you do it. Advanced mathematics, and even simple arithmetic, would be almost impossible without it. We use this criteria, to some degree, all the time. Just not enough. And we allow other forces to interfere when we shouldn't.

Now, this is an assertion. You can read The Nature of Order and test it yourself. I should point out that it's not really a training manual, or a training course, but more of a long explanation of the technique, its basis, and what it might mean. Showing someone how to apply feeling is something, I find, that is best communicated person-to-person. I'm not sure why.

Do you believe this? Many artists do, because they really need to use this technique explicitly throughout the day, to do their best work. Engineers have a harder time believing it, primarily because their working environment was formed with this shortcut only in some degree, but not often enough, and not explicitly enough. So we spend a lot of time wrestling with new, rather pedestrian computer tools that never seem to offer much of an advantage to engineers-as-human-beings. The programming environment designers didn't know how to apply feeling, and certainly didn't try to facilitate its use among their users.

The hard sciences have very little to say about the application of feeling. It's too complex a topic. Remember, physics is successful because it deals with the simplest imaginable phenomena. Chemistry is more complex. Biology even more complex than chemistry. And human biology is just off the scale ... we know much less than most researchers want to admit. The biology of human thought, which overlaps with psychology, is so complex that most of it is still 'soft science'.

So, it will be a very long time before we understand the application of feeling as a part of the human mind. We're not even sure what understanding it might look like. We can certainly see what kinds of structures are produced, and effective to people -- but they are hard to characterize the specific geometry of, at least in a way that a computer might recognize it. Exploring the geometry is a primary topic of The Nature of Orderusing a technique that's not so different from exploring universal grammar in biological linguistics. 

We could probably get a decent fMRI result of the state the mind enters when this evaluation-of-feeling is taking place. It's hard to see which questions to ask, after that. We could do more fMRI's to differentiate the application of feeling from other kinds of mental activity, essentially asking "how often does the feeling-evaluation-faculty enter into other mental processes?"

But I'm mostly interested in how hard it is for engineers to use this technique, even when it is done within a perfectly reasonable research context. It could have been used to 'rate' patterns in the software patterns movement, but it wasn't, even though rating is a prominent part of the original book A Pattern Language, and a critical tool in its predecessor, The Oregon Experiment

This has always troubled me. User interface designers have no trouble asking themselves this kind of question. Why do programmers, or programming-tool developers? If we're ever to make any progress with software tools, engineers will have to be open to asking and answering these perfectly reasonable questions about their interface with the machine.

Wednesday, July 3, 2013

Three aspects of programming language design: mentation mysteries, metaphysical mathematical momentum, and "the shortcut"

Programming language design is something that humans do. 

One could examine biologically the effects of notations on the human mind, and try to create a working model of what might be called the "mentation mysteries" behind programming languages. And use that to set some kinds of criteria for future programming languages.

That's hard work. That's why it's called hard science. So people don't do this, when they design programming languages. They obviously don't need to, because plenty of programming languages exist, even though this research is still on the starting block.

So, instead of biological research, what other tools do people use to create new programming languages? 

Two tools: metaphysics and feeling.

By metaphysics I mean metaphysical mathematical momentum. 

Someone has a theory of what might be useful. It's based on some 'computational model' that they respect: Haskell programmers prefer functions that don't act on named state variables, Grogix programmers believe the world could be defined by operational grammars, LISP programmers believe that our world can be defined as ramified lists, SNOBOL programmers believe that ultimately everything is a string, etc. This is not just the ontology of their world ... made of lists, strings, grammars, monads, etc. ... there's also a metaphysics, a model of what lies hidden behind programming, in a fantasy computational system which acts as the programmer's substitute for the "real world". These language designers then develop mathematics and achieve momentum which can trample many other considerations for their tool, such as usability.

Well, there's only so much an engineer has time for ... So most aspects of most programming languages did not emerge from either biologically confirmed results or theoretical imperatives.

They emerged because they felt right

All those open questions about the mind, and those potentially useful metaphysical systems, might yield something useful later. But good engineering (and that's what good programming language design is) needs to work now. So, we use our sensitivity, we try things out, we keep the good stuff, we throw out the bad stuff, and we try to keep the result feeling coherent, while we maintain some kind of logical consistency and pragmatism.

It's the shortcut. 

You can't prove that your "answer to the crisis of programming" is right. But, using your gut, you can build something good, something perhaps a touch idiosyncratic, and see if it works for you, your friends, and some members of the public.

That said, it's really important to do a post-mortem. Be explicit about which of the three criteria above are being used in different parts of your language design. Because, most likely, you are using these three, separately or in combination, for different aspects of your language. And the poor engineer learning this language should be able to know what was going on, in your analysis, when you invented this language feature, or that one ... It's simple transparency. To a certain degree, you could sidestep analysis by just answering "I used my feeling" for all of it, but that would be silly. We tend to think about something and use our feeling to judge something. If you can't analyze your own language in this way, I think people would be quite right in not taking the effort to understand your programming language. They may be wrong, and they may be missing out, but the onus is on the inventor to explain what's been done, and why.

If you think your programming language is so simple and pure that it requires no explanation, I beg to differ, from experience. I created a programming language (grogix) which only has one kind of statement. But it takes a great deal of work to know whether you can use that simple statement to do all the things you want to do, and do them in a way that is easier than some existing way. So an explanation and demonstration is required.

So, look at your creation, and ask yourself to rank the drive behind any given feature:

  1. cognitive science
  2. metaphysical imperative
  3. feeling