fx analysis

gistfile1.md

So, I was having a twitter discussion with the esteemed @alandipert and @swannodette that has gone beyond the scope of what can be effectively communicated in 140 characters.

It was on the perceived value of Clojure's new feature expressions and whether they are worth the complexity cost of adding to Clojure and all its dialects.

Alan's contention (and forgive me if I am misconstruing this, Alan) is that feature expressions make the Clojure reader considerably more complex, and so it becomes that much more difficult to write any software which reads Clojure code (except for Clojure's own reader, of course, where the work is already done). As best I understand Alan's argument, this is a significant enough effect to undermine or negate the value proposition of Feature Expressions all together.

I disagree, so I'd like to go through the pros and cons of each use case.

• Application developers (single-platform codebase): No impact.
• Application developers (multi-platform codebase): FX are strictly easier to use than CLJX. Positive impact.
• Library developers (single-platform codebase): No impact.
• Library developers (multi-platform codebase): Can now deliver *.cljc files with guaranteed support instead of having to generate seperate source artifacts for each target. Positive impact.

For Tool developers the story is a bit more complex. There are actually two dimensions here:

1. Tools which care about (cljx | FX) support, and those who do not.
2. Tools which operate on raw text (pre-reader), and those which utilize tools.reader.

For tools which do not care about (cljx|fx) support, nothing has changed from today. No impact. Just explicitly don't support *.cljc or *.cljx files, done.

For tools which utilize tools.reader (or JVM Clojure's built-in reader), all the work is done. They should function as normal. No impact.

For tools which operate on raw unread source text, and which want to support either cljx or FX, effort is definitely required. Parsing these files is a well-specified but nontrivial problem. HOWEVER. The effort required to support feature expressions is no greater than the effort required to support cljx. In fact, tools which already support cljx (e.g, CursiveClojure) work out of the box with FX (for the most part).

Therefore, my argument is that feature expressions are strictly superior to the status quo. The only possible sense in which tool-writers are worse off is that they may feel more of an obligation to support FX than they did to support CLJX, but this doesn't actually change facts on the ground for anyone, because everyone who wants to write cross-target code was already using CLJX. If anything, cross-platform application and library developers will now have more and better tooling available since there is an officially sanctioned way to do it.

Hey Luke, thanks, I think your statement of my position is roughly accurate. I would change it slightly by qualifying that I can't claim Feature Expressions make the reader considerably more complex. I would say that as new syntax, they make Clojure more complex, but whether considerably so or not is relative for the purposes of my argument.

Would you disagree also with this simplified statement, that Feature Expressions add syntax - and therefore complexity - to Clojure?

@alandipert Definitely, they are a new feature to Clojure and therefore by definition increase the number of parts it has, therefore its complexity.

My argument is based around the fact that CLJX is already a fact of life for me and many others, so Feature Expressions are a /reduction/ in complexity when you consider the whole ecosystem. Clojure+FX is more complex than Clojure 1.6, but Clojure+FX is considerably less complex than Clojure+CLJX, which is what we all have to live with otherwise.