Prev: Abstraction & singleton
Next: event handling issues in presentation model
From: topmind on 1 Feb 2008 14:12
On Jan 31, 10:01 am, S Perryman <q...(a)q.com> wrote:
> topmind wrote:

> > And I don't think it is fair to count a meta-table change as "severe"
> > as an app-code change. Why should adding a new specific publication
> > instance be counted low but adding a new publication "type" be counted
> > high? That does not make sense to me.
>
> If you wish to use "meta-tables" as a *developer* , that is fine.
> But we are not implementing a publications meta-system where the end
> user can define their own publication types.

To be realistic, we should consider it a *potential* change request.
It has a non-zero probability. However, I will agree not to dwell on
it other than as a caveat footnote for this.

-T-
From: topmind on 1 Feb 2008 11:10
There's something messed up here. You didn't write a whole app, merely
a bunch of (repetitious bureaucratic) accessors. Since My approach is
different, I wouldn't have code directly comparable. There is no
apples-to-apples to compare.

And, the issue is YOUR specific claim that a P/R solution will result
in a combinatorial explosion of some kind. It was *not* about being
maintenance-friendly and all those other metrics mentioned, but lots
of duplicate code.

Thus, just show some pseudo-code of what you think would be duplicated
and I'll teach you how to do it without mass repetition.

