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

Reality:

  • 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

Consequences

  • 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.

#design-patterns, #plop2014

Advertisements

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

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

Plenary address by Dave Thomas http://davethomas.net 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

Simplicity

  • 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

#plop2014, #programming, #simplicity

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

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

#pattern-language, #plop2014, #programming-style