Coffeescript in NodeJS projects

[Roman Land]

Hi Guys,

Was looking at Coffeescript as a base language to develop upon, my concern is that it doesnt really play nicely with the rest of the NodeJS eco system, thus is a niche..

Has anyone here considered and used Coffeescript as part of a big project? is it a good direction?

Thanks for sharing!
Roman

--
---
"Make everything as simple as possible, but not simpler."

- Albert Einstein

[Aria Stewart]

On Saturday, June 25, 2011 at 12:51 PM, Roman Land wrote:

> Hi Guys,
>
> Was looking at Coffeescript as a base language to develop upon, my concern is that it doesnt really play nicely with the rest of the NodeJS eco system, thus is a niche..
>
> Has anyone here considered and used Coffeescript as part of a big project? is it a good direction?

It works fine if you're into that sort of thing. It plays nice with other node modules, and extends require() to work for .coffee files, so you're good to go. Node can call coffeescript, coffeescript can call normal node stuff.

----
Aria Stewart

[Joshua Kehn]

No, I have never and would never consider CoffeeScript for any type of project. I believe that it is not a good direction.

Regards,

-Josh

____________________________________
Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Stephen Belanger]

I've used it for a few smaller projects. It's a fun language, but it has it's quirks. I find you really need to think about what you are doing or you'll likely break something. Here's a CouchDB request with cradle as an example;

users.get req.param 'user_id', (err, doc) ->

  # Do stuff.

At first glance you might thing it'd translate to this;

users.get(req.param('user_id'), function(err, doc){
  // Do stuff.

});

But it'll actually get translated to this;

users.get(req.param('user_id', function(err, doc){

  // Do Stuff.

}));

It's a simple mistake, but can be somewhat harder to spot I make a habit of always wrapping the argument list of function calls with a single argument, just in case I try to blindly copy/paste it somewhere else or code around it.

There's also some weird language related stuff like == becoming ===.

You might have expected something more like 

[Dmitry]

I thought Traceur http://code.google.com/p/traceur-compiler/ is good direction.

2011/6/25 Roman Land <roman...@gmail.com>:

[Bas Dirks]

Do you really need type coercion? == is considered bad practice, 

and no I certainly do no expect

users.get req.params 'user_id', (err, doc) ->

  // Do stuff.

to compile to 

users.get(req.param('user_id'), function(err, doc){
  // Do stuff.

});

If I wanted that I'd use

users.get (req.params 'user_id'), (err, doc) ->

  // Do stuff.

Not hard.

-- 
Bas Dirks
Sent with Sparrow

[Stephen Belanger]

Not saying it's hard or that type coercion is a good idea, just saying that they can catch you if you aren't careful. Also, rather than this;

users.get (req.params 'user_id'), (err, doc) ->

You can do this;

users.get req.params('user_id'), (err, doc) ->

It just seems a little awkward because it mixes styles. I specifically said though that I do make a point of doing that. I'm not saying Coffeescript is terrible or anything, just that it can much more easily fail silently than plain Javascript.

[Roman Land]

Thanks for your inputs!

Dmitry, thanks for "traceur", I have not heard of it before, but it seems to be much further from the NodeJS community compared to CS.. too much risk in adding it to my first big project with Node.

Unfortunately there is not enough information to go on from the response here, I was expecting some "CS saved my life!" ;) responses to push me into adoption but didnt get any..

At this point I think I will start off with using just JS, as I dont want to limit myself at the beginning of the project..

Thanks Again!
Roman

[Eric Muyser]

I almost don't use anything but CoffeeScript for my JS these days. Many times you really need to understand what your JS your CS is going to output. I don't find it too difficult to debug. Especially if you don't omit parenthesis too much (I never omit parenthesis for any argument nested on a second level). My biggest issue is when you have a back to back callbacks as arguments. The indentation and parenthesis can get tricky, or else you end up nesting the callbacks inside eachother (like in node-async waterfall, forEach, etc). It took a while, but I've got that down. To me, it's just another language construct to remember. In any case, languages have gotchas, and I'm willing to make some exceptions. The problem I have is it's such a fluid language, I can't depend that other coders are going to be familiar with that exact style. You're given more freedom to make your own code style (not simply indentation and where you put your curly brace). For now, I'm sticking with it. I don't believe the size of the project in which I use it is going to matter much unless I'm taking my team's preferences into account.

[Martin Wawrusch]

Well, it did not save my life, but once I started working with Coffeescript I never looked back. The syntax makes programming in a  Javascript environment fun again and much more productive. Most of the time I am able to write error free Coffeescript code in the first pass, something I was never able to do in Javascript. 

My advice to you: Go for it. If you really dislike it you can always abandon Coffeescript and reuse the generated javascript. Here is a good intro that you can go over in a couple of minutes, helped me a lot:  http://coffeescript-seattlejs.heroku.com

And remember: Life is just too short to waste it on curly braces. :P

[Roman Land]

Eric, have you been able to integrate nicely with a control flow framework (step, futures..), Express, testing (I am looking into Jasmine), crawling frameworks, Zombie etc..
Or maybe a simpler question is, have you had any difficulties integrating CS and a non-CS framework?

Thanks!

[Joshua Kehn]

If you can't write syntax error free JS in the first pass I think you have other issues.

"Life's too short to waste on curly braces" - then waste your life on Python.

Regards,

-Josh

____________________________________
Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

[Eric Muyser]

Because the Python environment is an asynchronous client and server powered language, with the benefits of Node and it's modules. Oh wait, it isn't. Your comments are neither helpful or appreciated, Josh.

[Roman Land]

Josh, I see where your coming from (I think), and I understand the reasoning of keeping a clean code stack, this is why I am trying to find the value in adding CS to the mix, but it also sounds like you have not tried it or you didnt find the value in it enough to add it to your tool belt.
Personally I find some parts in CS that are much to my likings, classes, cleaner code, less typing..
Its just a matter of cons and pros now :)

So I am still not clear about integrating CS code with non CS libraries, is it a natural thing??

Thanks for your advice!
Roman

[Aria Stewart]

On Saturday, June 25, 2011 at 3:26 PM, Roman Land wrote:

> Josh, I see where your coming from (I think), and I understand the reasoning of keeping a clean code stack, this is why I am trying to find the value in adding CS to the mix, but it also sounds like you have not tried it or you didnt find the value in it enough to add it to your tool belt.
> Personally I find some parts in CS that are much to my likings, classes, cleaner code, less typing..
> Its just a matter of cons and pros now :)
>
> So I am still not clear about integrating CS code with non CS libraries, is it a natural thing??

It should be: Coffeescript maps neatly to Javascript. It's really an alternate syntax, not a wholly new language. The semantics are VERY close to Javascript.

