Why CoffeeScript Isn't the Answer • Hacker News Board

Re: Why CoffeeScript Isn't the Answer

#111

Post by Dylan16807 » Sun, Mar 30, 2014, 9:47 PM UTC

berdario wrote: post #107

Dylan16807 wrote: post #83

Earlier quoted context omitted.

The problem is the combination of the two. You can have operator overloading if conversion is explicit. You can have a converting operator if the action is explicit. But you can't have loose overloading and automatic conversion at the same time without silly defects. Edit: And you didn't just disagree but call it a 'blatant absurdity' to blame the half of the problem that you happen to like better? Jeez.

I agree, "blatant absurdity" is quite a strong wording. I should've wrote "quite dubious" or the like. In my defense, I didn't even think of having a language with type coercion and 0 operator overloading (even on builtin types). I never saw such a language, and I'm skeptical that it could work. But it's an interesting take on the problem. I cannot say why I think that the no-coercion+overloading is the better soluti…

What I think of here is Lua, where builtin types have no overloading and there is a single type of coercion, between numbers and strings. This coercion is only triggered by arithmetic operators and concatenation. Unambiguous and pretty harmless.

(Technically objects can overload binary operators (with no coercion) but it's not very common)

Re: Why CoffeeScript Isn't the Answer

#112

Post by ilaksh » Sun, Mar 30, 2014, 9:51 PM UTC

rubyn00bie wrote: post #102

ilaksh wrote: post #97

Earlier quoted context omitted.

http://en.wikipedia.org/wiki/Status_quo_bias CoffeeScript obviously solves problems. Its not compelling to you because of status quo bias, and because you don't want to invest the effort to learn it. The issue with equality is a real issue. CoffeeScript solves that issue. Braces and parenthesis _do_ become awkward in JavaScript with callbacks. CoffeeScript solves that problem. You have been able to debug CoffeeScript…

Its cute you link to status quo bias, then immediately state, like a fact from god that "braces and parenthesis _do_ become awkward (...) Coffeescript solves that problem." It's your opinion that coffeescript solves the callback and parentheses issue. I'd also call your argument a bit of red herring. ... FWIW? I think futures do a mighty fine job of solving callback issues; no coffeescript needed. Design around them,…

For callbacks I have found ToffeeScript to be an even bigger improvement than CoffeeScript. You can write code like this:

    e, personJson = fs.readFile! "person.json"
    person = JSON.parse personJson
    matchesLastname = myDB.query! "lastname", person.name
    id = msgQueue.push! { JSON.stringify(matchesLastname) } 
    log.info "Message sent to queue: #{id}"

instead of this:

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

Why do you believe that it is better to design around serious issues rather than creating a new paradigm?

I have found that the best solutions always involve a new/different fundamental model that incorporates solutions to recurring problems.

Re: Why CoffeeScript Isn't the Answer

#113

Post by rubyn00bie » Sun, Mar 30, 2014, 10:08 PM UTC

ilaksh wrote: post #112

rubyn00bie wrote: post #102

Earlier quoted context omitted.

Its cute you link to status quo bias, then immediately state, like a fact from god that "braces and parenthesis _do_ become awkward (...) Coffeescript solves that problem." It's your opinion that coffeescript solves the callback and parentheses issue. I'd also call your argument a bit of red herring. ... FWIW? I think futures do a mighty fine job of solving callback issues; no coffeescript needed. Design around them,…

For callbacks I have found ToffeeScript to be an even bigger improvement than CoffeeScript. You can write code like this: e, personJson = fs.readFile! "person.json" person = JSON.parse personJson matchesLastname = myDB.query! "lastname", person.name id = msgQueue.push! { JSON.stringify(matchesLastname) } log.info "Message sent to queue: #{id}" instead of this: fs.readFile("person.json", function(e, personJson) { var…

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.

Re: Why CoffeeScript Isn't the Answer

#114

Post by mrcsparker » Sun, Mar 30, 2014, 10:11 PM UTC

While it might not be the answer, it has been a very good answer for me. Recently I worked on an Angular project that had a pretty complex data model, and converting the model to CS made the code much more readable. The rest of the app was still in JS, minus a ./models directory which was CS. The other devs found the code very readable also.

I am biased towards Python and Ruby. I think that they are nice looking languages.

Different tools for different jobs. Next time I am on a JS project and I want to model data, I will probably use CS again.

Re: Why CoffeeScript Isn't the Answer

#115

Post by mkremins » Sun, Mar 30, 2014, 10:24 PM UTC

aidenn0 wrote: post #103

z3phyr wrote: post #30

Then, for sure, Clojurescript is the answer.

Clojure is really hard for me to use, coming from a lisp background. The various special forms seem to sometimes want a list and sometimes want a vector and sometimes don't care. I've yet to find a way to keep track of that. Anyone have a link to something from Rich mentioning why vectors are used in basic syntactic constructs? It's the one departure from its lisp roots that I couldn't figure out any motivation for.

I've never seen any explanation from Rich on the subject, but semantically speaking, vectors used in syntactic constructs are almost universally meant to denote binding forms. Let-bindings, loop-bindings, function parameters and the like all use vectors in the context of binding symbols to values.

I find that, having gotten used to the mental shortcut "square brackets == binding", the distinction makes it easier to read the "shape" of code from a very high level and get a general understanding of its meaning at a glance. YMMV.

Re: Why CoffeeScript Isn't the Answer

#116

Post by ilaksh » Sun, Mar 30, 2014, 11:02 PM UTC

rubyn00bie wrote: post #113

ilaksh wrote: post #112

Earlier quoted context omitted.

For callbacks I have found ToffeeScript to be an even bigger improvement than CoffeeScript. You can write code like this: e, personJson = fs.readFile! "person.json" person = JSON.parse personJson matchesLastname = myDB.query! "lastname", person.name id = msgQueue.push! { JSON.stringify(matchesLastname) } log.info "Message sent to queue: #{id}" instead of this: fs.readFile("person.json", function(e, personJson) { var…

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?

Re: Why CoffeeScript Isn't the Answer

#117

Post by mrinterweb » Sun, Mar 30, 2014, 11:12 PM UTC

I find CoffeeScript very readable, and I highly value readability. The extra verbosity of JavaScript doesn't really help me when I am reading code. I read CoffeeScript code faster than I can read JavaScript because CoffeeScript removes so much of the repetitive boiler plate code and lets you focus on the intent of the code.

I don't really understand the ambiguity argument. From the code examples in the article, I get the impression that the author doesn't really understand CoffeeScript.

I definitely prefer CoffeeScript to good old JavaScript.

Re: Why CoffeeScript Isn't the Answer

#118

Post by antihero » Sun, Mar 30, 2014, 11:30 PM UTC

ilaksh wrote: post #96

crazygringo wrote: post #90

I used CoffeeScript full-time for a year, both client-side and server-side (node.js). I completely agree with everything here -- it's a great summary, and it describes exactly while I never, ever want to use it again. In CoffeeScript, ambiguous code is the rule, not the exception. On top of that, things like variable capture and everything-returns-a-value introduce new kinds of bugs. The author says "realistically, t…

You completely agree with everything he wrote, after a year full-time? Really? So you would use curly braces and commas to specify an object, and then be confused when CoffeeScript doesn't get it? After a year you didn't figure out that its a best practice to leave off the parenthesis in just the outermost function call, but to include them in the other calls on a line to make things clear? After a year, you didn't r…

I used it for about 6 months, and realised that it simply wasn't worth the hassle. Yes, it looks a bit prettier and the destructuring is nice, but it adds a level of ambiguity that just ain't nice.

The lack of explicit scoping is horrible, and the lack of actual named functions is annoying.

The only thing I use now is JSX (when doing ReactJS), or TypeScript when not using JSX, as that adds actual value.

Re: Why CoffeeScript Isn't the Answer

#119

Post by shittyanalogy » Sun, Mar 30, 2014, 11:35 PM UTC

couchand wrote: post #20

This article proves not that CoffeeScript is flawed but that Jeff Walker doesn't understand how to use it. For instance, his first example is: # BROKEN func 5, { event: (e) -> if e.something 36 else 45, val: 10} Anyone with more than a day's experience with CoffeeScript knows that it's much better to express this with the simpler: # far better func 5, event: (e) -> if e.something 36 else 45 val: 10 Note how just drop…

    func 5,
      val: 10
      event: (e) -> 
        if e.something then 36 else 45

Re: Why CoffeeScript Isn't the Answer

#120

Post by h1karu » Mon, Mar 31, 2014, 12:09 AM UTC

camus2 wrote: post #42

h1karu wrote: post #34

CLOJURESCRIPT IS THE ANSWER! no question about it

The problem I have with clojurescript is i couldnt find any closurescript tutorial that did not involve java. Let's say i want to start using closurescript,like coffeescript. i want to do npm install -g closurescript then closurescript compile myscript or closurescript myscript. How do I do that? If closurescript folks want their language to be popular with javascripters i need to be able to do that. Right now,search…

npm depends on a javascript compiler such as g8 so how is that different than clojurescript depending on the JVM ?! It's no different at all you're just complaining that you don't like to have to install software before using it which is ridiculous if you want to use powerful software.