Re: The Paradox of Choice

Marshall 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.

Quite the contrary. I have known business analysts straight from school who had no background in programming who picked up SQL syntax and relational concepts like a breeze. What they had difficulty with was the optimizer that arbitrarily chose to translate their perfectly good and valid queries into nested table scans.

Why should a dbms handle IN, OR and UNION differently in the first place? (The analysts in question were fond of 'IN'.)

  I wonder: might it be possible
> to provide these folks some training wheels?

How about predicate calculus?

  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.

How about a simpler syntax with less redundancy that SQL?

> 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?

Good language design helps a lot. Received on Wed Feb 07 2007 - 23:05:45 CET