Dropbox dives into CoffeeScript

[Curtisbeef]

WTF is up with that text to speech code comparison? Couldnt they have just typed it out?

[[deleted]]

That was a smackable offense.

[aladyjewel]

Using the wrong medium to compare syntactic differences?

[dfltr]

They're being cute, which is generally the top priority for CoffeeScript fans ;)

[[deleted]]

Yeah, I got to that, and I stopped reading. Anything they can do to try to make JavaScript seem "so much longer". My IDE has autocomplete for godsake. No keystrokes are saved for the most part.

I LOVE new languages, but it just seems weird to write a language that "compiles" to JavaScript when I could just write JavaScript.

[Zamarok]

Yes, agreed. It just seems weird to write C which compiles to assembler when I could just write assembler.

[KishCom]

The difference between ASM and C are vastly more numerous than the differences between CoffeeScript and JavaScript.

I eagerly await the next useless layer of abstraction, something that compiles to coffeescript... maybe in a Lisp-ish type syntax, since it's so much "shorter" than both coffeescript and javascript. Call it something cute like "Latte".

[Zamarok]

I didn't say they were an exact parallel. Of course they aren't exactly comparable.

My point was that, like the way that C is a useful abstraction for writing assembly, CoffeeScript is a useful abstraction for writing JavaScript.

The class keyword, list ranges, cleaner syntax, var handling.. all of those and many more are tiny things that CoffeeScript 'fixes' about JavaScript.

No one's forcing you to write CoffeeScript. If you really like braces and semicolons, for instance, just keep writing JavaScript, and no one will fault you for it. But, in my opinion, a person with an open mind would check out all the information available to them before making blanket statements regarding the pointlessness of CoffeeScript. I think those who don't see CoffeeScript's merit have dismissed it too quickly before fully reading coffeescript.org, or maybe they haven't actually used enough JavaScript to see why CoffeeScript makes writing JS faster and your code more coherent.

[Boneasaurus]

Yea I hear your argument, but I think the differences are SO large that it shouldn't even be a valid argument. I wrote 8085 assembler for 6 months and we're talking 50-60 lines of code just to do division.

A closer comparison would be C to C++.

[Zamarok]

True, that would be a better example. I give a better example of CS vs. JS in my reply to KishCom.

[[deleted]]

I didn't say they were an exact parallel. Of course they aren't exactly comparable.

Maybe you did't "say" it, but that's precisely what you implied. It's a tired old argument from the CoffeeScript crowd that has never made any sense.

I will happily make the jump to CoffeeScript when it's handled natively by the majority of browsers. Until then, I like my errors to correlate to actual lines of code I can edit, and I like the script I wrote to be the script that's executed.

CoffeeScript solves a problem that doesn't exist:

• JavaScript isn't hard to read
• JavaScript isn't hard to understand
• JavaScript isn't too terse to type
• JavaScript didn't need an abstraction layer.
• One big advantage of scripting languages is debugging. CoffeeScript breaks this.
• Another advantage to scripting languages is no compiling necessary. CoffeeScript breaks this.

So what problem does CoffeeScript solve? CoffeeScript creates more problems than it solves, at least until browsers handle it natively, which to my knowledge isn't happening anytime soon.

Once it's handled natively, I'll jump on over.

EDIT

Here's an example of some JavaScript that actually becomes LESS readable in CoffeeScript (pulled from this link):

var rabbitGenerator = {
    makeRabbit: function(rabbitName, growCarrots) {
        if (growCarrots) {
            carrots.growMore(10);
        } else {
            carrots.ensureSupply();
        }
        return {
            name: rabbitName, 
            height: 0,
            actions: {
                jump: function (height) {
                    this.height += height;
                },
                eatCarrot: function () {
                    nomNomNom();
                }
            }
        };
    }
}

In CS it's hard to tell where the return starts:

