I was at a seminar on Object Relation Mappers (ORMs) recently. The idea behind these is actually quite simple: they're a persistence layer for object-oriented languages. Through a little bit of glue code injected into the language's runtime engine, and some introspection tricks, object instances are transparently mirrored to a persistence layer like a database engine.
Having a database sitting behind an ORM, actually provides some nifty functionality. In particular, you can do nifty things like pose queries over object instances, classes, and so forth. Often, these queries can be posed in a database-agnostic way (i.e., without using SQL).
This is quite handy, since it gives object-oriented developers the power and optimization tricks of a declarative query processor. For example, in an application that manages a school's student population, you might have a relation that represents all of the students mapped to instances of a "student" object. The student object exposes functionality that might be performed on a student (i.e., register, etc...), and has access to all of the data available about the student. The developer can actually pose queries, and get all of the object instances that satisfy some predicate (e.g., all students with a GPA > 3.5).
That got me thinking. I've seen this before.
set myFiles to the documents of the application where the name of the owner is "Oliver"
This is an example of a language called Applescript, Apple's answer to shell scripting back in the 80s. The language still exists, and is occasionally used for automating tasks on OSX -- most often as a wrapper around shell scripts (If you've ever set up a Raspberry Pi on a mac, you know what I mean).
The clever thing about Applescript is that the language includes first class query primitives. A large fragment of the language actually has a direct correspondence to relational algebra. For example, the above Applescript code fragment could be rewritten in SQL as:
CREATE TEMPORARY VIEW myFiles AS
SELECT * FROM application.documents WHERE owner.name = "Oliver" INTO myFiles;
Applescript is designed to work very closely with applications. Each application and/or system component provides what's called a "Dictionary" which includes nouns (object classes) and verbs (object methods). That is, Applescript allows applications and system components to expose objects via predefined schemas. These objects can be queried just as easily as a normal language would operate on them.
I'd like to see more such things. Even now, ORMs feel like they're bolting query operations onto the language, as sort of a hack. This is true even for ORM-like functionality in DSL-friendly languages like Ruby (e.g. Ruby on Rails). It seems like this sort of query functionality needs to appear in the language from the ground up -- all the way from the design of the grammar.
Getting anew language, a sort of successor to Applescript that supported this kind of functionality would be awesome, especially if it could tie into an existing language like Java, Python, etc... Especially if it could tie into ORM functionality, connect to a database, and do all sorts of other tricks like that. That... would be really cool.