Live data from Hacker News

A Case Against Using CoffeeScript

ryanflorence.com

51–60 of 142 posts

Re: A Case Against Using CoffeeScript

#51
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.

I dunno, it would seem that upcoming SMAP support in Firefox and Webkit[1] comes pretty close to debugging the CoffeeScript directly.

[1] http://www.infoq.com/news/2011/08/debug-languages-on-javascr...

Re: A Case Against Using CoffeeScript

#52
Seems like author is trying to learn a new language and is having a hard time getting out of the shell he created around him with experience. During the struggle he wrote this post.

I had exactly same feelings about one-liners and understanding succint statements when I was learning Python after years of programming in C.

Re: A Case Against Using CoffeeScript

#53
post #48

I think this article is a mix of fair criticisms but at points lapses into a lot of hand waving. At points it devolves into "This is confusing/non-intuitive if you don't know CS" and "This is not the way I like to do things". I find the proposition that porting a library (no matter the size) gives you "as much experience as anyone" pretty dubious. It's clear the author has some experience with CS, and I wouldn't disc…

> "I find the proposition that porting a library (no matter the size) gives you "as much experience as anyone" pretty dubious"

My intro comes off as though I'm claiming to be some sort of authority, which wasn't my intention at all. So good call on your part. I just meant "It's not like I've only spent 5 mins with the language". Lots of folks out there are dismissing it w/o giving it a shot.

