Value of DCI without runtime role-binding?

[Jonah S]

Been revisiting DCI as I prepare for a new project, and am putting my understanding of it under the microscope.  I'd appreciate feedback on the following thoughts...

Two of the major benefits of DCI are:

1. Separation of "what the system is" from "what the system does"

2. Reclaiming FORTRAN's holistic algorithm from the exploded algorithms often found in distributed OO architectures.

It seems to me that we can often achieve these goals without the runtime role-binding part of DCI.  Consider the ruby code for the bank transfer example at the end of the post.  It has no concept of roles, treats the Account objects as dumb data, and extracts the transfer logic into it's own context.  My question is: Where does this fall short?  What, exactly, does runtime role-binding give us that this style fails to give us?  I know the bank transfer example is simple -- could you show me an example where the runtime role binding part of DCI is essential to an elegant solution?

Thanks,

Jonah

def log(message) puts('Transaction log: ' + message.to_s) end


Account = Struct.new(:name, :balance) do
  alias_method :to_s, :name
end


Transfer = Struct.new(:amount, :source, :destination) do
  def execute
    raise "Insufficient Funds" unless source.balance >= amount
    source.balance -= amount
    destination.balance += amount
  end
end


source = Account.new('checking', 100)
destination = Account.new('savings', 0)


log("#{source} has #{source.balance}")
log("#{destination} has #{destination.balance}")
log("Transferring 30")
Transfer.new(30, source, destination).execute
log("#{source} has #{source.balance}")
log("#{destination} has #{destination.balance}")

[Andreas Söderlund]

Hi Jonah, I think this FAQ question does a good job answering your question: http://fulloo.info/doku.php?id=what_is_the_advantage_of_distributing_the_interaction_algorithm_in_the_rolemethods_as_suggested_by_dci_instead_of_centralizing_it_in_a_context_method

With no RoleMethods, things become overly procedural, centralized, and the mental model is lost in programmer concepts.

/Andreas

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Matthew Browne]

Hi Jonah,
You can get a lot of the benefits of DCI from doing what you described, but there are important differences and unique advantages of DCI. These benefits are not that obvious in simple examples like the money transfer, but become more apparent with larger use cases (...one of the reasons we need more larger examples).

That's a good FAQ entry that Andreas pointed to. We have also discussed this question quite a bit on this list, although the relevant posts are a bit buried...

Here's the most recent thread where we discussed this (quoting from myself):
https://groups.google.com/d/msg/object-composition/pzwEHIZGPis/0vJUz9FtntAJ

On 12/7/14 6:56 AM, Hai Quang Kim wrote:

In that  sense, Context is a meta instruction/system operation that can recursively use sub-instruction/sub-operation.

So we just need to put Role Objects in, it all depends on how the programmer implements that Context.

The result is important.

That is about 90% of DCI, a network of OO or a set of functions run on that set of Role Object is less important to me.

I don't think this is even close to 90% of DCI - the OO concepts are arguably the most important part. And don't forget that there's OO in the data model too - "what the system does" is only half the system in the first place (the other half is "what the system is").

In many examples, to have a few lines of readable DCI, the cost now I need to pay is to type many Role Classes, maintain Stack of Contexts....

In a few cases I even need to change the compiler to make it work.

Can we at least encourage people to scale down DCI to DCA so that they start to have the benefit of DC_A/I?

And no need to wait until we can convince all of the programming language authors to provide us an official way to do pure DCI.

Yes, taking some inspiration from DCI and keeping use case logic together is great and is something I try to do when working on non-DCI projects. But it's important to be clear that it's not DCI. Even calling it a substitute for DCI would be a stretch - better to call it what it is: a mix of procedural programming (for the use cases) and object-oriented programming (for the data model). Cope mentioned his book on multi-paradigm design, and we have also previously discussed Ant's concept of "micro SOA" on this list. I think such approaches offer big advantages over traditional OO for projects with significant use case logic. But DCI has advantages that go beyond that, as is hopefully becoming clearer as you explore it further...

Another thing I have noticed when working with the absence of roles is that often there's behavior that's tied to a particular object, but it's only needed in a particular context (or maybe two contexts), so I find myself not wanting to put it into the domain class because those get messy if they have too many methods, and also it might need to interact with other objects specific to a context. But if I just put it as a method in the service class (or whatever you're using to encapsulate the use case), there's no good sub-grouping for the roles.

One from Rune:

On Wed, Dec 10, 2014 at 9:19 AM, Rune Funch Søltoft <funchs...@gmail.com> wrote:

> Den 10/12/2014 kl. 15.09 skrev Hai Quang Kim <wan...@gmail.com>:
>
> I am trying to challenge the need of OOP in Context to see what I am going to loose if I simplify that. What I am going to win is: no trait, no Context stack, and the easy of applying DCI in any programming language.

The ability to express several mental models through the use of compression and composition and through that you'll loose the ability of communicating with stockholders in terms of their mental model of the system and because of that you'll loose validation opportunity which will impact quality and/or cost
(Talking about larger complex systems here, if simple or small for all sake you could use assembles with no loss) :)

Finally, here's a quote from Lean Architecture:

Why not Put the Algorithm into a Procedure, and Combine the Procedural Paradigm with the Object Paradigm in a Single Program?

This is the old C++ approach and in fact is the approach advocated in Multi-paradigm design for C++ (Coplien 1998). The main problem with this approach is that it doesn’t express relationships between related algorithms, or between related algorithm fragments, that exist in the end user’s head. It obfuscates the role structure. These algorithms are not single closed copies of procedural code, but they play out through object roles.

A scenario that runs through objects frequently needs intimate knowledge about those objects. A closed procedure can access the internals of an object only through its public interface. If we put the use case scenarios in closed procedures, it would cause the interfaces of the objects to bloat to support this close relationship between the use case and the objects. By instead injecting the procedure (bit by bit) into the objects, we allow the code of the algorithms to gain access to object internals (such as domain object private methods) if needed. We need to add new interfaces to domain objects only for business-level functionality that is germane to the use case, rather than adding low-level access methods needed by the use case.

Does this mean that procedural design is completely dead? Of course not. There are still algorithms that are just algorithms (Freud’s “sometimes a cigar is just a cigar”). We can encapsulate algorithms in the private implementation of classes using procedural decomposition. There’s nothing wrong with that. However, those concerns are rarely architectural concerns; we leave those to the cleverness of designers and architects as they come to low-level design and the craftsmanship of implementation.

Coplien, James O.; Bj&#248;rnvig, Gertrud (2011-01-06). Lean Architecture: for Agile Software Development (p. 296). Wiley. Kindle Edition.

[Jonah S]

Matthew,

Thanks for taking the time to dig up the relevant discussions.  I greatly appreciate it.

Andreas,

Thanks for the wiki link, too.

Some followup questions:

After reading the wiki link, I think to "tldr" answer to my original question about the value of runtime role methods is simply: "the same value OO has in the first place, to avoid top-down, all-knowing procedural code."  Which makes sense.  But I'm still struggling to find good examples, and to locate the kinds of exceptions trygve mentions at the end.

Here's something specific:

Consider this role-based version of the transfer example from Jim's excellent casting library, in ruby: https://github.com/saturnflyer/casting/blob/master/examples/delegation_dci.rb. I actually find the decomposition into roles unnatural in this case: asking the destination to increase its balance, and letting the destination be responsible for decreasing the balance of the source.  My natural mental model in this case is top-down procedural.  If I were explaining it to a child, I'd say, "First you take money out of this one, and then you move the money over to this one."  Granted, maybe that only feels natural and easy because the algorithm is so simple....

Even more intriguing to me is the Lean Architecture passage Matthew quoted.  That feels, hazily, to have the answer I'm looking for, but I just can't fully grasp it without a specific example.

> A scenario that runs through objects frequently needs intimate knowledge

> about those objects. A closed procedure can access the internals of an object

> only through its public interface. If we put the use case scenarios in closed

> procedures, it would cause the interfaces of the objects to bloat to support

> this close relationship between the use case and the objects. By instead

> injecting the procedure (bit by bit) into the objects, we allow the code of

> the algorithms to gain access to object internals (such as domain object

> private methods) if needed. We need to add new interfaces to domain objects

> only for business-level functionality that is germane to the use case, rather

> than adding low-level access methods needed by the use case.

Specifically, I'm having trouble coming up with an example for role's accessing object's private methods as described in the passage below.  If the objects are dumb data, what private methods are we talking about?  And perhaps more significantly, is this just a matter of source file level separation of the "data object" methods and "role" methods?  That is, if the role's have full access to the internals, isn't the coupling the same as the case where we have data objects bloated with use case methods (classic 1000 line Rails AR class), except with the advantage that the use case methods are now together in their own file?  More importantly, if the roles do depend on the private methods of the data objects, don't those private methods just become part of a de facto public interface?

I feel I must still be missing something... I need that concrete example.

> Does this mean that procedural design is completely dead? Of course not. There

> are still algorithms that are just algorithms (Freud’s “sometimes a cigar is

> just a cigar”). We can encapsulate algorithms in the private implementation of

> classes using procedural decomposition. There’s nothing wrong with that.

> However, those concerns are rarely architectural concerns; we leave those to

> the cleverness of designers and architects as they come to low-level design and

> the craftsmanship of implementation.

What's a good example of an appropriate time to do this, versus a time when it's clearly not ideal?

On Sunday, January 3, 2016 at 9:03:47 AM UTC-6, Matthew Browne wrote:

Hi Jonah,
You can get a lot of the benefits of DCI from doing what you described, but there are important differences and unique advantages of DCI. These benefits are not that obvious in simple examples like the money transfer, but become more apparent with larger use cases (...one of the reasons we need more larger examples).

That's a good FAQ entry that Andreas pointed to. We have also discussed this question quite a bit on this list, although the relevant posts are a bit buried...

Here's the most recent thread where we discussed this (quoting from myself):
https://groups.google.com/d/msg/object-composition/pzwEHIZGPis/0vJUz9FtntAJ

On 12/7/14 6:56 AM, Hai Quang Kim wrote:

In that  sense, Context is a meta instruction/system operation that can recursively use sub-instruction/sub-operation.

So we just need to put Role Objects in, it all depends on how the programmer implements that Context.

The result is important.

That is about 90% of DCI, a network of OO or a set of functions run on that set of Role Object is less important to me.

I don't think this is even close to 90% of DCI - the OO concepts are arguably the most important part. And don't forget that there's OO in the data model too - "what the system does" is only half the system in the first place (the other half is "what the system is").

In many examples, to have a few lines of readable DCI, the cost now I need to pay is to type many Role Classes, maintain Stack of Contexts....

In a few cases I even need to change the compiler to make it work.

Can we at least encourage people to scale down DCI to DCA so that they start to have the benefit of DC_A/I?

And no need to wait until we can convince all of the programming language authors to provide us an official way to do pure DCI.

Yes, taking some inspiration from DCI and keeping use case logic together is great and is something I try to do when working on non-DCI projects. But it's important to be clear that it's not DCI. Even calling it a substitute for DCI would be a stretch - better to call it what it is: a mix of procedural programming (for the use cases) and object-oriented programming (for the data model). Cope mentioned his book on multi-paradigm design, and we have also previously discussed Ant's concept of "micro SOA" on this list. I think such approaches offer big advantages over traditional OO for projects with significant use case logic. But DCI has advantages that go beyond that, as is hopefully becoming clearer as you explore it further...

Another thing I have noticed when working with the absence of roles is that often there's behavior that's tied to a particular object, but it's only needed in a particular context (or maybe two contexts), so I find myself not wanting to put it into the domain class because those get messy if they have too many methods, and also it might need to interact with other objects specific to a context. But if I just put it as a method in the service class (or whatever you're using to encapsulate the use case), there's no good sub-grouping for the roles.

One from Rune:

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[Matthew Browne]

Hi Jonah,
I'll aim to give a fuller reply later, but for now I just wanted to clarify something important:

On 1/3/16 1:05 PM, Jonah S wrote:

Specifically, I'm having trouble coming up with an example for role's accessing object's private methods as described in the passage below.

Like you, I was originally under the impression that roles were able to access private instance methods (or perhaps you just now got that idea from this quote). In fact, that concept has never been part of DCI, and Trygve and Cope both feel it's important for private class members to remain internal to the class, i.e. they should not be accessible to roles. Even though role behavior mixes with data objects at runtime, there are principles of encapsulation that apply here. I personally think there may still be a place for a construct in DCI that would allow class programmers to intentionally make certain private methods available to certain kinds of roles, but that would only be an occasional thing.

I think what Cope was referring to in that passage is more about the fact that a lot of use case behavior naturally groups into roles / role-players. Code that deals with a particular object logically belongs with that object (either as an instance method or role method). Also, while this is not always the case, if you try decomposing an algorithm without even thinking about roles, chances are that the chunks you come up with will still correspond to roles. Cope himself raised some questions about that in an earlier thread though...

[James O Coplien]

Den 03/01/2016 kl. 19.05 skrev Jonah S <jona...@gmail.com>:

What's a good example of an appropriate time to do this, versus a time when it's clearly not ideal?

It is not a context-free question so there are no right answers. But I can try to answer from the perspective of everyday common practice and the level of software as it stands today.

The code for balancing a balanced B-tree or binary tree would be in a private method, rather than in another class or object. It is not of business concern. It’s commodity code.

The code to print a B-tree to output is perhaps a good candidate for a DCI context. It is not commodity code; it has substantial variations in formatting that could be factored into Role-players, and it may be generalised to work with other kinds of trees and a variety of output media.

[Jonah S]

The code for balancing a balanced B-tree or binary tree would be in a private method, rather than in another class or object. It is not of business concern. It’s commodity code.

That makes sense, it certainly feels different and I would naturally do what you're suggesting.  If we're going to define the difference between "business concern" and "commodity code", is it just a matter of rates of change?  The algorithm for balancing binary trees is highly stable, whereas the various ways and reasons we might have to print them are relatively volatile?

The code to print a B-tree to output is perhaps a good candidate for a DCI context. It is not commodity code; it has substantial variations in formatting that could be factored into Role-players, and it may be generalised to work with other kinds of trees and a variety of output media.

So the context might be "BTreePrinting."  I could see initializing this context with formatting options (print the tree downwards, sideways, with rounded or right-angled branches, etc).  What would be examples of the role players?  And, within these roles, can you think of an example that shows the advantage of role injection over an "injectionless" approach?

Thanks.

[James O Coplien]

Den 03/01/2016 kl. 21.05 skrev Jonah S <jona...@gmail.com>:

That makes sense, it certainly feels different and I would naturally do what you're suggesting.  If we're going to define the difference between "business concern" and "commodity code", is it just a matter of rates of change?

There are whole theories about this in domain engineering, but shearing layer dynamics is one of them.

The algorithm for balancing binary trees is highly stable, whereas the various ways and reasons we might have to print them are relatively volatile?

The code to print a B-tree to output is perhaps a good candidate for a DCI context. It is not commodity code; it has substantial variations in formatting that could be factored into Role-players, and it may be generalised to work with other kinds of trees and a variety of output media.

So the context might be "BTreePrinting."  I could see initializing this context with formatting options (print the tree downwards, sideways, with rounded or right-angled branches, etc).  What would be examples of the role players?

Formatting objects. You might also inject strategy objects that govern prefix, infix, or postfix traversal… A good domain analysis, using a CVS approach, would make these explicit.

It’s good to understand the nature of the problem before trying to solve it ;-)

And, within these roles, can you think of an example that shows the advantage of role injection over an "injectionless" approach?

It depends what you mean — “injectionless” probably tends to mean something on this mailing list, other than what you mean...

[Jonah S]

> It depends what you mean — “injectionless” probably tends to mean something on this mailing list, other than what you mean...

