I wonder if it's feasible to hack the javascript engines (v8, spidermonkey, ...) to support languages CoffeeScript? In case the answer is positive how come nobody's doing that?
CoffeeScript: The beautiful way to write JavaScript
61–70 of 88 posts
Re: CoffeeScript: The beautiful way to write JavaScript
#62Out of curiosity: What's with today's obsession over beautiful syntax? Shouldn't we strive for beautiful semantics, instead?
Absolutely, but the idea here is a bit different. JavaScript is a language that we're stuck with for the entire foreseeable future of the web, for better or for worse ... and CoffeeScript is a conscious attempt to try and work within that limitation. Unless you're willing to take the significant performance hit of running an interpreter on top of JavaScript, you have to stick fairly close to JavaScript semantics. Tha…
No, you aren't trying to "improve JS semantics", you are trying to 'Rubyify' Javascript. You've created a language that is NOT javascript. Sorry, but no matter how hard you try to sell it as === javascript, it still will never be javascript. It's a Ruby syntax wrapped around javascript with some bells and whistles. It isn't a solution for javascript programmers, but it might be a solution for Ruby programmers.
Re: CoffeeScript: The beautiful way to write JavaScript
#63Earlier quoted context omitted.
I don't think many use CoffeeScript because they don't "get" JavaScript. I think they use CoffeeScript because it gives them a much better JavaScript and makes them more productive and "happy".
I don't agree with your opinion at all. Your claim that coffeescript is somehow 'better' than javascript is just false. You prefer one syntax, fine, but don't assume that it is somehow 'better'. I prefer Javascript. I do not prefer Coffeescript at all, and I get javascript, and have gotten it for 14 years.
When targeting Node, one runtime and ES5, vanilla JS isn't so bad. Writing JS for browsers is painful, and CS addresses a lot of those pains.
A function that does nothing useful but illustrates some pain points:
function frob(obj) {
var rest = [].slice.call(arguments, 1)
, results = []
for (var k in obj) if (obj.hasOwnProperty(k)) {
v = obj[k]
if (blurgh(v, rest)) {
results.push(v)
}
}
return results
}
frob = (obj, rest...) -> [v for v of obj if blurgh(v, rest)]
edited: Fixed the CS to iterate over keys of obj using 'of' based on other comments here
Re: CoffeeScript: The beautiful way to write JavaScript
#64Earlier quoted context omitted.
Well it seems your assumption that "pretty" is purely a luxury, something that's nice to have but serves no practical purpose other than aesthetic satisfaction. Personally I disagree. I think a programming language is not like a car, at least not in that with a car whether it's pretty or not has no practical effect on the utility of the car. You are using the computer language to express your own ideas, and to formul…
My perspective is a little more subtle than that. To clarify: "Pretty" is great -- desirable, even. But if "pretty" comes at the cost of using immature tools that may slow me down, or at the cost of forcing my development team to learn a new syntax just because I believe it's "pretty" -- well, that's a harder value proposition. That's what I'm trying to get at with all this. It sounds like, to you, the level of "pret…
That's a fair point, and there are a few things I would point out in no particular order:
The first is that CoffeeScript is ultimately a sort of dialect of Javascript. CS and JS can interact with eachother seamlessly, so as mentioned in the OP article there's no need to switch over to CS for everything and/or all at once.
Another important thing is that where possible CS tries to map relatively directly to JS, so for experienced JS developers they will recognize CS as a series of shortcuts which map to idioms they use constantly.
If you are familiar with JS, doing a few small projects in CS should get you pretty familiar with it.
CS is obviously somewhat immature, but I think it's reached the point where it can be considered for "serious work". I've found the tooling is pretty decent: coffee is slick with commands like --watch to recompile on changes, and coffee-mode for emacs is nice. There's also CS mode for vim, textmate, gedit, + more.
Honestly the main hurdle is potential debugging problems, but I haven't found that to be too difficult either. Being mindful of how CS transforms your code, and strategic debugging code make the process for me not much different from debugging regular JS.
So I'd say at this point I don't think CS presents hurdles which are terribly difficult to overcome.
Re: CoffeeScript: The beautiful way to write JavaScript
#65Earlier quoted context omitted.
For competent Javascript developers the learning curve to CoffeeScript is an afternoon tops, because it is Javascript. If you consider that, it essentially becomes a free lunch since now you can express your ideas more clearly than raw JS.
Interesting. To me, CoffeeScript is emphatically not JavaScript. There are new tools and, well, there's a new syntax. Semantically they may be (almost) equivalent -- but it strikes me as a far stretch to say they're the same, or that developers will treat them the same. I suppose I would feel similarly about HAML, too.
CoffeeScript syntax is close enough to Python or Ruby syntax that the syntax itself is "instantly readable" and "quickly writable" -- HAML on the other hand is altogether new syntax and much more 'innovative' on that front than I'd argue Coffee is.
I'd be really shocked if you showed a solid Javascript programmer who has written code in a scripting language like Perl, Python, or Ruby a chunk of CoffeeScript code and he/she couldn't easily infer what was going on just by intuition alone.
Re: CoffeeScript: The beautiful way to write JavaScript
#66I can't shake the feeling that people that like CoffeeScript are those that don't "get" JavaScript (e.g. CoffeeScript's notion of a class, whereas JavaScript has none -- let go an embrace the prototypal object model). Further, most (if not all) of the examples of the problems with JavaScript are null and void. A language that combines paradigms? Most do. Sure, the name sucks, but that's hardly an issue. I understand…
Chris Okasaki has some high praise for languages implementing indentation as part of the syntax http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-i... Personally I think Coffeescript is a big step forward. A pity it will likely never gain enough momentum to see native implementations on the major browsers.
"Native implementations on the major browsers" will only harm coffeescript, since we'll never see rapid development and evolution of the language and maybe have to deal with the implementation incompatibility in different browsers.
Re: CoffeeScript: The beautiful way to write JavaScript
#67Earlier quoted context omitted.
Absolutely, but the idea here is a bit different. JavaScript is a language that we're stuck with for the entire foreseeable future of the web, for better or for worse ... and CoffeeScript is a conscious attempt to try and work within that limitation. Unless you're willing to take the significant performance hit of running an interpreter on top of JavaScript, you have to stick fairly close to JavaScript semantics. Tha…
No, you aren't trying to "improve JS semantics", you are trying to 'Rubyify' Javascript. You've created a language that is NOT javascript. Sorry, but no matter how hard you try to sell it as === javascript, it still will never be javascript. It's a Ruby syntax wrapped around javascript with some bells and whistles. It isn't a solution for javascript programmers, but it might be a solution for Ruby programmers.
It might also be a solution for programmers who don't tend to label themselves "LanguageX programmers".
Re: CoffeeScript: The beautiful way to write JavaScript
#68I can't shake the feeling that people that like CoffeeScript are those that don't "get" JavaScript (e.g. CoffeeScript's notion of a class, whereas JavaScript has none -- let go an embrace the prototypal object model). Further, most (if not all) of the examples of the problems with JavaScript are null and void. A language that combines paradigms? Most do. Sure, the name sucks, but that's hardly an issue. I understand…
Sure, the name sucks, but that's hardly an issue.
Re: CoffeeScript: The beautiful way to write JavaScript
#69I can't shake the feeling that people that like CoffeeScript are those that don't "get" JavaScript (e.g. CoffeeScript's notion of a class, whereas JavaScript has none -- let go an embrace the prototypal object model). Further, most (if not all) of the examples of the problems with JavaScript are null and void. A language that combines paradigms? Most do. Sure, the name sucks, but that's hardly an issue. I understand…
I agree with everything you are saying. Coffeescript really is for people who prefer a ruby/python syntax, and who just don't like javascript's syntax. BEATUY IS IN THE EYE OF THE BEHOLDER people! Just because you find javascript 'ugly' and coffeescript 'beautiful' doesn't actually mean everyone agrees with you. I think Javascript is beautiful and I've been coding it for 14 years. I have no need to replace the syntax…
Who said everyone has to agree? If you don't like coffee script, don't use it.
It's that simple.
Re: CoffeeScript: The beautiful way to write JavaScript
#70Earlier quoted context omitted.
Absolutely, but the idea here is a bit different. JavaScript is a language that we're stuck with for the entire foreseeable future of the web, for better or for worse ... and CoffeeScript is a conscious attempt to try and work within that limitation. Unless you're willing to take the significant performance hit of running an interpreter on top of JavaScript, you have to stick fairly close to JavaScript semantics. Tha…
No, you aren't trying to "improve JS semantics", you are trying to 'Rubyify' Javascript. You've created a language that is NOT javascript. Sorry, but no matter how hard you try to sell it as === javascript, it still will never be javascript. It's a Ruby syntax wrapped around javascript with some bells and whistles. It isn't a solution for javascript programmers, but it might be a solution for Ruby programmers.
are you trying to say that automatic lexical scoping and everything-is-an-expression are not improvements to javascript semantics? so what if they're "rubyfying" it?