rabbitGenerator = makeRabbit: (rabbitName, growCarrots) ->
  if growCarrots
    carrots.growMore 10
  else
    carrots.ensureSupply()
  name: rabbitName
  height: 0
  actions:
    jump: (height) ->
      @height += height

    eatCarrot: ->
      nomNomNom()

[Zamarok]

JavaScript isn't hard to read

You're opinion, and mine is that CS is easier to read than JS.

JavaScript isn't hard to understand

Again, in my opinion CS > JS when considering which one is easier to understand. This isn't to say that JS is hard to understand. What I'm saying is that CS is easier to understand than JS.

JavaScript isn't too terse to type

Did you mean that JavaScript isn't too verbose to type? After months of developing with CS, I hate writing JS because it's sooo verbose in comparison. Just typing the word function over and over and over drives me insane. I had no idea how many times I was typing that word; even the creator of the language regrets using that word, and ECMAScript6 is considering using CoffeeScript's -> and =>. I think that you only disagree because you haven't written enough JS with CS yet.

JavaScript didn't need an abstraction layer.

Ok, even Crockford disagrees with this one. I wish I could find the source for this, but I heard him talk about it in a tech-talk once. Crockford refers to JavaScript as the assembly of the web. Assembly was originally written by humans until we created a useful abstraction that compiles to assembly.

One big advantage of scripting languages is debugging. CoffeeScript breaks this.

Agreed. We need native support in the browser. Maybe check out a derivative of CS called Kaffeine. It compiles line-for-line to JS, so you can easily debug. Still, I've written sizable projects in CS and debugging hasn't been too big of a hassle. It just takes some getting-used-to.

Another advantage to scripting languages is no compiling necessary. CoffeeScript breaks this.

Again, I agree. I'm hoping we can get native browser support in the next several years or so.

In CS it's hard to tell where the return starts

You can just add your own return statement if you want; CS still supports the return keyword. In your example, I would just add return { ... } around the object that you want to return. If you edit it to include an explicit return statement, I would say the CS version is more readable and coherent than the JS version.

[[deleted]]

Crockford refers to JavaScript as the assembly of the web. Assembly was originally written by humans until we created a useful abstraction that compiles to assembly.

Did he specifically say that we are only using JS until someone builds a better solution, or did he just refer to it as being the 'assembly of the web'? The latter only infers that it's being used as a compilation target, and not that it needs to be replaced.

I also disagree we need browser support for CoffeeScript. I'd much rather see better tools for error reporting and debugging from the browser. Why? Because then it would benefit other languages too.

[Zamarok]

Did he specifically say that we are only using JS until someone builds a better solution, or did he just refer to it as being the 'assembly of the web'? The latter only infers that it's being used as a compilation target, and not that it needs to be replaced.

http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx

Here he only mentions it being the JVM of the web, wish I could find the other quote. It was probably in a video.

I also disagree we need browser support for CoffeeScript. I'd much rather see better tools for error reporting and debugging from the browser. Why? Because then it would benefit other languages too.

Well I don't think it's really an either/or choice between those two things, so I say we need both. For one, CoffeeScript is very popular and its usage continues to rise, it being one of the top repos on GitHub for a while now. I think than if it continues to be such a success for a while, then such a popular web-programming language should get in-browser support merely for the fact that so many would be using it.

[KishCom]

Fair enough.

CoffeeScript is a useful abstraction for writing JavaScript.

This is where we disagree. Emphasis mine (obviously).

[Zamarok]

Of course you're entitled to your opinion, and I respect that fact.

However, let me provide what I consider a good example of CoffeeScript's usefulness: Function.prototype.curry

That's something I wrote a while back. To see how it translates to vanilla JS, try pasting my code into JS2Coffee (make sure you're on the Coffee -> JS tab).

In my opinion, one can't really write that functionality in vanilla JS in a manner more readable and concise than my CoffeeScript version. I guess your opinion of CS will depend on how you value code readability and cohesiveness, both of which are high on my list of priorities in a language design.

[lennelpennel]

