21–30 of 142 posts
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.
It tells me the line number and what I did wrong. It makes my day every time.
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?
Edit: Okay, I see what you're doing; attach is supposed to be invoked with a bound scope, which does change the binding. So yeah, my code won't work in your example. I'd argue that that's more of a lack-of-context problem in the example though, since it's dependent on knowledge of the usage of the attach() function to know that that binding behavior isn't desired. Given the context of the example, I contend my solution was acceptable. :)
Fat arrow there is still functionally equivalent to $.proxy.
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.
Sure, but we'll learn from CoffeeScript and apply it to the next ECMA ver. The CoffeeScript discussion is a worthy one, but declaring it unworthy to have a seat at said table prevents progress.
I'd rather read articles on how to make things better instead of bashing.
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.
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 and causes carpal tunnel syndrome)
> I feel like people don't know how to use web inspector...
You're right, many people don't. I'm not one of them, but I encounter them all the time. That kind of thing is still relatively new, so it's hard to blame them as much as pity them. And of course the Web inspector isn't there outside of a Web browser context.
> There will never be native CoffeeScript, you will always debug the JavaScript.
I never said there would be native CoffeeScript; I meant they will support source maps for alternative languages. Unless the CoffeeScript compiler is introducing bugs into correct code, being able to get error line numbers in your CoffeeScript file will mean that you mostly won't have to debug the generated JavaScript.
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?
To see what scope the fat arrow is bound to, all you need to do is scan up the parent scope in the file and look for a thin arrow (or a class declaration).
Your "whitespace problem" is my solution.
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…
(I didn't know about assigning self in instance_eval, though - that makes me all kinds of happy!)
What I meant to convey is that every language that uses first class functions (I guess I should say "any language with first class functions and the concept of this/self") has to deal with the problem of execution context. Languages like Ruby and Python assume the common case and bundle the context by default. Languages like Javascript and Lua don't, leaving it up to the caller to explicitly specify. In all cases, though, the callee has to be made aware of some context, which is what I meant by the `this` problem. My point is that since Javascript requires explicit binding, a language construct that allows Ruby-style implicit binding is nice syntactic sugar. The author seemed to be conveying the idea that using jQuery's $.proxy magically freed him from the need to pass context around, which is just simply not the case.
> This is really weird:
getUser = (id) ->
url = "users/#{id}"
dfd = $.ajax
url: url
format: 'json'
method: 'get'
url: url
promise: dfd.promise()
> It’s hard to recognize instantly that I’m actually
> calling $.ajax, not just assigning it. If you don’t know
> CoffeeScript, I’m sure the last two lines are totally
> baffling.
In fact, I'll make a positive argument for the implicit call syntax: the whitespace under 'dfd' tells me, without reading any further, that the line is a call which takes an object argument. Without significant whitespace, I couldn't rule out it being just a typo.
> 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…
We scan the left side of the code when reading. Checking the right side of the code to see if it actually will execute must invariably be slower. Also, the language encourages super long comprehensions.
Exactly. Sometimes you want the predicate muted so the consequence is highlighted. I agree that it seems counterintuitive, but I'm pretty sensitive to code flow and it works for me personally.
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.
crude state of JS debugging tools? It tells me the line number and what I did wrong. It makes my day every time.
That would change if you practiced reading other peoples' code. When I see my code, I often think, "yeah, I wrote this" because I know how I name things, but other than that, my code looks like everyone else's code. I know this because I based my style on what other people do, rather than just inventing my own. (At work, people like to write Python likeItsJavaOrSomething, and I refuse to follow that convention. While ugly, it doesn't make the code amazingly hard to read. You get used to it with practice.)
Now, compiler output is another thing, but c'mon. Sometimes I have to figure out what the computer is doing by reading memory dumps in gdb or the assembly output of gcc -O3. Complaining about the output of a JavaScript compiler is just silly; do it more and you'll figure it out. Programming is all pattern recognition, and if you can't understand patterns in the output of your toolchain, then you aren't using the tools enough.
People also like to complain about things like GHC's type inference errors or Perl's "confess" dumps. I personally have no problem extracting the information I need from them. I write a lot of programs and they fail a lot, so I've gotten good at reading the debug messages. Instead of saying, "this is too hard", try harder, and soon your life will be much better.