I mean simply: no dynamic role binding on the data objects inside the context. Instead, the context itself has (mostly private) methods that work directly with the data objects public interface. These do the work that role methods do in "true" DCI. Others have called this fake DCI.

[Rune Funch Søltoft]

> Den 4. jan. 2016 kl. 16.19 skrev Jonah S <jona...@gmail.com>:
>
>
> I mean simply: no dynamic role binding on the data objects inside the context. Instead, the context itself has (mostly private) methods that work directly with the data objects public interface. These do the work that role methods do in "true" DCI. Others have called this fake DCI

And yet others have called it procedural programming

[Matthew Browne]

I think what he's referring to would be more accurately called
"multi-paradigm design" (as Cope calls it) -- specifically, a mix of
object-oriented and procedural. That's basically what SOA is as well.

[Rune Funch Søltoft]

> Den 4. jan. 2016 kl. 18.01 skrev Matthew Browne <mbro...@gmail.com>:
>
> That's basically what SOA is as well

Which has also been called procedural programming

[Jonah S]

zing! good one, rune! with your wit, it should be trivial to actually answer my question...

[Rune Funch Søltoft]

> Den 4. jan. 2016 kl. 19.07 skrev Jonah S <jona...@gmail.com>:
>
> zing! good one, rune! with your wit, it should be trivial to actually answer my question...

I think I kinda already did. If procedural programming fits the mental model, the. There no short comings if however the mental model involves interacting objects then the paradigm of choice should be DCI since all of procedural, functional and class oriented falls short of expressing the interaction between objects as a first class citizen in the source code. Specifically in your ruby code you have transformed two objects interacting into a procedure manipulating data

[Jonah S]

yet in that example i find my procedural version clearer and more natural than, eg, the purer DCI approach of jims example that I linked to, where you must arbitrarily choose one role whose "increase" method calls "decrease" on the other, or vice versa. perhaps you disagree?

regardless, i am asking for a non trivial example where DCI role binding is clearly superior to fake DCI or procedural or whatever you want to call it. this should be really, really easy for anyone claiming to fully understand DCI. it should take 10-15 minutes to do. yet here we are deep into another thread on this subject and it has yet to be done.

[James O Coplien]

I trust you have already read the Lean Architecture book, fully tried out its examples, have been through all the papers in the bibliography at http://fulloo.info/Documents/, all the examples at http://fulloo.info/Examples/, and you find them unsatisfactory?

I think we’re just all a little slow here. Perhaps if you gave an example that clearly demonstrates why OO is better than Algol-68 style programming, we’d have a concrete example to follow. Heck, it should take you 10 or fifteen minutes to do. Then we’ll just follow your example.

If you are going to make an investment in something, you should expect to invest more than 15 minutes to understand it. Given what you’ve said and the FORTRAN-cum-Ruby example you posted I think it would take me ten years to dispossess you of your current tacit beliefs. Your examples first shows no understanding of encapsulation or modularity; beyond that, nothing of object orientation; and if you came that far, we’d maybe be ready to talk about DCI.

If you’re looking for something easy to learn, go learn the syntax of another programming language. Here, you will have to learn to appreciate that some thought and fundamental mindset shifts will be appropriate if you are to understand that. If you expect one of us to be able, in ten minutes. to explain DCI to someone who hasn’t yet shown the faintest sign that he understands even encapsulation, I’m afraid you will be very disappointed with your interactions in this group.

It’s 20:55 here. You have 15 minutes.

> Den 04/01/2016 kl. 20.30 skrev Jonah S <jona...@gmail.com>:
>
> yet in that example i find my procedural version clearer and more natural than, eg, the purer DCI approach of jims example that I linked to, where you must arbitrarily choose one role whose "increase" method calls "decrease" on the other, or vice versa. perhaps you disagree?
>
> regardless, i am asking for a non trivial example where DCI role binding is clearly superior to fake DCI or procedural or whatever you want to call it. this should be really, really easy for anyone claiming to fully understand DCI. it should take 10-15 minutes to do. yet here we are deep into another thread on this subject and it has yet to be done.
>

> --
> You received this message because you are subscribed to the Google Groups "object-composition" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

[James O Coplien]

> Den 04/01/2016 kl. 20.55 skrev James O Coplien <jcop...@gmail.com>:
>
> It’s 20:55 here. You have 15 minutes.

Time is up. If you can¨t develop an example for something as simple as OO (it must be simple if DCI, which is somewhat more involved, can be explained in 15 minutes in the time you expected us to work up a DCI example, you have lost all credibility with me in terms of your appreciation of the difficulty of learning this approach.

[Matthew Browne]

Private message:
Please don't let Cope scare you off...I get what he's saying, but I wish
he wouldn't do it in a tone that comes off as nasty. I (hopefully joined
by others) will continue this thread with you when I have the time.
There are a lot of discussions going on right now.

[Hai Quang Kim]

I have same question like this before. So just want to share my thought after receiving excellent answer for Cope and Rune.

"Object with Identity compresses deep knowledge"

Let's say  you have an algo with step 1 to 10, next month you comeback can you remember step 3 if someone mentions that to you.

With proper OOP you will have something like in Context C A does this, B does that.

A, B, C with good name can help you to uncompress info you have in you head (may be passive to active....)

So if someone mention the context then A, I may be able to remember what AI can do....This is very good for reading code. (much better than procedural code even with your own code)

After learning DCI, I look at my code base (11 mil of c++/C# code).

A few things I can see it in different ways now: (replace number with your number)

1) less than 1000 LOC, procedural programming will do well enough

2) more than 1000+ LOC, procedural programming starts to fall, classic OOP can do well

3) more than 10K LOC, classic OOP starts to fall, and DCI OOP may do better

So the problem is about scaling not about coding an example...How good you can scale your code base (LOC, number of people, number of features...)

I think one of the problem programmers used to face:

- When I read code I like to readable code with good name, good design...(OOP thinking, thinking globally)

- But when I am doing code I like to think in procedural way:

Eg. Code already has step 1 - 10, now I need to change step 3 to improve feature...(thinking locally)

So it is very natural for my 1st version of code to be procedural code as a result of try and fail. 

But If I want to invest to good code I need to spend decent time and rethink about code design, good name...actually stepping back and understand the big picture I painted before, reorganize them in better way (DCI of course ;-) )....

I think doing everything right at the 1st attempt (code design, good name....) is still the myth for me.

That why I find refactoring (with some auto test) is still valid.

And I often spend more time for up front design with DCI thinking nowadays.

Of course if one is smart enough can do event/data/procedural paradigm with million of code and can remember/understand them all....then that one may not need any thing....ASM may work for him too :)

/quang

[Jonah S]

Cope,

I was boarding a plane as you issued your challenge (proof available upon request :)

I'll try to turn this around into something productive, if I can.  First, I shouldn't have made a comment to Rune that indirectly implicated you.  I believe you genuinely try to communicate your understanding of DCI, that you have a deep understanding of it, and that you don't like to see it dumbed down or oversimplified, and am appreciative of your efforts and time.  

I also believe that, despite my peevish tone, there is a valid point in my message, and I hope you'll hear me out.

First, let me answer the personal questions.  I have read your book, and I have watched all the videos of you online about DCI that I could find.  I've also read Jim Gay's book on DCI in ruby.  So, while you can criticize my grasp of DCI all you want, you can't make the claim that I haven't tried to understand, and you can't make the claim that I've been lazy about it.  I've also benefited from the parts I have understood.  Separating use-case logic from data objects -- the furniture from the pillars -- was a huge insight for me.  There are others too.

Secondly, if you search the mailing list archives you'll see I've been involved in a number of threads -- I think last spring, and maybe for another spurt before that.  You can verify that my tone has been respectul of you, appreciative of your time, and in general patient and thoughtful (with yesterday probably being the only exception).

With all that said, here's my honest and hopefully constructive responses of your other points:

> have been through all the papers in the bibliography at http://fulloo.info/Documents/, 

Do you read the full bibliography of every book you read before asking questions about it? 

> all the examples at http://fulloo.info/Examples/, and you find them unsatisfactory?

I think they would be more helpful if they were presented in a more curated form.  I want guidance connecting abstract concepts in the book to real code.  A code dump alone isn't as useful for me.

> I think we’re just all a little slow here. 

I don't think "slowness" is the problem at all.  In fact, just the opposite.  I think you know so much about this subject, and have thought so much about it, and that it's connected for you to so many ideas -- even philosophical ones that would appear unrelated to most -- that you suffer from a curse of knowledge (https://en.wikipedia.org/wiki/Curse_of_knowledge) that makes your answers less helpful than they could be at times to those learning DCI.  Specifically, I think they could be improved by the use of more concrete examples, including code.

> Perhaps if you gave an example that clearly demonstrates why OO is better than Algol-68 style programming, we’d have a concrete example to follow. 

Absolutely.  First, let's clarify: I didn't ask you or anyone else to explain DCI in 15 minutes.  I asked for code a sample that showed how using DCI role binding improved a "fake DCI" approach that used data objects and contexts without role binding.  That is, a short (but nontrivial) example, with "before" code and "after" code.  And (optionally) some explanation about the benefits of the "after" code.

I know you are familiar with this style of pedagogy.  It's the approach used in books like Kent Beck's "Refactoring," Bob Martin's "Clean Code," and innumerable others.  It takes us out of the realm of abstract concepts and into one where we far less likely to waste time talking around each other.  

Here's a personal example of a code review post where I introduced an object to help untangle concerns, and explained what the benefits of my refactoring were:

http://codereview.stackexchange.com/questions/105099/parsing-mathmatical-functions/105311#105311

Note: I'm not holding this up as an example of brilliant refactoring, but as an example of the kind of thing I'm looking for.  It's incomplete, but communicates the point I'm trying to make.  That's all I'm looking for.

For a slightly longer, but still succinct, example, here's a video (or slides) of Ralf Lammel explaining why C# can't effectively solve the expression problem:

https://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Dr-Ralf-Laemmel-Advanced-Functional-Programming-The-Expression-Problem

It is filled with "before" code, showing the various possible half-solutions that C# supports.  In the next video, he shows how Haskell's typeclasses provide a true solution.  Abstract concepts are interleaved with before and after code to demonstrate the benefits of typeclasses in solving the expression problem.

> Given what you’ve said and the FORTRAN-cum-Ruby example you posted I think it would take me ten years to dispossess you of your current tacit beliefs. 

My mind is open for business.  And I think, in reality, we're talking about a few threads of conversation.  My "tacit beliefs" are probably not what you think they are.

> Your examples first shows no understanding of encapsulation or modularity; beyond that, nothing of object orientation; and if you came that far, we’d maybe be ready to talk about DCI.

Show me how to improve it.  This is what I've been talking about.  It would take you hardly any longer to post a rewrite which would prove me wrong, but instead your response is at the level of abstraction.  Granted, this isn't the fairest example, since you may be just flaming me by this point :), but I think my point stands in general.  I've linked to Jim's alternative, which does use role binding and is (I presume?) more DCI, but I think it's not as clear, for reasons I already gave.  Still, I'm open to being convinced otherwise.  A little bit of code and a little bit of explanation is all it would take.

Anyway, feel free to read my other code review posts to decide if you think I'm a hopeless case.  If you do, that's fine.  Best of luck and no hard feelings.  But if you want to have a conversation based around real examples, I'd appreciate it.  And I bet others would benefit too.

Jonah

> To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

[Jonah S]

Hai,

Thanks for the reply.  Do you have an example refactoring showing the benefit you're talking about.  Specifically, an example of this:

> A, B, C with good name can help you to uncompress info you have in you head (may be passive to active....)

> So if someone mention the context then A, I may be able to remember what AI can do....

Jonah

[Egon Elbre]

On Tuesday, 5 January 2016 07:33:54 UTC+2, Jonah S wrote:

> Perhaps if you gave an example that clearly demonstrates why OO is better than Algol-68 style programming, we’d have a concrete example to follow. 

Absolutely.  First, let's clarify: I didn't ask you or anyone else to explain DCI in 15 minutes.  I asked for code a sample that showed how using DCI role binding improved a "fake DCI" approach that used data objects and contexts without role binding.  That is, a short (but nontrivial) example, with "before" code and "after" code.  And (optionally) some explanation about the benefits of the "after" code.

The fake DCI (see other threads for "poor-man's DCI") approaches improve the architecture even, if the code doesn't map directly to the mental model you are using to write it.

Let's take a simpler example from OO (using Go as the language):

type List struct {

Value int

Next  *List

}

// similar to C++

func (head *List) Append(other *List) {

if head.Next != nil {

head.Next.Append(other)

return

}

head.Next = other

}

// similar to C

func List_Append(head *List, other *List) {

if head.Next != nil {

List_Append(head.Next, other)

return

}

head.Next = other

}

I know, linked list is a stupid example, but will suffice here. These two linked lists have the same behavior. However the second version looks a bit "uglier". Essentially I could write OO code in C. However, the language itself is procedural... so every time I modify the code I have to translate between these two worlds - object oriented and procedural. It's as if you were to look at OO having unfocused sight.

Now with DCI vs OO, you will similar problems, the problems can manifest as "ugly code" or "object schizophrenia".

Case 1. I'm working on right now this: https://github.com/raintreeinc/ditaconvert/blob/master/loadmap.go#L12

It loads a ditamap, however all the responsibilities are wrong. It doesn't make sense for the loading context to do the actual file loading and putting the loaded thing into a cache. It doesn't make sense to need have cache attached to the index. Similarly the ProcessNode deeply belongs to the Index, rather than the loading context. Essentially the clear roles disappeared from the code and became unfocused; similarly how Object-Oriented C hides the OO nature of the code. You can use some conventions (such as the List_Append), to make things look better but it always will be at odds.

It probably would look like:

type MapLoading struct {

role Environment {

Dir      string

Entry    *Entry

CollType dita.CollectionType

Linking  dita.Linking

TOC      bool

}

role Cache {

AddTopic(...)

AddMap(...)

}

role FileSystem {

LoadTopic(filename string)

LoadMap(filename string)

}

role Index {

ProcessNode(...)

ProcessRelRow(...)

AddFamilyLinks(...)

CreateRelatedLinks(...)

}

}

But, I never came to that, because my mind is already busy with trying to express the loading requirements into code. Trying to additionally work on the "mental-model translation" wouldn't work here ... because my mind is already overworked from the essential complexity. It was easier not to do that, to get things done.

I have session code for handling multiplexing in a client/server (multiple clients, single server), it currently looks like (Participant is an interface):

