Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I feel bad saying this, because I respect raganwald greatly and I usually enjoy his writing, but this post is somewhere on the border between facile and false. For example:

> CoffeeScript has lots of more subtle transformations up its sleeve, like comprehensions, destructuring assignment, splats, or the "fat arrow" some rail against. Here's the secret to understand: None of these things are "language features" that compile from a language that has them—CoffeeScript—into a language that doesn't have them—JavaScript

Well, CoffeeScript does have these features, and JavaScript really doesn't have them. Would you describe JavaScript as a language that has them? Destructuring assignment doesn't exist in most implementations of JavaScript. It will have that feature later on, but it doesn't now. It also doesn't have comprehensions or splats. That's why the JavaScript that CoffeeScript generates doesn't just use JavaScript's syntax for these features — they aren't there. Instead, you have to do something else that gets the same effect.

This is also ignoring bigger changes, such as the fact that everything is an expression. That isn't true in JavaScript at all, and can't be mimicked with anything that even vaguely resembles it. You have to do what CoffeeScript does in the generated JS — constantly be storing intermediate values at the place where they're produced and assigning them afterward if you want to get a value out of most constructs (such as an if).

The two languages do correspond pretty closely, and that's intentional. But the same is true for C and machine language. If you think that C is just a shorthand for machine language, I guess you're welcome to your opinion, but you're pretty lonely with that one.

Any source language can be said to be a simple transformation of its target language, since that's what a compiler does. That doesn't mean they're the same.



Any source language can be said to be a simple transformation of its target language

Not always. There are a number of language features that have non-local implications, such as pattern matching, lazy evaluation, continuations, or exceptions. If you implement such a feature on top of a language that doesn’t have it, you will have decidedly complex transformations.

I agree that it’s overly simplistic to suggest that it isn’t a full language if it only involves local/simple transformations, but the question of local vs. non-local transformations at least hints at the idea that a new paradigm or way of thinking about programming is involved.


Nit: I think pattern matching would be local the way you are using the term; pattern matching is(/would be) implemented right at the site you use it with some form of if/else clauses that would be verbose, but obviously related to the original code. Your other three examples definitely involve large-scale "non-local" source transformation all over the place to implement them.

I say this because it took me a moment to figure out how those four things went together.


Clojure's core.match is implemented as a macro with almost exactly the technique you mention. It spits out a decision tree built out of conds.


the question of local vs. non-local transformations at least hints at the idea that a new paradigm or way of thinking about programming is involved.

Which is an excellent point, and I think the essay would have been better served if you had oriented it that way, and not around the "not a language worth learning" hook.


I think that essay would be even better than this one. Thanks!


I took part in a discussion of this idea about a month ago: http://news.ycombinator.com/item?id=3198941 There's a paper in there you would want to read as research for that essay.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: