Re: database systems and organizational intelligence

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

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

"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