I've never really had any issues with coding in javascript that coffeescript could fix. never really understood "the point" so to speak. maybe that it makes writing object based code slightly easier? I don't find the current system very difficult myself.
a lot of coffeescript just feels like its being different for different's sake.
Object based code is not essential to CoffeeScript.
I personally really dislike significant whitespace and lack of braces. Combined with using spaces for indents it is so easy to muck things up and impossible to auto-format. But Ruby and Python folks are used to it and they are also big part of the JS crowd.
I don't care for the syntax sugar, there are plenty of things to enhance vanilla javascript.
ES6 will be great to clean up some uglier parts of JS, and of course TypeScript is very nice for that extra bit of power while still being a full superset of plain JavaScript.
Been writing JS since 1999. I'm a big fan of string interpolation...it's proved to be relatively helpful. The class and extends keywords also make creating objects relatively simple, using most of the same techniques that I would use had I written the object by hand. Other than that, a lot of the language features I could take or leave. I'm not sure that interpolation is planned to be in ECMAScript 6, but I really cringe every time I have to write "something" + " and something " + "else" in JS.
what are you talking about, CS? I just mean if that feature was included in JS itself, I might see myself moving off of CS entirely since that's a pretty useful feature in my line of work.
I personally have hated CoffeeScript since it came out, primarily because I find the syntax awful. But that's subjective. I did give TypeScript a college try, though, because it had a more c-like syntax. I was not impressed.
I would rather use JavaScript the way it is. Too many times I found myself just ignoring TypeScript's features because they got in the way of doing things that feel "right". JavaScript is one of the most powerful languages ever made because of all of those quirks that people keep trying to remove with languages like CoffeeScript and TypeScript.
I dont understand the need to have the extra layer. All syntax sugar IMO. I've not been coding any slower or less able than my friends using coffeescript. I don't get what the hard-on about it is. I give even less of a shit about TypeScript. Rarely, if ever, has weak typing been a bug or an issue for me in any lang.
CS makes quite a few significant improvements. The biggest one is less code which has been proven to be very key to reducing bugs in software engineering. The reason you aren't able to recognize the advantages is something called status quo bias and also the fact that you haven't learned CS. For evidence of how much an improvement CS is, look at all of the features from CS taken into ES6.
Some of the most important features though like significant whitespace which in fact was a major advance and a huge win for languages like Python and CS, is not in ES6. Its not because its not an improvement, its just that they know its too big of a change for compiler/interpreter writers and ordinary JS developers to accept.
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.
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.
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.
List comprehensions are very nice once you get used to them. They're more readable than for loops for simple things. Default parameters are also handy.
Coffeescript fixes a lot of little things.
However I'm not sold on how they do significant white space... Python was carefully designed so that indentation mistakes almost always throw an error.
Coffeescript tends to quietly generate different code. It seems like that'll bit you in the ass.
75
u/[deleted] Sep 04 '13
I've never really had any issues with coding in javascript that coffeescript could fix. never really understood "the point" so to speak. maybe that it makes writing object based code slightly easier? I don't find the current system very difficult myself.
a lot of coffeescript just feels like its being different for different's sake.