A Case Against Using CoffeeScript • Hacker News Board

Re: A Case Against Using CoffeeScript

#11

Post by cheald » Wed, Dec 14, 2011, 12:24 AM UTC

ryanflorence wrote: post #9

cheald wrote: post #5

Earlier quoted context omitted.

I dunno. I think that a lot of that is just a matter of developer maturity and code discipline. If you can't recognize a code smell when you're writing code, the problem is probably that you aren't mature enough as a developer, not that the language is bad for allowing it. I don't think that most seasoned developers would look at that 160-column list comprehension, say "okay, that works!" and move on to the next task…

The code smells are on the demo page for CoffeeScript.

Which bits do you consider to be code smells, out of curiosity? Things like postfix conditionals and list comprehensions generally aren't considered to be smells by the majority of people that use them. I don't see any 160-column list comprehensions or implicit bracketless object returns there, which are genuine smells.

Re: A Case Against Using CoffeeScript

#12

Post by ryanflorence » Wed, Dec 14, 2011, 12:24 AM UTC

geraldalewis wrote: post #7

> Verbally Readable !== Quicker Comprehension -> is Coffee-Script's greatest trick. When I first started poking through the codebase, it would take me ages to 'sound out' each line. Coffee-Script is succinct not simply because its syntax is short, but because it is dense. Everything is an `expression`, which means I can be more expressive/loc. I can now read it as fast as any other language, which means I can compreh…

Source mapping will be helpful, but clearly fewer people than I'd expect know how to use the debugging tools in their browser to the extent that I use them.

I don't want a line number, I want a break point or watch expression in my code while I'm debugging, I don't want to go back to my editor until I know the state of my app that's causing problems.

It is all very minor, but it piles up and slows me down.

Re: A Case Against Using CoffeeScript

#13

Post by wycats » Wed, Dec 14, 2011, 12:24 AM UTC

cheald wrote: post #2

The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…

First-class functions have the `this` problem in every language, and the fat arrow is very nice syntactic sugar for what you have to do anyway

Not true. JavaScript's `this` binding is absolutely not the only way to do it.

In Ruby:

  class Foo
    def hello
      return proc { self }
    end
  end

  puts Foo.new.hello.call #=> #

In Python:

  class Foo(object):
    def hello(self):
      def zoo():
        return self

      return zoo

  zoo = Foo().hello()
  print(zoo()) #=>

In Ruby, blocks carry the original `self` as part of their variable scope. Rubinius exposes this if you want to poke around:

  ruby-1.9.3-head :007 > x = proc {}
   => # 
  ruby-1.9.3-head :008 > x.block.scope.self
   => main

In Python, it's a side-effect of the fact that you need to explicitly define `self` as a parameter.

In Ruby, it's possible to override the `self` in a block using instance_eval, just as it's possible to explicitly define a `this` in JavaScript using `.call`.

The difference is that in JavaScript, the callee is always responsible for deciding what the `this` should be (often implicitly), where in Ruby and Python, the function's original binding includes its `self`.

edit: another way to put it would be that Coffee's fat arrow fix is the default in Ruby and Python.

Re: A Case Against Using CoffeeScript

#14

Post by ryanflorence » Wed, Dec 14, 2011, 12:27 AM UTC

cheald wrote: post #2

The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…

> Why is [fat arrow] evil in Coffeescript, but okay in jQuery?

I'm writing a specific article on the issues with the fat-arrow, but the difference is nesting callbacks v. assigning.

I like the fat arrow in `class`.

Re: A Case Against Using CoffeeScript

#15

Post by ryanflorence » Wed, Dec 14, 2011, 12:29 AM UTC

cheald wrote: post #2

The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…

    widget =
      attach: ->
        @el.bind 'click', @handler
      handler: (event) =>
        doStuffWithThis()

wrong.

Handler is bound to whatever scope widget is in. http://jashkenas.github.com/coffee-script/#try:widget%20%3D%...

See how confusing fat arrow is?

Re: A Case Against Using CoffeeScript

#16

Post by wycats » Wed, Dec 14, 2011, 12:29 AM UTC

devongovett wrote: post #6

