
TransparentCompilation - lispython
http://martinfowler.com/bliki/TransparentCompilation.html
======
lukev
I think an important note would be to add that transparency is not a binary
property.

For example, he mentions ClojureScript as a language that compiles opaquely.
Fair enough; it's certainly more opaque than CoffeeScript. But it's still
relatively easy to read the emitted code, _much_ more transparent than GWT,
which is the other example he mentions.

~~~
jfarmer
As I read the article, I don't think that's what Fowler was talking about. I
think he noticed a trend in things like Less, Sass, Haml, CoffeeScript, etc.
The relationship between, say, Haml and HTML is qualitatively different than
the relationship between Clojure and Java (or JVM bytecode).

So, it feels like something new is happening and this essay was an attempt to
more precisely define an otherwise qualitative feeling. In my reading, here's
how he did it.

We say a compiler from language X to language Y is _transparent_ when two
things are true:

1\. The compiler produces a clear and human-understandable mapping between the
syntax of X and Y. That is, given code in language X, a human could predict
the compiler's output in Y.

2\. (1) is not merely a happy accident, but a stated design goal of the
compiler or underlying language X. That is, it's not whether (1) is the case,
it's whether we're guaranteed that (1) is the case.

It's (2) that separates ClojureScript and CoffeeScript. Lots of compilers
satisfy (1), e.g., a really naïve C compiler, but it's not by design. There's
no intention, no promise to the developer, that the mapping from X -> Y has
property (1).

For example, ClojureScript's priority is not about producing a clean mapping
between Clojure and JavaScript, it's about bringing the expressiveness and
power of Clojure to client-side development. If you look at the ClojureScript
example page you see lots of "Here's how you do X in ClojureScript, but
there's not native way to do X in JavaScript."

If we had two ClojureScript compilers A and B, and A produced 10x faster
JavaScript than B at the cost of lots of crazy optimizations, we might very
well choose A.

It'd be a much harder call for CoffeeScript, because part of the pitch
CoffeeScript makes to developers is that it's "like JavaScript without all the
bad parts."

I don't necessarily agree with the above, but that's my understanding of
Fowler's argument.

------
endlessvoid94
I've been playing with the lively kernel lately and noticed that it serializes
everything to a web page that includes CSS and javascript. My first reaction
was "how horrible", but then I realized that you never actually have to edit
the page itself -- whenever you change anything or need to debug, you load the
page first into the lively kernel (deserialize it).

So, there could be an addendum here -- the HTML/CSS/Javascript trio doesn't
need to remain fixed. It is totally possible (maybe tedious and slow) to build
a browser development environment where you write SASS and coffeescript in the
browser and execute it there. It would be interpreted and compiled on-the-fly,
and errors caught in that process, rather than in the browser's normal
execution. That way you could provide feedback about the sass and
coffeescript, rather than whatever it gets compiled into.

The lively-kernel (and squeak before it) does this quite well already. It even
provides readable tracebacks for javascript errors, rather than just a script
and line number like most web inspectors.