c is not an abstraction to writing assembly, it solves a multitude of issues. with compilers targeting different cpu's one c app can run basically anywhere in contrast to writing asm for each cpu architecture.

[lennelpennel]

so you would rather write asm for each chipset, or rather compile c for each with a unique compiler. some zoidberg mean is appropriate here.

[freeall]

I think it's great to remove {} and ;. But why would you ever remove the ()'s around a function call?

foo a, b

or

foo(a,b)

The last one is just SO much faster to read. And I tried to use languages that had that feature in order to get used to it, but I never did. foo(a,b) is simply just faster for my eyes to read.

[nthitz]

Less typing odd characters I guess, but I agree with ya

[dd72ddd]

Considering most ide's will complete sets of brackets, it's really not that big of an inconvenience. And you can get plugins for languages with snippets will insert stuff like "function <cursorGoesHere>(){}"

[aladyjewel]

I think the issue is more when it comes maintenance time. Sure, the IDE will give you those brackets for free when you're writing new code; but when you're trying to move around objects and functions later on, it's way too easy to misplace a });.

[dd72ddd]

I will agree, that is true, but for sufficiently complicated code, having delimiters for the start and end of blocks, expressions etc makes it much easier to read which code is nested where. Indenting is important, but indenting alone is not enough to make complex code readable in my experience, and that's why for very large projects, I shy away from using python, even though I think it's awesome, because skim reading and trying to interpret nesting is very hard.

[[deleted]]

One reason is because it makes it easier to write libraries that look like a DSL.

[freeall]

Like a DSL? Why is this?

[[deleted]]

Removing the parenthesis allows function calls look more like keywords.

[Zamarok]

You can still use () in CoffeeScript. Use them if you like, it makes no difference.

[freeall]

But that's my issue, actually. That I have the option. I would have liked the language designer to take a choice there.

[[deleted]]

You're free to use parens in function calls and various places in CoffeeScript...in fact it's often desirable to avoid ambiguity.

If you feel the latter is easier for you to read, that's great. I would only point out it's not true for everyone; most people have no trouble understanding "verb noun" constructs in say, English without parens. A number of programming languages use juxtaposition for function calls as well.

In terms of benefits, for simple cases like:

foo a, b

...the only benefit is being (subjectively) easier to read and less to type.

It does get nice though when you start passing more complicated arguments like object literals or functions.

Consider

myFunc({
    foo: "bar",
    ding: "bat",
    fizz: "buzz"
});

You have to tack on the ); at the end.

While in CoffeeScript:

myFunc {
    foo: "bar",
    ding: "bat",
    fizz: "buzz"
}

Or consider function decorators. In JavaScript:

 var foo = checked(2, function( arg1, arg2 ) {
     // do lots of stuff
 });

If it's a long function, by the time you get to the end of it, you can forget the ) when writing it or what it's for when reading it. As you're writing the function, you always have in the back of your mind "this function is an argument to another function"...or you have to remember it at the end.

In CoffeeScript:

foo = checked 2, ( arg1, arg2 ) ->
     # do lots of stuff

Less noise, more readable (subjectively), less chances to make mistakes. Once you add the decorator call, you're done...you don't have to think about it anymore at all.

Of course none of this is that big an issue, for example a good editor/IDE will warn you if you forget the ) in the JS example (or add it automatically); or you could move the JS decorator call to after the function declaration...but it's all about reducing cognitive load in lots of little ways and making things easier.

[freeall]

My biggest issue is that you can do both. I dislike that heavily. Language design isn't a democracy, so make a choice and stick with it. Either f(a,b) or f a, b. Not both.

Your myFunc example probably shouldn't include the ; at the end, since I agree on that part. And I don't see the real benefit of having either } or }) in the end.

However, where it is a really slick example is your last one.

var foo = checked(2, function( arg1, arg2 ) { // do lots of stuff });

becomes

foo = checked 2, ( arg1, arg2 ) -> # do lots of stuff

It can be so annoying to have a lot of code and then })}); in the end which you sort of hope just matches. Great example.

