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)
FROM titles,
releases, -- e.g., US or Canadian release
xtns,
theaters,
states
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.
Only to a certain degree. Read The Shlemiel way of software, a Salon interview with Joel Spolsky, he explains much better than I could (which is why I didn't originally answer). Choice quotation:
[A]ll these people that are trying to make the same perpetual-motion machine — where you just write your specification and it automatically becomes code — don't realize that the specification has to be as detailed as the code in order to work.
Re:
Ovid on 2004-12-13T20:11:31
There's a huge difference between what I am talking about and what Spolsky is talking about. He's talking about someone being able to generally specify something and have it just work. I'm talking about generally specifiying something and having the bulk of the code written to do it. 4GL languages suck because they ignore the complexity. Code generators rock because they take away the grunt work and all the programmer has to do is focus on the complexity.
Read about code generators in Code Complete. They have some interesting things to say (or is that Pragmatic Programmer. I can never remember.)
Re:
Aristotle on 2004-12-13T21:35:49
Oh, I definitely agree on that. That's why I did qualify my statement with “only to a certain degree” rather than saying “yes” or “no”.:-) It can just be difficult to tell which end of the spectrum someone is aiming for; and unlike most people's, my biggest weakness is false hubris, so I'm always wary about that.