81–90 of 132 posts
"And if you value making JavaScript easier to read by virtue of getting everyone to solve the same problems the same way with the same Design Patterns, CoffeeScript is a good tool for getting everyone else to write good JavaScript."
Does this really deserve a full article and a bait-and-switchy headline?
Raganwald: as much as I enjoy your writing, this condenses to a sentence. The Apple Summarizer actually did a good job: "And if you value making JavaScript easier to read by virtue of getting everyone to solve the same problems the same way with the same Design Patterns, CoffeeScript is a good tool for getting everyone else to write good JavaScript." Does this really deserve a full article and a bait-and-switchy head…
http://raganwald.posterous.com/why-i-downvote-tldr-comments-...
Earlier quoted context omitted.
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…
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.
what's wrong w/ javascript? fill me in, because i for one totally love js the way it is.
Earlier quoted context omitted.
You missed the rest of the essay, wherein Raganwald described how CoffeeScript “features” are a shorthand for common JavaScript design patterns, forcing everyone to use the same patterns in the same way. [In other words, he answered your specific comment at great length, rendering your criticism of one out-of-context quotation a bit weak, eh?] Specifically, most major JavaScript projects have some kind of class imple…
Class inheritance is not a common JavaScript design pattern. It's a hack, used by a minority of JavaScript developers, in a minority of projects. The crux of the argument is that when you write CoffeeScript you think in JavaScript. But I absolutely never think about overriding a parent function in JavaScript. In CoffeeScript this is actively encouraged. Like I said, as other ideas like await/defer become more mature…
If you don’t like the way JavaScript’s prototypal inheritance works, take it up with Brendan Eich.
You are simply wrong about the commonness of using prototypes though. Nearly every big JavaScript project is organized around extending and creating prototypes, and making instances via the `new` keyword. It’s only a few zealots who militate against using that feature... and to the detriment of their followers, who end up with code that is slow and a memory hog.
Earlier quoted context omitted.
There are a half a dozen different implementations of class inheritance in JavaScript. However no one writing a JS library is going to ask the consumer to extend one of their objects. This is what inheritance is all about. In Java you extend everything. Backbone.js is the only popular JS library I can think of which has their users use this pattern. It doesn't make since most of the time because: 1) The use of the pa…
> 1) The use of the pattern is not common in the js community. The use of prototypes is ubiquitous in the JS community. There's no two ways about it. Unfortunately, the avoidance of prototypes is also a common anti-pattern in the JS community, simply because JavaScript prototypes are so awkward, fragile and verbose. Doing the wrong thing with JS prototypes is easier than doing the right thing, which leads many develo…
My point is that this is leading (and other features like await/defer will do this as well) to different design patterns. Such as Batman.js taking use of your extends keyword for consumers to implement their framework.
Earlier quoted context omitted.
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…
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…
Earlier quoted context omitted.
I find really well-written CoffeeScript easier to comprehend and scan, even though the community at large believes I hate the stuff entirely (I don't). I'm just not sure if it's enough to make up for a less-than-optimal debugging experience, especially considering that most of us don't write really excellent code all the time.
So now we need Coffeescript, The Good Parts.
I'm not particularly sold on CoffeeScript, however this article seems to imply we'll someday have to maintain the generated files? As long as you keep the source near the generated files (which should be easy with version control -- you shouldn't even be checking in the generated source, in my opinion), I don't see the problem.
That is what we do for example in Hallo Editor: https://github.com/bergie/hallo
The obvious rejoinder is that new languages often evolve from design patterns: a pattern or technique is recognized and subsumed into a language: structured programming; object oriented etc. This is explicit in lisp DSLs, and even C++ at one stage was a bunch of C macros.
- True, the design patterns that CoffeeScript encapsulates aren't revolutionary - but few mainstream languages are.
- And also, the design patterns are local (unlike, say, garbage collection) - but so is structured programming.
There is a question of leakiness of abstraction. Ideally in a high-level language, you are insulated from lower-level details: C is (mostly) independent of the assembly language; VMs provide even more insulation for Java, C#, Ruby, Python; SQL is independent of physical storage. A problem with implementing a language with code-generation is that errors are stated in terms of the target language instead of the source language, making them confusing and hard to debug. But this is an implementation issue, not a language issue. For example, errors can be stated in terms of the source language, by including line numbers (this is also necessary for VMs).
I think the complaint is that because CoffeeScript is explicitly a JavaScript generator that is meant to be human-readable, it doesn't make sense to clutter it with line-numbers. It is trying to target two human user-interfaces; and it can't be a clean abstraction for both. This is a problem with the goal of the present project, not with the language itself.
The CoffeeScript project includes a language, with syntax and semantics (which happen to be defined in terms of JavaScript); it also includes a mapping to JavaScript. One might therefore say "The CoffeeScript project is not a language". But the CoffeeScript language is a language.
