Re: Declarative constraints in practical terms

Frank Hamersley wrote:

> dawn wrote:
> > Frank Hamersley wrote:
> >>dawn wrote:
> >>>Frank Hamersley wrote:
> >>>>dawn wrote:
> >
> [....]
>
> >>Your agenda is to discredit it, not to inform yourself. More artifice!
> >
> > My agenda is as I have stated it (better, faster, less expensive s/w
> > dev), all other points are in support of that. I never intended to
> > discredit the RM until I decided that it was not the most helpful model
> > for software developers to use after studying it.
>
> Regardless, as you say that point has been passed - the RM is not
> credible from your perspective. The rest is needless sugar coating.

The RM is definitely credible. The mathematics of it is credible. It brings some desirable features with it when used in practice. I have no more proof that the industry would be well-served to move beyond it than there was proof that we should move toward it a few decades ago. But I do have some reasons to believe that we could improve software development costs if we ditched the Information Principle, for example.

> > My only agenda in using this forum is to inform myself. I have been
> > taken to task by one MV developer who said that by continuing with
> > questions and giving my opinions, it was not helpful to MV. It isn't
> > my intent to harm people in any camp, but to find good solutions.
>
> First I see no malice. Second I see no evolution of your position.

It has definitely evolved, but likely not in directions with which you would agree.

> > I am
> > asking questions until I am either satisfied that I understand a topic
> > or satisfied that I will not understand it better by asking more. If I
> > were to evangelize for MV (which I have done on occasion), I would
> > surely not choose this spot. It takes all the balls I have and then
> > some to participate in this forum ;-)
>
> So RM is not a contender,

It is definitely a contender.

> and the MV promotion is for elsewhere

Or a better way to state it is that it any such "promotion" is in order to state my opinion more concretely. Since I'm not designing a language, but recognizing that there are things I have liked in MV that are not in RM, I use MV to state what I think works.

>- I take
> it then you are waiting at this bus stop for the "real McCoy"?

I'm not just waiting, I'm pushing

> To
> extend the metaphor you must appreciate if you do not embark, at some
> point the driver will close the doors and drive off.

I have products to use, if that is what you mean by embarking. I want to help move the s/w dev industry forward with the tidbits I have. At this point in my studies that means helping people get off the RM high horse and wrestle not only with questions of how something should happen with the database component of s/w development but with the entirety.

Although I think I'm losing in the analogy game with you (and I'm not accustomed to losing in that game!), but I'm going to roll with your foundation metaphor for a minute. What if we found that there was a great, really great, material with which one could pour a house foundation where there was almost no chance ever that the foundation would ever permit water through it. The trade-off was that it cost buckets more to build a house on such a foundation. Should we still build our houses that way because we have avoided this one thing? I have experienced leaks in the foundation of a house and would really, really like to avoid it ever again. So the question is a matter of costs and benefits and of what risks are appropriate for the project.

> >>>>It seems to me no matter what evidence or logical deductions are
> >>>>presented that this state of affairs will not change. Consequently I
> >>>>find interesting that you bother to project any ambivalence at all on
> >>>>these subjects.
> >>>
> >>>You are right that if my inclinations were as you have suggested, there
> >>>would be no point. So, you don't have me pegged right yet, I suspect.
> >>
> >>So you hope - I am not swayed.
> >
> > Have you read my blog? That is where I am giving my opinions in an
> > effort to sway. If you are not swayed by anything I say here, well, so
> > be it (although I like you, Frank, so I'd of course prefer you
> > understood and respected my motivations :-).
>
> I read some of the early posts - but I am generally time poor so it is
> an unreliable act and I have had to limit my interests to CDT alone to
> prevent a run away train. I understand and respect your prime
> motivations which are your own opinions etc - I am more particularly
> addressing your style of presentation which I see as cloaking those
> views to draw in a reader. A web perhaps ;-).

I'll try to understand what you are saying with that, but I'll admit that I don't right now.

> If your convictions are so
> strong why not just present them directly - perhaps it is a Venus/Mars
> thing and somewhat insoluble?

Perhaps, since I think I'm being very direct. "Is Codd Dead?" is not subtle.

> >>>I'm here to learn, not to proselytize, whereas with my blog I am trying
> >>>to write what I have learned and lay out a case for others to consider
> >>>in those areas in which I have an opinion. Here I render opinions,
> >>>too, but it is so that I can find out what I'm not seeing clearly and
> >>>make corrections. I am not nearly as fixed on any particular solution
> >>>as the average RM proponent.
> >>
> >>Heh heh - that is perfectly aligned with how you characterise RM
> >>adherents - rigid and unduly structured, blind to progress whilst you
> >>have to flexibility to reach nirvana.
> >
> > ooooooooooomm
>
> Dang! You're already there?
>
> [..]
>
> >>I guess my interest is somewhat broader - encompassing not only the act
> >>of development, but the whole box and dice. Wholistic (sic) if you like

I saw that after I posted it, having typed it that way twice. Ah well.  Perfection escapes me (or have you noticed), but I'll fix it in the quote, 'cause it is bugging me
.
> > And I was thinking I was being holistic recognizing I wasn't looking
> > at peace on earth, but narrowing it down to what might be termed
> > business data processing. I am looking at developer productivity
> > within that, but that very much includes user success with the
> > software. I'm not looking at developers to just build software faster
> > no matter how good it is. I very much care about the box and dice too,
> > as best I can tell, but I might be missing something. What is the more
> > holistic picture you ae addressing?
>
> Just that, the whole business - not just the data processing and
> definitely not just the programming.

Yes, that is what I thought you meant. I agree that is what I am doing now. I started with the big picture and I'm zeroing in from there. However, I do not want to lose perspective on the whole. So, while tweaking the details, I do need to keep making sure that I'm not just adjusting something like a database data model and then finding that while some small things might be better, the organization or even the larger society is adversely affected by the change. I think there has been plenty of tweaking like that already in our profession. If optimize one thing, we need to ask what the impact is.

> BTW - I don't recall any comment for or against multi-layered
> constraints as I described them - only your opening inference that the
> RM can't do it all, so coding solely in the application layer is better.
> All said and all done?

No, I suspect I was zipping along quickly and didn't give it the attention it deserved. I don't see that in this post, so perhaps I'll get a chance to find it again. Was that related to the aircraft that I better not build? I do see that there are some risks that can be mitigated if one team of engineers builds constraints in one layer and another team builds them in another layer so we have more chance that one of the teams got it right. If that is the topic, then I think it falls in with other reliability & accuracy designs as being related to risks and costs.

I know I used too many words in this reply, but I don't have the time to edit right now. Cheers! --dawn Received on Fri Feb 24 2006 - 15:47:14 CET