Re: The Paradox of Choice

On Feb 6, 12:04 pm, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> Vague thoughts:
>
> Choice isn't all its cracked up to be. Often times people don't want a
> lot
> of different ways of doing things to sort though, even if it means
> more
> flexibility overall.
>
> OOPLs give you basically one way of doing things. In general, the
> PLs with more choices of how to express relationships between
> classes have not been as successful as the ones that don't. Consider
> CLOS, which lets you do anything and everything; you can, if you want,
> make up your own object model with every different application.
> This is wildly popular with one extreme end of the programming
> community, but quite unpopular overall. You also have languages
> with prototype objects, per-object method binding, etc. Also popular
> with a narrow segment but generally low market share. On the other
> hand, Java has exactly one way to do inheritance. There is exactly
> one kind of object, no closures, no facilities for delegation, etc.
> It's very restricted. And it's the most popular programming language
> ever. Worse is better?
>
> It occurs to me that, while many of us here have no trouble mastering
> the SQL schema patterns for things like Master/Detail etc., these
> patterns are not immediately accessible to newbies, or to the vast
> hordes of dilettante programmers. I wonder: might it be possible
> to provide these folks some training wheels? Might we come up
> with some approach that lets us encode patterns like master/detail
> or many-to-many so that they may be used directly? The idea being
> to have a facade over the unrestricted RM that provides the appearance
> of there being only one way to do things, to avoid scaring people
> with too many choices. I am thinking of some kind of macro system.
>
> I realize there is a good counter argument about the importance of
> mastering ones' tools if one wants to be a master. However, not
> everyone wants to be a master. And we should also acknowledge
> that there is something to be said for the programmer being able
> to focus on the application domain and not on the toolset domain.
> I have found that handicapped accessibility features are useful to
> me, even though I don't require them.
>
> Thoughts?

If there were a facade on the RM, so that all interactions between developers and the DBMS and between any other software and the DBMS used this facade, then the data model(s) of the facade would be the relevant ones for software development. If this were not the RM, then the RM would be as (ir)relevant as any other models whose implementations were hidden to anyone not writing the actual DBMS software. [As an aside, we could then later decice to refactor the underlying software to avoid the RM altogether if something else is deemed better, faster, more flexible,...]

The "data model" for persisted data that is employed by developers would then be an abstraction of the language (or APIs or interfaces or services) employed by developers and other software using the DBMS. Good. Then we can move on to the important questions of what features are required and desired, including those requested by the users of the DBMS. (NF2, 2VL, lists, M-M,...) Count me in.

cheers! --dawn Received on Fri Feb 09 2007 - 01:15:59 CET