Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CoffeeScript: The beautiful way to write JavaScript

amix.dk

Post reply on HN
Print view View original

21–30 of 88 posts

Re: CoffeeScript: The beautiful way to write JavaScript

#21

Post by jashkenas »

davepeck wrote: post #12

Out 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.

That said, we certainly try to improve upon JS semantics, where it's possible to do so without a performance hit. Things like auto-lexical scoping, bound functions, chained comparisons and, most importantly, "everything is an expression", are all examples of this.

Re: CoffeeScript: The beautiful way to write JavaScript

#22

Post by grayrest »

jherdman wrote: post #4

I 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 prefer coffeescript for the reduced line noise, particularly around lambdas, loops/comprehensions, and object literals. I find the shorter lines and reduced line count* allows me to notice api flaws more easily, so I tend to do my api design in cs. I generally don't use the class construct unless the library I'm working with uses the same pattern (e.g. yui3). It's pretty much just syntactic sugar that simplifies the code at the expense of complicating the toolchain. I think it's worth it but I've met plenty of people who don't.

* In js->cs rewrites I usually wind up cutting the line count in half, but most of that is eliminating all the stray closing brackets on their own lines and collapsing if statements into single lines.

Re: CoffeeScript: The beautiful way to write JavaScript

#23

Post by boucher »

jashkenas wrote: post #16
hermanthegerman wrote: post #15

Earlier quoted context omitted.

I have to say that by using cs I learned a lot more about js. Maybe for old js cats it doesnt matter, but I only used js occasionally before, and now it became one of my favorite languages (I use with node, and I write all my node stuff in cs). One particular example that changed everything for me was the natural and simple way I could build the typical callback constructs with -> and => , so they almost look like bl…

To explain the reason for the "in/of" distinction... "for item in list" vs "for key, value of object" is an unfortunate necessary evil. It would be great to use the same keyword, "in", for both types of loop, but I'm afraid there's no way for us to know at compile time if "list" or "object" is really an array, or really an object.

I'm curious, why do you need to make a distinction? Is there some other feature of CS that depends on it? Certainly 'for key, value of array' could be implemented with numerical keys. If using just 'for value of dict' is allowed that would also work fine.

Re: CoffeeScript: The beautiful way to write JavaScript

#24

Post by oscilloscope »

barmstrong wrote: post #10

I would love to see javascript turn into assembly language. Google has already done with with GWT with great improvements in productivity. One question I had while reading this. Was there a technical reason why he didn't make a gem or toolkit in pure Ruby or Python that would then spit out Javascript? I think this is closer to how GWT did it where you can write pure Java, and of course it then wouldn't require people…

The issue is Ruby/Python/Java's semantics don't map perfectly to JavaScript. As it says in the documentation, the golden rule of CoffeeScript is "It's just JavaScript".

For people who know JavaScript, it's not a new language-- just some syntactic sugar and a few bonus features.

Re: CoffeeScript: The beautiful way to write JavaScript

#25

Post by dstein »

mrkurt wrote: post #17
dstein wrote: post #7

I really wanted to like CoffeeScript but that it can't be metaprogrammed and serialized (easily) is a huge problem for a scripting language. I guess scripting was never the point of CoffeeScript, but a lot of what makes JavaScript so flexible is lost when you add a compile stage.

I'm struggling to think of something I can do in Javascript, but not CoffeeScript. Can you give an example?

Because of whitespace and line break sensitivity you can't dynamically generate serialized CoffeeScript (unless delicately handled) because it won't compile.

Re: CoffeeScript: The beautiful way to write JavaScript

#26

Post by jacobolus »

davepeck wrote: post #20
skymt wrote: post #18

Earlier quoted context omitted.

In this case, the semantics were already decided: CoffeeScript was intended to map transparently to JavaScript. Each change to semantics would add complexity to that mapping.

Syntactic sugar is all CoffeeScript can ever be. Is pretty syntax better than common-use syntax? (To be clear: I don't have a strong opinion. I'm curious what the community thinks the value proposition for CoffeeScript, HAML, etc is.)

> Is pretty syntax better than common-use syntax?

What do you mean?

Re: CoffeeScript: The beautiful way to write JavaScript

#27

Post by jashkenas »

boucher wrote: post #23
jashkenas wrote: post #16

Earlier quoted context omitted.

To explain the reason for the "in/of" distinction... "for item in list" vs "for key, value of object" is an unfortunate necessary evil. It would be great to use the same keyword, "in", for both types of loop, but I'm afraid there's no way for us to know at compile time if "list" or "object" is really an array, or really an object.

I'm curious, why do you need to make a distinction? Is there some other feature of CS that depends on it? Certainly 'for key, value of array' could be implemented with numerical keys. If using just 'for value of dict' is allowed that would also work fine.

We need to make a distinction because we want to have arrays be iterated over with:

    for (var i = 0, l = list.length; i
And objects iterated over with:

    for (var key in object) { ... }
Using a "for-in" loop over a JS array isn't acceptable, for performance and semantics reasons, and neither is sniffing at runtime to determine whether the object passed is an array, or an object.

Ideally, JavaScript would have supported a single iteration protocol for both arrays and objects from the get-go, but alas...

Re: CoffeeScript: The beautiful way to write JavaScript

#29

Post by oscilloscope »

mrkurt wrote: post #17
dstein wrote: post #7

I really wanted to like CoffeeScript but that it can't be metaprogrammed and serialized (easily) is a huge problem for a scripting language. I guess scripting was never the point of CoffeeScript, but a lot of what makes JavaScript so flexible is lost when you add a compile stage.

I'm struggling to think of something I can do in Javascript, but not CoffeeScript. Can you give an example?

I'm building a web-based IDE for Raphael in CS. My big pain point: when users define a function, JS Shell returns the JS version of the function. If the user types in a function name without calling it, they see the JS definition. Since one can't go from JS -> CS, I can't figure out a good way to keep JS away from the user.

http://fleetinbeing.net/raffi/ (type "spiral 30" to run a function defined in CS, then type "spiral" to see the definition in JS)

Re: CoffeeScript: The beautiful way to write JavaScript

#30

Post by hermanthegerman »

jashkenas wrote: post #16
hermanthegerman wrote: post #15

Earlier quoted context omitted.

I have to say that by using cs I learned a lot more about js. Maybe for old js cats it doesnt matter, but I only used js occasionally before, and now it became one of my favorite languages (I use with node, and I write all my node stuff in cs). One particular example that changed everything for me was the natural and simple way I could build the typical callback constructs with -> and => , so they almost look like bl…

To explain the reason for the "in/of" distinction... "for item in list" vs "for key, value of object" is an unfortunate necessary evil. It would be great to use the same keyword, "in", for both types of loop, but I'm afraid there's no way for us to know at compile time if "list" or "object" is really an array, or really an object.

The fact that cs is doing this 'the right way', meaning safe for all environments, as you have explained below, is one of the reasons I like it.
Post reply on HN