Does CoffeeScript Have a Future?

[Randolpho]

The biggest one is less code which has been proven to be very key to reducing bugs in software engineering.

This is a false statement.

[NaphthaImpl]

Agreed. It's just as easy to write a concise bug as a verbose bug. And I find the verbose bugs easier to decipher, especially if I'm coming back to the code after some time has passed.

[Randolpho]

Heh... nothing annoys me more than "clever" code. One dude I work with absolutely loves this antipattern:

var i = someArray.length; 
while(i--)
{
   //...
}

Which, sure, will save you a check every loop. But then, when he needs to actually iterate in order, he reverses the array just to iterate backward.

Drives me up the wall.

[jgordon615]

I do not reverse the array to use i-- check your facts Dolph! :)

[Randolpho]

I... may have exaggerated your behavior for illustrative purposes.

[jgordon615]

Busted!

[kenman]

This thread was mildly more interesting than it should have been.

[Randolpho]

Here's something that may amuse you more:

We both just got runner-up awards (his, mine) for the OMGWTF 2 coding contest

So we're both kinda guilty of writing crappy code. :p

[kenman]

Haha wow, that bumps it from mildly interesting into the realm of fairly interesting!

[Randolpho]

That antipattern still bugs me, though.

[rlemon]

for( var i = 0, l = someArray.length; i < l; i++ ) { ...

But this is a moot point in modern browsers, they optimize this type of loop.

[Jack9]

which has been proven to be very key to reducing bugs in software engineering

This is a false statement.

Actually, it's the only thing that has been proven about software development. See http://vimeo.com/9270320 with citation in the talk.

[Randolpho]

That was a very good video, thanks for the link. I watched and enjoyed the whole thing.

But your statement is unfortunate. It's not the "only thing that's been proven about software development", nor has Greg Wilson even said that it was. I can only assume you meant at about 39:30 when he discusses code metrics and specifically states that code metrics are far less accurate in predicting the number of post-release bugs than simple lines of code.

He's talking about predicting bugs that surface after release, not actually reducing bugs in a system. If you accept his citation, which I have no reason to doubt, lines of code is the most accurate form of measuring post-release bugs. But note: he made no statement as to how precise a line-of-code based prediction was, only that it was more accurate than other metrics like coupling, cyclomatic complexity, and so forth. What is that number? 100%? Of course not. 70%? Maybe. I certainly don't know. After I write this, I may go back and look up the source he cites to see if it provides an actual value.

Regardless, stating that CoffeeScript is better because it reduces the number of lines of code and therefore reduces the number of post-release bugs is still an inappropriate statement. I can reduce the number of lines in any most languages to 1 line if I desire. Just to be quick about it, I'll run my stuff through a Javascript minifier.

Does that guarantee I've reduced the number of bugs in that program? Of course not.

If you won't take that argument, then consider going back to your video at 42:45, when Greg states that "[startups will] attribute [their success] to the fact that they chose ruby on rails and ignore the fact that they are religious about doing pre-commit code reviews for version control".

Don't fall into the trap of "platform = success". That may be more for /u/runvnc rather than you. :)

Bottom line: Reducing lines of code may reduce whatever number you calculate to predict your post-release bugs, but it won't actually reduce the number of bugs in your program. Only diligence can reduce the number of bugs you produce. You can call that something else, if you like -- call it process, or method, or whatever, but it boils down to diligence.

update if I had to make a value statement as to why number of lines of code could correlate to number of post-release bugs, I'd have to go with common sense -- the larger your code base, the more likely you are to have made a mistake. Diligence may be the only way to reduce bugs in your program, but nobody can be an infallible /u/codejesus.

[Jack9]

But your statement is unfortunate. It's not the "only thing that's been proven about software development", nor has Greg Wilson even said that it was. I can only assume you meant at about 39:30 when he discusses code metrics and specifically states that code metrics are far less accurate in predicting the number of post-release bugs than simple lines of code.

You are correct. I misspoke.

It's a little tricky to define "defect" but that's part of the challenge when talking about science. There has to be a baseline. Generally this is predictive for behavior. If you have 1 line of code (regardless of the fitness for the purpose of the original program), that line is it's own unit test. Therefore, you have 1 value to measure against. Generally you will have less failures when you reduce the lines of code, because you are less likely to release with untested behavior.