[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: succinctness = power
Okay, I want a share of the beer.
Here is how we argued with John V and what convinced him that, at a minimum,
you want to formulate patterns in a formal language.
Read any pattern in the GoF book. Contemplate whether all the terms
have been used in a consistent manner? Whether all the relationships
are described relative to the defined terms?
Read the whole book. Are all the cross-connections consistent? Proper?
Eventually John (and any reasonable person) will see that for something
like that you want a formal language so that you can build simple tools
for checking basic properties.
Now take that one level down. Someone writes that he's using the XYZ
pattern. That helps his psychopathic successor to navigate the code as
promised in the GoF book. Now a series of those successors work on the
code. How do you know whether the N pages of code still implement the
XYZ pattern? It's just a comment. For all you know, these people may
have messed up the relationships.
So at a minimum, you want to be able to say the following classes and
phrases implement an XYZ pattern and some tool can check this. I haven't
read Steve's work, but that sounds roughly like what he implemented.
And now you can go even further: you can provide language constructs that
encapsulate these structural constraints.
At Sun, 26 May 2002 19:53:50 -0400, Sundar Narasimhan wrote:
> Perhaps their biggest weakness is that their initial
> proponents did not demand linguistic mechanisms that would help
> programmers integrate patterns into programs.
> On the other hand, Erich Gamma promised me a beer and an explanation
> for why such a linguistic encapsulation would be a bad idea. I
> haven't had a chance to collect, but I imagine the argument might be
> that it would inhibit further discovery. However, I think the Lisp
> experience suggests contrariwise.
> Shriram: I'll bite. Could you say more why you believe this? I've
> always believed that patterns were useful precisely because they were
> NOT wedded to particular language hacks, and consequently more
> powerful in terms of mapping one programmer's mental constructs onto
> another -- especially when it comes to context-sensitive application.