Tutorial D, Industrial D and the relational model

From this interview with Chris Date :

[...] But the trouble with the relational model is, it's never been implemented--at least, not in commercial form, not properly, and certainly not fully. So while it's true that there have been a couple of developments in the marketplace over the past few years that I do quite like, I like them primarily because I see them as attempts to implement pieces of the relational model that should have been implemented years ago but weren't. I refer here to (a) "business rules" and (b) "object/relational DBMSs." I'll take them one at a time.

• Business rules: Business rule systems are a good idea, but they certainly aren't a new idea. Without going into a lot of detail, business rule systems can be seen as systems that attempt to implement the integrity piece of the relational model (which today's mainstream SQL products still--over 35 years after the model was first described!--so signally fail to do).
• Object/relational DBMSs: To a first approximation, "object/relational" just means the domains over which relations are defined can be of arbitrary complexity. As a consequence, we can have attributes of relations--or columns of tables, if you prefer--that contain geometric points, or polygons, or X rays, or XML documents, or fingerprints, or arrays, or lists, or relations, or any other kinds of values you can think of. But this idea too was always part of the relational model! The idea that the relational model could handle only rather simple kinds of data (like numbers, and strings, and dates, and times) is a huge misconception, and always was. In fact, the term object/relational, as such, is just a piece of marketing hype ... As far as I'm concerned, an object/relational system done right would simply be a relational system done right, nothing more and nothing less.

[...] The next thing I want to say is that, while the relational model is certainly the foundation for "doing databases right," it's only the foundation. There are various ways we can build on top of the relational model, and various attempts have been made to do such a thing over the past 25 years or so. Here are a couple of examples:

• Higher-level interfaces: It was never the intention that every user should have to wrestle with the complexities of something like SQL (or even the complexities, such as they are, of the relational algebra). I always rather liked the visual interfaces provided by Query-By-Example and the "visual programming" front-ends to Ingres, for instance. And there are many other attractive front-ends that simplify the business of building applications on top of a relational (or at least SQL) DBMS. 4GLs too can be regarded as a higher-level interface--but I was never very impressed by 4GLs as such, in part because they never seemed to be precisely defined anywhere; the idea might have been OK, but without a formal definition of the semantics of the language some very expensive mistakes can be (and were) made. Natural-language systems are another example; I still have an open mind about these, but I don't think anyone could claim they've been a huge success as yet.
• Special-purpose applications: I think the right way to view things like OLAP and data mining is as special-purpose applications that run on top of the DBMS. I mean, I don't think these things should be part of the core DBMS (I could be wrong). Either way, however, I do want to complain about the CUBE stuff in SQL, which takes one of the worst aspects of SQL--its support for nulls--and "exploits" it to make it even worse. But that's a particular hobbyhorse of mine ... I think I'd better stop right here.

19.12.2005, 0:01
 

Stop bashing Java

Jürg, making the case for Java beyond J2EE :

"...there were alternatives around since years (e.g. Helma , which is surprisingly similar to Rails in a few fields), and often the people who now blame J2EE for not having been efficient were simply to lazy to really look for alternatives earlier on."

"I think it might be time to stop bashing Java and enjoy the fact that there are actually ways of working with it or any language available in its growing little universe that are enjoyable, not bound to Sun licenses, very flexible, fast and resource-saving."

18.12.2005, 20:16

E4X Mocha Objects

The next generation of Mocha Objects might evolve in a direction that would look something like the following, tying in tighter with the hard-coding environment of Helma:

./Site/list.view.control

// function at Site.prototype.views.list.control(that)

    if (this.topics.count()) {

        that.topics = {};

        for (var topic in this.topics) {

            that.topics.name = this.topics[topic].name;

            that.topics.count = this.topics[topic].comments.count();

        }

    }

./Site/list.view

