Re: database systems and organizational intelligence

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:5Xotc.22642$So7.19056_at_newssvr31.news.prodigy.com...
> I think "code" is simply a bad word for discussions like these. In
languages
> like Lisp and Haskell, higher-order functions treat other functions as
data,
> as parameters for example, and both objects and closures blur the
> distinctions (though closures does it more cleanly, I think).

Yes. I took a look at Haskell when you brought it up earlier and if Java didn't have the industry backing, tools, and numbers of developers that I need for my efforts right now, I'd be playing (perhaps even working) with it.

It's all data. It's all functions. That's how I think about databases as well as languages.

> In another
> vein, rules engines and any application with a built-in interpreter (e.g.
> Jython, Guile, etc.) allow the end-user (or at least one of their
> developers, who may not be familiar with your software) to add scripts
which
> are invoked at appropriate times by the framework.

thus putting a new twist on the old "user exits" where it can now be the end-user, not just an IT professional, writing the code to be executed at various points. It makes sense that it be the end-user who maintains any constraints that are not related to the databases internal integrity -- for example, a size constraint (for display and input) on an attribute or whether to validate a particular value against a list of possible values. Setting up test environments can be tricky when using this approach, however. What was once "coding" is then often done in the live environment.

> Nonetheless, even those data have structure - a Java factory that reads a
> class name from a file and instantiates it is certainly expecting it to
> implement a particular interface. And even in dynamically-typed languages,
> there are implicit assumptions (such as that this instance X I've just
been
> handed implements a "fooBar()" method that takes 1 parameter of type
String,
> or something along those lines). That structure is similar in intent to
data
> structure, and the purpose of a method is similar to a constraint, in that
> an implementation that violates the interface's constraints can be
> considered to be incorrectly typed, just as data that violates a
constraint
> is incorrectly "typed".

You seem to have a broad language background-- with your appreciation of relational theory (perhaps including declarative languages?), functional languages, OO, and scripting languages (procedural) -- an off-topic question that I might have asked before:

Iin what (type of) language would you like to see data constraints encoded and constraint handling logic written so that these same "services" (components) can be used for both data entry (when needed for tossing up a UI or validating entered or sent values) and data storage (if the DBMS didn't lock you in)?

Lament -- I'm teaching Java in the Fall and the last time I taught a college language course was over 20 years ago --COBOL, Fortran, and BASIC. Where we were once able to teach a language and in short order a student could take in data, validate it, use it, modify it, store it, and retrieve it (i.e. data processing), we might now need to teach Java, SQL, XML (including many xml-based "languages" such as ant), jsp, html (along with taglibs etc) to write one little example of taking in data, storing it and retrieving it again the way a production system might work. (and then to get the software run-time environment set up...!!)

Thanks. --dawn

>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c94k3f$v88$1_at_news.netins.net...
> > And an end-user writing a rule for use in a software application is
> writing
> > code, then, right?
>
> I'd say they're writing a constraint, and that code (in general) is an
> expression of a constraint. Exceptions, of course, are those things that
> produce effects in the real world - calls to a SOAP service, or
> externalizing data to a database. It's those boundaries that require a
> "procedural" mode (unless of course you're in Monad-land), but most of the
> internals of an application are simply expressions against existing data.
>
> > And that code is stored as data. I'm not saying there
> > is no distinction, but it isn't easy to separate data and code into
> disjoint
> > categories.
>
> True, although many of the code-as-data concerns come into discusions of
> reuse, pluggability, domain-specific languages... in a word, frameworks.
>
> > And it leads to poor design if only "the code" or only "the
> > data" are designed,
>
> Agreed.
>
> > or even if one team designs one while another designs
> > the other.
>
> I disagree with this as a general statement. While it may be difficult in
> some cases, it is possible to analyze a domain (and the targeted solution
> technologies) sufficiently to produce statements that define the boundary.
> Whether this is always possible is another question, and moving
requirements
> cause problems... but although I don't believe in big analysis and design
> documents, I don't necessarily believe that we've done enough to really
> validate design and analysis up-front. While I think agile is a good
> implementation technique, I think it essentially throws its hands up in
the
> air because [analysis | design] is hard, and in lieu of spending some time
> to understand and document the application domain.
>
> > What's the API between code and data?
>
> Relations. :-)
>
> > Data and code are
> > interwoven, interrelated and should be taken together when designing
> > software, in my (current) opinion.
>
> I'll agree that they can be, but also believe that the degree to which
they
> are needs to be determined. Sometimes the demand for a highly-shared
> database dictates establishing an API early, so that multiple teams (e.g.
> the CRUD app and the reporting) can proceed in parallel. Furthermore, the
> team should have folks familiar with reuse tackling some of the more
> interesting code-as-data issues - like to what degree we're using code
> generation, higher-level functions for other developers to base their
> functions on, etc. The most interesting part is whether or not to use a
> domain-specific language - like functions the users of a system can drop
> into a Guile interpreter.
>
> However, all this adds complexity, so you have to choose your battles. I
> just worry that "code is data" is a license to just munge it all
together...
> it doesn't establish any distinctions, and there are distinctions to be
> made. It's just that they vary from project to project, and company to
> company...
>
> - erk
>
>
Received on Fri May 28 2004 - 15:10:26 CEST