(I already have 3 runnable examples on my website, I don't need 4.)

-T-
From: S Perryman on 1 Feb 2008 13:53
topmind wrote:

> There's something messed up here. You didn't write a whole app, merely
> a bunch of (repetitious bureaucratic) accessors. Since My approach is
> different, I wouldn't have code directly comparable. There is no
> apples-to-apples to compare.

This is the std "variant record" problem.
But stripped down to an absolute meaningful minimum, in order to allow
you and I to provide, a small (in terms of lines of text) representative
impl that we can discuss on Usenet (which is a media-constrained forum) .

So I do not see what your problem is.

If someone asks me to write a std procedural prog lang (Ada, C, Modula-2
etc) equivalent of the impl I provided, I can do it.

If someone asks me to write a functional programming equivalent, I can
do it.

The sizes (lines of text etc) will IMHO be effectively the same.


What is preventing you from providing a like-for-like equivalent using your
"procedural/relational" , because I cannot see any reason for you not to do
so.


> And, the issue is YOUR specific claim that a P/R solution will result
> in a combinatorial explosion of some kind.

No, that was (in another thread BTW) about what *appears* to be your
solution (based on perusal of IMHO disjointed writings on your website) .

So in order to remove assumption/prejudice/misunderstanding of what you
do/know/understand, I begin this thread.


> It was *not* about being
> maintenance-friendly and all those other metrics mentioned, but lots
> of duplicate code.

I have stated, have I not, on numerous occasions what I consider the issues
of the "variant record" problem to be. In fact, the reason I did so was in
response to a posting by you (way back when) dismissing my comments to
someone.

From the moment you engaged in this thread, you cannot claim you have been
misled, given incomplete information, or anything else. It is you who have
had the opportunity to read the source material. It is you who have chosen
to freely engage in debate therein.


> Thus, just show some pseudo-code of what you think would be duplicated
> and I'll teach you how to do it without mass repetition.

Who said anything about "duplication" ?? Certainly not me.

I suggest you re-read this thread from the very beginning (and the cited
posting from way back when) .


> (I already have 3 runnable examples on my website, I don't need 4.)

There is no requirement for your equivalent to be "runnable" .
Merely that it demonstrates :

1. the concepts/mechanisms you are using for your impl
2. anything in 1 can be shown to be provided by an *existing* prog lang/
env.

I suggest you re-read this thread from the very beginning (and the cited
posting from way back when) .


All the above aside, things remain the same.
When you have your like-for-like equivalent of the publications example
ready, make it available and let us know.


Regards,
Steven Perryman
From: topmind on 1 Feb 2008 16:10


S Perryman wrote:
> topmind wrote:
>
> > There's something messed up here. You didn't write a whole app, merely
> > a bunch of (repetitious bureaucratic) accessors. Since My approach is
> > different, I wouldn't have code directly comparable. There is no
> > apples-to-apples to compare.
>
> This is the std "variant record" problem.
> But stripped down to an absolute meaningful minimum, in order to allow
> you and I to provide, a small (in terms of lines of text) representative
> impl that we can discuss on Usenet (which is a media-constrained forum) .
>
> So I do not see what your problem is.
>
> If someone asks me to write a std procedural prog lang (Ada, C, Modula-2
> etc) equivalent of the impl I provided, I can do it.
>
> If someone asks me to write a functional programming equivalent, I can
> do it.

Only if there are well-defined inputs and outputs from the user's/
customer's perspective. You wrote a type framework with some
*internal* accessors. That is not user-side input and output. The user
does not interact with the accessors; they are an internal thing. Why
should I duplicate your internal framework when my internal framework
would be completely different?

I would be mirroring your PARADIGM/technique, NOT your program's
results (because it has none yet). Is this clear?

You assume that I write procedural programs like you would, perhaps. I
don't.


>
> The sizes (lines of text etc) will IMHO be effectively the same.
>
>
> What is preventing you from providing a like-for-like equivalent using your
> "procedural/relational" , because I cannot see any reason for you not to do
> so.
>
>
> > And, the issue is YOUR specific claim that a P/R solution will result
> > in a combinatorial explosion of some kind.
>
> No, that was (in another thread BTW) about what *appears* to be your
> solution (based on perusal of IMHO disjointed writings on your website) .
>
> So in order to remove assumption/prejudice/misunderstanding of what you
> do/know/understand, I begin this thread.

Just write pseudo-code of a small part of the portion you feel would
be a "combinatorial explosion". Use ellipses etc. if it simplifies
things. I just need to see what you have in mind so I can describe why
I wouldn't do it that way.

>
>
> > It was *not* about being
> > maintenance-friendly and all those other metrics mentioned, but lots
> > of duplicate code.
>
> I have stated, have I not, on numerous occasions what I consider the issues
> of the "variant record" problem to be. In fact, the reason I did so was in
> response to a posting by you (way back when) dismissing my comments to
> someone.
>
> From the moment you engaged in this thread, you cannot claim you have been
> misled, given incomplete information, or anything else. It is you who have
> had the opportunity to read the source material. It is you who have chosen
> to freely engage in debate therein.

You made a claim of procedural "combinatorial explosion", did you not?
That's all I am interested in here. One can study the payroll example
if they want a general P/R-vs-OO example.

>
>
> > Thus, just show some pseudo-code of what you think would be duplicated
> > and I'll teach you how to do it without mass repetition.
>
> Who said anything about "duplication" ?? Certainly not me.

Combinatorial explosion usually implies duplication when refering to
code. If you meant something else, then I apologize. Remember, I
cannot read your mind.

>
> I suggest you re-read this thread from the very beginning (and the cited
> posting from way back when) .
>
>
> > (I already have 3 runnable examples on my website, I don't need 4.)
>
> There is no requirement for your equivalent to be "runnable" .
> Merely that it demonstrates :
>
> 1. the concepts/mechanisms you are using for your impl
> 2. anything in 1 can be shown to be provided by an *existing* prog lang/
> env.
>
> I suggest you re-read this thread from the very beginning (and the cited
> posting from way back when) .
>
>
> All the above aside, things remain the same.
> When you have your like-for-like equivalent of the publications example
> ready, make it available and let us know.
>
>
> Regards,
> Steven Perryman

-T-
From: S Perryman on 2 Feb 2008 11:39
topmind wrote:

> S Perryman wrote:

>>topmind wrote:

TM>There's something messed up here. You didn't write a whole app, merely
TM>a bunch of (repetitious bureaucratic) accessors. Since My approach is
TM>different, I wouldn't have code directly comparable. There is no
TM>apples-to-apples to compare.

>>This is the std "variant record" problem.
>>But stripped down to an absolute meaningful minimum, in order to allow
>>you and I to provide, a small (in terms of lines of text) representative
>>impl that we can discuss on Usenet (which is a media-constrained forum) .

>>So I do not see what your problem is.

>>If someone asks me to write a std procedural prog lang (Ada, C, Modula-2
>>etc) equivalent of the impl I provided, I can do it.

>>If someone asks me to write a functional programming equivalent, I can
>>do it.

> Only if there are well-defined inputs and outputs from the user's/
> customer's perspective. You wrote a type framework with some
> *internal* accessors. That is not user-side input and output. The user
> does not interact with the accessors; they are an internal thing. Why
> should I duplicate your internal framework when my internal framework
> would be completely different?

> I would be mirroring your PARADIGM/technique, NOT your program's
> results (because it has none yet). Is this clear?

The program doesn't have "results" , it has *purpose* .
The purpose being for the given example, for me to show how a type
subsitutibility solution does the following for the "variant record"
problem :

- how the specific variants are defined and implemented

- how the properties of each specific variant are used/manipulated in a
simple program (that creates the instances, then reads the property
values)

- how each specific variant can be used/manipulated as an instance of a
entity that has properties common to *all* variants (the "publication"
type)


And then for you to provide your "procedural/relational" equivalent.
Thats' all there is to it.


> You assume that I write procedural programs like you would, perhaps. I
> don't.

Then *SHOW* us what you do "write" then.
Now is the time to correct any mis-assumption that I and others may or
may not make about what you do and don't do.


>>What is preventing you from providing a like-for-like equivalent using your
>>"procedural/relational" , because I cannot see any reason for you not to do
>>so.

This question is going to be asked again and again ...

What is preventing you from providing a like-for-like equivalent using your
"procedural/relational" , because I cannot see any reason for you not to do so.


> Just write pseudo-code of a small part of the portion you feel would
> be a "combinatorial explosion". Use ellipses etc. if it simplifies
> things. I just need to see what you have in mind so I can describe why
> I wouldn't do it that way.

Just provide your equivalent of the Publication example, as I have
concisely and precisely described it. Once I have your equivalent, I will
then show you that, and much more.


>>I have stated, have I not, on numerous occasions what I consider the issues
>>of the "variant record" problem to be. In fact, the reason I did so was in
>>response to a posting by you (way back when) dismissing my comments to
>>someone.

>> From the moment you engaged in this thread, you cannot claim you have been
>>misled, given incomplete information, or anything else. It is you who have
>>had the opportunity to read the source material. It is you who have chosen
>>to freely engage in debate therein.

> You made a claim of procedural "combinatorial explosion", did you not?
> That's all I am interested in here. One can study the payroll example
> if they want a general P/R-vs-OO example.

See above.


>>>Thus, just show some pseudo-code of what you think would be duplicated
>>>and I'll teach you how to do it without mass repetition.

>>No said anything about "duplication" ?? Certainly not me.

> Combinatorial explosion usually implies duplication when refering to
> code.

No it doesn't. It means no such thing.
The term "combinatorial explosion" means that when a number of factors
come together, the total *number* of possibilities (combinations)
"explodes" (ie becomes an increasingly large number) .


> If you meant something else, then I apologize. Remember, I
> cannot read your mind.

Don't bring mind-reading into it.

All a reader of this thread can see at the moment is the following :

You have been given a specific challenge.
You immediately asked for clarification on various things.

Then you went away for a day, and came back, not with what everyone
assumes (a legitimate assumption BTW) would be a simple equivalent,
but with a raft of excuses and evasions about why you haven't answered
the challenge.

The way things are looking at the moment is that this "procedural/
relational" thing that you proclaim, doesn't actually exist. It is a
figment of your imagination at worst, incapable of solving the basic
"variant record" problem at best.

Of course (once again) , providing your equivalent is the most emphatic
way of answering all the claims of your detractors, is it not ...


Regards,
Steven Perryman
First  |  Prev  | 
Pages: 1 2
Prev: Abstraction & singleton
Next: event handling issues in presentation model