DOCSLIB.ORG

A Different Look at Christopher Alexander and Pattern Languages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Different Look at Christopher Alexander and Pattern Languages Deep Thinking Problems Before Patterns: A Different Look at Christopher Alexander and Pattern Languages Molly Wright Steenson Princeton University School of Architecture | [email protected] Interaction and system design- tions, explored by Aaron Marcus, While pattern literature often ers alike gravitate to the idea of Shelley Evenson, Hugh Dubberly, focuses on patterns, there’s [1] Alexander, C., S. Ishikawa, and M. pattern languages. The notion and Rick Robinson, to name a an even greater focus on the Silverstein. A Pattern of patterns comes from the few [2,3]. Alan Cooper’s approach reproducible solution to a design Language: Towns, Buildings, Construction. work of architect Christopher to design was strongly inspired problem. As patterns move to New York: Oxford Alexander, who with his associ- by pattern languages. Kent Beck online reference models, they University Press, 1977. ates Sara Ishikawa and Murray and Ward Cunningham not only concentrate less on outlining the [2] Aaron, M. “Patterns Silverstein of the Center for cite Alexander’s influence on the problem and the context, and Within Patterns.” interac- Environmental Structure, pub- development of object-oriented more on the object, component, tions 11, no. 2 (2004): 28-34. lished A Pattern Language in 1977. programming languages at or interface solution. Where The book defines a set of funda- Xerox PARC in the early 1990s, this might help someone find a [3] Dubberly, H., mentals for building and plan- but also on extreme program- quick reference, it can be done S. Evenson, and R. Robinson.” The ning urban and architectural ming during the later part of the at the detriment of a problem Analysis-Synthesis projects that can be used by decade [4, 5]. And Erin Malone statement that offers expertise Bridge Model.” interac- tions 15 no. 2 (2008): non-expert designers. “Each pat- and Christian Crumlish are and context. John Vlissides, one 57-61. tern describes a problem which currently writing a book about of the four authors of Design occurs over and over again patterns for social software, Patterns: Elements of Reusable [4] Beck, K. “Embracing Change with Extreme in our environment,” wrote titled Designing Social Interfaces: Object-Oriented Software, noted Programming.” Alexander and his coauthors, Principles, Patterns, and Practices for in a 1997 article that one of the Computer 32, no. 10 (1999): 70-77. “and then describes the core of Improving the User Experience. primary offerings of patterns the solution to that problem, For designers of many disci- as a whole is their usefulness [5] Beck, Kent. <http:// in such a way that you can use plines, pattern languages are in addressing recurring prob- c2.com/ppr/about/ author/kent.html>. this solution a million times attractive because they offer a lems. “In short,” he wrote, “pat- over, without ever doing it the way to identify the core design terns are primarily food for the [6] Alexander, C., same way twice [1].” While the problem and because they brain, not fodder for a tool [7].” S. Ishikawa, and M. Silverstein. Pattern authors addressed architectural seek replicable rules and build- Skimping on defining the prob- Manual, Berkeley, 1967. and urban problems—in effect, ing blocks in their solutions. lem makes it more difficult to spatial problems—the approach Alexander and his colleagues critique, share, or build upon the [7] Vlissides, J.”Patterns: The Top offered (and continues to offer) even envisioned the kinds of learnings of the pattern. Ten Misconceptions.” ready parallels with the design sharing mechanisms central to The Pattern Manual deals with Object Magazine 7 no.1 March + April 2009 (1997): 30-33. <http:// problems faced by all designers. contemporary pattern libraries. the issue of the design prob- www.research.ibm. Alexander has long influenced As early as the mid-1960s, they lem. This little-known text by com/designpatterns/ pubs/top10misc.html.> interaction and software design- thought that patterns should Alexander and his colleagues Accessed 24 November 2008 ers. Pattern languages have be shared via an ever-growing, defined the landscape of the made numerous appearances open database of design prob- design problem in 1967—a Photograph of Christopher Alexander by Richard Morgenstein interactions in previous issues of interac- lems and solutions [6]. decade earlier than the publi- 20 Deep Thinking cation of the more familiar A these requirements, Alexander the problem, as it exists today Pattern Language. The methodol- expanded the architectural [6].” The pattern, then, is a set of ogy in the manual specifies a notion of program (it specifi- parts that relate to each other structure for setting up design cally means the set of functions in space. Patterns can address problems in order to find gen- fulfilled by a room, space, or anything from the appropriate eralities, particularities, and building). It is a program, he layout for a kitchen, to freeway eventual solutions. The authors wrote, “because it provides ramps, to designs for users of a considered it a “minimal and directions or instructions to the certain income or educational natural” format: the what, designer [8].” If this sounds like level, to furniture design, to where, and how of a situation; engineering language, it is no structures that hold up houses in other words, the problem, surprise. Alexander developed [6]. Where they can address a the context, and the resulting design-requirement data sets in huge variety of problems, they pattern [6]. Shifting the focus the early 1960s that were com- themselves seek to be reductive to the definition of the design plex enough to necessitate an and essential, offering only what problem and not just its result- IBM 704 mainframe computer is necessary. Where patterns ing pattern helps to ensure the for analysis. With his colleagues might not provide the only solu- pattern properly addresses the at the Center for Environmental tion to the problem, without it or situation, particularly in com- Structure, Alexander moved an equivalent, “the problem will plex environments. away from such a byzantine go unsolved [6].” Alexander long maintained analysis of requirements, instead Although titled the Pattern an interest in defining a design seeking a method for creating Manual, its heart is the design methodology in the face of com- straightforward descriptions of problem statement—the most plexity. Notes on the Synthesis of the program—that is, the design important element “from a Form, originally published in problem—in the Pattern Manual. human standpoint [6].” Problems [8] Alexander, C. Notes 1964, more than 20 years before The manual defines a gram- subsume the considerations on the Synthesis of Form. Cambridge, MA: A Pattern Language, outlines matical structure that maps that system designers address, Harvard University Press, 1971. the difficulty of designing for to a designer’s mental model. called “functional demands… a series of intermeshing, inter- A designer follows three steps [that] at one time or another acting systems, even when the when developing a pattern, “or, [have] been called requirements, final designed object itself might for that matter, [when he] enter- needs, performance standards, not look complicated. “In spite tains any idea about the physical facts, tendencies, objectives, of their superficial simplicity,” environment…. He considers a constraints, activities, technical Alexander wrote, “even these problem, invents a pattern to data, and so forth.” Yet the func- problems have a background of solve the problem, and makes tional demands do not stop with needs and activities which is a mental note of the range of what a system should do: They becoming too complex to grasp contexts where the pattern will address a wide variety of issues intuitively;” needs and activi- solve the problem [6].” Contexts surrounding the ecology of a sys- ties that sit within a growing and problems are paired with tem. “They may concern human ecosystem of other pressures, each other—wherever a par- behavior, economics, the state whether social, cultural, or ticular context appears, so too of technology, the political cli- informational [8]. In this setting, does its problem. The context mate, whatever. No limits can be Alexander found no place for modifies the pattern in the way placed on the kinds of elements the secret, intuitive processes that an adverb modifies a verb: necessary to describe a problem traditionally claimed by many It says how the pattern works properly [6].” designers, ones which did not and in which circumstances it If that sounds vast, it is. March + April 2009 take the intricacies of their con- is valid. The problem statement Patterns address an astonish- texts into consideration. Instead, provides the reasoning behind ingly wide variety of elements he advocated a logical, objective the pattern and context. It can that are organized in space in approach to design, in which be much lengthier, offering an some manner. The Pattern Manual form fit context by addressing a explanation of the situation, a offers an expansive list that interactions set of design requirements. With “common-sense description of includes “all kitchens; dormitory 22 FEATURE kitchens; efficiency apartment r*GUIFIPVTFJTPOFPGBSFHV- ations, Alexander, Ishikawa, and kitchens; …all industrial sites lar sequence of houses all using Silverstein all anticipated and larger than two acres; a 2x4… this pattern, then the sign letters inspired contemporary methods residential areas with 40 percent are at least 6 inches high. for design thinking. By seek- of their population under 25 r*GUIFIPVTFJTJTPMBUFE PS ing to provide “a natural way and median incomes between is one of a regular sequence of of expressing thoughts about $6,000 and $8,000; garden paths; houses not using this pattern, the physical environment,” the cobblestone paths; a doorknob; then the sign letters are at least authors offered a vital means any freeway; freeway exit ramps; 12 inches high [6]. to articulate the richness not bookshelves [6].” Any of these Consequently, a simple pat- only of a design solution, but its patterns provides a solution to tern that addresses angle and problem and its context [6].
Load more