func (session *Session) _pumpServer(server Participant) {

func (session *Session) _disconnectClient(id message.EID, client Participant) {

func (session *Session) _pumpClient(id message.EID, client Participant) {

In this case the _pumpServer, ideally would be server.Pump(); and similarly client.Disconnect(), client.Pump(). But, instead the session becomes a "controlling entity" rather than being the context where things happen.

If you only have two/three roles, it's not a big problem to track the "mental-model-mapping", but once you go further, brain isn't capable of dealing with the additional overhead. You start to miss obvious cases where things could be clearer with DCI.

It's not the technical aspects that are the problem; it's the thinking aspects and solving problems part.

+ Egon

[Hai Quang Kim]

You will never find anything that is obviously better than the previous one without defining what is good and what is bad.

I found it through my own experience. I saw my self/my seniors.... getting harder and harder to read code (mine and others including big top companies's code).

I think it is obviously some thing is wrong with current OOP and search for something else (DCI)

But if you want I can share my homework: https://github.com/wangvnn/DCIvsAOP_RibbonApp

I even built my own port of Baby IDE from Trygve's Smalltalk version:

• http://goo.gl/qfh5uI

They are here: https://github.com/wangvnn/TheDCIBabyIDE

/quang

[Egon Elbre]

I forgot to mention that in the server part, I started with completely OO approach (without having the "Session" context), i.e. the Server/Client weren't interfaces and communicated directly with messages, but... I had deadlocks, sometimes the communication would just hiccup, was too slow to transfer data etc. Eventually threw that approach away, because I wasn't able to properly coordinate the interaction.

After switching to modeling with roles, LOC was reduced and I was able to use the exact same code for "Server" and "Client" --> i.e. Participant.

[Hai Quang Kim]

btw, the IDE was built by poor man DCI code too, the diagram is generated from the poorman code by using Roslyn.

/quang

[Jonah S]

Egon,

Thanks!  I'll have to look at this tomorrow as it's getting late.  But fwiw I agree that 90% of the difficulty of programming is the thinking part, and preventing your natural way of thinking from getting overwhelmed by implementation details.

[Jonah S]

Thanks for these examples.  I noticed the comparison with aspectroid -- I haven't used that but I've been a big fan of Carlo Pescio's blog for a while.  

Only had a change to look at this over briefly so far, so forgive me if I'm off here, but it seem to me that the contexts, or at least their names -- StartNewTrack, StopTrack, UpdateTrack -- were mapping more to implementation details than to natural mental models.  That is, as I user of the app, I'd be thinking about "drawing".  Or if special thing happen at the start and end of drawing, then at least "StartingToDraw", "Drawing", and "FinishingDrawing", or something like that?  Maybe a minor point...

Anyway, the StartNewTrack was a pretty good example of an answer to my question.   I could see the benefit of the role-binding approach there, albeit in the small.  Maybe it just boils down to: We want to use OO techniques inside of our contexts, for the reason we'd want to use them outside of our contexts, and we need the role-binding to do that?

[Hai Quang Kim]

I reverse engineer the use case  from code, so I don't have the original use case (author's mental model). So I used mine. 

Anyway, mental model is a beast that is hard to understand even it does exist.

And everyone will have their own mental model, that why it is hard to debate which one is better (even unnatural to others...)

/quang

[Aryeh Hoffman]

Hi Egan,

Let's take a simpler example from OO (using Go as the language)

It's a little off the thread topic, but I thought your statement misleading.

Does the fact that Go (Golang) as a language supports the implicit passing of an instance of a struct (or a type or a function) to a method make Go Object Oriented?  Just because something (A) uses or exhibits a characteristic of something else (B), is A a B?

Just on Go...

Go's inclusion of interfaces as a first class concept directly supports differing sets of behavior acting on data.  Sounds like a role?

Food for thought... look to work with interfaces not structs in Go.  Rather than instantiate a new struct directly, consider creating a "new" method that returns an interface.  In that way, one could argue your programming against a "role" that encapsulates it's data.  Unless you do this, the encapsulation boundary in Go is the "package".

[Trygve Reenskaug]

Hi Jonah,
We have for years been looking for a "killer app" that gives the reader an "Aha!, so that's what it's all about!"  We haven't found it yet. Believe me, that's very frustrating. All the small and simple programs I have written with DCI could be rewritten in Java. No problem. A larger and not so simple program (about planning) shows the organizing capabilities of DCI. But it is not a "killer app" because it is too large and leads to discussions about readability and the benefits of one program structure as compared to another. What we have been looking for is a program with a few classes that implement two or more use cases. With regular OO, the code for the classes will be an interwoven mixture of the code for the use cases. With DCI, thew code for the use cases will be located in separate stand-alone parts. We haven't yet found such an example.

I have come to believe that we are looking in the wrong places. Most current languages are based on the von Neumann computer architecture. DCI is inherently non-von Neumann because communication is here a first class citizen.  I'm now looking for an example outside the von Neumann box. The "killer app" could, for example, be code that helps a user integrate several services available on the local net:


No data classes. A generic interface to communication based services that play roles in this context. Role methods that forge a tool that serves the user's needs. The program structure reflects the user's mental model 1:1.

Sorry I can't be more helpful.
BTW, I have been told that the hardest tasks facing text book authors is to device simple and illustrative examples.

--Trygve

[Egon Elbre]

On Tuesday, 5 January 2016 10:06:03 UTC+2, Aryeh Hoffman wrote:

Hi Egan,

s/Egan/Egon/

 

Let's take a simpler example from OO (using Go as the language)

It's a little off the thread topic, but I thought your statement misleading.

Does the fact that Go (Golang) as a language supports the implicit passing of an instance of a struct (or a type or a function) to a method make Go Object Oriented?  Just because something (A) uses or exhibits a characteristic of something else (B), is A a B?

Nope. Although, I could have written the same example in JS, C++, SmallTalk.

I have no problem using an OO mental when writing Go, nor do I need to "translate-my-mental-model" (except when dealing with highly dynamic stuff). So, for me, it serves well enough as a OO language (at least better than Java). JS works better, but it has too many quirks.

Just on Go...

Go's inclusion of interfaces as a first class concept directly supports differing sets of behavior acting on data.  Sounds like a role?

In DCI sense, it can only serve as a role contract.

Food for thought... look to work with interfaces not structs in Go.  Rather than instantiate a new struct directly, consider creating a "new" method that returns an interface.  In that way, one could argue your programming against a "role" that encapsulates it's data.  Unless you do this, the encapsulation boundary in Go is the "package".

By declaring the interface in the same package it will deeply tie things together. Especially, in Go you will start to get problems with circular imports. I see very little in declaring the interface in the same package as the thing that implements it. It will also make names more ugly.

Example: server usually would become dependent on the Database and Authentication package. Which doesn't make sense -- why should the server care where the database or authentication are implemented. Server only cares what the Database and Authentication package do.

* https://github.com/raintreeinc/knowledgebase/blob/master/kb/server.go
  https://github.com/raintreeinc/knowledgebase/blob/master/kb/database.go

More examples:

* https://github.com/egonelbre/mud/blob/master/telnet

* https://github.com/egonelbre/fedwiki

* https://github.com/johnwilson/bytengine

+ Egon

[rune funch]

2016-01-05 8:05 GMT+01:00 Jonah S <jona...@gmail.com>:

I agree that 90% of the difficulty of programming is the thinking part, and preventing your natural way of thinking from getting overwhelmed by implementation details.

And this is one of the strengths of DCI that you can't express in code. Using DCI you can (and in my oppion should) code the system from the outside. Don't start with the details. Start with the main flow and fill in the details as you learn. This in turn turns out to be very lean and agile and excellent for pretotyping as well

I gave a talk about that 4 years ago at wroc_love

[Risto Välimäki]

2016-01-04 17:19 GMT+02:00 Jonah S <jona...@gmail.com>:

> It depends what you mean — “injectionless” probably tends to mean something on this mailing list, other than what you mean...

I mean simply: no dynamic role binding on the data objects inside the context.  Instead, the context itself has (mostly private) methods that work directly with the data objects public interface. These do the work that role methods do in "true" DCI.  Others have called this fake DCI.

...yet there is no such thing that non-fake object oriented programming / non-fake DCI anyhow. Objects do not exist in CPU or in memory (at least in mainstream architectures). Objects exists only in programming languages and the heads of users and programmers. After compiling, everything is fake, unless you stay with low level C, or even better with assembly language.

For example, there is basically no difference between non-virtual methods of an "object" or any other method/function/extension method that's defined completely outside the class of that object. They are not part of that object in runtime, but the system knows where to call them when needed. Exactly the same that happens with injectionless / extension methods.

Everything is a fake. It's just about the possibility to maintain the illusion from the code to the runtime so that you are always able to reason the system with objects.

There are some crucial hard requirements for DCI such as:

-Object identity shouldn't be affected by roles

-Role methods are defined in context (code)

-Role methods are available/callable/affecting only within context (runtime)

All the above requirements can be 100% fulfilled with or without injection. 

-Injection is about wrapping the role methods with the role playing object. (Or wrapping the memory addresses of said methods / modules of methods with the role playing object).

-Injectionless is the non-wrapping-non-modifying solution which leaves the object intact. 

-Role-as-a-wrapper solution is no-go because the identity issues. At least those identity issues would be a nightmare to overcome with role-as-a-wrapper solution to maintain the illusion of single, undivided 

There might be recent hard requirements for DCI that render injectionless solutions as non-DCI or "fake DCI", but I'm not aware of these, since I have been offline more than a half year now. I have a year old draft version of the DCI paper by Trygve & Cope, and there is no requirement in that paper that would make it impossible (or even hard) to do injectionless DCI.

[Matthew Browne]

On 1/5/16 2:56 AM, rune funch wrote:

I guess you didn't intend to send that message to the list :)

Oops, no....but I do intend to send this one to the list to clear things up...

If it were a public message I would not have said it that way, and Cope, I hope you were not offended - more on that below to hopefully clarify that I did not in any way mean to insult you.

While it was intended to be a private message, I actually don't mind the sentiment behind it going public, because it's an honest sentiment I have about how this list might be perceived to newcomers in instances where we (legitimately) act more strict, strongly challenge their assumptions, and ask people to "do their homework". It's more about the tone than it is the actual points we're trying to convey. But I clearly need to be more careful before hitting that "Send" button! :-)

As to my concerns, in other instances I might have written a public message about them. I mainly held off from doing that this time because there are a lot of substantive discussions going on and I think it would have been distracting. And now that I'm writing this, I am unfortunately still contributing to that distraction, but I think it's important to clarify what I meant. This is the first time I've directly reached out to a member of the list to encourage them not to leave the list or give up on DCI (and now that I see Jonah's subsequent posts, I realize it was probably unnecessary). There have of course been conflicts in the past, but they unfortunately in some cases resulted in newcomers becoming disrespectful and personally attacking members of this list, and I'm glad that we don't put up with that sort of thing.

But Jonah has been respectful throughout this thread and is honestly just trying to better understand DCI. I can see how when he said "it should take 10-15 minutes to [create an example]" that would seem overly demanding (and maybe showing some misunderstanding about programming in general), and I think Cope's response aptly pointed out the problem with asking us to demonstrate the value of DCI in that way. But I can also sympathize with struggling to understand a lot of abstract concepts and theories without concrete examples, and I know that seeing something concrete can sometimes clear up confusion very quickly. So I think it would be better not to be dismissive of such a request, even if it could have been made more gracefully. I think that Cope's response had a lot of good parts in it, and my aim is not to try to convince Cope or anyone to change what they're saying but rather how they're saying it (in some instances). I actually didn't have much of a complaint about it until the post where he said "time is up", which just strikes me as silly. Cope, I hope you were at least half-joking about that, since obviously when you send an email it's not guaranteed that the other person sees it and reads it immediately. The 15-minute challenge was a legitimate one, I just think the way you phrased your most recent two posts could easily be misinterpreted to be something other than the pedagogical lesson you intended.

Before I go any further, I do want to say that I think things have been better on this list lately, and we have been more welcoming.

Cope, when I said, "Please don't let Cope scare you off", I was concerned that your tone and demands might seem unreasonable and would rub Jonah the wrong way and lead to misunderstanding on both sides. I did NOT mean to imply that you are inherently scary or that you would scare someone off on purpose.

My fundamental concern here is about DCI and its future. As you all know, I have a great passion and appreciation for DCI, and would like to see it benefit a lot more people. The primary aim of DCI is to offer a programming paradigm that's more understandable to everyone, and to make better software. Yet on this list, the barrier to entry often seems awfully high. I realize that we would all be acting very differently if our audience were people learning programming for the first time rather than fellow experienced programmers. So when an experienced programmer comes to this list asking questions, and especially if they start to challenge DCI without understanding it first, I agree that we should point out the importance of making an investment in the learning process, i.e. "do your homework". But by emphasizing that response so strongly and without much warmth and encouragement at times, I think we run a serious risk of giving the world a wrong impression of DCI and our community. I have seen all the regular members of this list offer truly wonderful help and encouragement to others, so all I'm asking is that we keep that up and that we be careful with our tone when communicating in public. I don't think the problem has ever been with the points we're trying to convey, even when we have been more strict or offered a challenge. Rather, the problem is that when you have a wide audience of people from different backgrounds, it's quite likely that someone could misinterpret what you mean and get the wrong impression, and we need to be aware of that.

Before closing, I would just like to reiterate that now may not be the best time to discuss the culture of this list, and that I actually think that for the most part, things have been fine lately, and the collaborative energy around the trygve language has been awesome - I have deep respect and appreciation to Cope for creating it. If anyone has follow-up comments about this, please feel free to reach out to me directly if it doesn't seem like something that needs to be CC'd to the whole group.

Cope and everyone, please accept my apology for introducing this distraction to the group discussion, and let's get back to our passion for DCI!

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

[Matthew Browne]

P.S. The main message that I feel has not been adequately communicated from this group is: "You can learn the basics of DCI and derive a lot of benefit from it without having to spend years reading every published work about it and a lot of other related theoretical texts."

I don't want to diminish the importance of reading and learning - paradigm shifts are hard, and it definitely requires a willingness from the person learning DCI to spend significant time on that. But there's a difference between understanding the basics of something and enjoying some practical benefits from it, and understanding it fully in all its complexities. The latter requires the kind of extensive reading that Cope mentioned. But if we expect every single person to do that, I don't see how DCI will ever become much more than a footnote in history.

[Matthew Browne]

Hi Jonah,
To reiterate a point from my previous post, the benefits of the DCI role-binding approach are not necessarily obvious from simple examples, but become increasingly apparent with larger use cases. Not to avoid your question (more about an example like you asked for below), but I think the best way to understand the difference is to try it out. After writing my first DCI system, I returned to another project that was not DCI, and I tried to do a mixed-paradigm approach to still at least get the benefits of consolidating use case logic in one place. But I ended up with a bunch of service methods that weren't organized as well as they could be, and I also ended up with some common behavior that I just put into the domain classes that sometimes mixed too many responsibilities - I could have used nested contexts to help better organize that with DCI.

Having said that, I recognize that seeing an example could also be very helpful. While I think it would take more than a single example to fully show the benefits of the role-binding approach, let's see if we can help make this more concrete for you...

Have you seen Marc's shopping cart example? It may answer some of your questions.

With regard to the money transfer example you linked to, I don't think that particular version is the best demonstration of DCI, because it only reflects a rather mechanistic view of increasing and decreasing balances - those methods could just go in an Account context without being role methods in a Transfer context. Of the original versions, the one I like the best is the one that goes something like this:

Source.transferFrom();

role Source {
    transferFrom() {
        self.decreaseBalance(amount);
        Destination.transferTo();
    }
}
   
role Destination
    transferTo() {
        self.increaseBalance(amount);
    }
}

What I like about this is that the naming of the transferFrom and transferTo methods gives a clear indication of why they make sense as role methods. What's happening here is that the transfer logic is being distributed - each account does half of the transfer logic...if there were just a Source.transfer method (and no Destination.transferTo method), then it begs the question, "Why is the source account the one responsible for doing the transfer? That seems arbitrary." But my current preferred version of the money transfer example goes like this (abbreviated below; full example here):

Bank.transfer();

role Bank {
    public void transfer() {
        SourceAccount.withdraw();
        DestinationAccount.deposit();
    }
}

role SourceAccount {   
    public void withdraw() {
        this.decreaseBalance(Amount);
    }
}

role DestinationAccount {
    public void deposit() {
        this.increaseBalance(Amount);
    }
}

My mental model of a bank transfer is more similar to yours, I think, then it is to the original example - I think of the transfer as something that the bank does, rather than something the accounts are doing with each other. I think both mental models are valid. This shows how DCI can support both something like a mediator pattern, and it can also support use case logic that is carried out entirely by role-playing objects acting directly on their own behalf and communicating directly with the other role players. But the other reason I prefer the latter example is that it incorporates the concepts of withdrawals and deposits, which are part of my mental model of a money transfer. I think that more clearly demonstrates the DCI concept of role behavior augmenting the behavior of data/domain objects and expressing multiple mental models simultaneously.

