How can we contribute to a project that we would like to emulate?
I have received the current draft of the Moldable Patterns paper from Oscar Nierstrasz. They would like to take it to the 29th European Conference on Pattern Languages of Programs (EuroPLoP '24). Oscar has asked me to review the draft and he would agree if we could look at it together and give feedback.
Ward skimmed the paper pdf and read the abstract, introduction, references, and conclusion more closely (everything except the patterns).
One of the first things I looked for was `rawData:`, which can be found under Moldable Data Wrapper.
The first highlight was the solution part of Moldable Collection Wrapper.
> *Solution*. Wrap a collection of domain objects in a dedicated collection wrapper, and give it dedicated views, actions and searches. In case there are multiple composite entities or collections that should share the same custom tools, factor these out into a common abstract superclass or Trait .
**Note**: Is that really an *or*? (common abstract superclass *or* trait) > A class is primarilly a generator of instances. […] A class has a secondary role as a unit of reuse. […] Unfortunately these two roles conflict. (Ducasse et al. 2006, Traits, p. 332)
Traits appear to be the preferred solution.
**Note**: The federated Wiki Sitemap could be a candidate for the Moldable Collection Wrapper.
Sitemap get slugs
Compare with the code in the paper:
GhOrganization new rawData: dictionary.
url := 'https://api.github.com/orgs/feenkcom'. json := ZnClient new get: url. dictionary := STON fromString: json.
**Note**: Why dictionary instead of array?
a Sitemap view
Ward notes that the term "live" is used 20 times in the paper, but he doesn't think a further definition is necessary.
> I think I know what they mean, but I would be guessing. I thought I would warm up by exploring this term online.
How might we characterize computing as being live?
> The [Smalltalk-80] runtime included a "mutator" that could instantly transform all versions of an object rearranging Slots and adding new, initially null, slots when asked. The practice of initializing slots at object creation worked against this feature and was to be avoided.
Message from Oscar Nierstrasz via discord: "For the wiki pages you might want to refer to the expanded patterns list ... page "
* Explainable System * Moldable Tool * […] * Blind Spot * […] * Contextual Playground * Custom View * Custom Search * Custom Action * Moldable Object * Example Object * Simple View * Moldable Data Wrapper * […] * Narrative Picture
 Stéphane Ducasse, Oscar Nierstrasz, Nathanael Schärli, Roel Wuyts, and Andrew P. Black. 2006. Traits: A mechanism for fine-grained reuse. TOPLAS: ACM Transactions on Programming Languages and Systems 28, 2 (March 2006), 331–388. doi
> How can you keep track of and document your progress in a Moldable Development project?
Ward thinks "the paper, the pdf, has some need to stand alone. Maybe this is not true anymore. But most of what I know of gt comes from the calls we had with Tudor. I was much impressed with how he said they would send gt quotes back and forth over slack with little or no accompanying explanation. They also say "Explanation" a lot. The abstract starts and ends with this word."
> Moldable development supports decision-making by making software systems explainable. ... mutually supporting patterns to explain how moldable development works in practice.
In one case gt explains, in the other case the patterns explain. Tutor's slack example shows the former, gt quotes as self explanatory.
Ward: Alexander distinguished between patterns and "Pattern Language" which was more generative in the Chomsky sense.
Ward: Lots of folks like to compose patterns with a template. On wiki I suggested two paragraphs separated by the word "Therefore" was sufficient so long as the first paragraph described a recurring problem with roots in human nature, and the second paragraph described something specific you could make or do that "resolves" the forces present in the first paragraph. I might have referred to this as Patlets once or twice.
> When we think of software development, we typically think about the active part. Of constructing. Of building new worlds that never existed. It's an empowering view. > > Yet, Developers spend most of their time figuring systems out. They do that because they want to learn enough about the system to make a decision. This is the single largest development expense we have. So, we should optimize software engineering for decision making.
Ward's reply: Yes. This is excellent. The Human Nature that I would like to see in problem statements could easily explore short-term vs long-term decisions. For example, molding is for the short term, but the information it exposes could be either, maybe even both, short for management, long for full time employees.
Since we are looking for assumptions that have not been addressed – cf. the Technique for Reading the Abstract mentioned in Ward's mail and note/Zettel ~/mpd/2 –, the question arises for me as to what concept of System the authors of the paper are using. I doubt that all readers have the same concept of e.g. software system and would see the concept of system more abstractly with regard to the topic of decision making. I think the addressees for these patterns are not only people but also organizations and thus social systems. Or do you consider the system concept used by the authors to be self-evident?
"Systems theory 1.0 revolves around the mereological notion of Whole-Part Theory. In this model, the system equals the whole. The parts are like organs in a body yet are thought of as more modular and static in nature. When you think of systems theory 1.0, think simple input-output machines (like a vending machine). You put a dollar in, and it spits out a snack (assuming it doesn’t get stuck)!"
is an object system, rather than a language.
Ward's reply: No, I don't think it self-evident, though I know enough about GT that I could guess. I have been trying not to guess.
List of Problem Statements – Intention: I (Ward) would like to read carefully each pattern keeping in mind that my greatest ambition would be to apply the patterns in my own environment. The authors conclude that this is believed possible. I now turn to the problem statement of each pattern as the first test of fit with my environment.
Ward via DM (matrix): I've decoded my first five patterns and they make sense as a system
Ward decoded his first 5 patterns and "they make sense as a system".
We have the opportunity to carefully read "Moldable Development Patterns" by Nierstrasz and Gîrba. This paper already offers a pattern hierarchy annotated as Tooling, Modeling or Process.
On Saturday, Ward completed his first run through two of the three sections.
Pattern MoldableTool Application artifact Recognize Mechanism dynamic Invoke Pattern ContextualPlayground Pattern MoldableObject Instantiates Application instance Binds Application snippet Evaluates Domain question Pose Pattern CustomView Application navigation Abstracts Application state Formats Pattern SimpleView Refines Pattern CustomSearch Extends Application attributes Enumerates Pattern CustomAction Extends Encapsulates Suggests Invites Application test Pattern ExampleObject Creates Represents Extends Application data Pattern MoldableDataWrapper Creates Extends Domain entity Reflects Pattern MoldableCollectionWrapper Aggregates Application collection Delegates Pattern ToolingBuildup Pattern BlindSpot Pattern ProjectDiary Instantiate
This already looks promising. It looks better when it's color coded, and it may look better when it's divided into overarching concerns (aspects).
On Sunday, he worked on entering them into one of our viewers. The goal was to read and match each pattern in the PDF file.
Now done with all Patterns. Ward's graph now sprawls a bit which will be fixed with aspect selection. The center of the graph is Domain.question, not a particular Pattern. This seems an insight.
Here as bits:
The center of the graph is Domain.question, not a particular Pattern.
Now in color:
The Super Collaborator explored online collaboration based on Croquet. We've stepped back from this interaction but think its graph merging mechanism will be useful for relating "read me" level documentation across many repos.
Ward thinks it's no surprise that Domain:question should stand out.
Here with tools and modeling selected we see the emphasis turn to the Application itself.
With tools and modeling selected
With Tools and Process selected, we see the Quick-Start fits in to the tool philosophy. Try these yourself: page
“separation of concerns”
Re: and it may look better when it's divided into overarching concerns (aspects).
Eric Evans writes at the end of a recent post ,
> I’m not surprised to see some form of “separation of concerns” pop up in a new situation. It is a very old and fundamental software design principle. And, it seems to me, surely it is not the only design principle that can be applied in this new paradigm, nor the most interesting.
When the moldable developer gets an answer to an important question, then what? Do moldable tools help refactor the application code that is overdue for attention?
Oscar Nierstrasz via discord DM: That depends what decision you are trying to make. Refactoring may or may not be a part of that.
Ralf: I would now expect "Decision" to appear prominently in the MD patterns, wouldn't you? Edward mentioned "the idea of Decision-Making as a Thing" in the review. The Project Diary asks "How can you keep track of decisions, ...?" Should something like a Decision Object be added? as a subclass of Moldable Object?! So Refactoring could be part of a Decision-Making Strategy!
And this Decision Object seems to collaborate with a map (Wardley Map, the MD patterns map, …), doesn't it?
Know where you are, choose where to go, ensure you go there