General talk about software patterns

[Christian Köppe <christian.koppe AT hu.nl>]

Al,

This will definitely be my last mail, as I'm sure that this discussion does not lead somewhere. So here are my last comments:

Just by stating that something is a fact it doesn't become a fact. And in your case it is even more problematic, as your "facts" are obviously not true. That you do not consider this seriously gives me the feeling that you're either not willing or not able to do so. Anyway, you shouldn't base your discussion on the assumption that your claims/ideas are true in order to show that they are.

Here are some terms which I make sure that my students understand before they do small research projects (either research- or subject-related):

- bias
- falsifiable
- literature study
- types of coupling (specifically semantic coupling)

I will not do your work and provide a list with related publications on concepts or other topics (google scholar is your friend). Naturally I would assume that you did this in the beginning of your work on your papers.


As said before, I won't answer again.

Christian

PS: you still claim in your publications on your website that these are also published in the proceedings of PLoP and in the ACM DL, which is still not true. So why don't you remove this notice?

---

Van: Messaging Design Pattern [dsheppard2k AT yahoo.com]
Verzonden: maandag 21 mei 2012 5:01
Aan: Christian Köppe
CC: gang-of-4-patterns AT cs.uiuc.edu; telecom-patterns AT cs.uiuc.edu; ipc-patterns AT cs.uiuc.edu; patterns-discussion AT cs.uiuc.edu
Onderwerp: Realistic Information Model and Concepts

Christian,

I seriously consider all specific feedback that I receive. Either via the list or as part of future work/papers. Obviously the feedback needs to provide specific information based on the paper being discussed. It should be also constructive critism in order to have a rational/logical conversation and move the discussion forward.

I may not agree with someone's views/opinion which is obviously a separate matter.  I have answered your previous specific questions/comments in detail (related to the papers). I appreciate the specificity of your latest question:


"(A) The information pattern family can provide comparable capabilities to the ones
provided by multithreaded and distributed applications/processes, (B) while at the same
time improving overall complexity, decoupling, encapsulation, reusability and scalability.
(C)As a consequence, software engineering processes are also improved in terms of reliability, cost, implementation timeframes and so forth.")

This statement is supported (factual) for several reasons:


The information primitive is Turing complete as demonstrated in the paper. Therefore the first of the part statement is true (A). Any arbitrary technology, including distributed access and concurrency can be implemented using the information primitive:

processInformation (message)


The second part is also factual(B). It should be obvious that messaging and the other information patterns improve decoupling and encapsulation: entities are fully decoupled and encapsulated. The paper covers the rest in detail. I'm not going over all of them as part of this email.

(C) is also factual as expected. If we are able to improve overall complexity, decoupling, encapsulation, reusability and scalability ... it should be expected that cost, timeframes and reliability will be improved as well. This is also supported by the reference implementation of the information patterns and many production quality applications.


Everyone with experience with distributed/multithreaded application can talk about the complexities/costs/delays associated with traditional RPC/multihreaded APIs. Moreover, if a conceptual framework is reused, the cost/timeframe of such implementation is very small. The information infrastructure (plumbing) is already provided by the framework and can be reused with minimum additional cost/time. In general Mutithreaded/RPC capabilities (like remote proxies) cannot be reused.  

It should become obvious that if we don't have to reimplement the concurrency/distributed/asynchronous capabilities, such approach will have an substantial impact on software cost, reliability, timeframes and so forth.

Let us assume that the implementation of a MDP component/package is comparable
to the cost of implementing traditional components/packages based on traditional APIs.
However, it can be argued that MDP component based on a conceptual/messaging API
are simpler: one primitive and a very limited number of message types (READ,
CREATE, UPDATE, SEND, etc). On top of this, individual MDP components/packages can be reused and/or purchased.
 
We still need the specifics about the papers on concepts that you mention. I agree that statements should be supported by specific facts/arguments/documentation/references/etc. I respect everyone's opinions/views. Obviously statements/views needs to be accompanied  and supported by specific facts/documents in order to be more than unsupported opinions/views. As I said, I'll be happy to add any references that may be required.  I'm afraid that specific empirical information is not part of the scope of every technical publication.

I'll address your other points (related to the paper) shortly. I hope this makes sense. As you can see this specific statement is supported by technical facts. It also supported
by a reference implementation of the information patterns and many production-quality applications.

I'm afraid that he traditional API/multithreaded/RPC model is limited. Complexities and shrotcomings are present. A realistic information model, as the conceptual model proposed, provides a more complete (better) model. No point in trying to second-guess nature and its information design patterns and concepts. The mind is best information processor available, so to speak. It is also a 'conceptual engine' based on messaging and the other information design patterns and concepts. Our best bet is mirroring it as part of computer systems and software. 


Regards,

Al