BTW, the idea of the Context itself playing a role, as I did in this example with the Bank role, is perhaps a bit of an advanced concept. In many cases there might be a role player other than the Context itself that would be suitable to play such a role, but there's no "Bank" data object here, nor do I think there needs to be for this use case, so by using the Context itself as the role player I'm still able to express that mental model.

Having explained all that, I should mention that the money transfer example is not one that I would say demonstrates the biggest advantages of DCI, compared to what some other examples (particularly larger examples) would show. We definitely need more of these examples, and as Trygve pointed out we are working on that (BTW have you seen his Prokon example)?

For now, let me know what you think of the shopping cart example and we can go from there.

Here's one other perspective that may be helpful: in some ways, DCI is actually a lot like domain-driven design (not necessarily just the Eric Evans flavor, but in general), but with an important difference (actually a lot of differences, but I'm making a point here ;):  you still have domain objects that contain both data and behavior at runtime, but the role behavior is added dynamically and is context-specific. (BTW, I could have said DCI is "a lot like traditional OOP in some ways", but OOP has been used and abused in so many ways that I think "domain-driven design" better communicates what I mean.) There are a lot of benefits to putting use case behavior in Contexts rather than putting it all in giant domain classes, and it sounds like you understand that part of DCI already. Here's the point: DCI allows you to organize that use case behavior in an object-oriented way that reflects our mental model of objects interacting with each other (I think most non-technical people think of software in terms of such interacting objects even if they don't realize it).

The other crucial benefit DCI brings to the picture is to make that communication between objects clear and easy to understand. As Quang pointed out, since each role is identified with a name for that role in the code, it makes it much easier to envision which objects will be interacting at runtime and how they will interact. This benefit is much more evident in complex use cases with lots of interactions - not so much for simple CRUD, for which DCI doesn't add much (if any) value.

On 1/3/16 1:05 PM, Jonah S wrote:

Matthew,

Thanks for taking the time to dig up the relevant discussions.  I greatly appreciate it.

Andreas,

Thanks for the wiki link, too.

Some followup questions:

After reading the wiki link, I think to "tldr" answer to my original question about the value of runtime role methods is simply: "the same value OO has in the first place, to avoid top-down, all-knowing procedural code."  Which makes sense.  But I'm still struggling to find good examples, and to locate the kinds of exceptions trygve mentions at the end.

Here's something specific:

Consider this role-based version of the transfer example from Jim's excellent casting library, in ruby: https://github.com/saturnflyer/casting/blob/master/examples/delegation_dci.rb. I actually find the decomposition into roles unnatural in this case: asking the destination to increase its balance, and letting the destination be responsible for decreasing the balance of the source.  My natural mental model in this case is top-down procedural.  If I were explaining it to a child, I'd say, "First you take money out of this one, and then you move the money over to this one."  Granted, maybe that only feels natural and easy because the algorithm is so simple....

Even more intriguing to me is the Lean Architecture passage Matthew quoted.  That feels, hazily, to have the answer I'm looking for, but I just can't fully grasp it without a specific example.

> A scenario that runs through objects frequently needs intimate knowledge

> about those objects. A closed procedure can access the internals of an object

> only through its public interface. If we put the use case scenarios in closed

> procedures, it would cause the interfaces of the objects to bloat to support

> this close relationship between the use case and the objects. By instead

> injecting the procedure (bit by bit) into the objects, we allow the code of

> the algorithms to gain access to object internals (such as domain object

> private methods) if needed. We need to add new interfaces to domain objects

> only for business-level functionality that is germane to the use case, rather

> than adding low-level access methods needed by the use case.

Specifically, I'm having trouble coming up with an example for role's accessing object's private methods as described in the passage below.  If the objects are dumb data, what private methods are we talking about?  And perhaps more significantly, is this just a matter of source file level separation of the "data object" methods and "role" methods?  That is, if the role's have full access to the internals, isn't the coupling the same as the case where we have data objects bloated with use case methods (classic 1000 line Rails AR class), except with the advantage that the use case methods are now together in their own file?  More importantly, if the roles do depend on the private methods of the data objects, don't those private methods just become part of a de facto public interface?

I feel I must still be missing something... I need that concrete example.

> Does this mean that procedural design is completely dead? Of course not. There

> are still algorithms that are just algorithms (Freud’s “sometimes a cigar is

> just a cigar”). We can encapsulate algorithms in the private implementation of

> classes using procedural decomposition. There’s nothing wrong with that.

> However, those concerns are rarely architectural concerns; we leave those to

> the cleverness of designers and architects as they come to low-level design and

> the craftsmanship of implementation.

What's a good example of an appropriate time to do this, versus a time when it's clearly not ideal?

On Sunday, January 3, 2016 at 9:03:47 AM UTC-6, Matthew Browne wrote:

Hi Jonah,
You can get a lot of the benefits of DCI from doing what you described, but there are important differences and unique advantages of DCI. These benefits are not that obvious in simple examples like the money transfer, but become more apparent with larger use cases (...one of the reasons we need more larger examples).

That's a good FAQ entry that Andreas pointed to. We have also discussed this question quite a bit on this list, although the relevant posts are a bit buried...

Here's the most recent thread where we discussed this (quoting from myself):
https://groups.google.com/d/msg/object-composition/pzwEHIZGPis/0vJUz9FtntAJ

On 12/7/14 6:56 AM, Hai Quang Kim wrote:

In that  sense, Context is a meta instruction/system operation that can recursively use sub-instruction/sub-operation.

So we just need to put Role Objects in, it all depends on how the programmer implements that Context.

The result is important.

That is about 90% of DCI, a network of OO or a set of functions run on that set of Role Object is less important to me.

I don't think this is even close to 90% of DCI - the OO concepts are arguably the most important part. And don't forget that there's OO in the data model too - "what the system does" is only half the system in the first place (the other half is "what the system is").

In many examples, to have a few lines of readable DCI, the cost now I need to pay is to type many Role Classes, maintain Stack of Contexts....

In a few cases I even need to change the compiler to make it work.

Can we at least encourage people to scale down DCI to DCA so that they start to have the benefit of DC_A/I?

And no need to wait until we can convince all of the programming language authors to provide us an official way to do pure DCI.

Yes, taking some inspiration from DCI and keeping use case logic together is great and is something I try to do when working on non-DCI projects. But it's important to be clear that it's not DCI. Even calling it a substitute for DCI would be a stretch - better to call it what it is: a mix of procedural programming (for the use cases) and object-oriented programming (for the data model). Cope mentioned his book on multi-paradigm design, and we have also previously discussed Ant's concept of "micro SOA" on this list. I think such approaches offer big advantages over traditional OO for projects with significant use case logic. But DCI has advantages that go beyond that, as is hopefully becoming clearer as you explore it further...

Another thing I have noticed when working with the absence of roles is that often there's behavior that's tied to a particular object, but it's only needed in a particular context (or maybe two contexts), so I find myself not wanting to put it into the domain class because those get messy if they have too many methods, and also it might need to interact with other objects specific to a context. But if I just put it as a method in the service class (or whatever you're using to encapsulate the use case), there's no good sub-grouping for the roles.

One from Rune:

On Wed, Dec 10, 2014 at 9:19 AM, Rune Funch Søltoft <funch...@gmail.com> wrote:

> Den 10/12/2014 kl. 15.09 skrev Hai Quang Kim <wan...@gmail.com>:
>
> I am trying to challenge the need of OOP in Context to see what I am going to loose if I simplify that. What I am going to win is: no trait, no Context stack, and the easy of applying DCI in any programming language.

The ability to express several mental models through the use of compression and composition and through that you'll loose the ability of communicating with stockholders in terms of their mental model of the system and because of that you'll loose validation opportunity which will impact quality and/or cost
(Talking about larger complex systems here, if simple or small for all sake you could use assembles with no loss) :)

Finally, here's a quote from Lean Architecture:

Why not Put the Algorithm into a Procedure, and Combine the Procedural Paradigm with the Object Paradigm in a Single Program?

This is the old C++ approach and in fact is the approach advocated in Multi-paradigm design for C++ (Coplien 1998). The main problem with this approach is that it doesn’t express relationships between related algorithms, or between related algorithm fragments, that exist in the end user’s head. It obfuscates the role structure. These algorithms are not single closed copies of procedural code, but they play out through object roles.

A scenario that runs through objects frequently needs intimate knowledge about those objects. A closed procedure can access the internals of an object only through its public interface. If we put the use case scenarios in closed procedures, it would cause the interfaces of the objects to bloat to support this close relationship between the use case and the objects. By instead injecting the procedure (bit by bit) into the objects, we allow the code of the algorithms to gain access to object internals (such as domain object private methods) if needed. We need to add new interfaces to domain objects only for business-level functionality that is germane to the use case, rather than adding low-level access methods needed by the use case.

Does this mean that procedural design is completely dead? Of course not. There are still algorithms that are just algorithms (Freud’s “sometimes a cigar is just a cigar”). We can encapsulate algorithms in the private implementation of classes using procedural decomposition. There’s nothing wrong with that. However, those concerns are rarely architectural concerns; we leave those to the cleverness of designers and architects as they come to low-level design and the craftsmanship of implementation.

Coplien, James O.; Bj&#248;rnvig, Gertrud (2011-01-06). Lean Architecture: for Agile Software Development (p. 296). Wiley. Kindle Edition.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.

To unsubscribe from this group and stop receiving emails from it, send an email to object-composition+unsub...@googlegroups.com.

To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[Matthew Browne]

On 1/4/16 8:56 PM, Hai Quang Kim wrote:

After learning DCI, I look at my code base (11 mil of c++/C# code).

A few things I can see it in different ways now: (replace number with your number)

1) less than 1000 LOC, procedural programming will do well enough

2) more than 1000+ LOC, procedural programming starts to fall, classic OOP can do well

3) more than 10K LOC, classic OOP starts to fall, and DCI OOP may do better

So the problem is about scaling not about coding an example...How good you can scale your code base (LOC, number of people, number of features...)

DCI really shines with large, complex use cases, but I disagree with these guidelines. To me it's more about the nature of the problem being solved. Small projects / use cases can sometimes benefit from DCI too, it's just that the differences from procedural or class-based code are more subtle then. As I mentioned in my previous post, I don't think there's much value in DCI for simple CRUD, for example, because that doesn't involve very much use case logic or object interaction.

[Rune Funch Søltoft]

> Den 5. jan. 2016 kl. 17.15 skrev Matthew Browne <mbro...@gmail.com>:
>
> DCI really shines with large, complex use cases, but I disagree with these guidelines. To me it's more about the nature of the problem being solved. Small projects / use cases can sometimes benefit from DCI too, it's just that the differences from procedural or class-based code are more subtle then. As I mentioned in my previous post, I don't think there's much value in DCI for simple CRUD, for example, because that doesn't involve very much use case logic or object interaction.

Personally I find size and complexity is irrelevant. DCI lets me approach the work entirely different. In a way that can't be achieved with procedural nor class oriented. I can get close with FP but the code ends up more scattered. That's also one of the reasons I don't think an example is really helpful. DCI differentiates itself in the entire process. Simple or complex that difference is substantial even when the difference in the resulting code is hard to see

[Jonah S]

Thanks for the reply, trygve.

Sorry I can't be more helpful.
BTW, I have been told that the hardest tasks facing text book authors is to device simple and illustrative examples.

This rings very true.  I think it appease not only to text book authors, but to anyone looking to communicate complex ideas well.  Finding good examples is very hard, but doing it well reaps great rewards.

Based on what you wrote, I'd add that (for me at least) a "killer app" example isn't even necessary, though of course it would be nice.  But really, a half baked, not exactly right but still illustrative example will probably work too.  I can probably fill in the blanks.  I'm just looking for something specific to hang my hat on.  Something that says: Here's the standard OO way, here's the DCI version, where I can see the advantages.

Jonah

[Trygve Reenskaug]

Now I was really disappointed, Jonah. I had hoped you would offer to start writing DCI code while looking for the missing example. Instead, you ask me to do more work for you ... This begins to smell like trolling to me -- I hope I'm wrong.

[Raoul Duke]

While I understand Trygve's comment, I didn't see Jonah's as trolling.

If somebody wants to sell (in a good way) DCI and doesn't have such a
clean example that shows DCI vs. OO then I think they are doing
themselves a disservice. Expecting others who are as yet unconvinced /
still ignorant to make those cases could well be seen as selfish
and/or lazy.

Overall, rather than attributing trolling or selfishness to
any/everybody, it would probably be OK for both parties to simply say
they don't want to make the demo / comparison, and leave it at that.
:-) The world will have to wait for some sucker/dogooder/sales person
to do it later, then.

[James O Coplien]

> Den 05/01/2016 kl. 21.03 skrev Raoul Duke <rao...@gmail.com>:
>
> If somebody wants to sell (in a good way) DCI and doesn't have such a
> clean example that shows DCI vs. OO then I think they are doing
> themselves a disservice.

O.K., Raoul, let me put up the same challenge I did earlier: Give me an example that shows that OO is better than Algol 68. The arguments must be immune to attack. If you can do that then I can maybe believe that it could be possible for DCI. But I remember all such examples from the early day of OO and they involved inheritance hierarchies with zoo animals. I for one was never convinced, as I’ve never written software for zoo animals.

[Matthew Browne]

+1

It's clear to me, at least, that Jonah is genuinely interested in
understanding DCI. Trygve, I understand why you reacted as you
did...some of Jonah's recent posts are basically saying, "write me an
example now!" rather than emphasizing what I think is the underlying
issue, which is having difficulty connecting all the abstract
theoretical texts about DCI with something more concrete to understand
it better. (Jonah did mention the latter too, but he keeps talking about
wanting an example.) I think at this point you have more than adequately
expressed that you need to see more DCI code in action to understand it
better, and we get that (or at least I do). It's reasonable to request
examples, but given that we are currently somewhat lacking in that
department, please remain open-minded and let us help you in other ways
as well.

[Raoul Duke]

> O.K., Raoul, let me put up the same challenge I did earlier: Give me an example that shows that OO is better than Algol 68. The arguments must be immune to attack. If you can do that then I can maybe believe that it could be possible for DCI. But I remember all such examples from the early day of OO and they involved inheritance hierarchies with zoo animals. I for one was never convinced, as I’ve never written software for zoo animals.

well, for starters, Do you think OO >> Alogl68 after all? Otherwise
the lack of good examples proves the point! ;-)

[James O Coplien]

> Den 05/01/2016 kl. 21.20 skrev Raoul Duke <rao...@gmail.com>:
>
> well, for starters, Do you think OO >> Alogl68 after all? Otherwise
> the lack of good examples proves the point! ;-)

This is a serious question. I am trying to help you to see the futility of such an exercise. Or do you give up already? If so, please don’t do so by avoiding the question.

[rune funch]

2016-01-05 20:49 GMT+01:00 Jonah S <jona...@gmail.com>:

Something that says: Here's the standard OO way, here's the DCI version, where I can see the advantages.