----
Aria Stewart

[Arnout Kazemier]

/me adds more oil on the fire

Python can be used async, for example using python twisted or tornado..

And you can use python to make desktop clients..  + has modules

So HA! Your comments are neither helpful or appreciated, Eric

(so are mine, but I don't really give a rats ass about that)

Anyways! Use Coffeescript where you see fit for it. I personally hate it

and would never ever use it, if I want to compile code I'll write C not CoffeeScript.

Arnout Kazemier

in...@3rd-Eden.com

[Joshua Kehn]

I'm guessing you've never heard of Twisted....

Now Python client side, I can't help you with that. 

Regards,

-Josh

____________________________________
Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

[Eric Muyser]

Arnout, that's hilarious.

Roman, I've had no such difficulties. It works cleanly with all pure JS libraries AFAIK. As I said, callback arguments take some tweaking, but the benefits (mostly callback hell - both shorthand and shortcuts, array notation, optional parameters, function proxying, and especially jslint stuff like variable resolution and type coercion) outweigh the negatives. I find my code cleaner, and more self explanatory, but it's personal preference and it always come down to JS. If you can't use JS/Node properly, CS isn't going to help you. It simply helps those who know JS well enough, want the shortcuts, and prefer it.

I wouldn't be lost without CoffeeScript, but I do prefer it to raw JS.

[Eric Muyser]

Python is not naturally asynchronous. If you see Twisted as being in line with Node.js, you have issues (without even considering speed).

[Stephen Belanger]

I think my previous replies came off a little more negatively than was intended. I totally encourage you to try Coffeescript. What I was trying to say is basically that, at first some things will seem awkward. You will probably spend a bunch of time with the official website open to run stuff through the compiler and see if it generates what you think it will. Don't be discouraged by the initial weirdness. It'll start to make sense once you figure out what the parser is actually doing.

[Hij1nx]

At first I hated coffeescript, but that was a knee-jerk reaction to it's aesthetic. I decided it's actually a great project for experimenting with new ideas for scripting. it has even inspired the committee responsible for improving javascript! I've talked to the original developer, Tim caswell as well as the current maintainer, Jeremy ashkanas, they are both incredible developers and bring inspiring ideas to the table.

 As much as I love experimenting with new technology, I won't use it in my stack. I think it's usefulness is going to become obscured by ES6. If you dislike javascrip's rough edges, and that is your primary motivation, there are other front ends for javascript, coffeescript is one of more than 50 to consider. See the coffeescript wiki on github to learn more. 

On the other hand, If you are just experimenting and aren't concerned with the associated business risks, dive in to one of these front ends!

Hope this helps!

--

hij1nx

http://www.github.com/hij1nx

http://www.twitter.com/hij1nx

[Roman Land]

hij1nx, by your logic all code written in pure JS (ES5?) will have to be switched over, so since CS is generating JS it will have the same fate..

Cheers

[Stephen Belanger]

I'm curious what you are referring to about it's usefulness being obscured by ES6. Care to elaborate?

[hij1nx.dev]

I'm not talking about rewriting anything, that's misread. I'm talking about the decision making process prior to any body of work that is produced. Which is on topic for the question posted by the OP. Also, according to what i've been reading on es-discuss, IS6 will be opt-in (also see: http://www.2ality.com/2011/02/david-herman-on-ecmascriptnext.html) and for the most part consist of non-breaking changes.

@Stephen, the next edition of javascript aims to solve almost the same problems that coffeescript does. ++Brendan Eich seems to be a pretty big fan of coffeescript. (http://brendaneich.com/2011/05/my-jsconf-us-presentation/).

-- 
hij1nx
http://twitter.com/hij1nx

http://github.com/hij1nx

[Bruno Jouhier]

> Eric, have you been able to integrate nicely with a control flow framework
> (step, futures..), Express, testing (I am looking into Jasmine), crawling
> frameworks, Zombie etc..

Coffescript works with streamline.js.

As you are going to preprocess code anyway with CS, why not go one
step further with preprocessors and let them take care of the callback
christmas tree.

Bruno

[Kris Walker]

I noticed CoffeeScript sometime in the summer of 2010, but only
started using it this past March.

We made a decision to use CS on a three man team to build a medium
sized project both server side (Node.js) and browser. All of us are
quite good JS coders, and the lure of CS for us is that it smooths out
some of the bumps in JS. For example, loops are much more intuitive,
var declarations are lifted to the head of the function, no need for
cruft like ".hasOwnProperty()", etc. For us, the learning curve was
not a problem... maybe 2 - 5 days of coding with the reference web
site constantly open.

Development in CoffeeScript is measurably more productive for us, but,
more importantly, the language is more expressive, and sometimes
encourages us to be more expressive when we wouldn't be with JS,
resulting in code which can be read and debugged much more easily.
For example, the class declaration syntax is very explicit, and the
language really wants you to use named callbacks rather than anonymous
functions, which aids tremendously in writing readable code with
explicit meaning associated with function names.

Also, as code ages, inline comments lie. That goes for everything.
Coding in an expressive style, giving explicit meaning to variables,
functions, and classes makes reading code pleasurable. Not that you
couldn't do that with JS, but CS seems to do a better job of
encouraging and facilitating an expressive style of writing. A
programmer's purpose is to manage complexity, and an expressive
language which is a pleasure to read, will get you most of the way
there.

I'm now 4 weeks into a very large project, again using CS on both the
server side and client side. We've had no problems integrating with
existing Node.js libraries or client libraries like jQuery or
Modernizr. If anything, it has made them easier to use. It's safe to
say... We're not looking back.

Just one thing: Although CoffeeScript allows you to omit parens around
function args, we've found it has to be treated like omitting
semicolons in JS.... only do it when the outcome is obvious.

[Ted Young]

Because you're adding a compile step, run-time errors no longer give
you a line number in the actual source code. Doesn't that make
debugging more of a headache? How do you mitigate that problem?

- Ted

[Kris Walker]

On Jun 25, 8:13 pm, Ted Young <t...@radicaldesigns.org> wrote:
> Because you're adding a compile step, run-time errors no longer give  
> you a line number in the actual source code.  Doesn't that make  
> debugging more of a headache?  How do you mitigate that problem?

I thought that would be a problem, but it never materialized. If the
error message is not enough to indicate the problem location, opening
the compiled JS is easy enough.

[shawn wilson]

Here's something I just experienced. I ran across socketstream - it looks cool, uses socket.io, and might be cool. However, I like seeing examples to see what something can do (I use api docs once I am using something but I like to wrap my head around how something works with a use case example).

Well, they have three examples and some other doc:
https://github.com/socketstream/socketstream
All written in CS. I don't know cs and don't really like the syntax (just preference). However, if you develop something that someone might use, I don't think writing documentation and examples in an abstracted language is useful.

[alessio_alex]

I wouldn't use CoffeeScript because I don't think it's useful for me.
I already know the JavaScript syntax, I like it, so no point in
learning another language that translates into JavaScript.

I think CoffeeScript is more for Ruby/Python devs.

[Tauren Mills]

I suggest giving it a try to see what you think. When I first learned of it sometime in the middle of 2010, I was very skeptical and stayed far clear of it. I never would have guessed I'd be defending it now. But a few weeks ago I was starting a new project and thought I would give it a chance.

To my surprise, I'm really enjoying using it and am finding myself more productive. It took very little effort to get up to speed. And debugging with inaccurate line numbers hasn't been a problem at all, as it is very easy to locate the problem coffeescript by looking at the compiled javascript. I haven't had any trouble using it with any node modules and am writing both server and client code with it.

By the way, I'm not a ruby/python developer and have been working with client-side javascript since the 90's. My server-side background is in java, hibernate, spring, etc. I'm completely used to working with curly braces, but am finding the lack of curly braces refreshing. Coffeescript has a place for more than just the rubyists/pythonistas.

[Aseem Kishore]

I couldn't agree more with Kris and Tauren; I'm in the same boat. Can't imagine going back to regular JS for serious, non-trivial projects now.

Special thanks to Daniel Gasienica for force-feeding it to me initially. ;) I was perfectly happy with regular JS, and he was a Pythonista at heart aching for lack of curly braces.

Aseem

[Jacobus brogly.decap]

how is CS a performance wrapper?

its just a set of JS libraries right?

Cheers

2011/6/26 Roman Land <roman...@gmail.com>

Thanks guys, you really helped me to make my mind.
One thing worth pointing out after reading all the comments, is anyone who tried to write a project with CS used it again, and its usually tailored towards the bigger projects (seems to be adding stability == scalability)
Like many others here I am also a huge fan of JS, CS just seems a nice performance wrapper on top of it.

Much appreciated!
Roman

--

---
"Make everything as simple as possible, but not simpler."

- Albert Einstein

[Roman Land]

Writing scalable code performance wrapper ;)

[Aseem Kishore]

Actually CoffeeScript is not just something I would prefer to use for larger projects, it's also something I prefer to use for quick prototypes, as it lets me write logic and save keystrokes on keywords, braces, etc.

Fwiw, I found your original question kind of funny: if anything, CoffeeScript is *meant* for Node. It integrates so nicely, e.g. I don't even need a build or compile step -- I can just require() .coffee files!

Aseem

[Roman Land]

Thanks guys, you really helped me to make my mind.
One thing worth pointing out after reading all the comments, is anyone who tried to write a project with CS used it again, and its usually tailored towards the bigger projects (seems to be adding stability == scalability)
Like many others here I am also a huge fan of JS, CS just seems a nice performance wrapper on top of it.

Much appreciated!
Roman

On Sun, Jun 26, 2011 at 8:24 PM, Aseem Kishore <aseem....@gmail.com> wrote:

--

[mgutz]

My sentiments exactly. I visualize the Javascript that Coffeescript generates as I code; much in the same way I can visualize the HTML that HAML/Jade/<your template engine>  generates. Coffeescript is Javascript in the end. What I find strange is that many people will use pythonic template engines like Jade and Stylus and turn their nose at Coffeescript. All of them are just syntax sugar. Coffeescript sweetens my Javascript code.

[Joe Developer]

I think you mean 'productivity wrapper'.

From what I have read on this thread this could hold true for people who find themselves spending most of their *actually typing code* - or perhaps agonizing over loops or over where to put var declarations. 

There is certainly something to be said for writing expressive code, but for larger projects I find that jsdoc -> searchable, browsable API docs are invaluable, hence the necessity of ensuring keeping inline comments valid.

I think it is great that it can be an asset to some users and teams - but I would caution against using it as an alternative to becoming comfortable in 'pure' js. 

--JoeDev

[Tauren Mills]

I agree. I use coffeescript as a productivity tool, but I would
certainly not advise anyone to use it if they don't already thoroughly
know how to write the same application in "pure" javascript.

As far as documentation goes, check out Docco. It doesn't really
generate traditional API docs, it is more for generating annotated
source documentation. Also, I believe you can create JSDoc compatible
comments using the ### block comment style.
http://jashkenas.github.com/coffee-script/#strings
http://jashkenas.github.com/docco/

I think my biggest concern with standardizing on CF was that new
developers to my team are less likely to be fluent in it. But after
finding it took me very little time to get efficient, that is less of
a concern anymore.

[Stephen Belanger]

HTML is much simpler than Javascript though. HTML is just plain XML. There is no behaviors that can go wrong based on odd conditions--it's static. If it doesn't work you will notice right away. Coffeescript, on the other hand; can produce errors that might take a long time to become visible. I wouldn't advise using it seriously until you fully understand Javascript and exactly how Coffeescript uses it.

On Sun, Jun 26, 2011 at 11:41 AM, mgutz <mario.l....@gmail.com> wrote:

My sentiments exactly. I visualize the Javascript that Coffeescript generates as I code; much in the same way I can visualize the HTML that HAML/Jade/<your template engine>  generates. Coffeescript is Javascript in the end. What I find strange is that many people will use pythonic template engines like Jade and Stylus and turn their nose at Coffeescript. All of them are just syntax sugar. Coffeescript sweetens my Javascript code.

--

[Paul Shirren]

On 27/06/11 4:11 AM, mgutz wrote:
> My sentiments exactly. I visualize the Javascript that Coffeescript
> generates as I code; much in the same way I can visualize the HTML that
> HAML/Jade/<your template engine> generates.

+1. I am alternating between javascript and coffee. Coffeescript is
nicer to read and maintain for some things but I will go to javascript
when I want more control over the code produced.

[shawn wilson]

i don't think this is a very sound comparison. a markup language vs a
programming / scripting language (of any type) is like comparing a dog
to a rock. while i don't see the point of abstracting any programming
language (with the exception of c with the abstraction that headers
provide), i just can't compare programming to static files.

also, html is loose markup. meaning that it doesn't enforce xml
standards. ie, i can write <a whatever></A> and it'll work just fine
and i don't have to close things out and they'll generally render
fine. also, there are slight variations on how vendors implement the
dom (or render html into a dom) so 'no behaviors that can go wrong
based on odd conditions' just doesn't cut it from where i sit.

[Evgeny Bogdanov]

+1, to Kris and Tauren, Aseem.

Was very sceptical about CS at first, not anymore.

Especially after reading the blogs of Brendan Eich (JavaScript creator),  Douglas Crockford (JSON creator).

And it seems as many of CS's features are going into new JavaScript:
http://brendaneich.com/2011/05/mozillas-nodeconf-presentation/

[Felix Geisendörfer]

The line number thing is currently my #1 reason why I can't use CoffeeScript.

When doing TTD, all I do is look at stack traces (from failed asserts) to figure out what I'm going to do next.

I really hope V8 / Mozilla are going to support file number annotations for generated JS soon.

--fg

[Jorge]

On 27/06/2011, at 15:27, Evgeny Bogdanov wrote:

> +1, to Kris and Tauren, Aseem.
>
> Was very sceptical about CS at first, not anymore.
>
> Especially after reading the blogs of Brendan Eich (JavaScript creator), Douglas Crockford (JSON creator).

-1(e9) to CS. It's just the opposite of the "JS of my dreams".

Where/when/what has Crockford said anything (positive) about CS ?

Have you got any links, please ?
--
Jorge.

[Aseem Kishore]

https://twitter.com/#!/TimSporcic/status/79563314849513473

Cheers,

Aseem

[Joshua Kehn]

Another popular quote from Crockford:

    Your sadly pathetic bleatings are harshing my mellow.

http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint/

Regards,

-Josh

____________________________________
Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

[Matthieu Riou]

I'd take it the other way around: why would you not use CoffeeScript if you have the choice? There are plenty of reasons why you wouldn't be able to make that choice (company politics, hires, etc.) but if you do, CoffeeScript only brought improvements to my code. It factors in several well-documented pitfalls in Javascript. Node.js callback-heavy style introduces a lot of accidental complexity to your code, making it noisy and verbose. Coffeescript eliminates most of that. And it has quite a few niceties of its own, like array comprehensions, everything being an expression and existential operator.

As mentioned, the line number in stack traces can be a problem but it's very straightforward to do:

coffee -p file.coffee | vim -

The generated code is not bad at all to look at.

Anything that makes my code shorter and more readable translates directly to less bugs and easier maintenance. So why not?

[Marak Squires]

+10

My style is usually writing a few lines at a time and then running the test / demo page...

CF's current workflow really punishes this type of development.

[shawn wilson]

CF? As in coldfusion? If so, we really have hit the bottom of the barrel...

[Stephen Belanger]

ColdFusion is the cutting edge! Even MySpace uses it! :O

[shawn wilson]

And tomorrow you'll tell me you use homesite as an IDE :P

[hij1nx.dev]

This thread needs to die.

-- 
hij1nx
http://twitter.com/hij1nx

http://github.com/hij1nx

[Stephen Belanger]

What's wrong hij1nx? Trolling got you down? Try this!

[Isaac Schlueter]

On Mon, Jun 27, 2011 at 11:24, hij1nx.dev <hij1n...@gmail.com> wrote:
> This thread needs to die.

You realize replying is the opposite of what you should do to make
that happen, right? ;P

[Marak Squires]

--

[Mikeal Rogers]

a few notes.

people tend to be hostile to coffeescript because we get github tickets and messages that say something along the lines of "can i rewrite this in coffeescript so that it's <insert some opinionated thing that they think about coffeescript>". it's disrespectful to come in to a library that is doing something you like and say "i like everything about this except all the code".

it's just as disrespectful to be hostile to people who are playing with coffeescript on their own island having a good time. good for them, it's a cute little language, let them mess around with it.

it looks like 101 libraries, at last count, require coffeescript http://search.npmjs.org/ . let's assume that just as many push the compiled javascript to npm and don't have cs as a dependency. that's optimistically 200 modules of over 2600 in the npm registry that are in coffeescript. the rest are plain old js. it's a nice little niche.

we can all get along as long as there is some mutual respect. js people can just not care about cs, that's a totally valid course of action. cs people should in turn let js people not have to care about cs.

and done.

[Karl Tiedt]

To reiterate what Peter Higgins likes to say....

Its all just javascript! (in the end)

-Karl Tiedt

(now lets get back to that instead of bikeshedding and bickering)

ps. very well said Mikeal :)