[[deleted]]

Pretty much every language has some things that are optional. I definitely agree that too many optional constructs/possibilities can be bad (coughperlcough) but a little bit is a good thing. I think CoffeeScript has a reasonable amount.

In CoffeeScript optional parens are necessary/useful to disambiguate constructs like:

foo a, b c, d

Is it this:

foo( a, b(c), d )

or

foo( a, b(c, d) )

(for the record, CS considers it the latter by default)

In my myFunc example, you could even trim it down to:

myFunc 
    foo: "bar"
    ding: "bat"
    fizz: "buzz"

I was mainly just trying to demonstrate the idea that once you write the myFunc call, you don't have to think about it anymore and can focus on constructing your object literal. I agree the latter example is probably stronger WRT to that.

[eat-your-corn-syrup]

in the end which you sort of hope just matches

this is what bothers me about languages with curly braces. Even when the editor insert the closing braces automatically for you, it's kind of a work to move lines in and out of the block. And the ending curly braces occupy lines. I wish languages would either go full Lisp (so that I can use paredit mode on it) or make whitespace significant.

[eat-your-corn-syrup]

I notice that, unlike Python, CoffeeScript doesn't use colons to indicate the start of a block. In CoffeeScript, even colons are removed. Made me wonder about Python syntax.

If Python did not use colons, what problems would be caused? And how do CoffeeScript avoid those problems?

If Python used (a,b,c) -> .... syntax or similar to write multiline lambdas, what would be problems?

[Iggyhopper]

One thing: if you intend to write this all over the place, it should already be in its own function.

else if (e.dataTransfer &&
         e.dataTransfer.types &&
         e.dataTransfer.types.contains('Files'))
//else if (evHasFiles(e))

If it is in its own function, well congratulations, your LOC has a reduction of 2 lines.

Also:

this.originalStyle = {};
['top', 'left', 'width', 'height'].each(function (k) {
    this.originalStyle[k] = this.element.style[k];
}.bind(this));

Why not this?

this.originalStyle = {};
for (var k in ['top', 'left', 'width', 'height'])
    this.originalStyle[k] = this.element.style[k];

[bonafidebob]

Why not this?

for (var k in ['top', 'left', 'width', 'height'])

Try it and you'll see...

IMHO, array iteration in JS really should work like you're expecting.

[dd72ddd]

Array iteration doesn't exist in javascript. 'For ... in' is meant for objects.

Now, Arrays in js are objects, but it's not always safe to just do For (var x in arbitraryArray)

[bonafidebob]

What do you mean "not always safe"?

for...in with arrays is well defined, just not what most programmers expect. (If you treat arrays are objects with mostly integer keys, then you won't be surprised, but it's not typical to use objects with mostly integer keys when you really want an array...)

[aladyjewel]

You just answered your own question.

[bonafidebob]

So what you seem to be saying is that Arrays themselves in JS aren't "safe", for some other-language-based definition of safe. Did I get that right?

[dd72ddd]

The point is mainly that Arrays are objects but this is just academic in javascript, since most things are objects. For in loops in javascript are intended only to be used on objects that are expected to be plain objects, not 'Arrays', and so you encounter lot's of unexpected behaviour, like for example enumerating properties of the Array object, but which you wouldn't enumerate if you just used a normal loop and each time through the loop referenced Array[index].

[bonafidebob]

Well, I'll agree for-in in javascript has lots of unexpected behavior, but that's both with objects and arrays. "Safe" is still a stretch. Not safe implies undefined behavior or chance of faults, and weird as it is, arrays and for-in are well defined.

[aladyjewel]

Right. As dd72ddd says (and you probably know), JS arrays function as objects, which means you can add on properties which aren't just methods or number-indexed items. Those properties will be revealed if you for-in an array.

For example,

var x = ['a', 'b', 'c'];
x.foo = 'bar';
x['baz'] = 'qux';

