Generative Programming Techniques vs Parser

[HS Thomas]

How do you differentiate between Generative (e.g. in Rapid Application Development) techniques and Parsers ?
I could quite easily write a SQL generator ( or parser ?) that doesn't really need one to know SQL to use it more than adequately.
SQL is itself a parser, if I remember correctly!
[ August 14, 2003: Message edited by: HS Thomas ]

[Ernest Friedman-Hill]

Warning: just one man's opinion.
"Generative Programming" as a movement is similar to oh-so-many other movements in software engineering. Its proponents posit as a a universal solution to everyone's problems. The reality is that it's a tool in the toolbox, and nothing more. So is parsing. Each tool is good for something.
In the case you've brought up, the SQL generator would need metadata about a given database. How would it get the metadata? Probably by parsing either an XML description or a SQL description of the database. How does the database deal with the generated SQL? By parsing it. So you really can't have one without the other.
In another thread, you bring this up again in as it relates to rule engines. And again, it all depends on how you look at it. A rule engine takes some description of a rule and compiles it (by parsing it) into an internal representation. Or, if you want to look at it differently, the rules are metadata, and the internal representation is generated by the rule engine. This internal representation is a procedural program of sorts (a FSM of some kind) while the rules themselves were declarative. It all depends on your point of view.
Where do the rules come from? A person might write them, or they may be generated from metadata. How does the generator get the metadata? Probably by parsing it from somewhere. And how does the generator get written? Someone has to write the rules by hand, study them, optimize them, generalize them, and then write the generator. This make sense if the rules for every application look the same, but of course, they often don't in reality. There's less commonality across applications than the GP folks want you to think.
A perhaps relevant situation from my experience: in the CAD/CAM world, much has been made in the last decade or two of the notion of Parametric Design. The idea is that you build a computer model of, say, a gear. The number of teeth, the diameter, the width of each tooth, and many other quantities are parameters that aren't specified in the model. Part of the model can be commands to computer-controlled machines to actually create a gear based on parameters. You can create metadata-driven tools to generate simple GUIs to let people design their own gears. To manufacture a real gear, you just plug in the numbers, and copies of the precise gear you want start rolling off the assembly line. A telephone operator can do it. You can send all the engineers home.
This works great for ACME Gears Unlimited, which makes vast families of similar gears. It works badly, though, for Consolitated Random Objects, Inc, which will never make more than one kind of gear. You need new CAD models all the time. Are there commonalities among designs? Absolutely. Does generative programming help? Not a whole lot -- those engineers will be busy building CAD models by hand.
Note that both kinds of businesses are important: you go to ACME when you're mass-producing alarm clocks from COTS parts. You go to Consolidated when you're building a prototype space shuttle for NASA. Every business, every situation is different, and no metadata schema will ever be flexible to cover the entire range of human experience.

[HS Thomas]

Ernest, thanks for such a detailed answer.

There's less commonality across applications than the GP folks want you to think.

So would you say Jess is only applicable in certain situatuions?
Generally , what types of applications. Deductive systems , Logistics systems ? Give me a rough guide so I'll be tempted to buy the book. Apparently, the cover alone is worth it.
Would the commonality of business rules be the exception rather than the rule ?
I am really surprised that not all projects would take ACME's approach to building software. Even just to get re-usable business logic seems to be a good thing to aim for.
Taking the SQL example again, it seems quite simple to define rules in such a way that it's easy to join them up. I started some studies that looked into it a while back, using Symbolic Logic.But the next few years at work I never came across anything similar and efforts to start something similar at work were thwarted.
Until recently, when I worked for a company that built rapid J2EE prototypes and the business rules were captured in a fashion ( using simple mathematical expressions) that made the SQL generatable.
There was a very short time to deliver and being able to generate the SQL came into it's own.You'd still need a group of specialists to have in-depth knowledge of SQL / databases. But developers were using it at a level that didn't require them to know SQL that well, ie it freed them to concentrate on J2EE work where a very sharp learning curve was required.
Now, I find myself expecting to do the same on any project that uses SQL/EJBQL/JDOQL but no one else shares that view. They don't want to be freed but would much rather write it all out by hand. This group is useful to have so that they form the technical QL specialist group.
Management need the information to feel empowered enough ( Jess In Action ? ) to be able to create another group that can think at another level( a business one), but still be able to use a Query Language.
One potential problem is that there won't be enough people drawn to working in the technical QL specialist group ! And this is a field that needs to grow and develop. Hope this question makes some sense.
regards
[ August 31, 2003: Message edited by: HS Thomas ]

[Ernest Friedman-Hill]

Well, Jess, like any tool, is only applicable in some situations, yes. Java is such a tool, too, of course. But Jess's applicability has nothing to do with the "Acme vs. Consolidated" dichotomy; you can use a rule engine in either case. The difference is that in the "Acme" case, you're a software house that writes more or less the same system, over and over, at least at some level of abstraction (and there are plenty of software consultancies that strive to do just this.) In the Consolidated case, every system has some unique features that require hand crafting (although certainly there is some reuse. But which kind of system you're working on has no bearing on whether a rule engine is useful.

[HS Thomas]

Thanks. Ernest, your response is really appreciated. I will be looking out for Jess in Action as it seems applicable everywhere.It has something for everyone.
What was it that motivated you to create Jess ?

regards

[Ernest Friedman-Hill]

Tell you what: hold that thought and ask me again next week in the "Other Java Products and Servers" forum -- the book giveaway next week is for "Jess in Action."

[HS Thomas]

Excellent!