Lambda the Ultimate

Your point 1 implies that the "languages you have to use at work" are actually more verbose than XML - which is why you want to define the schema in XML instead of code, in the first place. Maybe it would be more cost-effective to fix the verbosity problem, rather than bolt on even more features for code generation? Ditto for point 2.

Only point 3 seems to be a real problem, but Hibernate seems to have solved it for you.

Take Java, for example: I can not describe objects as simple records and have the compiler write the get/set methods. Being able to manipulate declarations as I fit at compile time would be a great advantage.

As for Hibernate, it is so huge and cumbersome that it has become a problem by itself. The code generation approach would be much better, because it would allow me to prepare the execution environment without needing to know and use anything else other than the language I am using.

Scattering a project amongst many tools, having to learn and maintain each tool, is not my preferred way of doing things. I think it is much simpler to use the same programming language to manipulate itself.

I think there's no question which choice is easier to maintain. (using HTML/DOM as an example since it's commonly understood)


<h3>Lambda The Ultimate</h3>
<p>Is <b>very</b> nice</p>


versus eg.


Element header = document.createElement("h3");
header.appendChild(document.createTextNode("Lambda The Ultimate"));
document.appendChild(header);
Element paragraph = document.createElement("p");
paragraph.appendChild(document.createTextNode("Is"));
Element bold = document.createElement("b");
bold.appendChild(document.createTextNode("very"));
paragraph.appendChild(bold);
paragraph.appendChild(document.createTextNode("nice"));


It's harder to spot bugs in the "code-DOM" approach (there are at least 3 in the example to demonstrate)

Obviously that example is, but that's mostly because of the way you wrote it. This isn't particularly verbose, for example:

body = Body(...,
    H3("Lambda The Ultimate"),
    P("is ", B("very"), " nice")
)

That's a lot better of course, but you have to define the H3, P, B etc. somewhere. You either define them by code generation (back where we started from), create them at runtime as closures eg. in JavaScript (in this case your programming language is powerful enough to do most things without code generation anyway), or hand-code them (ugh).

The point of the post was to compare DSLs and (D)OM builders in incapable languages like Java (where complex literal syntax is non-existent).

Java has constructors, doesn't it? If so, then it's completely possible to do exactly the same thing as above, albeit with the added verbosity of types.

I forgot about java's abysmal list facilities and lack of varargs. My mistake.

BTW, Java 5 does have varargs. Though the only way to accomodate both "h3" objects and strings in the same list would be to use a vararg array of type "Object".

This is partly due to using an absurdly verbose language (Java?), but also due to the fact that HTML/XML carries no associated semantics. Those have to be communicated out-of-band while the code spells out what is allowed and what isn't, i.e. it attaches semantics. (This may not be so apparent with HTML/XML output, but it certainly is with XML input.)

I am aware of DTD and XSD, but they are not enough. The arbiter of what is acceptable is always going to be the (business) logic, so why not simply generate a parser based on that?

Way back in '97 Weblogic had a HTML-generation library with a kinda cute approach to this in Java. Example code snippet from their Javadocs:

  HtmlPage hp = new HtmlPage();
  hp.getHead()
    .addElement(new TitleElement("Hello World"))
    .addElement(new LinkHeadElement(LinkHeadElement.relTag,
                                    LinkHeadElement.relCopyright,
                                    "http://www.weblogic.com/copyright.html"));
  hp.getBodyElement()
    .setAttribute(BodyElement.bgColor, HtmlColor.white)
    .setAttribute(BodyElement.textColor, HtmlColor.navy);
  hp.getBody()
    .addElement(MarkupElement.HorizontalRule)
    .addElement(new StringElement("Hello World!").asBoldElement())
    .addElement(MarkupElement.HorizontalRule);
  hp.output();

This is not very concise in comparison to e.g. Lisp but it is impressive to see what tricks people come up with when they get creative with the language at hand. That's really hard to do when you are using a language reluctantly and are reconciled to the idea that it sucks. :-)

I'd assumed that the trick was borrowed from Objective-C but Peter "Practical Lisp & Weblogic Hacker" Seibel tells me it was an independent invention. Small world. :-)

Hey I'm all up on Java this month. I was talking nostaliga with some friends at work and discovered that the first ever paid computer work I did (10 years ago! I'm getting on!) is still online and still runs! It's the arcade game Araknoid if you want to try your skill :-) Now I wish I could find my old Amiga demo programs!

Gotchya (again with the reminders from LtU that I need to learn O'Caml :-).

The blog entry pointed out that debugging through layers of generated code is hell, so I was hoping that there would be really great (if not so widely known) ways to get the equivalent power without code generation causing so much undebuggable verbosity.

Macros can be cool, but possibly inscrutible. Libraries can be cool, but possibly too verbose / something of an impedence mismatch. Are functors easy to grok and debug? Are there forms of genericity or parametricity or polymorphicness that are really cool and concise and powerful and easily debugged? I'm utterly unpracticed with such things.

(The blog's thought that debugging is important is what resonated with me. It would be interesting to follow discussion that looked at all of the programming tools from the perspective of ease of debugging. I guess it also depends on the ui of the debugging tools.)

[EDIT: uh, actually, maybe I just read into the blog the idea about debugging because that is my own hobby horse.]

Ever heard of smalltalk? Blocks are a pretty good replacement for this kind of metaprogramming if you don't mind the speed hit usually associated with them, of course this is really dependent on the language implementation as it's entirely conceivable to be able to use blocks in the same way as macros without the performance hit.

It was more of a "in-language DSLs/OM builders are bad in Java" post, not that OM builders are bad in general. If I was using Lisp or Ruby, say, I would certainly take the "code is specification" approach.

Sometimes you even don't need metaprogramming for it if your type system is powerful enough, eg. Haskell.

(Sufficiently capable type systems are indistinguishable from metaprogramming?)