Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • daviding 9:01 pm on September 16, 2014 Permalink | Reply
    Tags: design patterns,   

    2014/09/16 08:45 Ralph Johnson “Root causes analysis of some faults in Design Patterns” at PLoP2014

    Plenary talk at Pattern Languages of Programs Conference, Allerton Park, Monticello, Illinois

    This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

    About 40 participant in the room, laid out classroom style with a large screen projector

    Why Design Patterns gives bad advice?

    • 1. Time has changed? or
    • 2. Should have known better in 1994, but we had a lot of reviewers back then

    Had a workshop on Singleton pattern

    • It’s one of the most misused patterns
    • In early days, was shocked what people did with Singleton, people would say they used it 40 times
    • Singleton is about global state, protecting yourself against global state, you don’t want to have much of that
    • How could all of these people read the book, and completely misunderstand?  This is why we write tests in programming
    • This isn’t people how just use the pattern

    Focus on Observer pattern (because didn’t get time to do other ones, may not use all of slides, will give talk again in a few days)

    • A one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically
    • First named it as dependency, don’t remember how the name changed

    Observer diagram:

    • Think of bank robbers, with an FBI agent who is observing to see if they’re going to rob a bank
    • Bank robbers hope there aren’t any FBI agents, but don’t really know
    • Subject and observer (not typically called observable and observer)
    • Subject can addDependent:, removeDependent: and changed:
    • Observer can update:
    • Subject will have a list of observers, but loose coupling
    • Subject class doesn’t depend on FBIAgent class, but do have pointers from Subject class to Observer, and from FBIAgent to Observer
    • It means every Mobster is carrying around a list of agents with him (not like real life, it’s the way programming is done)

    Pattern has:

    • Registration: often the hardest bugs to find, as forget to register or deregister something
    • Notification:  could be tricky to find bugs
    • Update (which requires most code):  bugs are easy to find and fix

    Code example from the book

    • class Subject
    • class Observer {
    • public:  virtual ~Observer …
    • private ….

    In Java, they’re called Listeners, not Observers, code is different

    • The argument to update is better defined, always as an event that changes
    • There are subclasses of types of events, and EventListeners, each with own interface
    • An EventListener can have more than one interface, e.g. Swing ComponentListener has componentResized, componentMoved, componentShown, componentHidden

    Did we give hints in the book?

    • Did we do this in Smalltalk? Yes, but we didn’t do it all in Smalltalk.  There wasn’t events, but passed strings
    • Avoiding observer-specific update protocols:  the push and pull models.  Pass more information.
    • Pull means don’t send much information, let the observer ask for more information
    • Push means observer gets more information
    • Push assumes subject knows more about observier’s needs
    • The push model makes observer less reusable.  ?? Not really?  If you had a mouse event, it can’t do much, it moves and button up and down.  Everything you want to know about the mouse is in the event.  But listener interface is Java is simple, everything is push.  Then observer would become more reusable.  So this published statement is WRONG.

    We were writing up to our limits of understanding, without having looked at enough users.

    • Every paper here tries to generalized, but don’t know how dangerous could be

    We had Java listeners and tried to figure out how we missed that


    • Push model could make observers MORE reusable, by having specialized observer interfaces for particular kind of changes, e.g. mouse events
    • VisualWorks did this, it didn’t implement fully because Smalltalk is dynamically bound

    Thus, shows how we missed

    • Java shows, in that they use library names that were written having read the Design Patterns
    • Had observer pattern in Java, but then changed to listener
    • Smalltalk is dynamically typed, but in C++ everyone would build own observer pattern, as no library at that time
    • Requirement of wanting reuse, static typing
    • Event bit was a good idea, not sure it hadn’t been done in systems before

    Another idea missed:  Data binding

    • Talking with Erich Gamma, about how this is a lot about the observer pattern
    • Erich though data binding was about not having a big monolithic model, but wanting to break up into smaller pieces
    • Can observe a piece
    • Observing a whole object will be big and complicated
    • Will tend to have smaller and more usable interfaces
    • Select from a list, some things will change, and the selection will change
    • This gets away from explicitly having to send events: say there’s an event, and the property change will magically happen
    • If have observables (model) change then the observers (view) will change
    • Called data binding, but are setting up the observer interface


    • Don’t have to invoke update events explicitly
    • Observers can be reused
    • Main benefit is if there is a library, (which is less in C++ before there were libraries)

    Not everything can be done this way

    Use of Mediator with Observers

    • Libraries take care of easy things in event handling, and then have to still do hard stuff with the Java libraries
    • Have the mediator handle all of the special events
    • In VisualWorks, it was called the application model

    The book says that Mediator is related to Observer, but if you read the details, it says something else

    • If you change this object, you want to update this other one, and then you need a constraint manager, and figure out how to broadcast this
    • Most people are doing simpler things than this, but this is what was required in the graphical editors that John and Ralph were doing

    Use of Adapter with Observer

    • When listening to two different things
    • If different, e.g. action listener for buttons
    • Two buttons –> two listeners –> two inner classes
    • Convert ActionPerformed into the name you really want:  an adapter
    • Then when have more listening interfaces, you get this event, but you have a library that wants to use something different, then have an adapter

    Book doesn’t talk about either of those

    Observer is a piece of MVC

    • In book, say that MVC is a composite of views
    • MVC is a strategy
    • MVC uncouples?  Observer more uncouples.  It’s not about taking a big object and breaking it up into small objects
    • It says build standard observables
    • A toolkit of pieces, binding them together
    • Observer could be used with a big object, which tells you changes in the 57 different ways
    • Model – View – Controller, for a Smalltalk program, Controller isn’t in between the Model and the View, although frameworks for web tend to do it this way

    People tend to be lumpers or splitters

    • Ralph is a lumper
    • George Lakoff in Fire, Dangerous Things talks about how people make distinctions, e.g. chairs, some with wheels, they have four legs, if it has 3 legs, when do you start calling it a stool; if they’re mounted on a rail and can’t move it, is it chair?  As you move farther from the ideal, is the same thing, or do you need a new name?

    Iterator pattern

    • Idea wasn’t to ask for the next item
    • Object has a lot of structure, ask it to come back with an iterator as an object class
    • Simple, you could do a fork
    • Book writes about internal iterators and external iterators, for closure
    • For each and do
    • If you have closures, you will do a lot of iterations:  Smalltalk, Groovy
    • In Groovy, have collect, findAll
    • Can define on streams, not just on collections
    • Standard Smalltalk libraries don’t have streams
    • Didn’t talk about this in the book, should have
    • Javascript has map and filter

    The book didn’t say

    • A Stream is a kind of iterator (wasn’t it obvious?)
    • You can define map, filter and reduce on your iterators.  If you language has closures, you should (although it’s pain, so often people don’t do it)

    Reactive programming:  Iterator meets Observer

    • This could be what Rebecca was saying about Javascript
    • Think of a “subject” as an EventStream, then an Observer is a function on EventStream (maybe it produces a display)
    • It eliminates the need to keep state to synchronize different event streams
    • Makes error handling easier
    • Reduces memory leaks

    Asynchronous streams:

    • concatAll
    • Not deterministic, don’t know how long it will take to get to the end of the list

    Mouse Drags Collection

    • Ask an element for a stream of mouse down events
    • For each mouse down event, tell the document (that has mouse moves) to take mouse moves until the mouse up event
    • Gives a list of mouse movements, then concatAll of them gives mouse movement locations, so image is moved to a stream of locations

    There’s a library, search on “reactive extensions”

    When you treat a set of observables over a stream of events, you eliminate the need to write mediators, solves problems with race conditions

    Things that didn’t talk about in the book

    • Listener, didn’t think about that 20 years ago
    • Should have talked about events, as having event-objects, people were doing that but didn’t know it was interesting
    • More concerned about push versus pull and seeing that it wasn’t true
    • Just getting into looking at relationships between patterns, that could have happened if had another six months, but had a deadline
    • World has moved on
    • Interesting trying to get a handle at a point of time
    • Lisp people said they’ve done that, but book isn’t the only place where Lisp people have been ignored.
  • daviding 10:01 am on September 16, 2014 Permalink | Reply
    Tags: , programming, simplicity   

    2014/09/15 19:20 Dave Thomas, “Simplicity — The Road Not Taken”, PLoP 2014

    Plenary address by Dave Thomas Bedarra Research, at Pattern Languages of Programs 2014, Allerton Park Retreat Centre, Monticello, Illinois

    This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

    About 40 participant in the room, laid out classroom style with a large screen projector

    Arthur Whitney, A+ APL follow-on, then wrote core of interpreter for J in C, then used it in K

    • From Crista’s talk in the morning, this is a text editor in K


    • All on one screen
    • It would be nicer if could read the 1000 lines of Emacs
    • Complexity is relative

    Biased towards things that are short, even if they’re harder to understand

    • How to make things literate?
    • If you get into functional programming, or expression languages, could think about polishing it and make it smaller

    Immersed in the cloud

    • If you want to do any application today, you have to learn a new vocabulary, with some deep semantics (like why the don’t work).
    • They’re unstable
    • Benchmarks are bogus

    Lost on Planet Big data

    • Sparql benchmarks are bogus

    Web Next Open Force versus Walled Gardens

    Alien Languages:  take a lot to learn, accidental complexity

    Lush Plants with very thin process atmosphere

    • Wonder why normal people can’t write programs
    • Most programmers can’t talk to each other

    Everything Loosely Connected and Mobile

    Jurassic Software?

    • Prehistoric SaaS: Mainframes with simple productive 4GLs
    • Unix, Client-Server, Relatoinal
    • Naive Simplicity:  PC, spreadsheets
    • Absurd complexity

    What legacy space junk will be out there?

    • They keep changing langagues

    Phil Lester, HCI:  Complexity of Technology

    • Above line, too complex for people
    • Then have accidnetal complexity by people who don’t document and implement incorrectly

    The darker side of objects:  why people shouldn’t use objects

    • (Not enough time to talk about today)

    Simplicity, the road not taken?

    • We don’t seem to  hit a limit
    • We hope we can find a new language, a new expression

    The more things change, the more IT stays the same

    • Still CRUD Create – Read – Update – Delete
    • Why?

    Have a business process, make a computer process

    • But then people found out a transaction wasn’t as simple as originally thought

    IT is still CRUD, Workflow and Data

    • Inputs and Outputs
    • Workflow
    • Event/Actions: Event – state tables
    • Rules/Actions: Decision tables (rules engines)
    • Complex Calculations:  lots of people run their businesses on spreadsheets, but then get agile programmers who will need to as a product owner to write story cards, maybe write tests that have as much code as the program
    • Data and Relationships:  have been in denial to say shouldn’t have data models, only object models, which created bloatware, there are a lot of things that have only data, no state, so don’t need garbage collection

    IT 4.0?

    • Challenge of IT 3.0

    Should ship less code

    • The more code you have, the more there is to maintain
    • Written by a lot of people, then there’s a lot not understood
    • Poor refactoring tools

    Either we make magic tools, or try to figure out how to not makes things so complicated

    • Get rid of dependencies when we can
    • More memory means that we don’t have to fight for resources so much

    Abstraction bloat:

    • Framework is a promise that you won’t maintain

    Use less objects and less code

    • Table-driven programming:  rules as decision table; calculation as spreadsheet; data validation as domain and range table; mapping as lookup table; flow as data – work flow – message; events and matches as state table; processes and reports as input-output tables; acceptance criteria as BDD; domain models as entity-attribute dictionary
    • Enable customer self-service:  atom feeds vs. APIs; query vs. custom; expose scriptable services; self-described data (not JSON)

    The legacy of JSON will be worse than the legacy of XML

    Table Driven Programming is a lost art

    • Years of use, but not taught anywhere
    • Might show you a state machine, but not a complicated one

    Reduce integration time and dollars

    • Avoid slow and complex APIs
    • Should just federate from the data, rather than objectifying everything
    • Most stable thing is physical disk pages, can just get them off Oracle drive
    • Make read-only SQL replicas for fast reporting
    • Put Atom/RSS feeds on legacy / partner system for journal files and events (rather than having a team write Java queries)
    • REST and JSONify your service
    • Use ODBC as a simple interface to complex server systems, so anyone call pull data out of legacy systems

    Script to save time and money

    Loose coupling:

    • Data Flow
    • Structured Analysis and Design SADT used to be sequential
    • J. Paul Morrison convinced Japanese banks that could build a system with flow base programming, spinning up processes and have things flow between them, so the process model and the flow are the same
    • Hewitt Actors
    • Spreadsheets
    • Erlang
    • Messaging

    Enabling loose coupling

    • All APIs are value based and where possible stateless
    • Keep data, and don’t mutate
    • Occasionally disconnected with replication and sync
    • Simple implementations using coroutines
    • Functional Programming thinking encourages value orientation and composition, instead of working with pointers and mutating states

    The future of programming is query?

    • Historical views of programs
    • Program as procedures + data structures
    • Program as process + data flows
    • Program as expressions + constraints
    • Program as logic + control
    • Program as messages + object/actors
    • Program as pure functions + actions
    • Programs will be query + action (SQL plus functions)

    Collection oriented programming

    • Instead of building a new abstraction, working with old collections
    • Most object programs don’t have naked collections, they’re enclosed inside something else
    • May be easier to run on multiple cores
    • Favourites J and Clojure

    Let the hardware do the work!

    • Hardware is faster
    • Programmers are slower
    • When you have all of the data in memory, things are easier (which isn’t possible in Java, because of limited heap size)
    • Could work with 6TB of RAM
    • Next few years, will to go 20 to 30TB of RAM, easier to keep a small program in cache to manage resources
    • Data conversion and translation is cheap
    • Data compression and encryption is free on multicore, because they’re sitting there doing nothing
    • Haswell and Ivy Bridge find it faster to send messages between cores
    • Problem isn’t multiprocessing, it’s what’s in the cache
    • Latest Intel chips have 5 levels of cache, tricky for people to use them
    • Can execute Excel spreadsheets rapidly
    • Have your program live in the data for an accelerated experience

    Enable self-service

    Business app development

    • Some pioneering:  IBM QEDWiki, Yahoo Pipes, Google Mashup Editor, Dabble DB
    • If could kill off programmers who hate anything visual

    Live programming in a browser

    Could use Scratch to do functional vector programming, so know working on right shape

    If we could find ways to express in smaller amounts of code (e.g. visual), we could comprehend it, or at least introspect and look at it

    • Days of making complicated data structures over
    • Freedom, people can do things on a 1TB box with a thousand cores
    • Can build things that end users can live in
    • Can write queries visually
  • daviding 4:54 pm on September 15, 2014 Permalink | Reply
    Tags: , , programming style   

    2014/09/15 09:00 Cristina Videiera Lopes, “Exercises in Programming Style”, PLoP 2014

    Plenary address @cristalopes at Pattern Languages of Programs 2014, Allerton Park Retreat Centre, Monticello, Illinois

    This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

    About 20 participant in the room, laid out classroom style with a large screen projector

    Icons:  Art History, Simplified

    • Can recognize Dali style paintings

    Have programming styles

    • Ways of expressing tasks
    • Fractal, see in programs, organization, all scales
    • Frozen in programming languages, sense of convention in syntax, forcing people to think in a way:  programming paradigms

    Teaching advanced programming, students have a shallow understanding based in the languages they learned

    • How to teach?

    Raymond Queneau, Exercises in Style

    • Starts with trivial stories, tells 99 versions of the same story
    • Inquisitive approach, dreamy approach, etc.
    • Gives titles to each style, maybe not translated in the best way from the original French

    Oulipo’s styles

    • Based on constraints, that generate creativity
    • To start from the blank page, start from a constraint
    • “A Void” (La Disparition) by Georges Perec:  has a feeling like something is missing, it doesn’t use the letter “e”, so can’t use the natural word

    Computational approach, term frequency

    • Eliminate words like software
    • Normalize to lower case
    • List more frequently-occurring words
    • e.g. Pride and Prejudice, mr 796, elizabeth 6358, very 488, darcy 418

    First named as style #1, etc., because would get attacked on name, then put the names back in publishing the book

    Example with lots of ifs: what are the constraints?

    • No abstraction
    • No use of library functions
    • Monolithic style
    • Diagram:  control flow is overbearing
    • The language was Python, but would have the same constraints in Java

    Style #2, 6 lines of code

    • Code golf style, either fewest lines or fewest characters, comes from APL
    • As few lines of code of possible
    • “Try Hard”

    Style #3: 1.5 pages

    • Procedural abstraction
    • Shared state
    • Series of commands
    • Cook book style:  first sugar, then add other ingredients

    Style #4 seems almost identical, but different

    • Functional abstraction, think in terms of math
    • No shared state
    • Functional composition f o g
    • Pipeline style, chain one thing after the other (a fixed pipeline)

    Style #5

    • Like Javascript and Node, a functional form of goto
    • Functions take one additional parameter, f, call at the end
    • Kick forward style

    Style #6

    • Things, things and more things, capsules of data and procedures
    • Data is never accessed directly
    • Capsules can reappropriate procedures from other capsules
    • Kingdom of nouns style

    Style #7

    • Similar to #6
    • Capsules receives messages via single receiving procedure

    Style #8:  concurrency

    • Like Mapreduce, can parallelize
    • Hadoop has another map on the reduce function, then have many partial solutions
    • Two key abstractions, mapping of chunks and reducing to results

    Style #9:  not just counting words, extract more knowledge

    • Entities and relations between them
    • Query engine, with declarative queries
    • Persistent table style

    Take aways:

    • There are many ways to solve problems
    • Constraints are important for communication
    • Don’t be a hostage of one way of doing things
  • daviding 11:31 am on June 19, 2014 Permalink | Reply
    Tags: mobile, sms, virgin   

    Phoned @VirginMobileCan to confirm “SMS center” on phone is +1438276200 on Android 4.04 Motorola Razr V. Was mystified on what to “Set short message service number”. Backed up by

  • daviding 3:18 pm on June 13, 2014 Permalink | Reply
    Tags: cringely,   

    “The Decline and Fall of IBM” | Robert Cringely | June 2014 

    Quick read of “The Decline and Fall of IBM” by Robert Cringely, downloadable as Mobi, epub or PDF for $3.99USD from , or from Amazon on a Kindle in the U.S. or on a Kindle in Canada.

    The body of the book is relatively short. In PDF formatting, the content is as follows …

    p. 007: Preface
    p. 009: Introduction
    p. 013: Chapter 01: Good Old IBM
    p. 018: Chapter 02: Lou Gerstner Saves IBM for AWhile
    p. 028: Chapter 03: Sam Palmisano and the Long Con
    p. 033: Chapter 04: Why Big Companies Can’t Change
    p. 039: Chapter 05: LEAN AND Mean
    p. 048: Chapter 06: ‘Death March 2015′
    p. 054: Chapter 07: A Tale of Two Division Sales
    p. 057: Chapter 08: Financial Engineering
    p. 061: Chapter 09: An IT Labor Economics Lesson from Memphis for IBM
    p. 066: Chapter 10: The Ginni Paradox or How to Fix IBM
    p. 077: Afterword: What if Ginni Doesn’t Listen?
    p. 078: Comments from Readers (On Cringely Blogs from 2007-2013)
    p. 229: About the Author

    An (ex-)IBMer who reads Cringely regularly will probably be most interested in Chapter 10.

    These are my ideas for what Ginni Rometty should do as CEO. [p. 66]

    The Hardware Problem:
    Computer technology is becoming more of a commodity, and IBM must learn to become a commodity supplier. [pp. 66-67]
    The Hardware Solution:
    IBM needs to retain and grow its hardware division. The immediate goal should be to return it to break-even performance without any more staff cuts. Next, it needs to realign the business to better serve the market for the next decade. [p. 67]

    The Software Problem:
    Compared to many other software companies, IBM moves like a glacier. [p. 68]
    The Software Solution:
    Product development needs to understand the needs and directions of the customers; it needs to be empowered to design new products and versions that will increase its value to the market; and it needs to be enabled to produce those products and versions quickly and efficiently. [p. 68]

    The Services Problem:
    For the last 10 years, IBM’s Services divisions have been subjected to relentless cost reductions, layoffs, massive offshoring of work, and a scary process of dumbing down the talent. [....] Most of the great processes IBM developed over the years have been lost. [p. 69]
    The Services Solution:
    Global Services should launch a division-wide continuous quality improvement program. Teams should be empowered to find and act on ways to automate the business. [p. 70]

    The Cloud Problem:
    The infrastructure used to provide a Cloud service is much more complex than that of a typical IBM outsourcing account. IBM’s approach of throwing lots of bodies with narrow skills at the problem won’t work with Cloud technology. [p. 71]
    The Cloud Solution:
    Beyond leaving SoftLayer alone, what IBM needs to do to be successful with its Cloud investments is to fix other parts of the company. [....] IBM needs to provide value-added services to its Cloud platform to increase both revenue and profit. [p. 71]

    The Analytics Problem:
    IBM has hopes to make this a service they can offer in the Cloud. That will involve copying most of business data to a database outside the company. [...] The next challenge to a Cloud service is TIME—simple math and physics. [p. 72]
    The Analytics Solution:
    There is exciting work to be done in analytics; I just don’t see IBM positioned to grab a leadership role. There’s no way they’ll achieve their stated goal of making billions from this business. [p. 73]

    The Mobile Problem:
    IBM has completely missed the biggest change in Information Technology in a decade. [p. 73]
    The Mobile Solution:
    IBM should have its own App Store, which would offer customers a way to learn how to use the new mobile platforms. It could provide a way for the application developes to interact with IBM’s customers. Over time IBM could learn and develop mobile technology that is useful to IBM’s customers. [p. 73]

    The great opportunity is to fix the cause of the problem. In most cases, a poor corporate culture delivers decisions that cause quality problems. IBM needs to change its culture and its values. [p. 74]

    Restore Respect:
    IBM needs to start treating its workforce with respect, and as valued members of the corporation. IBM needs to invest in its people and get them working for the company again. [p. 74]

    Near the end of John Akers’ time as CEO … IBM’s divisions needed to operate more effectively. They needed to adapt to the needs of the market, but the corporate management structure was preventing this from happening. This was the exact problem Lou Gerstner found and fixed when he joined IBM. Well, Lou is gone and IBM has reverted back to its old bad habits. [p. 75]

    A New Business Model:
    IBM needs to learn ROI thinking. IBM spends far too much on gold-plating new products and services. IBM gives preference to its more expensive proprietary technology over commodity industry technology every time. Good design and good engineering makes the best use of money. If the commodity stuff works and is the best economic choice, then
    use it. [p. 75]

    A Better Business Goal:
    Lou inherited a financial disaster and made the tough decisions to stabilize the company. His financial decisions were not the ends they were the means. The long-term goal was to align IBM with its customers and the market. That needs to be done again. [p. 76]

    For those interested in IBM, the book is worth $3.99. Cringely is a (well-informed) journalist. He has not, however, ever had a decision-making role inside of IBM, so the analysis comes for an external perspective.

    The introduction for the book was replicated by the author on his blog “The Decline and Fall of IBM” | Robert X. Cringley | June 4, 2014 at at

    The Decline and Fall of IBM:  End of an American Icon?

  • daviding 8:50 am on June 2, 2014 Permalink | Reply  

    Roaming on Nexus 5 in UK @WindMobile finally resolved by @WINDCares over Twitter: With SIM Toolkit enable Roaming Setting .. Reselect Visited Network, then Settings … Mobile Network … manual setting for carrier works. Eight days with no roaming, multiple calls to Wind 1-877 and L3 support callback, and even Google Nexus support. SIM Toolkit wasn’t visible on first calls, may have been installed during wifi session. Phone service will be active for 24 hours before getting on a plane home to Toronto.

  • daviding 9:59 am on April 17, 2014 Permalink | Reply
    Tags: hyper-coordination, micro-coordination, mobile phones, smartphones   

    “Nobody sits at home and waits for the telephone to ring: Micro and hyper-coordination through the use of the mobile telephone” | Rich Ling and Birgitte Yttri (2002) 

    Smartphones have led to micro-coordination where meeting times and places are fluid, and hyper-coordination where in-group discussions can take place.

    … the mobile telephone has resulted in   new forms of interaction. … we have called …   micro coordination and hyper-coordination. These two types of “coordination” have arisen as a result of the wide scale adoption of mobile telephony. [....]

    One of the impacts of mobile telephony is the ability for nuanced, instrumental  coordination. This forms the core of micro coordination. With the use of mobile communication systems, one need not take an agreement to meet at a specific time  and place as immutable. Rather, those meeting have the ability to adjust the agreement as the need arises. In addition, mobile communication systems allow for the redirection of transportation to meet the needs of social groups. This is largely a functional and instrumental activity.

    Moving beyond this, “hyper-coordination” encompasses instrumental coordination and adds two other dimensions to this. The first is the expressive use of the mobile telephone. That is, in addition to the simple coordination of where and when, the device is employed for emotional and social communication. People chat with each  other. The Short Message System (SMS) function is used to send chain letters, and personal messages that can range all the way from innocent and over-sweet greetings to vulgar pornographic images. One sees the integration of the group via the use of the mobile telephone.

    The second aspect of hyper-coordination is the in-group discussion and agreement as  to the proper forms of self-presentation vis-à-vis the mobile telephone. That is, the  type of mobile telephone that is appropriate, the way in which it is carried on the body and the places in which it is used. Thus, hyper-coordination encompasses the instrumental and the expressive use of the mobile telephone as well as strictures regarding the presentation of self. One can see that the mobile telephone provides a type of integration or “coordination” that goes through several dimensions of social life.

    “Nobody sits at home and waits for the telephone to ring: Micro and hyper-coordination through the use of the mobile telephone” | Rich Ling and Birgitte Yttri  (2002) at , formally republished as Ling, R. and Yttri, B. 2002. “Hyper-coordination via mobile phones in Norway.” In Katz, J. and Aakhus, M. (eds.) Perpetual contact: Mobile communication, private talk, public performance. Cambridge University Press, Cambridge.

    Perpetual Contact: Mobile Communication, Private Talk, Public Performance

  • daviding 8:10 pm on April 6, 2014 Permalink | Reply
    Tags: generativity, nature of order, , patterns   

    1996/10/08 Christopher Alexander, “Patterns in Architecture”, OOPSLA ’96 

    Christopher Alexander’s presentation at the 1996 OOPSLA Conference was lightly edited in the 1999 article.  Watching the video and reading the text, the divergences are small until 46 minutes into 63-minutes, when the text was significantly rewritten.

    The digest maps the published 1999 article to the 1996 presentation on video.

    • Alexander, Christopher. 1996. “Patterns in Architecture” presented at OOPSLA ’96, October 8, San Jose, California.
    • Alexander, Christopher. 1999. “The Origins of Pattern Theory: The Future of the Theory, and the Generation of a Living World.” IEEE Software, 16 (5): 71–82. doi:10.1109/52.795104.

    [03:37] In effect, I’m just going to do three things.

    1. Pattern Theory. I’m going to talk first of all about patterns and pattern languages, what I did about that, a few little points about problems we encountered, why we did it, how we did it, and so forth. That is a historical survey referring back to the late ’60s and early ’70s.

    2. The Nature of Order. Then, I’m going to summarize the theoretical framework which has evolved out of the pattern work: a framework which is about to be published in a series of four books collectively called The Nature of Order, four books that will be put out by Oxford University Press in the year 2000. That framework is a fairly radical departure from what the pattern language in the earlier theories contained, although it is consistent with them.  [....]

    [04:50] [3. What the Future Holds in Store: The Generativity Problem and the Generation of a Living World]  [....]

    [06:00] All of my life I’ve spent trying to learn how to produce living structure in the world. That means towns, streets, buildings, rooms, gardens, places which are themselves living or alive. My assumption here — a sad one — is that for the most part what we have been doing for ourselves, at least during the last 50 years or so, perhaps starting somewhere around World War II, has virtually no ability to produce that kind of living structure in the world. This living structure which is needed to sustain us and nurture us and which did exist to some degree in the traditional societies and in rural communities and in early urban settlements has disappeared. It is drastically gone. We don’t know how to create it or generate it any more.


    Pattern Theory

    [08:30] The [initial] idea that materialized in the published pattern language was first of all, of course, intended just to get a handle on some of the physical structures that make the environment nurturing for human beings. And, secondly, it was done in a way that would allow this to happen on a really large scale. And, what I mean by that is that we wanted to generate the environment indirectly, just as biological organisms are generated, indirectly, by a genetic code.

    Architects themselves build a very, very small part of the world. Most of the physical world is built by just all kinds of people. It is built by developers, it is built by do-it-yourselvers in Latin America. It is built by hotel chains, by railroad companies, etc., etc.

    How could one possibly get a hold of all the massive amount of construction that is taking place on Earth and, somehow, make it well, that means let it be generated in a good fashion and a living fashion?

    This decision to use a genetic approach was not only because of the scale problem. It was important from the beginning, because one of the characteristics of any good environment is that every part of it is extremely highly adapted to its particularities. That local adaptation can happen successfully only if people (who are locally knowledgeable) do it for themselves.

    In traditional society where lay people either built or laid out their own houses, their own streets, and so on, the adaptation was natural. It occurred successfully because it was in the hands of the people that were directly using the buildings and streets.  So, with the help of the shared pattern languages which existed in traditional society, people were able to generate a complete living structure.

    [10:40] In our own time, the production of environment has gone out of the hands of people who use the environment. So, one of the efforts of the pattern language was not merely to try and identify structural features which would make the environment positive or nurturing, but also to do it in a fashion which could be in everybody’s hands, so that the whole thing would effectively then generate itself.

    What, now, of my evaluation of what you are doing with patterns in computer science?


    [12:30] The pattern language that we began creating in the 1970s had other essential features.

    First, it has a moral component.

    Second, it has the aim of creating coherence, morphological coherence in the things which are made with it.

    And third, it is generative: it allows people to create coherence, morally sound objects, and encourages and enables this process because of its emphasis on the coherence of the created whole.

    [12:40] I don’t know whether these features of pattern language have yet been translated into your discipline.

    Take the moral component, for example. In the architectural pattern language there is, at root, behind the whole thing, a constant preoccupation with the question, Under what circumstances is the environment good?

    In architecture that means something. It means something important and vital that goes, ultimately, to the nature of human life. [....]  The moral preoccupation with the need for a good environment, and for the living structure of built environment, and the objective nature of that question, is largely accepted. [....]

    … I have no idea whether the search for something that helps human life is a formal part of what you are searching for. Or are you primarily searching for — what should I call it—good technical performance? This seems to me a very, very vital issue.


    [15:10] People have asked me what kind of a process was involved in creating the architectural pattern language. One of the things we looked for was a profound impact on human life. We were able to judge patterns, and tried to judge them, according to the extent that when present in the environment we were confident that they really do make people more whole in themselves. Of course you may ask, How in the hell did you test for that? But that is too long a story which I cannot cover in this speech. The important point is that such testing was going on continuously.

    [15:30] A second, almost more important thing was going on. Whenever we had a language under development we always asked ourselves, To what extent does that language generate (hence produce) entities (buildings, rooms, groups of buildings, neighborhoods, etc.) that are whole and coherent?

    In other words, suppose I write a pattern language for a campus, and, I think I’ve got some sort of a language that looks as though it will actually do the job. To test it, I let it loose by giving it to people and asking them (in simulated form) to generate different campuses with this language. Let’s see what the resulting campuses look like. And we test it ourselves in the same way, by using it to generate designs, rapidly, and only for the purpose of testing the results for their coherence.

    As it turns out, many of the languages that one creates do not generate coherent designs or objects. That is, they contain a bunch of good ideas. One can use these good ideas to (sort of ) put something together from them, and a few fragmentary structural ideas will be present in the result. But that does not yet mean that the campuses created (in the above example) are coherent, well-formed, campuses. We were always looking for the capacity of a pattern language to generate coherence, and that was the most vital test used, again and again, during the process of creating a language. The language was always seen as a whole. We were looking for the extent to which, as a whole, a pattern language would produce a coherent entity


    [17:15] … it looks to me more as though mainly the pattern concept, for you, is an inspiring format that is a good way of exchanging fragmentary, atomic ideas about programming. Indeed, as I understand it, that part is working very well.

    But these other two dimensions, (1) the moral capacity to produce a living structure and (2) the generativity of the thing, its capability of producing coherent wholes — I haven’t seen very much evidence of those two things in software pattern theory.


    The Nature of Order

    [18:30] The pattern theory was followed by a deeper the- ory. I began to notice, by the late ’70s, some weaknesses in our work with patterns and the pattern languages.

    (1) Under the circumstances that I was most interested in, when we and others were using these patterns to generate buildings, the buildings generated were okay but not profound.


    [20:10] To what extent did they really have coherent living structure as wholes?

    By the late ’70s, I had begun to see many buildings that were being made in the world when the patterns were applied. I was not happy with what I saw. It seemed to me that we had fallen far short of the mark that I had intended.

    But, I also realized that whatever was going wrong wasn’t going to be corrected by writing a few more patterns or making the patterns a little bit better. There seemed to be something more fundamental that was missing from the pattern language. So, I started looking for what that thing was.

    (2) At about the same time I began to notice a deeper level of structure and a small number (15) of geometric properties that appeared to exist recursively in space whenever buildings had life.

    These 15 properties seemed to define a more fundamental kind of stuff; similar to the patterns we had defined earlier, but more condensed, more essential—some kind of stuff that all good patterns were made of. [....]  Anyway I began to notice that particular individual patterns seemed really to come always from the 15 deep properties that kept occurring again and again.

    [22:35] (3) Another thing that was happening around this time (late ’70s, early ’80s), my colleagues and I began toughening up our ability to discriminate empirically between living structure and not living structure.

    During the years of doing the pattern language, we’d really been intuitive about that and not very rigorous. We were just trying to get patterns written and learning to apply them without asking rigorously if they made buildings with more life in them.

    But, at this point (about 1980), we felt it was pretty important to get a fix on the difference between a chair which has a more living structure and a chair that has a less living structure. And the same for a building or a room or for a main street in a town. If you want to say this one has life, this one has less life, how do you say that with any degree of empirical certainty? Can it, in fact, be made a relatively objective matter which people can agree about if they perform the same experiments?

    Indeed, we did find such experimental techniques. The use of these techniques greatly sharpened our ability to distinguish what was really going on and what structures then correlated with the presence of life in a bit of the environment. The use of these techniques also helped us to refine the 15 deep geometric properties, as necessary correlates of all life in designed structures. These 15 properties turned out to be a substrate of all patterns, and began showing up more and more clearly in our work as the main correlates of living structure in places, buildings, things, space, and so forth.


    [27:25] The essence of the experiments is that you take the two things you are trying to compare and ask, for each one, Is my wholeness increasing in the presence of this object? How about in the presence of this one? Is it increasing more or less?


    [28:00] Then it turns out that there is quite a striking statistical agreement, 80–90%, very strong, as strong a level of agreement as one gets in any experiments in social science. All of these different experiments have to do with something like that.

    Do you feel more whole? Do you feel more alive in the presence of this thing? Do you feel that this one is more of a picture of your own true self than this thing you know whatever? It is always looking at two entities of some kind and comparing them as to which one has more life.


    [29:35] … to cut a long story short, it turns out that these kind of measurements do correlate with real structural features in the thing and with the presence of life in the thing measured by other methods, so that it isn’t just some sort of subjective I-groove-to-this, and I-don’t- groove-to-that, and so on. But it is a way of measuring a real deep condition in the particular things that are being compared or looked at.


    [31:20] Thus there is a hint of a profound connection between the nature of matter and behavior of material systems, and the human person.


    [31:55] So there began developing, in my mind, a view of structure which, at the same time that it is objective and is about the behavior of material systems in the world, is somehow at the same time coming home more and more and more, all the time, into the person. The life that is actually in the thing is correlated in some peculiar fashion with the condition of wholeness in ourselves when we are in the presence of that thing.


    [33:20] … we are living in a period where perhaps the most noticeable and most problematic feature of our world is that feeling has been removed from it.


    [35:50] … the 15 properties that I have mentioned provide us the ability to be precise about the nature of living structure, in just precisely such a way that it is connected, not only to all mechanical function, but also to the depths of human feeling. That is why it is an important structure.

    At the root of these 15 properties, there appears to be a recursive structure based on repeated appearances of a single type of entity — the primitive element of all wholeness. These entities are what I call ‘centers.’

    [36:30 spoken] In particular, just going back to these 15 properties that I mentioned, and the ability to be precise about the nature of living structure, at the root of these 15 properties, there appears to be a recursive structure with only one type of entity.  This entity, in my own current writings about them, I call “centers”.

    [37:30 written] All wholeness is built from centers, and centers are recursively defined in terms of other centers. Centers have life, or not, in different degree, according to the degree that the centers are built from other centers using the 15 geometric relationships which I have identified. This scheme, which is at the foundation of all the work in The Nature of Order, provides a complete and coherent picture of all living structure.

    Stretching a bit, I think there may even be a little bit of a connection between the geometric centers which appear as the building blocks of all life in buildings, and the software entities that you call ‘objects.’

    Centers are field-like structures that appear in some region of space. They don’t have sharp boundaries, but they are the focal organizing entities that one perceives at the
    core of all pattern, all structure, and all wholeness.  Everything is made of these kinds of centers. The centers are more living or less living. And, that’s essentially the only important property that they have.

    And the question of whether a center is more living or less living depends recursively on the amount of livingness in the other centers that it is made of, because each living center is always (and can only be defined as) a structure of other centers. This sort of recursion is familiar in computer science. But whether the structure I have discovered and reported in The Nature of Order will translate in any interesting ways to things that you do, I don’t know.


    [38:25] What is true, I can tell you from my own experiences in these last years, is that when one has this view of things in architecture, it becomes enormously easier to produce living structure in buildings. It has immediate practical usefulness. If you start understanding everything in terms of these living centers, and you recognize the recursion that makes a center, living as it is, dependent on the other centers that it is made of and the other larger centers in which it is embedded, suddenly you begin to get a view of things which almost by itself starts leading you towards the production of more successful and more living buildings.


    [40:20] I can tell you in the case of buildings. If one has identified living structure with a reasonable level of objectivity, and if one has identified this recursive center-based structure as being the key to the whole thing, that’s all very well. But then of course the practical question arises, How the hell do you produce this living structure? What do you have to do to actually produce it?

    You can clumsily try to find your way towards it in a particular case. But, in general, what are the rules of its production?

    The answer is fascinating. It turns out that these living structures can only be produced by an unfolding wholeness. That it, there is a condition in which you have space in a certain state. You operate on it through things that I have come to call ‘structure-preserving transformations,’maintaining the whole at each step, but gradually introducing differentiations one after the other. And if these transformations are truly structure-preserving and structure-enhancing, then you will come out at the end with living structure.

    Just think of an acorn becoming an oak. The end result is very different from the start point but happens in a smooth unfolding way in which each step clearly emanates from the previous one.

    Very abstract, I know, but the punchline is the fol lowing. That is what happens in all the living structures we think of as nature. When you analyze carefully just what’s going on and how things are happening in the natural world, this sort of structure-preserving transformation tends to be what’s going on most of the time. That is why, when nature is left alone, most of the time living structure is produced.

    However, in the approaches that we currently have to the creation of the built world and the environment (planning design, construction, and so forth), that is simply not what is happening. The process of design that we currently recognize as normal is one where the architect or somebody else is sort of moving stuff around, trying to get into some kind of good con figuration. Effectively this means searching in an almost random way in configuration space, and never homing in on the good structure.

    That is why the present-day structure of cities, buildings, conventional halls, and houses are so often lifeless. The processes by which they are generated are — in principle — not life creating or life seeking. If a process doesn’t go in the structure-preserving way that I’m talking about, the result is never living structure.

    In effect you can write theorems which say, Under the kind of conditions which occur in the construction industry today, you cannot produce living structure.

    So, the poor folks who designed and built this convention center were stuck with something lifeless, because they were embedded in the wrong kind of process. There was nothing they could do about it. It was part of the process by which this kind of entity is produced in today’s society. As things stand, it cannot come out with a living structure at the end. That is a shattering discovery.

    A very large part of my work and that of my colleagues in the last years has been one of trying to define social processes, economic processes, administrative and management processes which are of such a nature that they permit true structure-preserving unfolding to occur in society, thus to allow the generation and production of living structure.

    What the Future Holds in Store:  The Generativity Problem and the Generation of a Living World

    [46:15]  << describing where he was in spring 1996, pp 79-80 are resequenced from the talk >>

    [57:10 spoken and written] Let me just go back to the structure-preserving unfolding process that I described in Part 2 of this talk. I talked about this structure-preserving unfolding process.

    [written that isn't spoken]: When I first constructed the pattern language, it was based on certain generative schemes that exist in traditional cultures. These generative schemes are sets of instructions which, carried out sequentially, will allow a person or a group of people to create a coherent artifact, beautifully and simply. The number of steps vary: there may be as few as half a dozen steps, or as many as 20 or 50. When the generative scheme is carried out, the results are always different, because the generative scheme always generates structure that starts with the existing con text, and creates things which relate directly and specifically to that context. Thus the beautiful organic variety which was commonplace in traditional society could exist because these generative schemes were used by thousands of different people, and allowed people to create houses, or rooms, or windows, unique to their circumstances.

    [written that isn't spoken]: When I first hit on the idea of creating, and using, pattern languages, I was inspired by these traditional generative schemes, and thought that I was essentially copying them. However, in the huge effort of creating a believable, new pattern language, in the 1960’s the effort went entirely onto the individual patterns (their formulation, verification, etc.), and the idea that they were to be used sequentially, one after the other, dropped into the background.

    [written that isn't spoken]:  In fact, both A Pattern Language and The Timeless Way of Building say that the pattern language is to be used sequentially. In practice, however, this feature dropped out of site, and was not emphasized in use. As a result, the beautiful efficacy of traditional languages and their simple and beautiful sequential nature disappeared from view.

    [written that isn't spoken]:  In our most recent work, that has changed. We are now focusing on pattern languages which are truly generative. That means, they are sequences of instructions which allow a person to make a complete, coherent building, by following the steps of the generative scheme. We have done this for houses, for public buildings, for office furniture layout, and so forth. It works. And it is powerful.

    [57:10] Compared to the pattern language that you’ve seen in A Pattern Language, these generative schemes are much more like what you call code. They are generative processes which are defined by sets of instructions that produce or generate designs. They are, in fact, systems of instructions which allow unfolding to occur in space in just the way that I was talking about a minute ago (Part 2), and are therefore more capable of producing living structure. The published pattern language by comparison is static. The new generative languages are dynamic and, like software, interact with context, to allow people to generate an infinite variety of possible results—but, in this case, with a built-in guarantee of well-formed results. The design that is created or generated is guaranteed, ahead of time, to be coherent, useful, and to have living structure.

    [end at 63:35]

  • daviding 9:03 am on April 5, 2014 Permalink | Reply
    Tags: , , personalized   

    The announcement by the Open Source Initiative OSI… 

    The announcement by the Open Source Initiative (OSI) of inBloom — an educational institution — as an affilate member contrasts to the major of OSI members who are centered on core technologioes.

    The Open Source Initiative ( is very pleased to announce … Affiliate Members: inBloom ( …  [....]

    inBloom is an independent nonprofit organization that provides efficient and cost-effective means for school districts to give teachers the information and tools necessary to strengthen their connection with each student. inBloom’s Secure Data Service enables widely varied educational tools to work together so that teachers can more easily tailor education to the needs, skill level and learning pace of each individual student. It can also engage parents more deeply in their children’s learning, and save teachers time and schools money. In addition, inBloom offers a substantial security upgrade to the common resources being used, including paper records or disconnected and antiquated databases with few security features.

    “inBloom intends to become a champion of open source software development in the context of educational tools for K12 and fully uphold the Open Source Definition. As a company that has built a disruptive technology for an industry where there is a lot of resistance to change, our mission mirrors that of the OSI as educators and advocates for the transparency and community involvement that is synonymous with open source software,” said Vincent Mayers, Open Source Community Manager at inBloom.

    “Open Source Initiative (OSI) announces new Affiliate Members” | Deb Bryant | March 12, 2014 at .

    Here’s a video of the inBloom vision.

    From the FAQ at

    Q: How is inBloom funded?

    inBloom was established as an independent, nonprofit organization to carry forward the mission of the Shared Learning Collaborative (SLC) and make personalized learning a reality for every student in America. inBloom is funded with initial philanthropic support from the Bill & Melinda Gates Foundation and Carnegie Corporation of New York.

    inBloom services focus on data operability, with content search services the Learning Resources Metadata Initiative, the national Learning Registry, and the Common Core and other standards, and will support companies that want to create third-party applications.

    The open source project for developers has some starter apps.


  • daviding 8:03 am on April 5, 2014 Permalink | Reply  

    Saybrook in Japan: An International Collaboration for Innovation in Applied Systems Science | Gary Metcalf | March 11, 2014 | Rethinking Complexity 

    Gary Metcalf describes the annual meeting at the Tokyo Institute of Technology that we both attended, as well as development of a new program of Saybrook University jointly with Osaka Prefecture University.

    … at the seventh workshop and symposium about service systems science, hosted by Prof. Kyoichi (Jim) Kijima from the Tokyo Institute of Technology. The purpose of the event was “to describe visions of the society in ten years time, and to develop real ICT-based devices/products/services/networks to cope with challenges in an aging society to lead to a smart and sustainable society by co-creating new social value. In particular, Japan should be the lead market for overcoming [challenges of] an aging society…”  [...]

    The connection for this research into service systems goes back to a presentation by Jim Spohrer from IBM, at the 2005 meeting of the ISSS. [....]  IBM … began to work on this concept of a science of services (initially, Service Science, Engineering, Management, and Design – see a paper summarizing the ideas by Spohrer and Kwan at .)

    The interest in service systems in Japan came from many of the same concerns. Having been a manufacturing-based economy for decades, Japan found itself challenged by lower-cost labor in developing neighbor countries. The need to restructure its economic base was apparent, but not simple to achieve. The focus this year on aging societies comes from additional challenges, in that Japan has the highest percentage of older people, on average, in the world. If it can develop innovations for improving the livelihood of people 80 years and older, it is possible that it could create new export markets as well. Projections, for instance, are that China will have 100 million citizens over the age of 80 by the year 2050. A looming question is the relative economic potential. How high-tech, and how costly, can the innovations be, relative to the money available to pay for them?

    After a few days in Tokyo, Gary continued on to Osaka.

    My visit to Osaka was to get acquainted with Prof. Toshiyuki Matsui and his colleagues at Osaka Prefecture University (OPU), following his visit to Saybrook’s RC in January. OPU has recently received a grant from the Japanese government to develop a program for Systems-inspired Leaders in Material Science (SiMS). The program will support 20 students per year from departments across OPU, with a focus on research into materials science. Students will continue work on their degrees within their own departments, with additional courses including leadership and systems science, and an international internship, as parts of the new program.


    My trip to Japan provided the opportunity for a visit to OPU and the delivery of a presentation to faculty and propective students on systems sciences. What I learned again is how important language can be. In this case, it was not just English to Japanese. What I interpret as systems science, including theories and authors, was new to my Japanese colleagues. And we look forward to the opportunity to share our knowledge and understanding and develop common frames of reference.

    Saybrook in Japan: An International Collaboration for Innovation in Applied Systems Science | Gary Metcalf | March 11, 2014 | Rethinking Complexity at

    Osaka Prefecture University

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc

Get every new post delivered to your Inbox.

Join 29 other followers