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

[moe]

I'm regularly curiously peeking at the functional languages but I must say those slides did not convince me much - perhaps just bad choice of examples.

E.g. on slide 79 the sight of generating HTML through a DSL horrifies me. Littering the code with presentation details like that leads to maintenance hell.

Likewise in the comparison of slide 83 vs 85 I frankly don't see any difference between python and lisp in terms of verbosity.

So whatever point the author was trying to make - didn't work for me.

[weavejester → moe]

HTML isn't meant to handle presentation. Ideally, it's a way of marking up content to allow an arbitrary presentation layer to be laid on top.

I prefer generating HTML content through s-expressions. It's more flexible and concise than a templating library, and it forces you to bear in mind the separation of content and presentation. In turn, this makes it easier to unit-test the views, and to write automated integration tests.

For instance, if I were a designer writing a template, I have control over both the CSS and the HTML. This might tempt me to write the HTML around a particular design:

  <div class="post">
    <div class="small">
      <%= post.points %> points by <%= author.name %>
    </div>
  </div>

But if I am a programmer, without necessarily much knowledge of the presentation, I might be more careful to write more semantic HTML that's presentation-neutral.

  [:div.post {:id (str "post-" (:id post))}
    [:div.header
      [:span.points (:points post)]
      " points by "
      [:span.author (:name author)]]

Which has the useful side effect of making it easier to write tests:

  (is (= (css-select "#post-1 .author" (:body response))
         "Test User"))

[swannodette → moe]

Python templating solutions are also broken. They mix markup and logic. You could do everything described in the slides and use something like Enlive instead which cleanly separates markup and presentation logic. Most of the fancy features in popular templating solutions is just function composition in Enlive. Being a competent Lisp, macros can take things to a whole other level.

83 and 85 are the least interesting slides. How could instance instantiation be made much more succinct than that?

Having developed web apps in Python (CherryPy, Django) a lot of boilerplate could be eliminated just by having access to macros.

[flogic → moe]

Having done the DSL templatng route in Perl, it's not really that bad. Really there isn't much difference between having the templates in a template language or a first class programming language. I can see it getting bad if you're not disciplined and mix you app logic with you display logic. But it's not really all that bad. I did it so I could use closures and what-not in my templates. Worked out well. Makes the higher level templates more readable.

[moe → flogic]

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.

[jcromartie → moe]

Well forget the HTML-in-Clojure bit. Most people don't like that. Enlive is the current standard for complete separation of presentation and logic in Clojure right now. And hey, at least it's not HAML :)