Computing products, research, interfaces, tools, environments, and programming languages, that work more naturally, and comfortably -- applying as sensitive a consideration of human thought, life, and feeling, as we can -- making use of surprising principles that are found both in nature and in good human work, which help people to build coherent complexity and robust systems, and which are reminiscent of biological morphogenesis -- hence "blooming logic".
We all know that humans have many natural tendencies, within ourselves, which are often in conflict with one another.
These conflicts are reflected in all human artifacts and pursuits. And, over the millennia, when we manage to pay attention to these hard-to-identify and easy-to-forget tendencies, we sometimes become a little more effective at making best use of conflicting faculties.
One of the obvious conflicts, is between what we innately believe is 'natural' and what we innately believe is 'logical'. We've all experienced this, and it has been vastly commented upon. In almost everything we do, there seems to be a struggle, resolved mostly unconsciously, more or less to our satisfaction.
But this can certainly be studied with more rigor. Especially in computing practice.
Our research program represents a particular stance on this conflict. We call it 'Blooming Logic'. It's an initiative to pursue a different technological direction than today's dominant approach, where the 'logical' side has 'won', much to its own detriment. And to ours.
Programmers are the formal logicians of our day (but not regarding the other classic concern of logicians: uncovering the nature of cognition). Their recruitment of certain constrained ideas and particular algebras, is serving an ever-growing engineering economy. But sensitivity to the nature of programmers as people, their natural selves, has become so lost, that all the 'progress' in programming tools, languages and development environments has become a reshuffling of closed symbolic practices and minor rearrangement of the ideas, still in the minds of programmers, assigned to terms in formal systems. We're going nowhere. Even in unpressured circumstances, software still sucks.
There's a hint, in our everyday practices, that reveals the more productive direction.
Even in 'symbolic cognition' we make constant use of our sense of nature, coherence, and beauty. We regularly reorganize our programs, our files, indentation, and labels -- we don't do this only to organize our symbols according to formal rules, but to make ourselves comfortable with them, according to unknown cognitive judgements.
But then, why do we stop there? Why do our basic languages and development environments change so rarely, and so rarely in the direction of human comfort? These should constantly be adjusted to make software development a more comprehensible, beautiful, natural task, in accordance with these 'non-logical' innate judgements.
We believe that 'sensitivity' and 'comfort' are simply not made explicit in our computing culture. To a certain degree, these judgments are understood by some user interface builders, but they are often ignored by the programmers themselves. The separation of the job of 'programmer' from that of 'designer', was one of the worst mistakes in the history of computing. As a result, 'comfort' gets no conscious attention, study, or training, while the recombined formal denotations of symbols and rules are pondered endlessly with little beneficial result.
We aim to change this.
The starting point for this work was a cognitive effect, the smooth unfolding of something with feeling, demonstrated by the design tool Gatemaker. This was created by Christopher Alexander and Greg Bryant in the Fall and Winter of 1996-1997. It's based on observations, experiments, and processes, during group design and build projects, which Alexander had refined for decades, and which can be found described in The Timeless Way of Building and The Nature of Order.
But the most important thing to know about Gatemaker, is that it's an example of a novel user interface produced by the persistent application of human feeling.
A contemporary account on Gatemaker can be found at gatemaker.org. A recent account was presented at the 2013 PUARL conference in Portland, Oregon and was pre-printed in RAIN Magazine in 2014 as "Gatemaker: Christopher Alexander's dialogue with the computer industry".
The use of Gatemaker for the unfolding of structures in the world of human habitat, while a major undertaking, is relatively straightforward compared to the question of what to do with this effect in the development of software. To quote Christoper Alexander in 1997:
“The conclusion I draw is that the character of this program has a bearing not only on the future generation of programs in the building/environment field, but that all software (including software designed to help developers design software) may, in all probability, also benefit from the kind of sea-change which is anticipated in Gatemaker. One may describe this sea-change, broadly, by saying that there are reasons for thinking that the character of the computer environment of the future needs to become more childish, and more human, if it is to help human beings genuinely extract the best of themselves …”
The possibility of an engineering application was the hope of the grant that enabled Alexander and Bryant to create Gatemaker in the first place.
Bryant believes that you can find hints of this effect everywhere in software development. He also believes that the Software Patterns movement, wed to particular ideologies and technologies, was never able to connect with this effect, or the major element of the effect, the human ability to judge things with life. This is something that Alexander has written about brilliantly and tirelessly, but seems not to be conveyed by reading alone.
We're just beginning to put together interactive tools that might help people to discover their innate faculty for discovering life. Using Gatemaker at urbanology.com is helped by learning some sketching-from-life basics at the website sketch.life, and then considering the exercises on learning to detect life at detect.life. What we're doing here is trying to replace, as much as possible, the effect of the Alexander-trained helper, which seems to make all the difference in understanding his work as intended.
These are internal faculties, which are hard enough to engage, without getting too obsessed about characterizing the qualities of the external stimulus -- 'things with life'. Characterizing the morphology of life is difficult because we only know it based on our psychological faculty. That is, we have no other way to detect life but to recognize it, because we have defined it, as animals ourselves. Still, the question of a somewhat more detached characterization of life is interesting, and outside of the work of Alexander and Nikos Salingaros, you can find some of Greg Bryant's observations on the topic at examine.life.
So, what about software development?
The first question is: what level to pursue life in software? But this has been answered by the domain of construction pretty well: anywhere you can. But not more than that. If a project is never completed because 'everything must have life', then that's an endless research program, not a finish-able computer program. And any initiative to insert life is unlikely to be influential, if there's no point of connection between existing ideas and technologies.
Along those lines, Bryant created a macro programming language, which has its own simple operating procedure, called grogix, which can be found discussed on grogix.org. It really is just a runtime programming-text structuring framework ... as if maybe Unix's m4 had been turned into the center or operation (which is why this is called an 'operational grammar'). But because it is language and environment independent, it's an interesting layer in these studies. But we're not particularly wed to it.
Grogix emerged from a different macro language called SUPL,which was an attempt to make it easier to construct smooth unfolding sequences of programs.
The smooth unfolding sequence for software development was explored at corememory.org. It represents some important aspect of the cognitive effect of Gatemaker, but certainly not the entire effect. But itself, the smooth unfolding of programs in development environments is worth studying to improve the engineer's experience. But almost no one with control of the purse-strings in the computer industry is convinced of the need to improve the engineering experience. And most engineers don't know quite where to start to improve all of software, so they improve small and immediate aspects of their workspaces, as part of organizing their work to get things done.
So, unfolding software development sequences, with an understanding of the process by training with gatemaker, can almost certainly inject more life into the structure of a program, and improve the user experience sensibility of the programmer as well. Most importantly, it will allow a developer to get a sense for natural structure, which can guide a future objective standard for program quality. This may take a long time, because computer science is not actually a natural science, and so the physiological reality of these cognitive effects is not taken seriously. Bryant writes about this a great deal at Computing Philosophy.
Currently, we're exploring a far more radical approach to the creation of smooth sequences and beautiful programs.
Think of it this this way: if you take seriously every result from the Gatemaker Theory produced by Alexander and Bryant, then you would build an environment for programming that looked like Gatemaker. The focused center of the screen would hold some very small, beautiful representation of some aspect of the natural structure of your program. This is a far cry from the torrents of text -- the classes, functions, files, and processes -- that current IDEs essentially dump upon a developer. It's vision closer to a literate, healing approach to program and user interface design, one that treats the engineer as a human being.