On: How a Clojure pet project turned into a full-blown...

[moe]

Well, I commonly use template inheritance (in jinja) to great effect and can think of dozens little reasons why having the HTML in separate files makes a lot of sense (i18n, re-use, designers editing them, testing outside the app etc.).

I also found the code presented in the slide especially scary because it was intermixed with Lisp brackets and such. I imagine it would be a major pain to rearrange something in there, don't even want to think about exploratory programming in that style...

That's not to say it can't be neat in little one-off scripts - but for production code I'd be extremely wary of that technique.

[swannodette → moe]

Again you don't need to do it that way in Clojure. And in fact Enlive put solutions like jinja, mako, etc to shame:

  (defn viewc [params session]
    (let [navs (if (= (:action params) "reverse") (reverse navs) navs)
         [nav1 nav2] navs]
      (base {:title "View C"
             :main (three-col {:left nav1
                               :right nav2})})))

This is what a "template" looks like in Enlive. Enlive actually can extract HTML fragments out of a pure HTML file and manipulate them. This means designers can work in pure HTML and the coder can manipulate those HTML files at will w/o putting any code into the markup.

[moe → swannodette]

Well, thanks for providing a peek, although I'm still not sure I could bear that syntax. I just find it very hard to parse ("})})))", seriously?), but perhaps that gets better with age/familiarity.

The "can extract fragments from pure HTML" part certainly sounds interesting. But still I have to wonder how well that scales to complex templates. I mean, mixing logic into templates is ugly, but the alternative - completely separating the interpretation from the template - doesn't seem so rosy to me either. During a bigger re-arrangement I imagine it could become quite nasty to re-sync the new template version with what the code expects?

I assume the above "template interpretation code" was for quite a trivial thing. What would it look like for complex stuff? (70 chars of closing parentheses? ;-) )

[swannodette → moe]

Yet you're are okay with the following? :)

  {%for x in foo%}
  <div id="cool">{{x.bar}} {{x.baz|pluralize}}</div>
  {%endfor%}

It's just different flavors of line noise. At least with Emacs you have paredit to manage code structure for you, no need manually track parens/braces at all.

[moe → swannodette]

Yet you're are okay with the following? :)

Quite frankly; yes.

Not pretty in any way but I guess 15 years of familiarity play their part and I have never had a big problem with that particular concept (it just works well for me in practice).

However, to each their own. Looking forward to see how compojure adoption will play out, perhaps at some point I'll just "get it" and wonder how I ever worked without it. ;-)

[weavejester → moe]

Generally speaking, Lisp programmers tend to ignore the closing brackets. They're something for the editor to handle.

Also, most Clojure functions tend to be only a few lines, so you'd rarely find yourself with more than, say, 8 closing brackets.

[asolove → moe]

Actually, just the opposite for someone familiar with Lisp. A friendly editor can rearrange and splice s-expressions very quickly.