Lambda the Ultimate

From the OASIS group, responsible for OpenOffice formats among other things, comes a new schema for business processes. The gem here is the new standard for addresses, something long overdue in the XML world.

Ever since my early data modelling experience, with a pre-release version of IMS/DB, deciding how best to deal with addresses has been a major issue. So I looked at this area in particular and it does seem to work well and give the flexibility needed (this is partly due to the greater flexibility of XML over IMS) and I can easily see this becoming the standard.

There's a discussion about favoured programming language features on Slashdot.

Unification, parametric polymorphism etc. are mentioned.

Type-Based Optimization for Regular Patterns, by Michael Y. Levin and Benjamin C. Pierce. WWW Workshop on High-Performance XML Processing, May 2004.

We describe work in progress on a compilation method based on matching automata, a form of tree automata specialized for pattern compilation, in which we use the schema of the value owing into a pattern matching expression to generate more efficient target code.

A set of slides is also available.

From time to time I like to return to the issue of database integration, only to once again remark that the difficulty in creating good database APIs (as opposed to simply embedding SQL) is the result of the poor programming facilities provided by most programming languages (e.g., no macros for syntax extension, no continuation or first class functions to handle control flow etc.).

Why return to this topic today? Jeremy Zawodny aruges on his blog that Database Abstraction Layers Must Die!

Along the way he says,

Adding another layer increases complexity, degrades performance, and generally doesn't really improve things.

So why do folks do it? Because PHP is also a programming language and they feel the need to "dumb it down" or insulate themselves (or others) from the "complexity" of PHP.

Ouch!

Why do we need an abstraction layer anyway?

The author uses an argument I hear all the time: If you use a good abstraction layer, it'll be easy to move from $this_database to $other_database down the road.

That's bullshit. It's never easy.

Double ouch, but true enough. Databases are like women (can't live with them, can't live without), and getting rid of one can be as painful as divorce...

So what's the solution? Surprise, surprise: use a libary. But isn't that an abstraction layer? Of course it is.

What Jeremy advocates is plain old software engineering and design. Everyone should do it. I can't beleive anyone does anything else.

But wait. I just told you it's hard to build such a library, since programming languages makes the design of such libraries hard (e.g., should you use iterators, cursors or return record buffers? should your library database access routine be as flexible as a select statement?) So we design libaries that aren't very good, but hopefully are good enough.

And that's the question I put before you. We all know about coupling and cohesion. We all know about building software abstractions. Are our tools for building abstractions powerful enough for this basic and standard abstraction: the database access abstraction layer?

This may be of interest to LtU readers.

Most of the specific language features were discussed here previously, but the C# perspective may make this worth a look.