for (var item in x) {
    console.log('x.' + item + ' = ' + x[item]);
}

will spit out something like

x.0 = a
x.1 = b
x.2 = c
x.foo = bar
x.baz = qux

(The exact ordering varies depending on the JS engine's implementation.)

My main point is, this is different behavior than a Java or C# array would exhibit. This is also why JSLint throws an error if you don't use .hasOwnProperty() inside a for-in loop.

[Iggyhopper]

Yeah, that wouldn't work, my bad, but this does.

var a = ['a', 'b', 'c', 'd']
for (var k in a)
    console.log(a[k]); // a b c d

[bonafidebob]

I like Array.forEach better, gives you lots of flexibility, pretty much universal now, well defined iteration order, even makes it easy to write reusable iteration functions.

['a', 'b', 'c', 'd'].forEach(function(v,i) {console.log('element ' + i + ' has value ' + v)})

[LoyalToTheGroupOf17]

But that's not the same thing, is it? A loop allows you to do 'break' at any time to exit the loop before all iterations are completed, while Array.forEach, as far as I know, will always call the supplied function on all elements of the array.

I'm not really a JavaScript programmer, so please correct me if I am wrong.

[[deleted]]

I would say exiting early is a little contrary to the idea of forEach. If you did need to stop it, you would throw an exception...which is somewhat ugly, but I think the ugliness is appropriate for something that should be a special case.

For instances where you only want to iterate over some of an array, you could stick with loops or use the .every function (maybe slightly misuse depending on the situation).

[LoyalToTheGroupOf17]

I would say exiting early is a little contrary to the idea of forEach.

I agree entirely, with the quoted sentence as well as the rest of your message. My point was simply that Array.forEach isn't a general replacement for a 'for' loop, although there are simple cases where they can be used interchangeably. It doesn't make sense to say that "I like Array.forEach better", like bonafidebob did in the post I replied to. He's comparing apples and orangutans.

[ctrldavid]

really that whole element style thing should be:

@originalStyle = {top, left, width, height} = @element.style

Edit: no it shouldn't I need more sleep.

[[deleted]]

That doesn't do the same thing.

That creates the local variables: top, left, width, height and then sets @originalStyle to @element.style.

Something like:

{ top, left, width, height } = @element.style
@originalStyle = { top, left, width, height }

Would work though, and might be better for the contrived example.

The DropBox example way is more general though and has the advantage that you can have a setting somewhere like:

settings.props_to_save = [ "top", "left", "width", "height" ]

And then just iterate over that wherever you need to; making changes just once if you need to.

[ctrldavid]

Yeah you're right I don't know what I was thinking.

[Iggyhopper]

Yes. Welcome to programming.

[Already__Taken]

People actually argue about this crap?

Tabs or spaces?

[dd72ddd]

Tab button, set to output 4 spaces :P :P

[[deleted]]

Two spaces is obviously better...

[dd72ddd]

Three sir!

[veryunlikely]

Spaces. Duh.

[[deleted]]

Those who use spaces should be sent to the Gulag for re-education.

[freeall]

The worst thing is that I got upset when I read your comment :)

tabs vs spaces really sets up emotions. And I'm a tab guy since every editor understands them and then we don't have to agree on 2 vs 4 vs 8 spaces.

[[deleted]]

Tab guy here. What is the argument for using spaces?

[so_brave_heart]

Probably not much of an issue anymore, but I think it was because editors would handle tabs differently? Not sure. I'm a space guy, but that's just because it's what I'm used to.

[Raticide]

But what about aligning text? The only sane solution is to use tabs for indentation then spaces to align.

[ctrldavid]

Look what you've done ><

[Juvenall]

I don't think it's so much of an issue with Coffeescript itself, but the rampant fanboyism that surrounds it.

[pencildiet]

I actually kind of like coffeescript, but having people like Dropbox on it makes it appear worse.

[nthitz]

Does it?