Why CoffeeScript Isn't the Answer

Post by varkson » Mon, Mar 31, 2014, 12:15 AM UTC

kaonashi wrote: post #57

Roboprog wrote: post #46

Disclosure: I have never used CoffeeScript. However, based on the article, the death-knell against CoffeeScript for me was the variable scoping rules. With no variable declaration keyword (a la var, my, local, private), adding a variable assignment anywhere could radically change the variable scoping. I'm done, this isn't suitable for prime-time, time to go somewhere else. I spent too many years in the 80s working wi…

I've used coffeescript extensively for years, and I have never had that be an issue. Not sure if it's because I rarely write a file longer than ~200 lines, or I'm careful about variable names and global scope. More generally I've found that coffeescript mixes much better with a functional style than with an imperitive one.

Post by TheZenPsycho » Mon, Mar 31, 2014, 12:35 AM UTC

ilaksh wrote: post #116

rubyn00bie wrote: post #113

Earlier quoted context omitted.

I guess I just don't think it's a serious issue. I've found that often when I have an "issue" it's more so my design lacking not the tool (javascript) itself.

What would the code look like for my example using futures in JavaScript?

    fs.readFile("person.json")
    .then(function(e, personJson) {
        var person = JSON.parse(personJson);
        return myDB.query("lastname", person.name);
    })
    .then(function(matched) {
        return msgQueue.push(JSON.stringify(matchesLastname));
    })
    .then(function(id) {
        log.info("Message sent to queue: " + id);
    });

Post by olalonde » Mon, Mar 31, 2014, 12:54 AM UTC

shittyanalogy wrote: post #110

It's a tool, that is all. Ambiguous code is a poorly thought out contrived example with a simple solution. To me, this: eat food for food in foods when food isnt 'chocolate' Is kind of beautiful and much more readable than: for (var i = 0, var len = foods.length; i How is this even an argument?: "One wouldn’t realize it was conditional until reading the end." How do you expect to understand any code without reading i…

  foods.filter(function (e) { return e !== 'chocolate'; }).forEach(eat);

Post by colbyh » Mon, Mar 31, 2014, 1:28 AM UTC

olalonde wrote: post #125

shittyanalogy wrote: post #110

It's a tool, that is all. Ambiguous code is a poorly thought out contrived example with a simple solution. To me, this: eat food for food in foods when food isnt 'chocolate' Is kind of beautiful and much more readable than: for (var i = 0, var len = foods.length; i How is this even an argument?: "One wouldn’t realize it was conditional until reading the end." How do you expect to understand any code without reading i…

Your Javascript example is a bit contrived too. How about: foods.filter(function (e) { return e !== 'chocolate'; }).forEach(eat); Regardless, I disagree that the Coffeescript example is more readable. My brain is much faster at parsing symbols (`(`, `{`, etc.) than english words. With your JS example, without having to read the words, I know there's a loop, a conditional and a function invocation. I also know that I…

Post by shittyanalogy » Mon, Mar 31, 2014, 1:45 AM UTC

colbyh wrote: post #127

olalonde wrote: post #125

Earlier quoted context omitted.

Your Javascript example is a bit contrived too. How about: foods.filter(function (e) { return e !== 'chocolate'; }).forEach(eat); Regardless, I disagree that the Coffeescript example is more readable. My brain is much faster at parsing symbols (`(`, `{`, etc.) than english words. With your JS example, without having to read the words, I know there's a loop, a conditional and a function invocation. I also know that I…

I'm obliged to agree. Even the "contrived" example is easier for me to parse given that I have years of seeing "{}[]()" as delimiters. Not to mention that filter/each functions will get even easier to parse once es6 standards reach the browser (stabby procs, woo).