On Mon, Jun 27, 2011 at 15:34, Mikeal Rogers <mikeal...@gmail.com> wrote:
> a few notes.

[Jorge]

On 27/06/2011, at 18:39, Aseem Kishore wrote:

https://twitter.com/#!/TimSporcic/status/79563314849513473

You're saying that somebody says that Crockford said ?

Especially after reading the blogs of Brendan Eich (JavaScript creator),  Douglas Crockford (JSON creator).

Where's *that* blog of Crockford ?

-- 

Jorge.

[Karl Tiedt]

He actually did say that... Pretty sure the #txjs folks were filming
it too (I was there as well).

-Karl Tiedt

[DTrejo]

I can help you.

Python client side!
http://www.skulpt.org/

Now you can write everything in python, just like you can write
everything in javascript! (or CS, if you're into that...)

On Jun 25, 12:35 pm, Joshua Kehn <josh.k...@gmail.com> wrote:
> I'm guessing you've never heard of Twisted....
>
> Now Python client side, I can't help you with that.
>
> Regards,
>
> -Josh
> ____________________________________
> Joshua Kehn | Josh.k...@gmail.comhttp://joshuakehn.com
>
> On Jun 25, 2011, at 3:16 PM, Eric Muyser wrote:
>
>
>
>
>
>
>
> > Because the Python environment is an asynchronous client and server powered language, with the benefits of Node and it's modules. Oh wait, it isn't. Your comments are neither helpful or appreciated, Josh.
>
> > On Sat, Jun 25, 2011 at 12:09 PM, Joshua Kehn <josh.k...@gmail.com> wrote:
> > If you can't write syntax error free JS in the first pass I think you have other issues.
>
> > "Life's too short to waste on curly braces" - then waste your life on Python.
>
> > Regards,
>
> > -Josh
> > ____________________________________
> > Joshua Kehn | Josh.k...@gmail.com
> >http://joshuakehn.com
>
> > On Jun 25, 2011, at 2:54 PM, Martin Wawrusch wrote:
>
> >> Well, it did not save my life, but once I started working with Coffeescript I never looked back. The syntax makes programming in a  Javascript environment fun again and much more productive. Most of the time I am able to write error free Coffeescript code in the first pass, something I was never able to do in Javascript.
>
> >> My advice to you: Go for it. If you really dislike it you can always abandon Coffeescript and reuse the generated javascript. Here is a good intro that you can go over in a couple of minutes, helped me a lot:  http://coffeescript-seattlejs.heroku.com
>
> >> And remember: Life is just too short to waste it on curly braces. :P
>
> >> On Sat, Jun 25, 2011 at 11:44 AM, Eric Muyser <eric.muy...@gmail.com> wrote:
> >> I almost don't use anything but CoffeeScript for my JS these days. Many times you really need to understand what your JS your CS is going to output. I don't find it too difficult to debug. Especially if you don't omit parenthesis too much (I never omit parenthesis for any argument nested on a second level). My biggest issue is when you have a back to back callbacks as arguments. The indentation and parenthesis can get tricky, or else you end up nesting the callbacks inside eachother (like in node-async waterfall, forEach, etc). It took a while, but I've got that down. To me, it's just another language construct to remember. In any case, languages have gotchas, and I'm willing to make some exceptions. The problem I have is it's such a fluid language, I can't depend that other coders are going to be familiar with that exact style. You're given more freedom to make your own code style (not simply indentation and where you put your curly brace). For now, I'm sticking with it. I don't believe the size of the project in which I use it is going to matter much unless I'm taking my team's preferences into account.
>
> >> On Sat, Jun 25, 2011 at 11:30 AM, Stephen Belanger <cyruzdr...@gmail.com> wrote:
> >> Not saying it's hard or that type coercion is a good idea, just saying that they can catch you if you aren't careful. Also, rather than this;
>
> >> users.get (req.params 'user_id'), (err, doc) ->
>
> >> You can do this;
>
> >> users.get req.params('user_id'), (err, doc) ->
>
> >> It just seems a little awkward because it mixes styles. I specifically said though that I do make a point of doing that. I'm not saying Coffeescript is terrible or anything, just that it can much more easily fail silently than plain Javascript.
>
> >> On Sat, Jun 25, 2011 at 11:20 AM, Bas Dirks <i...@basdirks.eu> wrote:
> >> Do you really need type coercion? == is considered bad practice,
> >> and no I certainly do no expect
>
> >> users.get req.params 'user_id', (err, doc) ->
> >>   // Do stuff.
>
> >> to compile to
>
> >> users.get(req.param('user_id'), function(err, doc){
> >>   // Do stuff.
> >> });
>
> >> If I wanted that I'd use
>
> >> users.get (req.params 'user_id'), (err, doc) ->
> >>   // Do stuff.
>
> >> Not hard.
>
> >> --
> >> Bas Dirks
> >> Sent with Sparrow
> >> On Saturday, June 25, 2011 at 7:14 PM, Stephen Belanger wrote:
>
> >>> I've used it for a few smaller projects. It's a fun language, but it has it's quirks. I find you really need to think about what you are doing or you'll likely break something. Here's a CouchDB request with cradle as an example;
>
> >>> users.get req.param 'user_id', (err, doc) ->
> >>>   # Do stuff.
>
> >>> At first glance you might thing it'd translate to this;
>
> >>> users.get(req.param('user_id'), function(err, doc){
> >>>   // Do stuff.
> >>> });
>
> >>> But it'll actually get translated to this;
>
> >>> users.get(req.param('user_id', function(err, doc){
> >>>   // Do Stuff.
> >>> }));
>
> >>> It's a simple mistake, but can be somewhat harder to spot I make a habit of always wrapping the argument list of function calls with a single argument, just in case I try to blindly copy/paste it somewhere else or code around it.
>
> >>> There's also some weird language related stuff like == becoming ===.
>
> >>> You might have expected something more like
>
> >>> On Sat, Jun 25, 2011 at 9:52 AM, Aria Stewart <aredri...@nbtsc.org> wrote:
>
> >>>> On Saturday, June 25, 2011 at 12:51 PM, Roman Land wrote:
>
> >>>> > Hi Guys,
>
> >>>> > Was looking at Coffeescript as a base language to develop upon, my concern is that it doesnt really play nicely with the rest of the NodeJS eco system, thus is a niche..
>
> >>>> > Has anyone here considered and used Coffeescript as part of a big project? is it a good direction?
> >>>> It works fine if you're into that sort of thing. It plays nice with other node modules, and extends require() to work for .coffee files, so you're good to go. Node can call coffeescript, coffeescript can call normal node stuff.
>
> >>>> ----
> >>>> Aria Stewart

[Evgeny Bogdanov]

> -1(e9) to CS. It's just the opposite of the "JS of my dreams".

I am not sure I understand how it is opposite, please be specific!

Things that Brendan mentions are exactly what iis in CS:
destructuring, Paren-free syntax, array slicing and splicing, iterators
http://brendaneich.com/2011/01/harmony-of-my-dreams/

Plus much more from CS are considered for ES.next  (CS classes, aliases "==" -> "is", etc.)
http://brendaneich.com/2011/05/my-jsconf-us-presentation/

"One of my favorites along those lines is a new little language called CoffeeScript, which takes the good parts -- not even all of the good parts, but a nice little language -- and comes up with groovy new syntax for it, which is minimal. It's almost like dandelions: little fluffs of programs that do everything that conventional JavaScript programs do. You can't do anything in that language that you can't do in JavaScript, so it's all cosmetic. I don't know if all or much of that will find its way into JavaScript, because I'm not sure there's enough of a payoff there. But just as an experiment, as a design exercise, I think it's a brilliant piece of work. I'm excited to see stuff like that happening. "
-- Douglas Crockford (author of "Javascript: The Good Parts")

[Jorge]

On 28/06/2011, at 12:01, Evgeny Bogdanov wrote:

> "One of my favorites along those lines is a new little language called CoffeeScript, which takes the good parts -- not even all of the good parts, but a nice little language -- and comes up with groovy new syntax for it, which is minimal. It's almost like dandelions: little fluffs of programs that do everything that conventional JavaScript programs do. You can't do anything in that language that you can't do in JavaScript, so it's all cosmetic. I don't know if all or much of that will find its way into JavaScript, because I'm not sure there's enough of a payoff there. But just as an experiment, as a design exercise, I think it's a brilliant piece of work. I'm excited to see stuff like that happening. "

I'd put the emphasis in "I'm not sure there's enough of a payoff there".
--
Jorge.

[Ted Young]

I'm fine continuing to use straight js, but as js becomes more and
more ubiquitous I think a number of languages that see it as a compile
target are going to sprout. CS is just the first one to do so that
caught everyone's sweet tooth. I would prefer everyone stick with
straight js to prevent fracturing the knowledge base, but I can see
why it's happening.

[Mark Hahn]

> I would prefer everyone stick with  straight js to prevent fracturing the knowledge base

That line of thinking would have all of us using C for the rest of time.

[Joshua Kehn]

CS is sugar - not a different language. 

Correct me if I'm wrong, but Python isn't translated to C code and then compiled. Is it? 

Regards,

-Josh

____________________________________
Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

On Jun 28, 2011, at 2:06 PM, Mark Hahn wrote:

> I would prefer everyone stick with  straight js to prevent fracturing the knowledge base

That line of thinking would have all of us using C for the rest of time.

[Stephen Belanger]

Every language is translated and compiled to something else except binary. I would say CS is like a different language that uses the same standard libraries. It's not so different from C/C++.

[Mark Hahn]

Sure, I'll correct you.  Python is interpreted.  There are many forks of python that handle it differently and at at least one does compile it to C.

[Joshua Kehn]

That wasn't the question.

Is Python compiled or translated to another language meant for human editing before execution?

CS is. And that can (IMO) lead to fracturing of the collective code base. Some write in CS, some write in native JavaScript. If you want to write compatible libraries, hook them into the JavaScript engine - not by translating back into JS.

Regards,

-Josh

____________________________________
Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

[Joshua Kehn]

Was Python originally designed to be translated into C code? 

Regards,

-Josh

____________________________________
Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

On Jun 28, 2011, at 2:19 PM, Mark Hahn wrote:

Sure, I'll correct you.  Python is interpreted.  There are many forks of python that handle it differently and at at least one does compile it to C.

[Mark Hahn]

> And that can (IMO) lead to fracturing of the collective code base.

I didn't mean to say it wasn't fracturing things. I just meant that
fracturing is necessary for evolution. With no evolution we'd all
still be using C.

I don't understand your distinction between compiling to a language
that can be edited by humans and those that can't. I don't see where
that has any link to our discussion. Many languages compile to other
human-readable languages and that is not a factor in whether they
caused disruption or not.

--
Mark Hahn
Website Manager
ma...@boutiquing.com
949-342-4246

[Mark Hahn]

No, it was not.

[Matt Patenaude]

I think you severely misstate the relationship between C and C++.

In my opinion, CoffeeScript is the same language as JavaScript with a different syntax: the semantics, methodologies, paradigms, and library are effectively the same, it's just how it's written that's different. It's like Objective-C named properties: you can say myObj.prop = blah or [myObj setProp:blah], depending on what kind of syntax you like, but they mean the same thing. A language is much more than its syntax, just like the argument could be made that Objective-C and Ruby are much closer cousins than Objective-C and C++, in spite of the fact that they're both C-based object-oriented languages.

Since CoffeeScript evolved with the specific goal of targeting JavaScript as a compilation destination, one would argue that it cannot paradigmatically break from JavaScript in any serious way without introducing quirks.

Also, there's this on the CoffeeScript home page: 'The golden rule of CoffeeScript is: "It's just JavaScript".'

-Matt

[Stephen Belanger]

Obviously comparing C/C++ is going to be different--compiled, class-based languages vs interpreted, prototypical languages. But the ways in which C++ is similar to C are somewhat relative to how Coffeescript is similar to Javascript. Much of C can be used in C++, just as much of Javascript can be used in Coffeescript. The main difference being that C++ doesn't compile to C first. But that is more a difference of the interpretation than the language itself.

[jashkenas]

Funny to jump into this thread in this fashion, but C++ *did* originally compile into C source code ... and that approach served as the reference compiler for C++ until about 1990.

http://en.wikipedia.org/wiki/Cfront

[Stephen Belanger]

Interesting. Didn't know that. I suppose I would've expected that though. Most radical variations of a language tend to start out just like that--some add-ons that compile into something less elegant looking.

On Tue, Jun 28, 2011 at 11:58 AM, jashkenas <jash...@gmail.com> wrote:

Funny to jump into this thread in this fashion, but C++ *did* originally compile into C source code ... and that approach served as the reference compiler for C++ until about 1990.

http://en.wikipedia.org/wiki/Cfront

--

[Marco Rogers]

@Jeremy:

That is interesting. If you don't mind, I'm gonna use this thread as an excuse to probe you about your philosophy on CS. I hope it doesn't come off as trolling. I'm genuinely interested in your thoughts.

It might be helpful to compare to C/C++, despite the obvious differences. One thing is that C++ is a superset of the C language even *syntactically*. That was a stated goal wasn't it? I don't know how well modern C++ has adhered to this. Can you put regular C code into a .cpp file and compile it as C++?

Is it safe to say you chose to go the CS direction because you feel that the syntax changes (no, parens/braces, function '->', etc) are worthwhile, and go part and parcel with "fixing javascript"? I think the major syntax change is one of the things that bothers me the most about CS, both subjectively and objectively.

Subjectively because I prefer braces, semis, commas and all these other things that help give my brain clues as to the code's intention when I'm reading it. This is a matter of opinion obviously. And it always comes with a caveat of "all within reason" where reason is defined by me :) I actually like the fact that JS is flexible with syntactic preference. It was a pain before the rules were well understood, but now it's nice because IMO programming style is a deeply personal issue.

