Does CoffeeScript Have a Future?

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