Today has been a geek day for me. I finished my Java homework (mind-bogglingly dull and easy, but time-consuming). I also spent a lot of time thinking about domain specific languages and code generators. What most developers do is take specifications and write a bunch of code that reflects them. That's common, but it's impractical if it can be avoided. The right thing to do is to take specifications and find a way to turn them into the code. Thus, writing the specs is writing the program. To be fair, even though many experienced programmers acknowledge that this is a superior way of doing things, it's rarely done. I once started building a system that did that, but I didn't follow up on it. I wish I had.
Just to give you an idea of how this works, let's say that a movie distributor wants to know how their films are doing on a state-by-state basis. To determine that we might issue an SQL command like the following:
SELECT states.name, titles.name, sum(xtns.revenue)
releases, -- e.g., US or Canadian release
WHERE titles.id = releases.title_id
AND releases.id = xtns.release_id
AND xtns.theater_id = theaters.id
AND theaters.state_id = states.id
AND releases.distributor_id = 'SONY'
AND releases.country_id = 'US'
GROUP BY states.name, titles.name
ORDER BY states.name, xtns.revenue
(This isn't quite how our database is set up, and I've deliberately hidden some things, but you get the idea.)
Is that SQL correct? Just at a glance it could be tough to say (hint: it's not correct.) The customer, of course, is in no position to answer that question and it can be very time-consuming to learn the answer. All the customer wants to know is the revenue per title per state. And that, actually, gets to be rather interesting. What if that was my program?
DECLARE report IS revenue PER title PER state
Can you really make things that easy? Instead of trying to figure out how to join together five database tables (and deciding which five we need), we simply skip that step. In my example it is possible to do but it takes a lot of work up front. However, that work pays off once you get the benefit of having code that is this easy to write. Of course, some of you may protest that this is what fourth generation computer (4GL) languages were intended to do and those sucked. However, what if, instead of being a 4GL, it generated 3GL code that was easy to manipulate? That's similar to what we do at my current employer and that's what we may do with my new employer. This is where programming is heading: have the computer do what the customer wants instead of having the programmer tell the computer what the customer wants. By cutting out the middle-man, so to speak, you improve productivity by orders of magnitude. Finding the programmers who can build those systems is tough, but the payoff is worth it.