Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday November 22, 2004
01:11 AM

Domain Specific Languages

[ #21945 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Only to a certain degree. Read The Shlemiel way of software [salon.com], 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.

    • 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. T

      • 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.