Objectively, because I have qualms about whether you can preserve the clarity of some javascript paradigms while also trying to "help" underneath the covers.  Consider this contrived example.

https://gist.github.com/1052033

My CS skills are non existent. So maybe a valid response to this is "don't do that". But that also raises a question. From the CoffeeScript website: "Because you don't have direct access to the var keyword, it's impossible to shadow an outer variable on purpose, you may only refer to it." Do you think this level of dictation on how people should write code is warranted? We're all opinionated, but I don't think the semantics of var are a "bad" part of JS. It allows explicitly stating intentions and feeling free to reuse temporary variable names (e.g. key, i, etc).

And it's things like this that prompt people to criticize CS (I'm guilty of poking mean-spirited jabs, sorry). Because if you only learn CS then it's quite possible that you won't really learn javascript and you'll never have a good understanding on these subtle issues in the language you're deploying. Toolkits like jQuery are guilty of this to a certain degree, but they don't cross this line. You still can't escape var. jQuery has to stay within real language constraints, instead of using pre-processing tricks to "hide" things or taking things that were intentionally explicit and making them implicit. 

This is an attempt to make my peace with the popularity of CoffeeScript so I hope you'll help to dispel my knee-jerk ignorance and dismissal.

:Marco

[Stephen Belanger]

I also prefer the parens and braces. CS is fairly flexible with parens, so you can use them where you would normally expect them to be. It would be nice if braces were also optional, so the code wouldn't break, should you choose to use them.

