Interesting article by Rich Seeley on TenFold, which allows you to build web applications without coding. TenFold provides a set of standard business components and an environment where you can model your app as a composition and configuration of uses of those components. The model is stored in a relational database and read at run-time by the TenFold "rendering engine": no code generation or compilation.

The company has been around for over a decade but went through the wringer around the turn of the millennium. Things are sadly still looking shaky: last year's results show a loss of over $5m on revenue of $5m.

An earlier article on ZDNet quoted a PCMag review saying that TenFold is let down by its UI (both for creating and using the apps). It's disappointing to see that even today the 'modeling' is actually just filling in tables and property sheets -- no graphical language. That might just scrape by for simple application structure, but business logic needs a more powerful language: either textual or graphical. A comment on one of the articles points to a blog entry by James Taylor on this issue. As he writes:

No business user is going to maintain this:

public class Application {
  private Customer customers[];
  private Customer goldCustomers[];
  ...
  public void checkOrder() {
  for (int i = 0; i < numCustomers; i++) {
    Customer aCustomer = customers[i];
    if (aCustomer.checkIfGold()) {
      numGoldCustomers++;
      goldCustomers[numGoldCustomers] = aCustomer;
      if (aCustomer.getCurrentOrder().getAmount() > 100000)
        aCustomer.setSpecialDiscount (0.05);
    }
  }
}

They might maintain this:

If customer is GoldCustomer
  and Home_ Equity_Loan_Value is more than $100,000
  then college_loan_discount = 0.5%

But what they really want to do is see something like this:

College Loan Discounts
Current Discount = [0.5]%
Eligibility:
  <Gold Customer> and
  Home Equity Loan <more than> [$100,000]

Where the [numbers] are editable and the <lists> can be selected easily.

Obviously the last version is very close to DSM: not only is the language concise, but it is also strongly bounded. The implication is that the text is not freely editable: not just that it must parse, but that when creating it you must choose from a limited set of elements, and the tool guarantees that anything you can input will be legal. That's what distinguishes this from the "natural language" version: the tool will guide you far more than auto-complete and syntax highlighting in IDEs.

The trick when building a DSM language for something like this is choosing where to use text, where to use property sheets and tables, and where to use a graphical language.

• Text is quick to enter and concise, but prone to errors on entry, hard to manipulate during generation, and makes it impossible to reuse any constituent parts elsewhere.
• Property sheets (Objects) are still quick to fill in, but can only represent simple information whose structure and number of occurrences is known in advance.
• Tables (or Objects within Objects) allow multiple occurrences and even tree structures, are well suited to generation, and relatively concise visually, but tend to be clumsier to fill in, and while elements can be reused, it is often hard to see what is reused where.
• Graphical models allow almost any structures, are easy to understand, work with, generate from and reuse, but are not as fast as text to enter, and take up the most screen real estate

It would be nice if there could be a universal graphical language for business logic, but it seems unlikely that it would be simultaneously sufficiently powerful for all needs and yet easy enough to work with. Our experience is that for any given company, they only need a subset of the total possible set of functionality, and by implementing just that, the language remains manageable. This also allows special concise ways of representing complex structures that are used frequently by this company: the complex structure will reoccur with only a few parts changing, so just create a special Object type for that structure with properties for the parts that change.

That indeed is one of the joys of DSM: you can grab such low-hanging fruit whenever you want, for maximum power and abstraction. At the other end of the scale, if you decide to leave some uncommon cases out to keep the language small, there's no problem at all to write those parts in code. You can then include them in the model by name reference (generally better than including the full text of the code). Of course staying at the high end of the scale is better: once you have hand-written code, you are generally limited to one implementation language and probably one platform and set of libraries. Any change in those would require everyone to rewrite all those pieces of code, rather than the normal DSM coolness of just one developer changing the generator to output the new format.