Since some time I am intrigued by Flow-Based Programming (FBP) programming. It feels natural to me because I've worked with vvvv back in university, doing some interactive work, early on with Node and Erlang, and share a general interest on the life cycle of systems, flow in architecture and how to bring process and flow into model versioning.
Daniel points out the social aspect to FBP when he links it to Bret Victor's "Future of Programming" arguing we should (I paraphrase) bring computing technologies to people rather than people to technologies. The way Alex puts it is a bit more extreme: "People shouldn't have to learn to code to apply software to these problems". The question is not technology, or how we present technology. There will always be professional engineers that like to use vim, and there will always be people who like to learn the quirks despite their original profession. And technology has already become a lot more accessible, easier to learn and distribute. On the other hand, however, people don't want to think abstract, externalizing their creativity into a formal language.
In Code, Georg Vrachliotis tells the story of how Architecture scholars reacted to the rise of the computer. From the Architecture Machine and the 1970s statement "We want to arrange matters so that the computer can be used as naturally and easily as a pencil" all the way up to the contemporary view of code and architecture cross-pollinating each other, at the section of programming a drawing, with technologies like CAAD - much like visual programming or FBP.
We can't bring technologies to people, neither can we bring people to technology. We can create, however, a new space that provides the tools for people to pick up and decide how much they want to engage with technology. We have to build systems and technology that is both easy and versatile, comfortable and challenging, stable and fluid. By doing so we avoid the System design trap - the more we engineer, the less natural a system feels. It reminds me of one of my favorite quotes from John Gall:
Trying to design a System in the hope that the System will somehow solve the Problem, rather than simply solving the Problem in the first place, is to present oneself with two problems in place of one
UPDATE: On the discussion of common sense and using Nudge as a way of "Utopian Realism" I like to add the beautiful end of the Manifest for a New Realism:
Enlightenment still calls for a choice of position and faith in mankind, in knowledge and in progress [...] What are needed are knowledge, truth and reality. Failing to accept them [...] means pursuing the ever-open alternative proposed by Dostoevsky’s Grand Inquisitor: the path of miracles, mystery and authority.
No comments:
Post a Comment