search

jashkenas / coffeescript

Unfancy JavaScript
https://coffeescript.org/
MIT License
16.5k stars 1.99k forks source link

"Zen" of CoffeeScript #1221

Closed OnesimusUnbound closed 13 years ago

OnesimusUnbound commented 13 years ago

Where can I find a compilation of design principles behind CoffeeScript, just like Zen of Python. One the core principle is this one (straight from the home page)

dvv commented 13 years ago

Judging on the latest feature requests, I guess it's becoming more of 'Zen of Ruby' :D Sorry, couldn't help noticing...

michaelficarra commented 13 years ago

@dvv: we could do without the flamebait.

@OnesimusUnbound: See #1197 (it starts about half way down), which contains a few of the more important goals of CoffeeScript's output. Unfortunately, I don't think there's a true list written down at this time; it's all just what we have learned from each other (and especially jashkenas) over time. I'd be interested in taking a look at a nice list that we could possibly add to the documentation if anyone is interested in fleshing one out.

dvv commented 13 years ago

@michaelficarra: I wouldn't call it such -- in reality there is a bunch of requests starting as "In Ruby I can do X. Let's register a keyword in CoffeeScript to make me comfortable." This may signify people started to look at CS as at a collection of good syntactic sugar, not as 'just JS', and this may be an item in the requested list.

michaelficarra commented 13 years ago

@dvv: Yeah, and we've had a bunch that start "In python, I can..." and "In perl, I can...". CoffeeScript borrows good ideas from whoever has them. It happens to be the case that Ruby has a lot of useful syntactic sugar from which we like to borrow or by which we are inspired. And CS really is almost all sugar. That's how we continue to be "just JS". It's just an easier to read, easier to write version of Javascript. In conclusion, your comment added nothing to the conversation and only detracted from it by provoking an argument. If you want to continue, go open another issue for it.

dvv commented 13 years ago

I'm not sure I 100% correctly get the word "Zen", but if it's kinda "how things should be" I think CS should look towards JS patterns. That is, imho, 1) intrinsic asynchronity and thus various continuation code styles; 2) duck-typing. While for both there are external libraries, I find it would be good to have in CS core, inclusion being configurable via, say, coffee cmdline option. To normalize JS engines (that IIRC is one of CS goals) and help duck-typing people often include underscore,js. This lib is tiny when minimized, and could be bundled behind the scene into the resulting JS code, say, be doing coffee -U src.coffee. This is more for client side. For server-side, of which primary is node.js, creationix/Step (which again is tiny and robust), or another lib of choice, could be included augmented by some syntactic sugar. The same is already done to support classes -- CS includes some startup code behind the scene.

michaelficarra commented 13 years ago

@dvv:

Firstly, I think what he was looking for was more the "essence" of coffeescript -- its defining features.

Again, with regard to duck-typing, I don't think that it means what I think you think it means. There is also no engine normalization done by coffee. It just outputs code that works on all engines (IE6 and better), no hacks or feature tests required. Underscore does not help people with duck-typing, it pushes them away from it by trying to define strict types (and using duck-typing to do that of course). And finally, CS does not have classes in the OO sense. It uses the (already reserved in JS) class and extends keywords as sugar (there's that word again) for creating a nice prototypal inheritance chain.

Now, I'd like to steer this conversation back to the goals of CoffeeScript. That is, if anyone is willing to try to take a first stab at it.

OnesimusUnbound commented 13 years ago

@michaelficarra

Yeah, it's more of design goal for CoffeeScript.

Reading through #1197 I found your comment helpful.

We compile for human-readability and performance, followed by code size. It is both more readable and more performant to modularize it. The performance benefit comes from how modern JS engines compile JS before running it

One thing I notice is that CS will add syntactic sugar for commonly used construct, like using -> instead of the verbose function(){}, list comprehension, and class.

I think it's more of bring the best of JS, hiding it's shortcomings.

michaelficarra commented 13 years ago

@OnesimusUnbound: yes, that is a good general goal