That's one of two points in this (which I posted earlier) the advantages can't be seen so much as experienced. Sure DCI claims more readable code and I believe that to be the case but only significantly/easier dicernable for substantially complex domains because one of it's strong suits is not scatter the use case all over the place. There's no way to show that in a _small_ and _simple_ example. Trying to design a system using the approach in lean architecture or the above talk might give you what you are looking for though. Quang tried it out came back asked questions related to his experiments, experimented some more and the result was one of the steepest learning curves I've seen on this list. I'd say it was even steeper than mine eventhough I had Cope as my personal mentor when I was learning DCI. To be honest I started out believing that Cope and Trygve had simply given IoC a new name. I didn't believe in the idea and I didn't experiment. My own personal learning didn't start until I decided that I would want to believe that it was a paradigm not just a new name for somethign old. My experiment was writing a language which I wrote from scratch and rewrote several times before I abandoned it completely, to take the shorter road now known as Marvin because I wanted to prove a point. That DCI could be done injectionless (which I'm no longer sure it actually can). A few years back Trygve, Cope and I met in Oslo and discussed DCI. We all learnt something new about DCI and we challenged some standing definitions as well. We learned because we experimented. Most of them thought experiments but experiments none the less. Some of the learnings I had during those days have been the basis for quite a few of my replies since then.

I had been doing DCI for several years when wroc_love invited me to give a talk. While I was preparing for the talk I wrote the first version of maroon. The first version was not written in DCI style but in cowboy style. I rewrote it during the conference and while doing so, experimenting how to I learned something new. The point is even working together with one of the founders of DCI I didn't learn anything until I started experimenting with DCI. I think that is true for most, probably all, people that understands DCI.

[Raoul Duke]

Since all code sucks and everything depends on context, I agree that
one cannot write examples that are iron clad proofs of Paradigm A
being always better/worse than Paradigm B. But I don't see how that
means nobody should ever do compare-contrast examples for A & B ever
at all never on way. That seems like a rather fallacious conclusion,
that it is all pointless.

[Raoul Duke]

I agree that a lot of judgments are really to be done based on
personal experience! Zen baby!

But I do not see how that means nobody should try to work on making
small compare-contrast examples of dis/advantages. E.g. pick the thing
you hate most about the maintenance phase of OO and then say how DCI
makes that less bad. And try to boil it down to some straw man
sketches so that people can get the gist of it.

I am not saying anybody has to do that. I am saying I don't see what
would be bad about it if somebody wanted to do that, or if somebody
else thought they could perhaps understand things better if such
examples existed.

[James O Coplien]

Den 05/01/2016 kl. 21.24 skrev rune funch <funchs...@gmail.com>:

The point is even working together with one of the founders of DCI I didn't learn anything until I started experimenting with DCI.

Rune,

If you’re implying that I was a worthless teacher, then

I am at peace that my Buddhist side as sensei has taken the right path

Things like this can be learned, but cannot be taught.

[James O Coplien]

That is my point. What is being asked for is a demonstration of superiority.

But since you are still evading my question I’ll let you off the hook with a side-by-side comparison from which one could argue the relative merits of the two approaches. I just want you to succeed at this, and you seem a whole lot less confident about it than you did three mails ago.

[James O Coplien]

If you are confident, why don’t you just do it?

Enough of the meta stuff in Emails already. Put your money where your mouth is.

[Raoul Duke]

Uh, no, I don't think Rune was saying that. Overall this ambiance
today makes me feel like what happened on the Artima article
discussion where I do think you and Trygve were oddly seeing thew
worst in everyone's notes. $0.02.

[James O Coplien]

I don’t think you appreciated (as I’m sure Rune did) that this mail pays a great complement both to him and, even moreso, to his astute observation of how things work.

No problem, no sweat.

Now, as for you — don’t use this as another distraction taking you away from that example.

;-)

[Raoul Duke]

> That is my point. What is being asked for is a demonstration of superiority.

If someone is asking for proof that Paradigm A is superior in all ways
to B then that is a trolling or ignorant or unrealistic or day dreamy
thing. If somebody is asking for how some aspects of A are better than
B and for some examples of that, it doesn't strike me as clearly
trolling.

If somebody is saying A *is* better than B (e.g. DCI is better than
MVC) then if when they are asked why they say, "one finger pointing at
the moon" that is their choice, and I can understand that approach.
But I think it is rather unrealistic :-)

[James O Coplien]

So when I read:

Something that says: Here's the standard OO way, here's the DCI version, where I can see the advantages.

I read that you, too, are saying that the writer has one finger pointing at the moon?

Glad to see you changing your mind and substantiating the point the Rune, Trygve and I have been trying to make.

In the mean time: Stop stalling. To the example.

[Raoul Duke]

> Now, as for you — don’t use this as another distraction taking you away from that example.

If somebody asks you to do something, you can of course graciously
decline. And if they say it in a rude way you can all tell them to
piss off. :-) If I say it didn't seem weird or rudely posed, to me,
for them to make the request, then I do not see how that means I am
saying I should do what they asked.

I think this conflation comes up with both you and Trygve often cf.
here and Artima.

sincerely.

[James O Coplien]

All right, I’ll piss off, then ;-)

But I am disappointed that you put so much energy into saying someone should come to the rescue of your argued position by writing an example to substantiate it, yet you are unwilling — or unable — to do it yourself.

I choose to read the latter, and that’s the end of it.

[Raoul Duke]

> Something that says: Here's the standard OO way, here's the DCI version,
> where I can see the advantages.
>
> I read that you, too, are saying that the writer has one finger pointing at
> the moon?

I don't follow. I didn't write that, it was the OP who did.

What I am continuing to try to point out is that if the OP wants it
for every aspect of the paradigms then that is
unrealistic/ignorant/possibly trolling, yes BUT I don't see why it
can't be a reasonable request when sufficiently constrained.

There are many Paths, and one of them is induction! :-)

[James O Coplien]

> Den 05/01/2016 kl. 21.49 skrev Raoul Duke <rao...@gmail.com>:
>
> I don't follow. I didn't write that, it was the OP who did.

I know that. But just in case you had lost track, that was at the foundation of this discussion.

As I said: case closed.

[Raoul Duke]

> But I am disappointed that you put so much energy into saying someone should come to the rescue of your argued position by writing an example to substantiate it, yet you are unwilling — or unable — to do it yourself.

Er, I think I wrote more than once probably that I didn't expect
*anybody* to write any examples. I wrote (attempted to say) that
asking for examples in order to help people grok the points isn't an
outright silly thing to ask for, imho.

[James O Coplien]

> Den 05/01/2016 kl. 21.50 skrev Raoul Duke <rao...@gmail.com>:
>
> Er, I think I wrote more than once probably that I didn't expect
> *anybody* to write any examples. I wrote (attempted to say) that
> asking for examples in order to help people grok the points isn't an
> outright silly thing to ask for, imho.

It is just a rewording of the same. You are willing to expend the energy advocating that an example is a good idea, but are unwilling to spend any time actually doing it yourself.

End of story.

[Matthew Browne]

To echo what Raoul is saying, I think we should keep these two things in mind:

1. Examples are important and very helpful when learning a new paradigm