<table border="1">

        <tr if="topics">

            <th lookup="true">Topic Name</th>

            <th lookup="true">Comment Count</th>

        </tr>

        <tr for="topics" class="rowcolor{ $topics % 2 }">

            <td>{ topics$.name }</td>

            <td if="!topics$.count" lookup="true">

                No comments yet</td>

            <td if="topics$.count == 1" lookup="true">

                { topics$.count } comment</td>

            <td if="topics$.count > 1" lookup="true">

                { topics$.count } comments</td>

        </tr>

        <tr if="!topics">

            <td colspan="2" align="center" lookup="true">

                This list is empty</td>

        </tr>

    </table>

./Site/list.control

// function at Site.prototype.controls.list

    var content = {

        main : this.views.list.render()

    };

    var page = Page.views.default.render(content);

    return page;

this.views.list.control() is invoked when the list view is rendered. When it is invoked, "that" is the object which was passed as parameter of the render() method or otherwise an empty/default object. "that" is the object that will be used as the Javascript context when rendering the view.

Views would be E4X Javascript XML objects. When Helma would render these views, it would parse them for "lookup", "if" and "for" attributes and then evaluate them in the context of "that".

When parsing the "for" attributes, Helma would loop through the indicated object (topics) with "for(var $topics in topics)" and repeat the specified element (the table row) with topics$ == topics[$topics]

When parsing the "lookup" attributes, Helma would check if a lookup handler function exists and if so would apply it to the element's content.

this.controls.list would be the function that is called in order to handle the request, similar to todays this.list_action.

9.12.2005, 9:02

Logging and other antimatters

Javascript logging from log4j to log4js.

GCC on MacOS X with GCJ .

W3C has chartered a Web APIs Working Group .

There is no danger from antimatter. There are of course other dangers on the CERN site, as in any laboratory:  high voltage power in certain areas, deep pits to fall in, etc.

Wikis, weblogs and microlearning, learning from microformats: The theory of Vanilla .

24.11.2005, 7:02

Stronger types in Javascript 2

From Brendan Eich's JS2 design notes : 

Goals:

1. Support programming in the large with stronger types and naming.
2. Enable bootstrapping , self-hosting , and reflection .
3. Backward compatibility apart from a few simplifying changes.

 Non-Goals:

1. To become more like any other language (including Java!).
2. To be more easily optimized than the current language.

Type operators and type annotations

Type annotations are optional. To support strict options that require every declaration to be annotated, * may be used for ⊤ (the top type), e.g. var v is * , which is equivalent to var v . Note that * is used differently for E4X, but its meaning as ⊤ is unambiguous in type operator and annotation right operand contexts.

In a nutshell, is t annotations insist on type t and defend against null and undefined (no more "foo has no properties" errors; with static analysis, an error that can't be avoided at runtime can even be reported at compile time). as t annotations enforce ( is t )-or-null invariance. And to t annotations convert according to cleaner, class-extensible rules.

[...]

Given types, you can assert (is), coerce (as), or convert (to). Conversion alone is not enough, since it either leaves null unconverted, which is a "foo has no properties" hazard that one should be able to assert against with an annotated declaration; or conversion changes, e.g., null to String "null", which may be acceptable with dynamic types only (Edition 3 and earlier), but which is wrong with asserting and coercing annotations such as "var str is String" and "var strOrNull as String".

Since "to" converts rather than asserts or coerces, it is not sufficient as the only kind of type annotation.

Hence the symmetry between the type operators and annotations. Failing to provide an annotation for a type operator gratuitously forces programmers to hand-code constraints, instead of letting the type system do the work.

10.11.2005, 17:32

Javascript Diagnosis & Testing

Some interesting additions that were made to the AjaxPatterns page:

Diagnosis

• Logging Instrument your Javascript with log messages.
• Debugging Diagnose problems with a Javascript debugger.
• DOM Inspection Use a DOM Inspection Tool to explore the dynamic DOM state.
• Traffic Sniffing Diagnose problems by sniffing Web Remoting traffic.

Homo Oxymora

" Artificial artificial intelligence " and " why the future doesn't need us ".

"[...] a well-known problem with the design and use of technology, and one that is clearly related to Murphy's law - "Anything that can go wrong, will." (Actually, this is Finagle's law, which in itself shows that Finagle was right.)"

5.11.2005, 17:57

>>> Yeah, why not Javascript?