5 ms·

TransparentCompilation

29 points by lispython 14y ago

lukev 14y ago
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 14y ago
  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 14y ago
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.

29 points by lispython 14y ago

lukev 14y ago

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 14y ago
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 14y ago

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.