2. Examples alone, without understanding of theory and experimentation, fall far short of being an effective learning approach (that's an understatement).

#2 does not contradict #1. I think more examples would certainly help people to better understand DCI, and asking for them (once or twice) is very reasonable. But there should not be any expectation that just because someone sees an example, some aspect of DCI will immediately be understood. Maybe Jonah had such a mistaken expectation, but I think rather that he was hoping to see an example as an aid to his learning process to better understand the value of role-binding in particular...and after all, he has already spent a lot of time learning the theory (though apparently not actually practicing much yet). I don't think a single example would be able to showcase that because his question is bigger than I think he realizes, but an example could still be helpful (and perhaps some of the existing ones I mentioned will be).

--
Sent from my Android device with K-9 Mail.

[Raoul Duke]

> It is just a rewording of the same. You are willing to expend the energy advocating that an example is a good idea, but are unwilling to spend any time actually doing it yourself.

I do not understand why advocacy always requires more action.

I advocate reconsidering the 2nd amendment.
I advocate you floss and brush.
I advocate I should go exercise more.
And a zillion other things.

These are otherwise known as having opinions. I do not understand why
any of those things requires that I fly over there and do the flossing
and brushing for you. Or that if you say you don't want to do them
that I'm a jerk for holding the opinion. etc.

I really do not see how there can be any strong claim that advocacy
logically requires or is utterly not allowed w/out action beyond the
advocacy.

[rune funch]

2016-01-05 21:30 GMT+01:00 James O Coplien <co...@gertrudandcope.com>:

If you’re implying that I was a worthless teacher

On the contrary, I was stating that even with one of the best teacher I could have hoped for, I still didn't learn much until I personally invested in it

[James O Coplien]

Den 05/01/2016 kl. 21.58 skrev Matthew Browne <mbro...@gmail.com>:

I don't think a single example would be able to showcase that because his question is bigger than I think he realizes, but an example could still be helpful

From a pedagogical and historic perspective I have to strongly disagree even with the last part. Individual examples leverage some level of pre-existing understanding, and the OP had not yet demonstrated enough proficiency even in the most rudimentary concepts to benefit from such an example.

A suite of examples can help an informed practitioner see the pattern. That’s called a book, or a thesis, or the material within the syllabus of a university course, and from a pedagogical perspective takes time (months, years) to develop.

*Playing with* examples is the path to learning. It’s funny that that was Kay’s whole point in object orientation: that a Skinner-style “programmed learning” approach based on examples and relative value assessment (rewards, like a pigeon getting a piece of corn) was a dead end, but that exploration provided learning options. And Kay literally meant exploration through writing programs. I have never seen him mention example programs — only cases where students responded to an energizing question within them.

Single examples are highly contextualized. The MoneyTransfer example targeted a particular learning gap and abstracts away much of the reality of real banking software. The book moves towards a more realistic example, but even it is somewhat undercontextualized. So a good example isn’t just code — it’s code, plus support for the contextualization. We can argue about whether this mailing list can be or should be the means for such discussion. But it is not a site that can go to the level of basics that we’re at in these discussions right now. These same questions have recurred in this space countless times over the past 7 or 8 years. There are books, papers and seminars out there which serve as the traditional entry point for someone serious about learning a new technology. The only time I asked the question about whether such resources had been consulted, the respondent dodged the question.

I think that coming here and asking for an example is really asking for free consulting. It’s trivial to Google them on the web. As noted, coming here asking for on-the-spot examples even smacks of trolling. We need to decide whether this mailing list can be that. Matt, you were the one who said not to let Cope dissuade further interaction, and that you would be more than willing to offer help. If you want to field those questions, more power to you. I’d propose perhaps setting up an alternative mailing list so the rest of us won’t have to re-read the same answers every time someone asks. (We once had that — remember? — and then got back to the point where most people coming here had done their homework, so we folded the other list. Maybe it’s time to re-enact that list.)

Last, and most important, examples can mislead. Even the best examples from the very best are misleading. Early C++ books — some by the creators of C++ — showed the superiority of inheritance over case statements for being able to draw shapes. They also showed a hierarchy of different kinds of windowing systems. They work fine individually but when you try to write a function that draws a shape on a window, C++ simply can’t do it. To appreciate the power of the technology you often need slightly scaled examples. (And in this case, C++ itself couldn’t scale to solve the problem! Maybe that’s because it was written according to simple examples… But the point is, the individual examples were terribly unillustrative and even misleading about the fundamentals beneath OO.)

I can name you countless examples from OOPSLA papers that individually could (and did) take people down the wrong path. I do think examples can help, but they must be very carefully constructed with learning gaps in mind, must complement each other and build on each other, and rarely work in isolation. A formal background in learning gap analysis and even´curriculum development can help. Yes, there is a science to this, and there are methodologies for developing such material, and I don’t think many people here have a clue about it.  There’s no reason to believe that they should. And I think that’s the real reason that Raoul balked — any single example is simply too easy to attack.

If you disagree then I’ll put the same challenge to you: to develop the examples.

[James O Coplien]

Den 05/01/2016 kl. 22.20 skrev rune funch <funchs...@gmail.com>:

On the contrary, I was stating that even with one of the best teacher I could have hoped for, I still didn't learn much until I personally invested in it

O, I got that.

Again,we’re violently agreeing with different words.

[James O Coplien]

> Den 05/01/2016 kl. 21.59 skrev Raoul Duke <rao...@gmail.com>:
>
> I really do not see how there can be any strong claim that advocacy
> logically requires or is utterly not allowed w/out action beyond the
> advocacy.

This is not an advocacy forum, in my opinion, and we do not vote. We come together to work, or not. We can contribute technical insights as part of the work.

Advocacy that you’re not willing to back up will, at least in my case, fall on deaf ears.

[Jonah S]

trygve,

Just wanted to say I am definitely not trolling, even though yes I am asking for something.  Just clarifying the scope of my request is not as big as (it seemed) you thought it might be.

I had actually considered trying my hand at doing something like writing Tetris with DCI (as best as I understand it), and posting the code, and letting the DCI experts tear into it and let me know how it could be improved or made more truly DCI.  That would probably take me a few hours at least, and I'd do it if people were willing to give specific feedback.  But based on the discussions, it seems like the response I would get is an explanation about why tetris wasn't a suitable candidate for discussing DCI, or why it was impossible to rewrite my code sample in a more DCI style.  

You haven't said this trygve, but the claim from cope and rune, at least, based on the other comments that were posted today, seems to be that DCI can't be learned from examples, and that indeed even asking for an example merely illustrates a fundamental understanding of DCI's nature.  cope has said it's like asking for an example showing why OO is better than algol, as if that demonstrates the absurdity of the question.  But of course books on OO are filled with examples of procedural code rewritten in an OO style, along with an explanation of the advantages.  And that's all I've ever been talking about.  I don't want a philosophical proof of superiority, and I don't want to raise deep questions about what better means in this context.  

If DCI really is so abstract that examples have no place in learning it, I think I have misunderstood it.  Because my interest in it has always been as a method for making real code readable and maintainable and faithful to the natural way that I think.  If it can't be used to rewrite poor example code in a better way, I don't see how it can possibly achieve those goals.

I'm willing to be the guinea pig for any experiment, and put in more time and effort, but I'm willing to spend more time having abstract discussions.  Because honestly, I feel like I'm the one being trolled.

On Tuesday, January 5, 2016 at 2:59:59 PM UTC-5, trygve wrote:

Now I was really disappointed, Jonah. I had hoped you would offer to start writing DCI code while looking for the missing example. Instead, you ask me to do more work for you ... This begins to smell like trolling to me -- I hope I'm wrong.

On 05.01.2016 20:49, Jonah S wrote:

Thanks for the reply, trygve.

Sorry I can't be more helpful.
BTW, I have been told that the hardest tasks facing text book authors is to device simple and illustrative examples.

This rings very true.  I think it appease not only to text book authors, but to anyone looking to communicate complex ideas well.  Finding good examples is very hard, but doing it well reaps great rewards.

Based on what you wrote, I'd add that (for me at least) a "killer app" example isn't even necessary, though of course it would be nice.  But really, a half baked, not exactly right but still illustrative example will probably work too.  I can probably fill in the blanks.  I'm just looking for something specific to hang my hat on.  Something that says: Here's the standard OO way, here's the DCI version, where I can see the advantages.

Jonah

[James O. Coplien]

I think it was PJ Plaugher who said that the (only? best?) way to learn a programming language was by writing a compiler for it.

It’s how I learned C++.

Den 05/01/2016 kl. 21.24 skrev rune funch <funchs...@gmail.com>:

[Matthew Browne]

On 1/5/16 6:22 PM, James O. Coplien wrote:

I think it was PJ Plaugher who said that the (only? best?) way to learn a programming language was by writing a compiler for it.

It’s how I learned C++.

Again, a good statement on how to thoroughly understand something. But it's raising the bar awfully high if you're suggesting that DCI can only be used effectively by those who have written a DCI implementation of their own. And it's certainly not the first thing I would suggest for a beginner to do to learn DCI (more like something that might be a good exercise after already being somewhat proficient in writing DCI code).

We don't need to -- and definitely should not -- raise the bar that high. DCI can be used both by those who take the time to become DCI experts, and those who aren't aiming for expert level (at least not initially) but can still gain a lot of practical benefit from it (I include myself in the latter category, hopefully on the path toward greater mastery as time goes on).

I think our community should welcome both kinds of people, as long as they are willing to be good students. Otherwise, saying that DCI is aiming to make programming more understandable to everyone is a blatant lie, and is counterproductive to our aim of growing the community and getting DCI out there in the world (note that I do not mean dumbing it down or appealing to the widest audience possible just for the sake of popularity). I know that you and Trygve truly cherish the vision of sharing DCI with a growing number of people from many backgrounds, both technical and non-technical. So it's puzzling to me why you seem to be making the barrier to entry so high that it's completely unfeasible for many busy professionals. Asking someone to read a book and several articles is one thing. Insisting that they read volumes of books and write their own compiler is quite another.

[Matthew Browne]

I wonder if a good starting exercise for Jonah might be to write a mixed-paradigm (procedural) version of the shopping cart example and see how it compares with Marc's DCI version. Or maybe that wouldn't be the best exercise because the DCI version is already complete (although of course he could try out variations on it)... Thoughts anyone?

--

[Matthew Browne]

On 1/5/16 4:27 PM, James O Coplien wrote:

Den 05/01/2016 kl. 21.58 skrev Matthew Browne <mbro...@gmail.com>:

I don't think a single example would be able to showcase that because his question is bigger than I think he realizes, but an example could still be helpful

From a pedagogical and historic perspective I have to strongly disagree even with the last part. Individual examples leverage some level of pre-existing understanding, and the OP had not yet demonstrated enough proficiency even in the most rudimentary concepts to benefit from such an example.

DCI is very heavy on theory and abstract explanations about its advantages (for good reason). That wasn't always my perception as a beginner -- many of the concepts are very well-explained and illustrated in the articles - but it was certainly my perception with regard to a number of aspects of DCI. And of course much of my learning has happened through this group, where we all have limited time and often the answers to questions need to be concise due to those time constraints and because the purpose of this group is not to offer "free consulting", as you put it. Many of those answers were encouraging me to practice on my own and "do my homework", all of which was valuable.

But as valuable as all of those theoretical conversations were, I also think that discussing real-world examples was a vital part of my learning process. As just one example, discussing how to approach the shopping cart use case with Marc certainly contributed a lot to my understanding. I don't think these examples would have been helpful without the reading, thinking, and experimenting I was also doing, so I understand what you're saying about the shortcomings of examples.

If there had been a larger body of community examples (particularly larger examples) when I was first learning DCI, I think it would have enhanced my learning process even more. It's very possible of course to learn DCI with the great number of published materials already available, and spending time practicing (and/or using it in real projects). And I know that we have many competing priorities, and I'm not sure where creating more examples fits in at the moment. But I think you are overly downplaying the usefulness of examples as one part of the learning process. Examples help people to connect the dots between the abstract and the concrete so they don't have to fill in all the blanks on their own. Some people are better at filling in those blanks than others, or maybe find they can understand one concept that way but not another.

Having said all that, your post did make me realize some shortcomings of examples which I hadn't thought of, and I'm certainly not promoting them as a panacea.

I do think examples can help, but they must be very carefully constructed with learning gaps in mind, must complement each other and build on each other, and rarely work in isolation. A formal background in learning gap analysis and even´curriculum development can help. Yes, there is a science to this, and there are methodologies for developing such material, and I don’t think many people here have a clue about it.

I agree. That's exactly what I think is missing! I know that it's a lot of work to create a good curriculum of examples and that this will take time.

Matt, you were the one who said not to let Cope dissuade further interaction, and that you would be more than willing to offer help. If you want to field those questions, more power to you. I’d propose perhaps setting up an alternative mailing list so the rest of us won’t have to re-read the same answers every time someone asks. (We once had that — remember? — and then got back to the point where most people coming here had done their homework, so we folded the other list. Maybe it’s time to re-enact that list.)

I do think that the multiple purposes of this group are part of the problem - I was going to mention that. I think it leads to muddled conversations sometimes when we're getting deep into engineering discussions about the trygve language, or about the evolution of DCI, and at the same time we're fielding beginner questions or questions from people who are still trying to decide whether to invest in DCI at all.

Like you, I don't want this to be a tutorial group either - I'm not advocating for hand-holding every step of the way. I'm just asking that we be a little more understanding and avoid giving people the impression that DCI is so enormously complex and requires such a huge investment of time and study that it's impractical for them to decide whether it's even worth their time. How can we help a lot more people benefit from DCI if we're giving that impression? Rune pointed out that a "leap of faith" is required with DCI, and I agree. But my point stands.

As to creating a new tutorial group, it's a good idea but I'm not sure how practical it is at this point, given the small size of our community. I could be involved in such a group but I have limited time and would not be able to answer everyone's questions on my own. Maybe if others here would be interested in helping out with that, it could work...

But I don't think we have to give up on our current setup (one single mailing list) just yet. Things had been going well for quite a while, and I think we can probably still get back on track. And I think we can do so without either becoming a tutorial group or conversely, giving off the wrong vibe to newcomers. But it will take more awareness from everyone here about how we communicate, as I explained previously.

Honestly, what I would like most of all at this point is to get back to substantive discussions. This discussion about the culture of our group is an important one, and I didn't want to leave your email unanswered. But it's taking a lot of time and I for one would like to refocus. I welcome you to reply to this email, but after that maybe we can postpone the remainder of this discussion till later...

[Rune Funch Søltoft]

> Den 6. jan. 2016 kl. 00.11 skrev Jonah S <jona...@gmail.com>:
>
> I'm willing to be the guinea pig for any experiment

I think that's a really good way to learn. That was the point of my previous post. What you would need is a system where multiple objects interact/communicate. If in your Tetris that's the case then that could be your experiment. Take the design approach from the wroc_love talk and write it up. Not the end result but the intermediate steps. If in the end you have a few good contexts then rewrite the end result into class oriented code and notice whether it's easy or feels awkward. My money is on the latter. If you do that experiment I'll invest time in it but I or any one else can't help you by giving you the result and I'm guessing that's not have you were taught math either

[Jonah S]

Rune, you seem like a good guy, after all.  Honestly.  But on further reflection, I've decided this is not an environment where I want to spend any more time.  I've already answered many of my own questions.   More to the point, though, the style of discussion I'm interested in is, essentially, off-topic here.   Which is totally cool.  It was my mistake.  I wish everyone the best of luck.

[Egon Elbre]

I believe there are several issues with newcomers.

1. This forum looks like a regular forum -- however it's more a research work-group.

First suggestion, let's add some sort of introductory text for the forum, what is expected of people, who discuss here and how the work is done. Google groups allows to add a text here:

See https://groups.google.com/forum/#!forum/golang-nuts for an example.

I'm sure Cope/Trygve can write something better, but:

Welcome to object-composition, it is a DCI research work-group for improving the state of programming.

Fastest way to understand DCI is to write a few examples, we suggest starting with Dijkstra. It's expected that you have done or tried to do that before asking questions.

 

For more information see ...

This would help to orient newcomers to the attitude and how work is done on the mailing-list.

2. If we truly improve state of the art, we should be able to demonstrate it without people having to take a leap of faith. This is not about whether they understand DCI or not. I mean "A Pattern Language" has lots of examples, with regards how having a pattern is objectively better than not having it and without watering down the content. You can look at a pattern and say, "Yes, this is better" -- but yes you may not understand the full picture.

It would be possible to demonstrate that each piece of DCI improves clarity. Roles make sense because and here is the comparison. Object Schizophrenia worsens things because and here is how it breaks down etc. Wrapper worsens things because ...

I totally agree that to truly understand DCI is to write code with it. (And, yup, I went through the same problems as many.)

3. There's lack of clarity in what DCI is, which means that anyone coming from outside can get easily confused. Saying that it is a "new paradigm", although correct, says little to most people. Saying what it's goals are, says very little about the thing.

It seems that the materials always cover "thinking" and "technical" aspects together, with a lot of history in-between. For programmers it's easier to understand the technical aspects, which means that it's really easy to get stuck in it, and they just skip the history part.

For me, most of the value from DCI has come from the "thinking" aspect, not from the "technical" things. I cannot remember a case of object-schizophrenia from poor-man's DCI, that wasn't facilitated. Of course, I'm not saying the "technical" aspects aren't important.

a. The introduction to DCI should start with Role modeling, how it is related to the world.

... probably some more thinking parts, i.e. System / Interaction etc.

b. Then the importance of mental-model mapping directly to code.

c. And finally all the gritty technical aspects.

This helps to layer up the knowledge, without having something "easy" to get stuck into.

[Egon Elbre]

On Wednesday, 6 January 2016 09:07:31 UTC+2, Jonah S wrote:

Rune, you seem like a good guy, after all.  Honestly.

Note, people here are actually friendly. The tone is harsh and direct, because it helps to get more things done, faster and gets messages across clearer. Pleasantries just get in the way. Of course, looking from outside, it might look like hostility.

[James O Coplien]

Den 06/01/2016 kl. 02.25 skrev Matthew Browne <mbro...@gmail.com>:

If there had been a larger body of community examples (particularly larger examples) when I was first learning DCI, I think it would have enhanced my learning process even more.

The key point here is that you need a body of examples — not, as all recent posters have been asking, a Demonstration of Superiority. As you say, a body of examples can be a part of the learning process. But they need to be designed. They don’t stand alone (that was part of the danger of many of the OO examples I discussed earlier), so they need a lot of supporting material, and it’s non-trivial to create that material. It’s hard to develop a set of examples. I know, because I’ve done it (not only for DCI but for other design approaches and programming languages as well).

So I think you confuse my pushback on individual examples with disdain for an example-aided approach. I think you confuse my admonition that this is a non-trivial job with a refusal to support the use of examples. The distinction is difficult in this medium. So let me be concise and clear:

1. A body of mutually supportive examples is useful.

2. Such a body of examples does not stand alone.

3. What has been requested here, and what the topic of discussion is here, though it is called “examples,” is the request for something “hang one’s hat on,” for “[s]omething that says: Here's the standard OO way, here's the DCI version, where I can see the advantages.” It seems like they are looking for a sales pitch, marketing brochure, or watered-down abstract of a case study. If they were serious they would be asking for a case study. But they’re asking for something they feel can be done in 10 or 15 minutes.

4. We should not confuse what is being requested in #3 with what you asked for and which I refer to in #1. And we are.

And, last,

5. We already have such a path for people to learn about DCI, and several bodies of examples.

6. That path requires investment and time, in contrast to the 10- or 15-minute expectations that folks have brought to the table.

Those unwilling to make the commitment to the learning path have often in the past worn us down looking for the shortcut. It is better that they discover early that it is not appreciated here, and that they either become lurkers or leave. We have made one step of progress in this area in the past day.

It's very possible of course to learn DCI with the great number of published materials already available, and spending time practicing (and/or using it in real projects). And I know that we have many competing priorities, and I'm not sure where creating more examples fits in at the moment.

If we don’t know where it fits in, it is counterproductive to shine a spotlight on it. Let’s first figure where it fits in. Part of my goal of this mail is to answer that question. It is a question that we thought about many years ago and we did what we did, and we have the examples that we have. My involvement in developing them builds on the insights from 35 years of teaching experience and from basic pedagogical theory. Any further effort should be equally well-grounded.

More broadly, I think that the way forward is for individuals to develop of vision of where X fits in and to rally people around the vision, and then take it forward. Just suggesting that someone do it only builds frustration and has all the social trappings of developing guilt. Whining that “we need X” is not being part of the solution. It is in fact being part of the problem. That was my frustration with Raoul’s mails.

But I think you are overly downplaying the usefulness of examples as one part of the learning process

No. I agree with you that examples are valuable. But we don’t have enough, and we’re not going to be able to have them jump out of the woodwork when someone new appears on the scene and gets upset because we don’t have examples to deliver on a silver platter. This will take a concerted group effort. If you want to convene a group to build a gap analysis and to build some examples and other pedagogical support for it, you’re welcome. The amount of effort is on the order of development of a two-day course but is short of the effort for writing a book. It is certainly greater than the effort for writing a compiler, and for trygve that’s sizing up to be about a one-year job.

That said: I spent many years developing examples, stories, and models, and have packaged it into a book. I spent many months building a course around the book. If people are serious (I mean serious) about learning this material then, as you say, the examples are out there. One just has to buy the book or attend the seminar. I’ve avoided much saying “buy my book” here on this list because I hate commercial promotion on a list as much as anyone else. But I still think it exactly fits your fantasy of what prep materials should look like. The examples are online to play with.

I have also packaged the material into a seminar, and I give them every once in a while. The next one is coming up in Brussels soon. Egon attended the last one. I now know that Egon is serious about learning DCI and contributing to it; he in fact has been a major contributor to the trygve effort, and it couldn’t have happened without him. I am going to focus my attention on supporting those kind of people because I think the payoff goes with the evidence of passion through the idea, evidenced by making the commitment to reading a book or attending a seminar. As you say, there are only so many squirrels in the cage and I can focus my effort either on the seminar or on hand-holding. I’m willing to do hand-holding, but for people who have first been through some introductory step to master the basics.

In the mean time, my earlier many years’ work on developing the examples and pedagogical materials is still paying dividends again and again. The examples in them are valuable. They don’t stand alone — as you said, they are one part of a learning process. They are designed to go together with the supporting material in the book and the seminar, and are delivered together; the examples do not stand alone as a corpus. So we have a set of examples. Stop whining. ;-) Sign up for the course. Buy the book. If you don’t like those, develop your own.

I have often sent the message here that more people should give talks and seminars about DCI. We all have those opportunities. I think those have bigger leverage than hand-holding — at least at the introductory. But, like I said in an earlier mail, if you want to do the introductory hand-holding, you’re welcome to spend your time that way. I’d just suggest that this may not be the site where we should do that. It’s more like consulting than teaching / learning. And this isn’t an elementary learning site. As I just peeked ahead at a recent mail from Egon, we’re a research site. There is great learning in research, in exploring the au courant ideas that build on our common understanding of DCI basics. We need examples at that level, too, and they’re very unlike the examples that either serve consulting or which fit the needs of elementary pedagogy. As I said in my mail yesterday, the Money Transfer example wasn’t created as a stellar example of how DCI might be used (I don’t expect a lot of people to start writing banking systems in that style, but it’s not an unreasonable request, to quote a pundit of our time) but as a description of how DCI works, that also taps into common mental models and, to go meta, into the very concept of mental models and their importance to the DCI milieu.

As for examples, I await more from you. I am currently in the process of weaving examples into the trygve tutorial I am writing (part of the GitHub distribution). I’ll likely include the shopping cart example (if that’s O.k., Marc). Indeed, the whole focus of developing trygve was to be able to support the creation of new examples that allow us both to evaluate and to teach DCI in a setting less cluttered by the trappings of the current languages we are using.

[James O Coplien]

Den 06/01/2016 kl. 00.47 skrev Matthew Browne <mbro...@gmail.com>:

So it's puzzling to me why you seem to be making the barrier to entry so high that it's completely unfeasible for many busy professionals.

It’s puzzling to me that you extrapolated my statement that far. I am stipulating no barrier. I’m not even making a suggestion.

There are several efforts going on here: one set furthers DCI as a way of development, and the other is exploring ways to realise it. We often mix the two. You certainly don’t need to have implemented a compiler to contribute powerfully to the discussion about the paradigm; done right, it should touch on issues of philosophy and culture. In fact it is frustrating when the discussions go down to the level of whether a binary expression evaluation should terminate once it is known that further evaluations won’t change the answer. I think the nerd side of us tolerates and even celebrates that, but I think it’s hardly what we’re here for.