Also, a minor note about your gist;

foo -> alert 'foo'

Would actually become;

foo(function(){ alert('foo'); });

--

[Marco Rogers]

Hmmm, so how do you create a named function statement? What's the equivalent of this?

function foo() {

  alert('foo');

[Stephen Belanger]

You don't. You do it like this;

foo = -> alert 'foo'

to generate this;

var foo;

foo = function(){

  alert('foo');

};

Which is technically slightly different, but for the purposes of coffeescript that is mostly irrelevant.

[Mark Hahn]

I am not aware of any advantages to named functions. It used to be
that named functions were needed for debugging, but nowadays debuggers
use context so coffeescript works fine with debugging.

Oh, you can't forward-reference functions unless they are named. But
everything in coffeescript disallows forward-referencing. It is a
design principle of the language.

--

[Marco Rogers]

Yeah that makes sense. I can accept that as a solution. It adds to the learning curve for a long time javascripter transitioning to CS, but that curve is pretty minimal in general as far as I've seen.

I'm more concerned about the philosophy behind the term "disallows". In terms of affordances for programmers, there's features that "help",  features that "insulate", and then there's features that "coddle". I have my opinions on where these things should fall in terms of language features, libraries, frameworks, etc. I'm looking for more info about the coffeescript mantra.

:Marco

On Tue, Jun 28, 2011 at 4:23 PM, Mark Hahn <ma...@boutiquing.com> wrote:

I am not aware of any advantages to named functions. It used to be
that named functions were needed for debugging, but nowadays debuggers
use context so coffeescript works fine with debugging.

Oh, you can't forward-reference functions unless they are named.  But
everything in coffeescript disallows forward-referencing.  It is a
design principle of the language.

--
Marco Rogers
marco....@gmail.com

Life is ten percent what happens to you and ninety percent how you respond to it.
- Lou Holtz

[Stephen Belanger]

Named functions get hoisted to the top of the context to be executed, which can catch you off-guard in coffeescript, if you are used to that.

For example;

test();

function test(){ console.log('this works.'); }

As opposed to;

test()

test = -> console.log('this doesn\'t');

--

[Mark Hahn]

> I have my opinions on where these things should fall in terms of language features, libraries, frameworks, etc.

Me too. I have yet to find tools that match my opinions exactly.
Well, one time I took a sabbatical and forked Python to use prototypes
instead of classes (Prothon) and I made it pretty much exactly match
what i liked. Of course no one else used it.

.> I'm looking for more info about the coffeescript mantra.

Unlike Python, no one writes about "the coffeescript way". I think it
is too new to be so philosophical.

Coffeescript needs a lot of things written about. I had to learn
coffeescript by reading source code and all the issues (boy was that
painful). I'm proud that I posted the issue that caused this google
group to be formed. It was extremely painful reading hundreds of
issues.

[Marco Rogers]

@Stephen Yeah I assume that's what Mark meant by forward references. I'm not arguing that it isn't bad practice. But forward referencing (bad) is different from explicit variable declaration (good). Unfortunately in javascript the two are bound up in the same syntax stickiness.

On Tue, Jun 28, 2011 at 5:05 PM, Stephen Belanger <cyruz...@gmail.com> wrote:

Named functions get hoisted to the top of the context to be executed, which can catch you off-guard in coffeescript, if you are used to that.

@Mark perhaps the learning curve is steeper than I thought?

On Tue, Jun 28, 2011 at 5:08 PM, Mark Hahn <ma...@boutiquing.com> wrote:

> I have my opinions on where these things should fall in terms of language features, libraries, frameworks, etc.

Me too.  I have yet to find tools that match my opinions exactly.
Well, one time I took a sabbatical and forked Python to use prototypes
instead of classes (Prothon) and I made it pretty much exactly match
what i liked.  Of course no one else used it.

.> I'm looking for more info about the coffeescript mantra.

Unlike Python, no one writes about "the coffeescript way".  I think it
is too new to be so philosophical.

Coffeescript needs a lot of things written about.  I had to learn
coffeescript by reading source code and all the issues (boy was that
painful).  I'm proud that I posted the issue that caused this google
group to be formed.  It was extremely painful reading hundreds of
issues.

[Mark Hahn]

> perhaps the learning curve is steeper than I thought?

You may be brighter than me. And I really think that having a
discussion forum like this would have made it a lot easier. I feel
pressured to only post important stuff in the issues section of
github. Here I ask stupid questions all the time and get great
answers, often from the CS-god himself. :-)

