Re: Mixing OO and DB
Date: Sun, 10 Feb 2008 15:34:17 +0100
Message-ID: <47af0aba$0$85784$e4fe514c_at_news.xs4all.nl>
Patrick May wrote:
> mAsterdam writes:
>> Patrick May wrote: >>> I prefer to work with people who understand procedural, >>> relational, OO, and functional programming. The boundaries between >>> these paradigms are not sharp -- useful techniques span paradigms. >>> Ultimately I'm looking for a gestalt development environment that >>> leverages the benefits of the superset of these techniques to >>> deliver high quality software. That's the real goal, after all. >> That is stricly one side of the fence - it is the goal for a >> software development process. The goal for a DB is to serve as a >> vehicle to manage data.or with 'stricly one side of the fence', or with both?
>
> I disagree.
Whith 'The goal for a DB is to serve as a vehicle to manage data.',
> Software is a means to an end, not an end in itself,
> at least in the vast majority of commercial settings.
Software is a business asset, not the business itself 'in the vast majority of commercial settings'. That is just excluding software companies. One can distinguish between their products and the stuff they use to do their business - even when they do eat their own dogfood.
I don't see the relevance of this exclusion (yet?). If your point is just a proposal to look at it as a means to an end - I'm ok with that.
> Databases are just one type of software.
Conflating database and the software supporting it, DBMS.
Do you need that? The further you are away from something the less distinctions you see, of course, but when reasoning about one part leads you to wrong conclusions about the whole, you'll have to inspect more closely.
> The end goal is to provide business value.
Is data a business asset in your view?
> Quality software, meaning software that meets the current
> needs of the business, that can be easily extended to meet future
> needs, and that is economically feasible to develop, provides that
> business value. No business really wants a database per se, but many
> do want the benefits of rapid access to consistent business
> information.
Somewhat like answering 'Is data a business asset in your view?'
With 'not per se'.
Not accepting a reason of being is another way of
saying 'the other guys are so stupid'.
>> Paradigm, gestalt development environment, leverages the benefits of >> the superset of these techniques, gestalt development, I'll requote: >> >>>> Let's cross this divide, and behave as if it is a real border. >>>> This means you can't carry all of your preconceptions, and you >>>> will have to adapt your language. >> Do I need to explain?
>
> Evidently, because I don't accept that the divide exists in any
> meaningful sense.
So, nothing to mix. This denies the validity of the OP's question.
I'd snip the rest, but there was something of interest per se in the remainder of your post.
> I use multiple paradigms as the situation warrants
> and I work with a number of people who do as well.
> They're all just different tools, each with advantages and disadvantages.
http://en.wikipedia.org/wiki/Paradigm currently says: "Kuhn defines a scientific paradigm as:
- what is to be observed and scrutinized
- the kind of questions that are supposed to be asked and probed for answers in relation to this subject
- how these questions are to be structured
- how the results of scientific investigations should be interpreted", and there is a link to a nice article: http://www.mnsu.edu/comdis/kuster/Infostuttering/Paradigmparalysis.html
Liberal and overly selfconfident use of the word paradigm hints at entrenchment within one, not the capability of distinguishing the boundaries, their nature and how to deal with them.
> Grouping one set of tools together and calling it "relational",
> another set "object oriented", and another set "functional"
> is useful to identify those that complement each other,
> but it's important to realize that those sets are not disjoint.
> It's also important to realize that the tools in each set
> complement each other _in a particular context_. In a
> different context, that is, a different problem or solution domain,
> different sets of tools may make sense.
Agreed. A consequence of this position is, though, that it becomes crucial to recognize contexts, particularity of situations and the divides between them.
> There are more things in heaven and earth, mAsterdam, than are
> dreamt of in your paradigms.
Queerer than we can suppose:
http://video.google.com/videoplay?docid=6308228560462155344
-- What you see depends on where you stand.Received on Sun Feb 10 2008 - 15:34:17 CET