So, taking a page from Raoul’s book, let me be clear that I don’t expect people to go out and start writing compilers.

On the other hand, Plaugher isn’t the only one to have said this and, when it comes to programming language, I think he’s right. So what he says does apply to the trygve effort and, I think, to the Marvin and Maroon efforts. As I said at the outset, the early work will tolerate input in the usual fashion of discussion we have here. Very soon I’ll start suggesting that people provide their suggestion as a pull request on the GitHub instance.

Going a step further, I think those that take the effort to implement a browser, an environment, a compiler, an impact-of-change evaluator, or a visualiser, learn things about the paradigm that few will ever learn just by programming. I do hope that we end with a raft of languages to draw on, whose features we can evaluate, if these languages (and their environments) are cheap to build. That, too, is lean — it’s called set-based design. A friendly bake-off wherein we can explore options. Rune and I are having dinner tonight and we’ll likely be trading notes; as he said, we’ve in the past gotten together with Trygve and we’re long overdue for a reunion. Maybe we should have a small conference. So, again, taking a page from Raoul’s book, while I don’t expect a whole bunch of compilers to pop out of the woodwork, it is not an unreasonable thing to ask.

And I’m not even asking, or suggesting. In bringing up the Plaugher quote I was just trying to demonstrate that those of us who have built “compilers” (Rune, Trygve, myself, Rickard Öberg, Egon’s work in Javascript, and a few others) probably should be looked to as having some deeper insight than those who are approaching the material vicariously. Andreas is quickly becoming the world’s expert on trygve, with a good number of working programs under his belt. (By the way, he can probably offer some insights into why good examples are hard — though he has written several programs I think he’d tell you that only a few of them really show off DCI). I was just honouring that Rune had put in the effort, and maybe suggesting that the insight one gets is proportional to what effort one puts in. Writing a compiler is probably the most powerful way, but I think there’d be a lot of honour for anyone who coordinated a community effort to develop a suite of examples….

[Matthew Browne]

+1.  As I have said, the problem isn't about what we're discussing and doing here, it's about the impression we're giving the outside world. I think that if people knew that this is a research work-group going in, that would be a big step in the right direction.

[Marc Grue]

On Wednesday, January 6, 2016 at 12:23:55 PM UTC+1, cope wrote:

I’ll likely include the shopping cart example (if that’s O.k., Marc).

Absolutely. 

Feel free also to use any of the comments there too if you can find anything useful (the use cases for instance). I tried to sum up the thoughts we had for doing each variation there.

Cheers,

Marc

[Matthew Browne]

I don't think I explained what I mean about the examples well enough, and I apologize for that. In retrospect I realize why it sounded like I was (perhaps impatiently) asking you, Trygve, and others to create more examples. That wasn't what I meant at all. I was simply pointing out that I think a larger body of examples would be helpful, which we clearly agree about. I greatly respect the wisdom and experience of you and Trygve and I think you should proceed however you see fit with regard to the creation of future resources and the evolution of DCI in general.

The point of my comments about examples was that even with all our current resources and examples, it can be very hard for a newcomer to connect all the dots, and we should be sensitive to that. If someone asks a question because they are still confused about something after reading quite a bit about DCI, we shouldn't immediately assume the worst of their intentions and imply that they're lazy. As to the culture of the group, it seems there are still some critical misunderstandings to be cleared up before we move on, so I'll clarify myself as concisely as I can...

The point I have stated again and again which you still seem not to have acknowledged is how our goals of sharing DCI with the world can be obstructed by giving off an impression that we are unfriendly and unhelpful and that DCI is so complex that it requires an unfeasibly large investment of time to understand even the basics. I don't think you or anyone here is doing that intentionally, but I do think a lot of people end up getting that impression, much more than you may be aware. Some more comments inline...

On 1/6/16 6:46 AM, James O Coplien wrote:

Den 06/01/2016 kl. 00.47 skrev Matthew Browne <mbro...@gmail.com>:

So it's puzzling to me why you seem to be making the barrier to entry so high that it's completely unfeasible for many busy professionals.

It’s puzzling to me that you extrapolated my statement that far. I am stipulating no barrier. I’m not even making a suggestion.

I didn't mean to put words in your mouth, and I may have gone too far here. I read too much into your comment, and it's not accurate to say you're demanding that someone write a compiler in order to pass some barrier to entry. But your tone and comments when you begin to suspect laziness could very easily give that impression to someone new to our community.

On the other hand, Plaugher isn’t the only one to have said this and, when it comes to programming language, I think he’s right. So what he says does apply to the trygve effort and, I think, to the Marvin and Maroon efforts.

I'm not sure if you were hinting something here, but FYI, I have worked on DCI source transformation solutions (in addition to pseudo-DCI implementations like for PHP and native Javascript of which you're aware). Granted that's not the same as building a true compiler, but it still requires a significant investment in understanding DCI to do it. I recently got an initial proof-of-concept working for a new source transformation solution for Javascript with a real parser (which I will be presenting to the group soon), and I also earlier wrote an implementation for Typescript. And writing those implementations has indeed helped me to understand DCI more deeply.

Those unwilling to make the commitment to the learning path have often in the past worn us down looking for the shortcut. It is better that they discover early that it is not appreciated here, and that they either become lurkers or leave. We have made one step of progress in this area in the past day.

But the thing is, Jonah was willing to make the commitment. I believe that if we hadn't implied that he was lazy and outright accused him of trolling but rather simply explained why his request was unfeasible, he would not have announced today that he's leaving the group, but rather would be happily working on some experiment or suggestion we gave him. Of course, now that we have responded the way we did, he is apparently no longer interested in making that commitment. Perhaps he was on the fence as to whether DCI would even be valuable to him at all, and rather than give him more insight into its value we have instead given him a bad impression of our community.

Finally, a point that many people seem to have missed is that Jonah was not asking for us to show him a single short example to explain ALL of DCI, but rather only one of its many concepts. The thing that I don't think Jonah is aware of is that in order to understand the value of role-binding in DCI, you have to understand a lot of its concepts - role binding is a central piece of making it all work that really ties into a lot of DCI fundamentals. He was also perhaps not aware of the shortcomings of examples for explaining that concept in and of themselves (but of course if we already did have more examples, that might have been a good aid to his learning). So his request was based on some misunderstandings, but that doesn't make it an unreasonable request, nor do I think he was looking for "free consulting" but rather a little help and guidance to help him get past a stumbling block in his learning process.

[rune funch]

2016-01-06 12:23 GMT+01:00 James O Coplien <co...@gertrudandcope.com>:

Den 06/01/2016 kl. 02.25 skrev Matthew Browne <mbro...@gmail.com>:

If there had been a larger body of community examples (particularly larger examples) when I was first learning DCI, I think it would have enhanced my learning process even more.

The key point here is that you need a body of examples — not, as all recent posters have been asking, a Demonstration of Superiority. As you say, a body of examples can be a part of the learning process. But they need to be designed. They don’t stand alone (that was part of the danger of many of the OO examples I discussed earlier), so they need a lot of supporting material, and it’s non-trivial to create that material. It’s hard to develop a set of examples. I know, because I’ve done it (not only for DCI but for other design approaches and programming languages as well).

Once again expressing the same thoughts in different words. I decided to write up a blog post that tries to describe my view. I decided on a blog post for something I can refer to in similar situations. Feel free to ignore/comment/suggest improvements

http://runefs.com/ 

[James O Coplien]

Den 06/01/2016 kl. 14.44 skrev Matthew Browne <mbro...@gmail.com>:

I didn't mean to put words in your mouth, and I may have gone too far here. I read too much into your comment, and it's not accurate to say you're demanding that someone write a compiler in order to pass some barrier to entry. But your tone and comments when you begin to suspect laziness could very easily give that impression to someone new to our community.

Let me clarify that, in this case, a cigar was just a cigar.

On the other hand, Plaugher isn’t the only one to have said this and, when it comes to programming language, I think he’s right. So what he says does apply to the trygve effort and, I think, to the Marvin and Maroon efforts.

I'm not sure if you were hinting something here, but FYI, I have worked on DCI source transformation solutions (in addition to pseudo-DCI implementations like for PHP and native Javascript of which you're aware). Granted that's not the same as building a true compiler, but it still requires a significant investment in understanding DCI to do it. I recently got an initial proof-of-concept working for a new source transformation solution for Javascript with a real parser (which I will be presenting to the group soon), and I also earlier wrote an implementation for Typescript. And writing those implementations has indeed helped me to understand DCI more deeply.

I include such work in what I was referring to, and you’re certainly one who has made the investment.

Those unwilling to make the commitment to the learning path have often in the past worn us down looking for the shortcut. It is better that they discover early that it is not appreciated here, and that they either become lurkers or leave. We have made one step of progress in this area in the past day.

But the thing is, Jonah was willing to make the commitment. 

Neither of us can speak for him. I do not believe he was. His actions support my perspective. Someone else on the list wrote to me off line pointing out, with relief, that Jonah had been “unmasked."

[James O Coplien]

Den 06/01/2016 kl. 14.44 skrev Matthew Browne <mbro...@gmail.com>:

I don't think I explained what I mean about the examples well enough, and I apologize for that. In retrospect I realize why it sounded like I was (perhaps impatiently) asking you, Trygve, and others to create more examples. That wasn't what I meant at all. I was simply pointing out that I think a larger body of examples would be helpful, which we clearly agree about. I greatly respect the wisdom and experience of you and Trygve and I think you should proceed however you see fit with regard to the creation of future resources and the evolution of DCI in general.

No sweat.

The point of my comments about examples was that even with all our current resources and examples, it can be very hard for a newcomer to connect all the dots, and we should be sensitive to that. If someone asks a question because they are still confused about something after reading quite a bit about DCI, we shouldn't immediately assume the worst of their intentions and imply that they're lazy. As to the culture of the group, it seems there are still some critical misunderstandings to be cleared up before we move on, so I'll clarify myself as concisely as I can…

If a newcomer wants to commit to learning this, there are many community resources that are adequate to get started. That is what I hear you failing to acknowledge;-) We as a list are not Mecca. And I don’t think we should cater to people who come here expecting to be spoon-fed. That was the sense in which Jonah was “unmasked.”

The point I have stated again and again which you still seem not to have acknowledged is how our goals of sharing DCI with the world can be obstructed by giving off an impression that we are unfriendly and unhelpful and that DCI is so complex that it requires an unfeasibly large investment of time to understand even the basics. I don't think you or anyone here is doing that intentionally, but I do think a lot of people end up getting that impression, much more than you may be aware. Some more comments inline...

My counter is that people approach us with rude, unproductive, and unprofessional expectations. I would *never* approach a stackoverflow.com forum with the nature of questions that are on the table right now. There on stackoverflow there is stong community moderation. Here we have none.

It *is* a paradigm shift and requires an *investment* in learning. If people come here not realising that, they’ll end going away like a gun half-cocked. It is not an unfeasibly large investment of time (you are extrapolating again :-) ).

[James O Coplien]

Den 06/01/2016 kl. 08.13 skrev Egon Elbre <egon...@gmail.com>:

I believe there are several issues with newcomers.

1. This forum looks like a regular forum -- however it's more a research work-group.

First, this is the kind of thing I meant about making a concrete vision and trying to rally people around the vision, with an implied commitment of putting skin in the game.

Second, I have been an academic and a researcher — an academic’s academic (holder of the Vloebergh Endowed Chair at VUB) and a Researcher’s Researcher (a Principle Investigator in Bell Labs Research). From what I qualify as “research” this is not a research group. The closest thing to research I’ve done on the DCI front involved attalk I gave at the Simula Centre in Oslo, where I looked at the computation complexity of both the usual OO subtyping-based inclusion polymorphism model and DCI. It appears that “regular OO” is overly computationally complex for the nature of the problems it solves and that DCI is much simpler — a perfect fit to the complexity of the problems. One can formalize the models of computational complexity of the two, and I tried to entice someone in the audience to take up that research agenda. (To my knowledge it never happened.)

The only other case I can think of is the research behind the Elephant Paper, which is a somewhat playful articulation of a taxonomy that arose from research into historic paradigm development in the OO milieux. It is research in the sense that Brachman’s “I lied about the trees” paper is AI research.

What I see us doing here is more like engineering. It is rooted in very real everyday problems. It requires immersion in the code and can be amplified by social discussion. This is a powerful group in that respect and we’ve learned a lot here, together, by stumbling our way along. It hardly follows the rhythms of a research program and its language is hardly research language. I’ve seen nary a Greek letter here.

Third, before we make such a pronouncement… I’d like to gather a little more data. From Quang, if he’s willing. Quang came here impressed with the potential of the work and a promise to explore what DCI was all about. He was immediately welcomed by three or more people, *all of whom pointed him to existing examples or references*. It was quite a while before he even came back with questions. I know there was some noise about whether his application was pure DCI or just the best he could do under his current architectural constraints, but I think that’s more a reflection on his work situation than on either his ability or desire to understand.

So, Quang, if you’re willing to share — how did you perceive this group and your process of coming on board? As a research group? As a resource group? As a place, as Raoul implied, to come with advocacy for advancing some position — kind of a super Santa Claus?

The reason I ask is that I don’t want to make it less likely that we get more people like you, and I think that labeling the group as a research forum may do that.

[James O Coplien]

a commendable read!

[James O Coplien]

Den 06/01/2016 kl. 08.13 skrev Egon Elbre <egon...@gmail.com>:

a. The introduction to DCI should start with Role modeling, how it is related to the world.

... probably some more thinking parts, i.e. System / Interaction etc.

b. Then the importance of mental-model mapping directly to code.

c. And finally all the gritty technical aspects.

Again: I like the concreteness as a foundation for something to discuss.

I wonder that if before Roles we need people to understand use cases? The Roles to me are a way of chunking use cases in two dimension: one, chunking them along the time dimension so the parts (Role methods) can individually be understood, and, two chunking together Role methods that are mutually coupled in the traditional sense of coupling. I suppose one could start anywhere, including with Roles, but I think use cases provide the necessary context (literally and figuratively) to give Roles meaning.

I think a good way to illustrate Roles is with CRC cards, at least as a metaphor, and perhaps as a “best practice” design technique.

Then come Contexts — pretty easy, as the administrative unit around a use case — and, finally, Role / object bindings.

Weaving the theatre metaphor through all of this helps tie it together.

I am musing out loud and asking for feedback because I am in fact right in the middle of putting this content into the .docx file that comes with the trygve distribution. I’d love to have some input.

[Matthew Browne]

StackOverflow is a good example. If someone comes to StackOverflow with a well-written question and is respectful of the people answering it, there is a great community effort to give a good answer. Yes, there is an expectation of professionalism and it's not about hand-holding, but I think what's happening here is different -- immediately assuming the worst of people and implying that they're lazy. People get called out for being lazy on StackOverflow too but only if the question clearly demonstrated laziness and/or lack of respect. Well-meaning people don't react well to such implications and get turned off even if they were previously eager to learn and do whatever homework is needed. I'm sure some of the people really are lazy, or want to spend only a small amount of time trying to understand DCI and then immediately start challenging it, which of course is unfair and annoying. But between the tone of some of our responses here and the wrong impressions we're giving about the barrier to entry being incredibly high, I think we're turning a lot of people off from DCI in a way that is sad and unnecessary, and as I said before, could ultimately lead to DCI being nothing more than a footnote in history.

If a newcomer wants to commit to learning this, there are many community resources that are adequate to get started. That is what I hear you failing to acknowledge;-)

Yes, I acknowledge that. I am saying that we can improve on those resources, not that a smart and dedicated person can't learn DCI from the resources we already have. But if someone has already gone through those resources and is still struggling to understand the value and distinction of DCI from other approaches, we shouldn't respond in a way that actually dissuades them from wanting to pursue it further or makes it seem like even basic DCI is unsuitable for dedicated and open-minded adults with limited time, let alone children who aren't mature enough yet to understand advanced concepts and theory.