My biggest problem was indentation rules. I kept having my own ideas
of how indentation should work and I'd get surprised. I found myself
pasting code into the online converter all the time. Once I caught on
to the "correct" way of doing the different line-wrapping cases, etc.
it wnt smoothly. Of course back then the rules were changing out from
under me. CS in the beginning even had a:3 instead of a=3. It would
still be a:3 if he hadn't discovered that using the colon ruled out a
lot of cool haml-like object construction.

However hard it was it would have been worth it at many times harder.
I am so hooked now that I would have a really hard time going back. I
just started working at a new place of employment and I'm starting a
project from scratch. The had always used PHP and Bake (which I think
is kind of a PHP rails).

I railed on about how great JS/Node/CouchDB was and to my surprise
they wanted me to go for it in the new project. However, they are
still looking sideways at my use of CS. It's a good thing I have the
old argument about how I could just delete the CS files, run the JS
through a prettifier, and switch back to JS. I'm pretty confident
that once anyone actually reads my code seriously and writes some they
will get hooked also.

[Jorge]

On 28/06/2011, at 12:01, Evgeny Bogdanov wrote:

> > -1(e9) to CS. It's just the opposite of the "JS of my dreams".
> I am not sure I understand how it is opposite, please be specific!

Syntax. This sudden urge to make JS look like CS is pointless, because CS's syntax is not better than the current syntax. It's even foolish, as if *that* was what we were dreaming for ES.next. I don't want it to look cool on the surface, I want it to be better deep inside. I like function hoisting, call()s with (obligatory) parens, blocks enclosed in curly braces, useful punctuation marks such as semicolons, and I don't like meaningful indentation à la python. Yes, I just like its C-like syntax. What's wrong with that ? C is a honorable language. It's the language of the linux kernel, it's the language of git, it's the language of most embedded processors, it's the language of openCL, it's the language that every programmer that wants to deserve to be called a programmer will have to learn, sooner or later. CS is... CS who ? The time/effort would be better spent in adding interesting features that are missing, such as e.g., in the multi-core era, language level support for parallelism, to name one. Seriously, these are the things that would make ES.next a better language. But instead, looks like we're fixing what ain't broken.
--
Jorge.

