Re: Declarative constraints in practical terms
Date: Sat, 25 Feb 2006 07:09:36 GMT
Message-ID: <QoTLf.15771$yK1.12184_at_news-server.bigpond.net.au>
dawn wrote:
> Frank Hamersley wrote:
>>dawn wrote: >>>Frank Hamersley wrote: >>>>dawn wrote: >>>>>Frank Hamersley wrote: >>>>>>dawn wrote:
[..]
> 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.
Don't forget that helmet!
>>>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.
Perhaps over a longer time scale than my involvement. Thats OK - where there is life there is "natural selection" (sic)!
>>>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.
Phew! Thats reassuring.
>>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 have no problem with a collaboration, but much less so with an either or choice.
>>- I take >>it then you are waiting at this bus stop for the "real McCoy"?
>
> I'm not just waiting, I'm pushing
Sounds like my Xian bus embarkation/debarkation dining out stories!
>>To >>extend the metaphor you must appreciate if you do not embark, at some >>point the driver will close the doors and drive off.
This happens in Xian too - cos' the bus is *FULL*.
> 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.
I don't see the RM as triumphalist - really its just some common sense nice and clearly propounded by a bright dude.
> 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.
True. In home constructions some things are discretionary (perhaps your sealant), others aren't. The latter are prolly expressed in the building code for your locale - such as secure safe basements for tornado prone areas, or corrosion resistance for coastal constructions. We all accept these as givens because the sum of human experience in the area has demanded this minimum as obligatory for community standards.
IT is way different. There is no statute, no professional body, only some gems of thought from various quarters but with no compulsion to adopt. This is not a good state of affairs and something in this forum I try to address - Canutish I know, but stimulating anyway.
[..]
>>>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.
In summary, I admit I haven't fully surveyed all your writings, but having been here on CDT for a little while, I felt your written persona was not as clear cut as your actual underlying position. That made me feel that a new reader/responder may have been easy game for an ambush over the RM in particular.
But I'm a bloke and you're a sister and that itself might be a better explanation for a disconnect on my part if your intentions were duly judged (by peers) as honourable!
[..]
>>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.
Funnily this is how real science generally proceeds - methodical, staid, building on the past, critical peer review etc. IT (less so IT academia I feel) turfs all that out the window and flits from fad to fad like a moth to flame. It is much more exciting which is why this B.Sc. (Zool) is punching a keyboard rather than counting sea squirts within 1 metre squares on the Barrier Reef (although I do sometimes wonder if I made the right choice)!
Perhaps it because the thinking stones are less than 100 years old that it is all so underdeveloped? That said there are plenty of models around on how to do it better (pun intended).
>>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.
Thats not the picture I have. Its not about 1 team getting it done and relieving the other teams of their responsibility. Its about all teams building their own layer correctly and then deploying all those efforts in unison. The distinction is once the aircraft is at 35,000 feet and 1 module fails, there are 2 others to prevent a disaster. This relates to my earlier point about the design engineers not being present of every flight deck every flight to craftily (nay agilely) work their way around the problem at hand.
> If that is the topic, then I think it
> falls in with other reliability & accuracy designs as being related to
> risks and costs.
Sure, but I always find resolving problems earlier rather than later is less expensive and less embarrassing as well.
That is even before we talk about the mistakes we make in classifying risks eg. where at the outset we all agree that X happening is unlikely and not a big risk, but on deployment due to unforeseen circumstances not considered in our original assessment the impact is unconscionable.
Cheers, Frank. Received on Sat Feb 25 2006 - 08:09:36 CET