[James O Coplien]

Den 06/01/2016 kl. 16.16 skrev Matthew Browne <mbro...@gmail.com>:

StackOverflow is a good example. If someone comes to StackOverflow with a well-written question and is respectful of the people answering it, there is a great community effort to give a good answer. Yes, there is an expectation of professionalism and it's not about hand-holding, but I think what's happening here is different -- immediately assuming the worst of people and implying that they're lazy. People get called out for being lazy on StackOverflow too but only if the question clearly demonstrated laziness and/or lack of respect. Well-meaning people don't react well to such implications and get turned off even if they were previously eager to learn and do whatever homework is needed. I'm sure some of the people really are lazy, or want to spend only a small amount of time trying to understand DCI and then immediately start challenging it, which of course is unfair and annoying. But between the tone of some of our responses here and the wrong impressions we're giving about the barrier to entry being incredibly high, I think we're turning a lot of people off from DCI in a way that is sad and unnecessary, and as I said before, could ultimately lead to DCI being nothing more than a footnote in history.

I see our responses and conduct as having been perfectly in line with what I see on stackoverflow.

If we took the open approach that you are advocating with Kay’s original ideas of OO back in 1972, then real OO would have taken a place in history where it is only a footnote, buried under all the crap that an inclusive policy of toleration spawned. Maybe that is why, as Rune points out, Kay says that there is really only one OO system extant and surviving in the world today.

I’ve been through too many Sorcerer’s Apprentice episodes. You’re still young and perhaps you haven’t yet been burned. Ten times burned, twice cautious.

If a newcomer wants to commit to learning this, there are many community resources that are adequate to get started. That is what I hear you failing to acknowledge;-)

Yes, I acknowledge that. I am saying that we can improve on those resources,

Then let’s do it.

not that a smart and dedicated person can't learn DCI from the resources we already have. But if someone has already gone through those resources and is still struggling to understand the value and distinction of DCI from other approaches, we shouldn't respond in a way that actually dissuades them from wanting to pursue it further or makes it seem like even basic DCI is unsuitable for dedicated and open-minded adults with limited time, let alone children who aren't mature enough yet to understand advanced concepts and theory.

As I said in my other post: I don’t see any theory here. None. A theory is a set of formalisms that attempt to explain some phenemology. There indeed could be a lot of theory here and, if anyone else is interested in exploring issues of computational complexity and decidability, I’m happy to take that up here. Or if anyone is interested in exploring Dansky’s theories or other theories of developmental psychology, relevant to how we roll out DCI in trygve, then we can indeed can get into that. Bring it on. Sharpen up your Greek quill pen. I’m taking up those discussions in another community. This discussion group is, unfortunately, a theoretical desert, because people are blinded even to the childlike simplicity of the basics. 

I think it may look like research (a handy pejorative term implying “elitist” to outsiders just because it’s different from their life experience, which should be a good reminder to go read Kuhn again). It reminds me of the Heinlein quote, “Any sufficiently advanced technology is indistinguishable from magic.” To the masses this looks like high academic magic. But that’s a label. I don’t care if they use academic means or experimentation to come on board. It will take people some research effort to understand DCI: heck, even going to the library and reading up on something is research. But it will take people an intense focused effort to overcome the prejudices they have built up.

That’s a problem that child learners don’t have. Some people have been able to approach us a child learners; others want to impress us with how clever they are. There’s a high correlation of success with one of these and failure with the other. I frankly don’t know what more we can be doing about it that we’re not doing already. Again: I think your suggestions, though well meaning, have a track record of causing the good to drive out the perfect. And here, just the good isn’t good enough.

[Egon Elbre]

On Wednesday, 6 January 2016 17:06:39 UTC+2, cope wrote:

Den 06/01/2016 kl. 08.13 skrev Egon Elbre <egon...@gmail.com>:

a. The introduction to DCI should start with Role modeling, how it is related to the world.

... probably some more thinking parts, i.e. System / Interaction etc.

b. Then the importance of mental-model mapping directly to code.

c. And finally all the gritty technical aspects.

Again: I like the concreteness as a foundation for something to discuss.

I wonder that if before Roles we need people to understand use cases?

To me it's somewhat different. Roles and interaction are a way of seeing the world. Use Case simply gives roles, context and interaction the clarity required to describe interaction fully.

I would introduce Use Cases after objects, roles and interaction; because objects, roles and interactions are more fundamental to how people think. And I don't mean the final definitions as in DCI, but rather the idea of roles and interaction in our thinking.

In other words:

1. objects (how people describe the world)

2. roles and interaction (how people describe behavior)

3. use cases (how to give specificity for 1, 2)

4. problems with converting our mental model to computation (why it's necessary to use that model)

5. Objects (as in OO)

6. Role, Context (as defined in DCI)

7. mapping them into code

8. the impact of writing the code that way

9. technical issues with getting the mapping right

Pieces 1-3 are fundamental, because that is what we want to represent in code. 4 prepares people for getting technical, and also makes sure that people understand why it necessary to keep code as close to 1-3 as possible. 5-6 is how we can represent and think about them in our computation. 7 how it can be represented in code.

The Roles to me are a way of chunking use cases in two dimension: one, chunking them along the time dimension so the parts (Role methods) can individually be understood, and, two chunking together Role methods that are mutually coupled in the traditional sense of coupling. I suppose one could start anywhere, including with Roles, but I think use cases provide the necessary context (literally and figuratively) to give Roles meaning.

Already mentioning "methods" would give something easy to grasp onto.

When I transfer money, I don't think about methods. Methods are a side-product of mapping a behavior into computation on a Object.

I think a good way to illustrate Roles is with CRC cards, at least as a metaphor, and perhaps as a “best practice” design technique.

I think it would be fine, as long as "class" isn't mentioned when describing it.

[Matthew Browne]

Cope,
I'm just asking that you tone down the harshness of some of your responses at least slightly, to avoid giving wrong impressions that I don't think you yourself intend. In my view such harshness is only warranted for someone who has shown lack of respect and initiative, as opposed to honestly expressed frustration. I guess that's too much to ask. But I don't understand why it's too much to ask -- you could still enforce just as much discipline as at StackOverflow, or even more, without being so harsh and mistrusting of people's intentions.

You’re still young and perhaps you haven’t yet been burned. Ten times burned, twice cautious.

I get that. I think you've gotten a little too cautious and too quick to judge people's intentions. Can you see how that might become a self-fulfilling prophecy about those suspicions in some cases?

Thank you for hearing me out, and although we still disagree, I feel that at least now we are more clear on our disagreement and on areas where we do agree. I hope that you will at least keep my points in mind if you ever have a question in the back or your mind as to whether your response to some question (or just the phrasing of that response) might be misinterpreted and give the wrong impression of DCI or our community.

I think a more productive direction at this point is to discuss Egon's suggestions about better publicly clarifying the purpose of the group and recommended starting points.

Thank you,
Matt

[Marc Grue]

On 06/01/2016, at 16.06, James O Coplien <co...@gertrudandcope.com> wrote:

I wonder that if before Roles we need people to understand use cases? The Roles to me are a way of chunking use cases in two dimension: one, chunking them along the time dimension so the parts (Role methods) can individually be understood, and, two chunking together Role methods that are mutually coupled in the traditional sense of coupling. I suppose one could start anywhere, including with Roles, but I think use cases provide the necessary context (literally and figuratively) to give Roles meaning.

I really like the idea of bringing use cases to the table pretty early in a DCI learning process. Maybe even as some sort of "requirement" for further assistance (or maybe this is taking it too far?). Of course DCI is more than use cases, but use cases are a perfect fit for DCI and plenty of learning material exists to learn to write them. 

If a newcomer is asked to and succeeds in formulating an example problem as a use case then I think the chances of bridging to DCI concepts are raised a good deal. We could continue from a basic understanding of:

1) Roles

2) That Roles are carefully crafted for certain kinds of people/things (objects) to act/play them (role-object contracts)

3) That Roles belongs to and are contextualized in the UC (Context)

4) That Roles pass on responsibilities to the next Role (Interactions in a distributed manner)

5) That deviations (runtime conditions) can cause different scenarios (different networks of Interactions)

6) That a UC (Context) is triggered to initiate the flow starting with one of the Roles

7) That UC can have pre/post-conditions and stake holder requirements (pre/post-assertions?)

8) Implicitly: a mental model of the problem domain

more?...

I don't suggest a 1:1 correlation between UC/DCI concepts but rather conceptual similarities that will help bridge the gap to understand some (not all) DCI concepts (the list above could of course be improved/rearranged, but you get the pedagogical idea...).

Maybe we could to a higher degree expect UCs (even from ourselves) as starting points of examining solutions instead of user stories, algorithms and sparse operations that we often see? The latter can often be a sign of a weak mental model (not a good starting point) and/or nerds itching to get to the technicalities/code immediately. This is why I considered it to be important to write a use case for each ShoppingCart variation.

Cheers,

Marc

[Matthew Browne]

+1 on use cases as a good starting point. I think part of the reason I was able to appreciate DCI even before I understood it very well was that use cases had been part of my curriculum in school. I could see how DCI maps well to use cases (and also some aspects of UML) and could see how that would be valuable for writing better software.

[Hai Quang Kim]

I think nowadays the info is free, and accessible online, so people do not appreciate the info they have.

I remember long time ago when I had no internet access, my teacher gave me one lesson per month, and I spent a month to do it.

Nowadays we have ton of info/lesson to read, it is hard to spend enough time to really understand them all. 

But net citizen even have a bad habit to criticize thing before  really understanding it. We read a lot nowadays, but it is hard to trust everything.

And Yes I did that too when I first approached the forum as normal net citizen expecting free stuffs otherwise my complaint. :)

Yes, learning DCI is very tough thing, but best thing I ever learned.

I did go back read history of computer science, read Trygve's all the papers, read Kay's papers, try out Smalltalk...

go deep to debug BabyIDE with Trygve to get it work with Etoys....

It was not easy, and I am still learning with a blurry canvas in my mind...

But I think I have better understand OO and its purpose. 

And maybe people come here with the 'anger' they have from classic OO, otherwise why would they end up here.

And since they read article about DCI somewhere so they may expect strong medicine to fix the issue.

I always hate classic OOP because of the size of my code base making it super to read and understand stuffs. 

I thought I am more on the procedural programmer.

But when I say good bye to classic OOP, I realized how much I got hooked into it...my thinking, my implementation...

So It is very hard to think in DCI without taking time to really understand what is right/wrong with classic OOP..and unlearn it.

That took me a while too.

Right now I am using poor man DCI in real project, with DCI code in my new feature's island, and using existing system's objects as Role Player.

It is kind of better for reading code, and thinking..... (of course it has its own problem too, but I am happy enough)

It becomes super clear to me which one is better when putting too solutions side by side...I cannot share example code.

But even I show them to a non technical guy he can see the benefit and understand the DCI code.

I think both sides (new comer and experts in this forum), need to be patient. What we are trying to learn/discuss here is not a simple thing.

There will be a gap between expectation, experience....To bridge the gap, it will take time.

Before, whenever Cope said some thing, I replied with a lot of counter questions....which will just go to no where since the main problem is my understanding.

So Now I just take more time to understand what Cope said carefully because it usually comes with a ton of experience hidden in the quote....

This group is more like mix of research/engineering and less like a resource group with well defined solutions, tutors and examples....

But I cannot find any other group that has good defined solution with examples about classic OOP too, that why I am here :)

Moving forward, I like the idea to warn new comers: what they can expect and what they should not.

Doing a lot of exercise is good one, the classic Prokon is good example. We already have DCI version.

It is not hard to find or build the classic OOP version of it and compare it.

I think what Cope trying to say is to focus on people who seriously want to learn or help to explore DCI.

If DCI works and it can help people to solve problems, then more people will use it naturally without selling pitches just like the MVC.

For people who just comes here to look for free stuffs, quick solution, they can wait.... :)

/quang

[James O Coplien]

Golden. Thanks.

These thoughts lead me to my own conclusion that though much of the focus here is on experimentation (in the vulgar sense) and exploration (better terms, I think, than “research” or “academic,” because what we do here is neither) that it is still a good “hang-out” for newcomers who have made the investment in the existing resources.

FWIW: This group was NOT set up as a DCI group, but was set up by Serge Beaumont as a group around the broader concept of “object composition” (which may even have wrongly been named; perhaps it should have been “class composition”). It’s just that DCI has kind of taken over.

For those who do not know some of the other history: We’ve been here before with this problem of focus on the group and, for a while, set up a separate group called dci-evolution. We found that there was enough interest from “lurkers” to follow the experimentation discussions, and enough cross-postings, and a low enough level of posting traffic overall, that it didn’t make sense to continue with both groups. So dci-evolution was mothballed and we came back here. I don’t expect different results were we to try that experiment again.

So my suggestion is (w that we post an introductory message (in the place Egon indicated) suggesting that this is a place for people developing object-composition solutions and for people with enough experience using such systems that they want either to contribute from their posture of experience, or want to just lurk and follow the discussions. I’d add explicitly that it is not a tutorial site. That leaves it a bit ambiguous about whether one can come here and ask for help, which is as I think it always has been. And I do feel people should be able to come and get support and help here — but they should bring issues here that go beyond what the publicly available resources offer. These requests for support and help often shed insight into the ongoing experiments and gedanken experiments.

Just my contribution to Egon’s suggestion.

[Matthew Browne]

At the current time, what do we all think of Trygve's comments from back in 2013? (Note, I added additional emphasis to the Scientific American motto [it was already italic in the original though].)

On Wednesday, September 25, 2013 at 4:54:38 AM UTC-4, trygve wrote:

Originally, this list was for newbies who were curious to learn about DCI.� A helpful community should help them across the chasm from class oriented to object oriented thinking and coding.

I haven't seen any newbies on this list lately. Perhaps they have been frightened away by the esoteric nature of the discussions. Jim created the new evolution list for the kind of discussions we have had for the last month? year? years?.� I admit I have contributed to this sad state of affairs.

One of the DCI goals is that end users shall be empowered to understand DCI programs, to be able to read the code and some may even write code. Things happen in the world around us. I have seen that there is a growing movement "teaching kids programming", [C2P]. A key question is what to teach: Fortran? C? Java?. PHP? One serious contender is MS SmallBasic. I believeDCI is a better choice because a bod can start very simple and grow to full fledged professional programming without ever changing the fundamental model.

My current task is to write an article on DCI aimed at the membership of ACM. It shall adhere to the Scientific American motto:
Never underestimate your reader's intelligence. Never overestimate your reader's prior knowledge.
My readership knows about computing seen from one angle or another. Only a minority has a computer science education. The goal is to build a powerful model of computing in the reader's mind. This means that there must be a minimum of new concepts in the article, and each of them has to be carefully explained. The article describes DCI as I see it. Some key concepts are data, information, data processing; the DCI object with its encapsulation and key class and role abstractions; representation of end user information: Data classes; representation of end user model of data processing with representation of system behavior: messages and methods. And more.

[Matthew Browne]

Note about the Scientific American motto: lest anyone get the wrong impression, I realize that for most programmers, learning DCI is more about unlearning than anything, as Cope pointed out. But I still think it's a good quote. Anyway, I mainly wanted to bring up Trygve's comments about newcomers and ask the group if we think his comments still apply to the current goals of the group.

[James O Coplien]

I agree with the quote’s insight that we had already then moved beyond it being a place for newbies.

And in retrospect, the alternative we set up (dci-evolution) wasn’t very satisfying, and was folded.