[Mark Hahn]

> I don't want it to look cool on the surface,

I do. I live with that damn surface all day long every day.

On Wed, Jun 29, 2011 at 2:15 AM, Jorge <jo...@jorgechamorro.com> wrote:
> I don't want it to look cool on the surface,

--

[Bas Dirks]

You don't have to use it, and still you seem annoyed by CoffeeScript. That's interesting because it suggests anxiety. Why are you mentioning the linux kernel when we're discussing syntax? Makes no sense as C's power is in anything BUT its syntax.

"it's the language that every programmer that wants to deserve to be called a programmer will have to learn, sooner or later. CS is... CS who ?"

Now that's quite a clownesque thing to say and pretty much proves that you're just on you're own little crusade regarding this syntax business. I agree with you on the need for more meaningful improvements.

-- 
Bas Dirks
Sent with Sparrow

[Jorge]

On 29/06/2011, at 12:57, Bas Dirks wrote:

You don't have to use it,

AFAICS, l'll have to use it if its syntax goes into ES.next. Or not ?

and still you seem annoyed by CoffeeScript.

I'm not annoyed: it's sweet, in fact. But JS's syntax is ~ fine as it is now.

That's interesting because it suggests anxiety. Why are you mentioning the linux kernel when we're discussing syntax? Makes no sense as C's power is in anything BUT its syntax.