IsaacSchlueter wrote: post #3

Earlier quoted context omitted.

I think part of the gist of the article was that abused CoffeeScript is more bad than abused JavaScript. So, yes, of course, you can do everything differently. But the point is, in the moment when writing it, it's not confusing, and doesn't stand out as a bad thing. Later, when you look at it, it IS confusing.

That is an opinion. I like that CoffeeScript allows me to have more choice over how I write my programs. If I want to write a piece of code in a different way, I can. If I don't think it will improve readability, I won't. You don't have to use all features of CoffeeScript all the time. Plus, if you don't like it at all, just don't use it and quit complaining. :)

I think the point of this article is that because of Coffee's wide use, developers will often find themselves in a situation where they can't "just don't use it".

You could say "don't take that job", but I think the point of the article is to make it clear that CoffeeScript is not an unvarnished win, and that choosing to use it will result in otherwise qualified people taking your advice and not wanting to work on your project.

Re: A Case Against Using CoffeeScript

#17

Post by ryanflorence » Wed, Dec 14, 2011, 12:31 AM UTC

ryanflorence wrote: post #9

cheald wrote: post #5

Earlier quoted context omitted.

I dunno. I think that a lot of that is just a matter of developer maturity and code discipline. If you can't recognize a code smell when you're writing code, the problem is probably that you aren't mature enough as a developer, not that the language is bad for allowing it. I don't think that most seasoned developers would look at that 160-column list comprehension, say "okay, that works!" and move on to the next task…

The code smells are on the demo page for CoffeeScript.

once you turn a comprehension into a multi-line block of code it looks just like JavaScript, so ... :\

Re: A Case Against Using CoffeeScript

#18

Post by ryanflorence » Wed, Dec 14, 2011, 12:34 AM UTC

chc wrote: post #4

The debugging complaint is valid, but a) doesn't generally seem that troublesome in practice (especially given the still-crude state of JavaScript debugging tools in general), and b) will be a lot less valid in the near future, as WebKit, Google and Mozilla are all adopting support for alternative languages in their respective JavaScript implementations IIRC.

Go ahead and [do this horrible thing], it's not _that_ bad.

> especially given the still-crude state of JavaScript debugging tools in general

I feel like people don't know how to use web inspector...

There will never be native CoffeeScript, you will always debug the JavaScript.

Re: A Case Against Using CoffeeScript

#19

Post by phzbOx » Wed, Dec 14, 2011, 12:34 AM UTC

To quote the author:

"Check out this one-liner I pulled out of the first .coffee file I randomly opened from our application:

scores = (student["assignment_#{@assignment.id}"].score for own idx, student of @gradebook.students when student["assignment_#{@assignment.id}"]?.score?)

That’s 160 columns of “readable code”..."

You can write a 160 columns of unreadable code in any languages. If you guys enjoy coding like that, don't blame coffeescript.

You might be right however that it is "more tempting". For instance, with scheme, it's really easy to start using macro and redefining everything; or to nest lambdas into lambdas into lambdas "because you can do it and it avoids using variables".

Still, I think it's the programmer's job to write clear code, whatever the language.

Re: A Case Against Using CoffeeScript

#20

Post by RobertKohr » Wed, Dec 14, 2011, 12:39 AM UTC

The debugging complexity is more than just a fair point. It is what kills the language for me.

I spend way more time debugging code than writing it. I suspect most coders do. Programming has taught me that I am far from perfect.

Give me a language where I can jump right to the problem and my debugger will tell me how I goofed up, and I can look at it as a potential language I will use. Give me something where you double my debug time (which will add probably 30% to my total programming time) and I will ignore it. It doesn't matter how pretty and short it makes the code. Give me error line numbers or go home.

If you make my debugging more of a chore than it already is, you ain't no friend of mine.

I also agree with the author on the need for symbols rather than words in languages. It may make people feel all warm and fuzzy to write what looks like english, but && trumps and every day. {} or () wrapping something gives me a lot of info about what is going on and with little mental parsing.

In the end, CS just doesn't deliver a advantage to me that is worth moving away from something as easy to code in as JS, warts and all. And I have tried very hard to want to like it.