However, I do know the language well at this point since it has a lot of rubyisms (and I'm alright with ruby) and at the end of the day is just JavaScript™.

Concerning images/symbols v. words. Like I said in the article, I _feel_ the relationship when I see `!==`, I don't feel it when I read `isnt`. However, I went from design -> code, so maybe imagery is a bigger deal to me.

> but I doubt very much giving stupid people JavaScript will give you overall less problems...just different ones

Yeah, one of which is not a less-than-optimal debugging experience.

> The only time I really break out the debugger is debugging other people's code.

Welcome to my article.

> Editor macros make inserting logs dead simple

I use vim, and I agree. But that's an extra few steps from my JS debugging. When something unexpected happens, I go straight the console, start adding break points, watch expressions, mutating data, etc. etc. to find the problem before I ever get back to vim. People who have always console.log'd will probably not get as frustrated as me. I feel like I'm limping.

Thanks for the criticisms. For me, the imagery is a big deal, it's not hand-waving, it's my true experience, and that of others I've talked to. We all have different minds.

Re: A Case Against Using CoffeeScript

#54
post #48

I think this article is a mix of fair criticisms but at points lapses into a lot of hand waving. At points it devolves into "This is confusing/non-intuitive if you don't know CS" and "This is not the way I like to do things". I find the proposition that porting a library (no matter the size) gives you "as much experience as anyone" pretty dubious. It's clear the author has some experience with CS, and I wouldn't disc…

Woah, missed a whole section:

> This is not a valid construct. By using "of" you are iterating through the keys of dishes, which will inevitable be strings.

No, they are objects with properties like "dirty", not strings. Dishes is an object of key value pairs. I've been very active in MooTools, contributed to its source, and have written plenty of my own stuff to know the importance of iterating arrays v. objects properly, (and have since repented of extending built-ins).

While I'm on the topic, I love `for own key, val of obj`, own is so, so awesome right there.

Re: A Case Against Using CoffeeScript

#55
post #24

Earlier quoted context omitted.

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.

> Go ahead and [do this horrible thing], it's not _that_ bad. Sure. Let me insert a few things that can have really bad side effects that I still think you should do: • Leave your house every day (car crashes ROFLstomp homicide as a cause of death) • Eat food (most foods have some ill effect on your body) • Write some code in C (it's a very unsafe language, but sometimes necessary) • Use a computer (hurts your eyes a…

Source maps will be helpful, but I still can't put a break point in my coffee script from the browser.

Re: A Case Against Using CoffeeScript

#56
post #50

What are your experiences writing CS on top of another well-established javascript API framework, e.g. Dojo. I do a lot of work with ArcGIS Server's Javascript API, which is based in Dojo. I also mix in Jquery when needed (because I prefer it over Dojo). So, would CS be a benefit in these situations, or just muddy the waters?

It's totally natural. So if you prefer CS don't let using a third-party lib change your mind.

Re: A Case Against Using CoffeeScript

#57
post #48

I think this article is a mix of fair criticisms but at points lapses into a lot of hand waving. At points it devolves into "This is confusing/non-intuitive if you don't know CS" and "This is not the way I like to do things". I find the proposition that porting a library (no matter the size) gives you "as much experience as anyone" pretty dubious. It's clear the author has some experience with CS, and I wouldn't disc…

Woah, missed a whole section: > This is not a valid construct. By using "of" you are iterating through the keys of dishes, which will inevitable be strings. No, they are objects with properties like "dirty", not strings. Dishes is an object of key value pairs. I've been very active in MooTools, contributed to its source, and have written plenty of my own stuff to know the importance of iterating arrays v. objects pro…

Ok, just to be clear because this comment is ambiguous as to if you understand what I'm saying.

The comprehension in your article is not valid, you need to change one thing or the other for it to work.

> Dishes is an object of key value pairs

Yes, and you are getting the KEYS, not the VALUES. I doubt I need to say this, but per the spec KEYS are ipso facto strings.

At the point you do

    plate.dirty
"plate" is a STRING, one of the key names in the dishes object.

See, here is the compiled code fresh from the compiler (with added comments):

    var plate;

    if (meal.status === 'done') {
        for (plate in dishes) {
            // plate is a STRING, plate.dirty will not exist
           // you want dishes[plate].dirty
            if (plate.dirty) wash(plate, brush, sink);
        }
    }
You're making the mistake of thinking CS will do the plate = dishes[ key ] part for you, but it won't...do it yourself or us "in" on an array.

You'll also note there are no sanity checks, so use with caution.

This is precisely what I mean when I talk about not knowing CS well enough. I mean this with all due respect and do not intend to dismiss you. You are clearly very bright and a good coder. Anyone will get tripped up in any language at first.

The point is I've used CS so much I breathe this stuff...I knew instantly that it was an invalid construct.... I'm simply saying (like any language) once you learn it well enough a lot of these sorts of issues fade into the background.

Maybe you don't think it's worth the effort to get to this point, and that would be fair enough. I just think it needs saying that some of the points you raise are related to being relatively new to CS.

Re: A Case Against Using CoffeeScript

#58
post #48

I think this article is a mix of fair criticisms but at points lapses into a lot of hand waving. At points it devolves into "This is confusing/non-intuitive if you don't know CS" and "This is not the way I like to do things". I find the proposition that porting a library (no matter the size) gives you "as much experience as anyone" pretty dubious. It's clear the author has some experience with CS, and I wouldn't disc…

> "I find the proposition that porting a library (no matter the size) gives you "as much experience as anyone" pretty dubious" My intro comes off as though I'm claiming to be some sort of authority, which wasn't my intention at all. So good call on your part. I just meant "It's not like I've only spent 5 mins with the language". Lots of folks out there are dismissing it w/o giving it a shot. However, I do know the la…

Sure, likewise it's not my intention to write you off, you clearly have some good points based on real usage... I'm just trying to contrast your experience with people who have used it even longer still.

> Like I said in the article, I _feel_ the relationship when I see `!==`, I don't feel it when I read `isnt`.

Sure, I think that's fair. The point that I'm trying to make is that I think this is subjective based on your own personal background/brain/whatever other nebulous factors.

In your article it could be taken to sound like you are making a case that there is some neurological reason that "!==" is more readable, and I'm not prepared to accept that without some more substantial evidence.

I think I get where you're going, you're just trying to draw comparisons...I just want to add that those comparisons are somewhat nebulous and should not be taken absolutely.

> Welcome to my article.

I didn't get a chance to expand on that point because of space limits. What I mostly mean there is once you're in someone elses code, as far as I'm concerned it's basically all bets are off anyway. At this point when debugging other-code it's often JS, so the point is moot anyway. However, even when it's CS I don't find debugging the JS directly very difficult because it's clear enough for that purpose. Usually it's some issue like a value is not being coerced properly, or arguments being passed in the wrong order, and those are pretty easy for me to nail down with a debugger even if the source is a mess of compiled JavScript...then it's easy to fix it.

Re: debugging, I think we are on the same page. We have different styles. Yours is somewhat crippled by CoffeeScript. It may get better in the future, it may not. I just wanted to say I feel no such impediment.

> it's not hand-waving

My main objection is your examples. Like I said they could be construed as making a more scientific-objective case, rather than a more philosophical subjective one.

Re: A Case Against Using CoffeeScript

#59

> 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.

Perhaps an article (or webcast) on how you use your debugging tools is in order.

Re: A Case Against Using CoffeeScript

#60

It took me about 3 months of intense CS usage to really get the hang of it. I've written a good 20-30k lines of CS so far for my application, so I've developed a lot of good practices since I started. Now, I can't imagine writing 'pure' JS ever again. I tend to avoid a lot of the one-line comprehensions for the reasons documented in this article (they get difficult to 'parse'). I also tend to write in a more of a Jav…

> if/when browsers natively support CS. They won't, and source maps are not native support. Check out AMD with RequireJS (make sure you optimize) for your "import" stuff. I haven't incorporated optimization yet for the project, but you can see how it works with my snackJS project http://github.com/rpflorence/snack/tree/amd-coffee/lib

Thanks Ryan. I've looked at the RequireJS/AMD import stuff and it seems really over engineered for what I need. I feel like there is too much declaration going on. For now I think I'll wait to see what else people come up with along these lines.
Post reply on HN