Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brief Video: Rewriting JavaScript into CoffeeScript

ryanflorence.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#21

Post by TazeTSchnitzel »

threecreepio wrote: post #12

I both like and use CoffeeScript, but the video does show off one thing that i personally quite dislike about it.. Implicit returns (which I love in ruby..). When trying to port over some applications to coffeescript, I had to revisit a whole lot of my functions to add in an empty return; line after code like: test: (m) -> m(i) for i in this.set Since I didn't really expect them to build up and return arrays of the r…

Well, it's part of the CoffeeScript idea that everything is an expression, but surely they could have manual returns?

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#22

Post by nxn »

Is that code really valid CoffeeScript? Last I looked, and I admit that the last time was months ago, 'on' was a reserved keyword (an alias of 'true') and I had to do some quite ugly hacks to be able to have a method named 'on'. This may have been related to dynamically adding the method onto the prototype of some constructor rather than defining it in a class.

Besides that, I still get feelings of discomfort when thinking about rewriting JS to coffeescript when knowing that the compiler will just write it as JS again.

EDIT: Tried it. In this case it seems to works.

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#24

Post by MatthewPhillips »

munificent wrote: post #19

This is very cool, though I personally find postfix flow control confusing to read. The postfix loop with destructuring is especially odd to me. As I read left to right, I see variables that don't exist "yet" until I get to the later loop clause. This is probably just a familiarity thing and I would get used to it, but compared to all of the other changes in the video which I think are pretty clean that stood out to…

I agree. I also find unless statements to be difficult to read. I use this pattern all of the time in my JavaScript:

  if(!foo) {
    maybeDoSomething();

    return;
  }

  bar();
This lets me early exit, if needed, while letting the meat of the function not suffer from unnecessary indentation.

The unless statement makes the early exit seem like the default action rather than the exceptional action it (hopefully) is.

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#25

Post by eaurouge »

jashkenas wrote: post #18
threecreepio wrote: post #12

I both like and use CoffeeScript, but the video does show off one thing that i personally quite dislike about it.. Implicit returns (which I love in ruby..). When trying to port over some applications to coffeescript, I had to revisit a whole lot of my functions to add in an empty return; line after code like: test: (m) -> m(i) for i in this.set Since I didn't really expect them to build up and return arrays of the r…

Out of curiosity ... if you love implicit returns in principle, then why would you dislike them in this context? Certainly, you need to keep in mind the return value of a function while you're writing it -- if you don't want to return any value, then just "return". And it's definitely something that you need to keep more in mind while porting JS than when writing code from scratch. But given all that, would you reall…

Out of curiosity ... if you love implicit returns in principle, then why would you dislike them in this context?

I'll guess it's because speed is less of a concern when programming in Ruby.

if you don't want to return any value, then just "return".

Yes, but that leads to clutter and goes against one of the selling points of CoffeeScript.

Previous discussions on this:

http://github.com/jashkenas/coffee-script/issues/1401

http://github.com/jashkenas/coffee-script/issues/899

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#26

Post by clux »

threecreepio wrote: post #12

I both like and use CoffeeScript, but the video does show off one thing that i personally quite dislike about it.. Implicit returns (which I love in ruby..). When trying to port over some applications to coffeescript, I had to revisit a whole lot of my functions to add in an empty return; line after code like: test: (m) -> m(i) for i in this.set Since I didn't really expect them to build up and return arrays of the r…

I quit using CS for essentially this reason. Implicit returns are a nice idea, but they are just implemented a bit too inconsistently. Additionally, it changes the language from being "it's just JavaScript" to sugared JS with different behaviour.

I listed some of the pitfalls with implicit returns at the following CS issue: https://github.com/jashkenas/coffee-script/issues/899#issuec...

Re: Brief Video: Rewriting JavaScript into CoffeeScript

#27

Post by threecreepio »

jashkenas wrote: post #18
threecreepio wrote: post #12

I both like and use CoffeeScript, but the video does show off one thing that i personally quite dislike about it.. Implicit returns (which I love in ruby..). When trying to port over some applications to coffeescript, I had to revisit a whole lot of my functions to add in an empty return; line after code like: test: (m) -> m(i) for i in this.set Since I didn't really expect them to build up and return arrays of the r…

Out of curiosity ... if you love implicit returns in principle, then why would you dislike them in this context? Certainly, you need to keep in mind the return value of a function while you're writing it -- if you don't want to return any value, then just "return". And it's definitely something that you need to keep more in mind while porting JS than when writing code from scratch. But given all that, would you reall…

I hadn't actually looked at the issues list to notice that this and similar issues have already been brought up plenty enough, so, sorry about that. And I do like implicit returns, and they're one of the main reasons I'm using CoffeeScript in some projects.

What I was trying to express was that I don't generally run into this issue in ruby because the similar looping constructs don't behave this way, and don't carry the same kind of unexpected side-effects:

    def test(lst) lst.each{|i|do_stuff(i)} end
this method will return "lst" back to me, it won't create any new arrays of the do_stuff(i) results, the same goes for for/while loops, whereas:

    def test(lst) lst.map{|i|do_stuff(i)} end
will return the block results. The key difference being that the map method always creates an array and returns it, even if I would have a return; after, so it is consistent.

The only situation where I get into the problem is with looping, and after some time using CoffeeScript, only rarely, so it may just be one of those things you have to put up with. Still crops up occasionally after refactoring though.

I would not want to get rid of implicit returns, and would far rather continue dealing with the loop problems than that. Would just love it if those weren't the only options.

Post reply on HN