Recommended publications
  • Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp
    Kyle Brown An Introduction to Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp. 4001 Weston Parkway CSC591O Cary, North Carolina 27513-2303 April 7-9, 1997 919-481-4000 Raleigh, NC [email protected] http://www.ksccary.com Copyright (C) 1996, Kyle Brown, Bobby Woolf, and 1 2 Knowledge Systems Corp. All rights reserved. Overview Bobby Woolf Senior Member of Technical Staff O Patterns Knowledge Systems Corp. O Software Patterns 4001 Weston Parkway O Design Patterns Cary, North Carolina 27513-2303 O Architectural Patterns 919-481-4000 O Pattern Catalogs [email protected] O Pattern Languages http://www.ksccary.com 3 4 Patterns -- Why? Patterns -- Why? !@#$ O Learning software development is hard » Lots of new concepts O Must be some way to » Hard to distinguish good communicate better ideas from bad ones » Allow us to concentrate O Languages and on the problem frameworks are very O Patterns can provide the complex answer » Too much to explain » Much of their structure is incidental to our problem 5 6 Patterns -- What? Patterns -- Parts O Patterns are made up of four main parts O What is a pattern? » Title -- the name of the pattern » A solution to a problem in a context » Problem -- a statement of what the pattern solves » A structured way of representing design » Context -- a discussion of the constraints and information in prose and diagrams forces on the problem »A way of communicating design information from an expert to a novice » Solution -- a description of how to solve the problem » Generative:
    [Show full text]
  • Neuroscience, the Natural Environment, and Building Design
    Neuroscience, the Natural Environment, and Building Design. Nikos A. Salingaros, Professor of Mathematics, University of Texas at San Antonio. Kenneth G. Masden II, Associate Professor of Architecture, University of Texas at San Antonio. Presented at the Bringing Buildings to Life Conference, Yale University, 10-12 May 2006. Chapter 5 of: Biophilic Design: The Theory, Science and Practice of Bringing Buildings to Life, edited by Stephen R. Kellert, Judith Heerwagen, and Martin Mador (John Wiley, New York, 2008), pages 59-83. Abstract: The human mind is split between genetically-structured neural systems, and an internally-generated worldview. This split occurs in a way that can elicit contradictory mental processes for our actions, and the interpretation of our environment. Part of our perceptive system looks for information, whereas another part looks for meaning, and in so doing gives rise to cultural, philosophical, and ideological constructs. Architects have come to operate in this second domain almost exclusively, effectively neglecting the first domain. By imposing an artificial meaning on the built environment, contemporary architects contradict physical and natural processes, and thus create buildings and cities that are inhuman in their form, scale, and construction. A new effort has to be made to reconnect human beings to the buildings and places they inhabit. Biophilic design, as one of the most recent and viable reconnection theories, incorporates organic life into the built environment in an essential manner. Extending this logic, the building forms, articulations, and textures could themselves follow the same geometry found in all living forms. Empirical evidence confirms that designs which connect humans to the lived experience enhance our overall sense of wellbeing, with positive and therapeutic consequences on physiology.
    [Show full text]
  • Open Source Architecture, Began in Much the Same Way As the Domus Article
    About the Authors Carlo Ratti is an architect and engineer by training. He practices in Italy and teaches at the Massachusetts Institute of Technology, where he directs the Senseable City Lab. His work has been exhibited at the Venice Biennale and MoMA in New York. Two of his projects were hailed by Time Magazine as ‘Best Invention of the Year’. He has been included in Blueprint Magazine’s ‘25 People who will Change the World of Design’ and Wired’s ‘Smart List 2012: 50 people who will change the world’. Matthew Claudel is a researcher at MIT’s Senseable City Lab. He studied architecture at Yale University, where he was awarded the 2013 Sudler Prize, Yale’s highest award for the arts. He has taught at MIT, is on the curatorial board of the Media Architecture Biennale, is an active protagonist of Hans Ulrich Obrist’s 89plus, and has presented widely as a critic, speaker, and artist in-residence. Adjunct Editors The authorship of this book was a collective endeavor. The text was developed by a team of contributing editors from the worlds of art, architecture, literature, and theory. Assaf Biderman Michele Bonino Ricky Burdett Pierre-Alain Croset Keller Easterling Giuliano da Empoli Joseph Grima N. John Habraken Alex Haw Hans Ulrich Obrist Alastair Parvin Ethel Baraona Pohl Tamar Shafrir Other titles of interest published by Thames & Hudson include: The Elements of Modern Architecture The New Autonomous House World Architecture: The Masterworks Mediterranean Modern See our websites www.thamesandhudson.com www.thamesandhudsonusa.com Contents
    [Show full text]
  • Wiki As Pattern Language
    Wiki as Pattern Language Ward Cunningham Cunningham and Cunningham, Inc.1 Sustasis Foundation Portland, Oregon Michael W. Mehaffy Faculty of Architecture Delft University of Technology2 Sustasis Foundation Portland, Oregon Abstract We describe the origin of wiki technology, which has become widely influential, and its relationship to the development of pattern languages in software. We show here how the relationship is deeper than previously understood, opening up the possibility of expanded capability for wikis, including a new generation of “federated” wiki. [NOTE TO REVIEWERS: This paper is part first-person history and part theory. The history is given by one of the participants, an original developer of wiki and co-developer of pattern language. The theory points toward future potential of pattern language within a federated, peer-to-peer framework.] 1. Introduction Wiki is today widely established as a kind of website that allows users to quickly and easily share, modify and improve information collaboratively (Leuf and Cunningham, 2001). It is described on Wikipedia – perhaps its best known example – as “a website which allows its users to add, modify, or delete its content via a web browser usually using a simplified markup language or a rich-text editor” (Wikipedia, 2013). Wiki is so well established, in fact, that a Google search engine result for the term displays approximately 1.25 billion page “hits”, or pages on the World Wide Web that include this term somewhere within their text (Google, 2013a). Along with this growth, the definition of what constitutes a “wiki” has broadened since its introduction in 1995. Consider the example of WikiLeaks, where editable content would defeat the purpose of the site.
    [Show full text]
  • Enterprise Integration Patterns Introduction
    Enterprise Integration Patterns Gregor Hohpe Sr. Architect, ThoughtWorks [email protected] July 23, 2002 Introduction Integration of applications and business processes is a top priority for many enterprises today. Requirements for improved customer service or self-service, rapidly changing business environments and support for mergers and acquisitions are major drivers for increased integration between existing “stovepipe” systems. Very few new business applications are being developed or deployed without a major focus on integration, essentially making integratability a defining quality of enterprise applications. Many different tools and technologies are available in the marketplace to address the inevitable complexities of integrating disparate systems. Enterprise Application Integration (EAI) tool suites offer proprietary messaging mechanisms, enriched with powerful tools for metadata management, visual editing of data transformations and a series of adapters for various popular business applications. Newer technologies such as the JMS specification and Web Services standards have intensified the focus on integration technologies and best practices. Architecting an integration solution is a complex task. There are many conflicting drivers and even more possible ‘right’ solutions. Whether the architecture was in fact a good choice usually is not known until many months or even years later, when inevitable changes and additions put the original architecture to test. There is no cookbook for enterprise integration solutions. Most integration vendors provide methodologies and best practices, but these instructions tend to be very much geared towards the vendor-provided tool set and often lack treatment of the bigger picture, including underlying guidelines and principles. As a result, successful enterprise integration architects tend to be few and far in between and have usually acquired their knowledge the hard way.
    [Show full text]
  • Design Patterns Promote Reuse
    Design Patterns Promote Reuse “A pattern describes a problem that occurs often, along with a tried solution to the problem” - Christopher Alexander, 1977 • Christopher Alexander’s 253 (civil) architectural patterns range from the creation of cities (2. distribution of towns) to particular building problems (232. roof cap) • A pattern language is an organized way of tackling an architectural problem using patterns Kinds of Patterns in Software • Architectural (“macroscale”) patterns • Model-view-controller • Pipe & Filter (e.g. compiler, Unix pipeline) • Event-based (e.g. interactive game) • Layering (e.g. SaaS technology stack) • Computation patterns • Fast Fourier transform • Structured & unstructured grids • Dense linear algebra • Sparse linear algebra • GoF (Gang of Four) Patterns: structural, creational, behavior The Gang of Four (GoF) • 23 structural design patterns • description of communicating objects & classes • captures common (and successful) solution to a category of related problem instances • can be customized to solve a specific (new) problem in that category • Pattern ≠ • individual classes or libraries (list, hash, ...) • full design—more like a blueprint for a design The GoF Pattern Zoo 1. Factory 13. Observer 14. Mediator 2. Abstract factory 15. Chain of responsibility 3. Builder Creation 16. Command 4. Prototype 17. Interpreter 18. Iterator 5. Singleton/Null obj 19. Memento (memoization) 6. Adapter Behavioral 20. State 21. Strategy 7. Composite 22. Template 8. Proxy 23. Visitor Structural 9. Bridge 10. Flyweight 11.
    [Show full text]
  • From a Pattern Language to a Field of Centers and Beyond Patterns and Centers, Innovation, Improvisation, and Creativity
    From a Pattern Language to a Field of Centers and Beyond Patterns and Centers, Innovation, Improvisation, and Creativity Hajo Neis Illustration 1: University of Oregon in Portland Downtown Urban Campus The Campus is located in downtown Portland in adapted old warehouse buildings, and was first designed in the Oregon pattern language method with the principles of pat- terns and user participation. The White Stag building facilities are open since 2009. 144 Hajo Neis INTRODUCTION What we call now the ›overall pattern language approach‹ in architecture, urban design, and planning has grown from its original principle of ›pattern and pat- tern language‹ into a large and solid body of theory and professional work. To- day, pattern theory and practice includes a large number of principles, methods, techniques and practical project applications in which patterns themselves play a specific part within this larger body of knowledge. Not only has the pattern lan- guage approach grown in its original area of architecture, but it has also (though less triumphantly than silently) expanded into a large number of other disciplines and fields, in particular computer and software science, education, biology, com- munity psychology, and numerous practical fields. Nevertheless, we first have to acknowledge that the pattern approach originally started with a single principle almost 50 years ago, the principle of pattern and pattern language that gave the name to this school of thought and practical professional project work. In this article we want to trace some of the theoretical and practical develop- ment of the pattern method and its realization in practical projects. We want to explore how challenges and opportunities resulted in the adaptation of the pattern language method into various forms of pattern project formats and formulations including ›pattern language‹ and ›project language.‹ We want to look at various forms of innovations and techniques that deal with theoretical improvements as well as the necessities of adaptation for practical cases and projects.
    [Show full text]
  • Analysis Patterns.Pdf
    Symbols for mappings DLKING , : www.dlking.com Generalization notation DLKING , : www.dlking.com Contents Foreword v Foreword vii Preface xv Chapter 1. Introduction 1 1.1 Conceptual Models 1 1.2 The World of Patterns 4 1.3 The Patterns in this Book 8 1.4 Conceptual Models and Business Process Reengineering 10 1.5 Patterns and Frameworks 11 1.6 Using the Patterns 11 References 14 Part 1. Analysis Patterns 15 Chapter 2. Accountability 17 2.1 Party 18 2.2 Organization Hierarchies 19 2.3 Organization Structure 21 2.4 Accountability 22 2.5 Accountability Knowledge Level 24 2.6 Party Type Generalizations 27 2.7 Hierarchic Accountability 28 2.8 Operating Scopes 30 2.9 Post 32 References 33 Chapter 3. Observations and Measurements 35 3.1 Quantity 36 3.2 Conversion Ratio 38 3.3 Compound Units 39 3.4 Measurement 41 3.5 Observation 42 3.6 Subtyping Observation Concepts 46 3.7 Protocol 46 3.8 Dual Time Record 47 IX DLKING , : www.dlking.com x Contents 3.9 Rejected Observation 48 3.10 Active Observation, Hypothesis, and Projection 49 3.11 Associated Observation 50 3.12 Process of Observation 51 References 55 Chapter 4. Observations for Corporate Finance 57 4.1 Enterprise Segment 59 4.2 Measurement Protocol 65 4.3 Range 76 4.4 Phenomenon with Range 77 4.5 Using the Resulting Framework 82 References 83 Chapter 5. Referring to Objects 85 5.1 Name 86 5.2 Identification Scheme 88 5.3 Object Merge 90 5.4 Object Equivalence 92 References 93 Chapter 6.
    [Show full text]
  • Pedagogical and Elementary Patterns Patterns Overview
    Pedagogical and Elementary Patterns Overview Patterns Joe Bergin Pace University http://csis.pace.edu/~bergin Thanks to Eugene Wallingford for some material here. Jim (Cope) Coplien also gave advice in the design. 11/26/00 1 11/26/00 2 Patterns--What they DO Where Patterns Came From • Capture Expert Practice • Christopher Alexander --A Pattern Language • Communicate Expertise to Others – Architecture • Solve Common Recurring Problems • Structural Relationships that recur in good spaces • Ward Cunningham, Kent Beck (oopsla ‘87), • Vocabulary of Solutions. Dick Gabriel, Jim Coplien, and others • Bring a set of forces/constraints into • Johnson, Gamma, Helm, and Vlisides (GOF) equilibrium • Structural Relationships that recur in good programs • Work with other patterns 11/26/00 3 11/26/00 4 Patterns Branch Out Patterns--What they ARE • Software Design Patterns (GOF...) •A Thing • Organizational Patterns (XP, SCRUM...) • A Description of a Thing • Telecommunication Patterns (Hub…) • A Description of how to Create the Thing • Pedagogical Patterns •A Solution of a Recurring Problem in a • Elementary Patterns Context – Unfortunately this “definition” is only useful if you already know what patterns are 11/26/00 5 11/26/00 6 Patterns--What they ARE (2) Elements of a Pattern • Structural relationships between •Problem components of a system that brings into • Context equilibrium a set of demands on the system •Forces • A way to generate complex (emergent) •Solution behavior from simple rules • Examples of Use (several) • A way to make the world a better place for humans -- not just developers or teachers... • Consequences and Resulting Context 11/26/00 7 11/26/00 8 Exercise Exercise • Problem: Build a stairway up a castle tower • Problem: Design the intersection of two or • Context: 12th Century Denmark.
    [Show full text]
  • Pattern Languages in HCI: a Critical Review
    HUMAN–COMPUTER INTERACTION, 2006, Volume 21, pp. 49–102 Copyright © 2006, Lawrence Erlbaum Associates, Inc. Pattern Languages in HCI: A Critical Review Andy Dearden Sheffield Hallam University Janet Finlay Leeds Metropolitan University ABSTRACT This article presents a critical review of patterns and pattern languages in hu- man–computer interaction (HCI). In recent years, patterns and pattern languages have received considerable attention in HCI for their potential as a means for de- veloping and communicating information and knowledge to support good de- sign. This review examines the background to patterns and pattern languages in HCI, and seeks to locate pattern languages in relation to other approaches to in- teraction design. The review explores four key issues: What is a pattern? What is a pattern language? How are patterns and pattern languages used? and How are values reflected in the pattern-based approach to design? Following on from the review, a future research agenda is proposed for patterns and pattern languages in HCI. Andy Dearden is an interaction designer with an interest in knowledge sharing and communication in software development. He is a senior lecturer in the Com- munication and Computing Research Centre at Sheffield Hallam University. Janet Finlay is a usability researcher with an interest in design communication and systems evaluation. She is Professor of Interactive Systems in Innovation North at Leeds Metropolitan University. 50 DEARDEN AND FINLAY CONTENTS 1. INTRODUCTION 2. THE SCOPE OF THIS REVIEW 2.1. General Software Design Patterns 2.2. Interface Software Design Patterns 2.3. Interaction Design Patterns 3. A SHORT HISTORY OF PATTERNS 3.1.
    [Show full text]
  • The Origins of Pattern Theory: the Future of the Theory, and the Generation of a Living World
    www.computer.org/software The Origins of Pattern Theory: The Future of the Theory, and the Generation of a Living World Christopher Alexander Vol. 16, No. 5 September/October 1999 This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder. © 2006 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. For more information, please see www.ieee.org/portal/pages/about/documentation/copyright/polilink.html. THE ORIGINS OF PATTERN THEORY THE FUTURE OF THE THEORY, AND THE GENERATION OF A LIVING WORLD Christopher Alexander Introduction by James O. Coplien nce in a great while, a great idea makes it across the boundary of one discipline to take root in another. The adoption of Christopher O Alexander’s patterns by the software community is one such event. Alexander both commands respect and inspires controversy in his own discipline; he is the author of several books with long-running publication records, the first recipient of the AIA Gold Medal for Research, a member of the Swedish Royal Academy since 1980, a member of the American Academy of Arts and Sciences, recipient of dozens of awards and honors including the Best Building in Japan award in 1985, and the American Association of Collegiate Schools of Architecture Distinguished Professor Award.
    [Show full text]
  • Frontiers of Pattern Language Technology
    Frontiers of Pattern Language Technology Pattern Language, 1977 Network of Relationships “We need a web way of thinking.” - Jane Jacobs Herbert Simon, 1962 “The Architecture of Complexity” - nearly decomposable hierarchies (with “panarchic” connections - Holling) Christopher Alexander, 1964-5 “A city is not a tree” – its “overlaps” create clusters, or “patterns,” that can be manipulated more easily (related to Object-Oriented Programming) The surprising existing benefits of Pattern Language technology.... * “Design patterns” used as a widespread computer programming system (Mac OS, iPhone, most games, etc.) * Wiki invented by Ward Cunningham as a direct outgrowth * Direct lineage to Agile, Scrum, Extreme Programming * Pattern languages used in many other fields …. So why have they not been more infuential in the built environment??? Why have pattern languages not been more infuential in the built environment?.... * Theory 1: “Architects are just weird!” (Preference for “starchitecure,” extravagant objects, etc.) * Theory 2: The original book is too “proprietary,” not “open source” enough for extensive development and refinement * Theory 3: The software people, especially, used key strategies to make pattern languages far more useful, leading to an explosion of useful new tools and approaches …. So what can we learn from them??? * Portland, OR. Based NGO with international network of researchers * Executive director is Michael Mehaffy, student and long-time colleague of Christopher Alexander, inter-disciplinary collaborator in philosophy, sciences, public affairs, business and economics, architecture, planning * Board member is Ward Cunningham, one of the pioneers of pattern languages in software, Agile, Scrum etc., and inventor of wiki * Other board members are architects, financial experts, former students of Alexander Custom “Project Pattern Languages” (in conventional paper format) Custom “Project Pattern Languages” create the elements of a “generative code” (e.g.
    [Show full text]