There's an infinity of applications and systems in use that were written in C, and an infinity of applications and systems that are being written in C nowadays, right now (e.g. node.js). Do I need to prove that C's syntax is still important because C is still important nowadays and deserves to be learnt? What's wrong when I say that it's a plus to have syntax in common with such an important language? OTOH I see no benefit (beyond its cuteness, which is a subjective matter) in a migration towards CS syntax, and away from a C-like syntax.

"it's the language that every programmer that wants to deserve to be called a programmer will have to learn, sooner or later. CS is... CS who ?"

Now that's quite a clownesque thing to say and pretty much proves that you're just on you're own little crusade regarding this syntax business.

Clownesque why, exactly? Because Ruby/Rails/CS is (in your mind) what's cool and fashion (unlike C) ? Most web programmers can't tell a pointer from a handle, nor care even the slightest. Is that a good thing, in your opinion ?

I agree with you on the need for more meaningful improvements.

That's the point. More meaningful. Not on the surface, but deep inside.

-- 

Jorge.

[Jorge]

On 29/06/2011, at 12:02, Mark Hahn wrote:

>> I don't want it to look cool on the surface,
>

> I do. I live with that damn surface all day long every day.

I do too, and I enjoy it.
--
Jorge.

[Bas Dirks]

C is certainly one of the best languages so far. Ruby/Rails blows monkeyballs as far as I'm concerned, so we're of one mind on this one it seems. LISP, Haskell & Python get my "cool points".

I understand you concerns regarding ES.next

-- 
Bas Dirks
Sent with Sparrow

--

[Joshua Kehn]

On Jun 29, 2011, at 8:00 AM, Bas Dirks wrote:

Ruby/Rails blows monkeyballs as far as I'm concerned,

I'm going to "borrow" this for use later.

Regards,

-Josh

____________________________________
Joshua Kehn | Josh...@gmail.com

http://joshuakehn.com

[Karl Tiedt]

"Most web programmers can't tell a pointer from a handle, nor care
even the slightest. Is that a good thing, in your opinion ?"

A web programmer should care as much about knowing the difference
between a handle and a pointer as a hair stylist cares about
understanding the difference between a swamp cooler and an air
conditioner.

If they happen to it's great... but it does not and will not affect
their chosen job.

-Karl Tiedt

[Ryan Gahl]

pointer: http://www.petplanet.co.uk/petplanet/images/breeds/pointer.jpg

handles: http://img.directindustry.com/images_di/press/press-g/economy-plus-handle-series-ec-P333406.jpg

[jashkenas]

Sure thing. Probe away.

People often ask why CoffeeScript isn't a strict superset of JS ... And the answer is that being a strict superset of JS isn't the point  of CoffeeScript: There are already plenty of excellent projects and languages that do just that: Objective-J, Streamline.js, StratifiedJS, and so on:

http://altjs.org/

The point of CoffeeScript is to try and find a minimal syntax that expresses just the "good parts" of JavaScript. Nothing more (no complex code transformations or helper libraries included as a foundation), and nothing less (no manual loops, statements, with, named functions or semicolon debates). 

If you prefer your punctuation: braces, semis, commas -- then by all means, use them. I'm not in any way suggesting you stop programming in JavaScript if you prefer it, whatever floats your boat. You'll still be able to use CoffeeScript libraries without issue, and vice-versa. Speaking personally, I probably program in JavaScript more than 90% of the time, overall.

Getting rid of "var" is certainly one of the more controversial aspects of making CoffeeScript minimal, but it's not the only controversial one. 

The con is: You can't shadow variables on purpose. 

The pros are: You never have to worry about leaking variables to global scope. You never have to know where to write "var", and where not to. All assignment becomes an expression. "var x = 1" in JavaScript is a statement, and can't be returned or used as part of a larger expression. You can't shadow variables, so an identifier "x" within a certain lexical scope only ever has one identity. Scrolling through a page of nested code -- you *know* that every time you see "x", you're talking about the same variable. Shadowing variables on purpose is a bug, in my opinion. You lose the ability to reference the outer variable for the remainder of the function ... and if you know you're shadowing it, why not just choose a more appropriate variable name, instead of confusing the reader?

Hope that answers your questions. A lot of these specific debates around certain features are first hashed out in the GitHub issues, if you're curious about how they developed.

Cheers,

Jeremy

[john.tiger]

I think it would be more beneficial to put more attention to best
practices and recipes with Node instead of all this brain attention to
syntax flavor of the month.

Node allows major programming paradigm shifts away from higher back and
forth server calls in MVC by using web sockets and/or listening on the
backend of db changes with most interface work done on the front end w/
jquery / backbone / whatever client stuff. That's where the real
breakthroughs are (ie the Rails successor), not another level of syntax
abstraction.

[Dean Landolt]

On Wed, Jun 29, 2011 at 1:38 PM, john.tiger <john.tig...@gmail.com> wrote:

I think it would be more beneficial to put more attention to best practices and recipes with Node instead of all this brain attention to syntax flavor of the month.

Node allows major programming paradigm shifts away from higher back and forth server calls in MVC by using web sockets and/or listening on the backend of db changes with most interface work done on the front end w/ jquery / backbone / whatever client stuff.   That's where the real breakthroughs are (ie the Rails successor), not another level of syntax abstraction.

I too would like to see developer attention focused on what I consider to be real problems it turns out not everyone agrees with my assessment of which problems are important. Oh, and even if they did, this is open source -- can we really dictate which itches are appropriate for developers to scratch? And what if they just want to play? For example, I'd love to see what Jed Schmidt could accomplish if he decided to write code for a living, but we can't very well force him to do that, now can we? 

[jashkenas]

On Wed, Jun 29, 2011 at 1:51 PM, Dean Landolt <de...@deanlandolt.com> wrote: 

For example, I'd love to see what Jed Schmidt could accomplish if he decided to write code for a living, but we can't very well force him to do that, now can we?

I'd argue that *not* writing code for a living is precisely what makes Jed's code so swell.

[Dean Landolt]

He argues that too. But still, there's only so much time in the day :)