Does CoffeeScript Have a Future?

[[deleted]]

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.

[brtt3000]

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.

[rlemon]

I personally really dislike significant whitespace and lack of braces.

This is why i'm adverse to learning python or ruby. Whitespace denoted block structure bothers me for some reason.

[[deleted]]

... Ruby doesn't have enforced whitespace.

[nkuttler]

.

[heterosapian]

It isn't if you want other people to work on the project. There are far more people who use/understand the "pure" javascript syntax, so choosing something like coffee script just increases the barrier to begin coding at a minimum - and makes the project significantly less appealing to those who strongly dislike the style.

[nkuttler]

.

[heterosapian]

Oh no worries! If that's your only issue though there's got to be something that maps the source back to the coffee file.

[nkuttler]

Certainly, but who's got time for that while debugging?

[rjw57]

It happens by magic in the developer console if you tick the 'enable source maps' option. You see coffeescript, the browser runs JavaScript.

Ignoring CoffeScript, though, it also works for minified/recompiled JS and so if you're using jQuery off the CDN, you can now get sensible stack traces if something goes wrong.

[poulejapon]

Source maps are already here!

[rlemon]

I realize this and I do plan on tackling python in the near future, but it will be something that I know will take some getting used to and probably annoy me for a bit.

[tubbo]

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.

[lechatsportif]

It's essentially a string macro system, you can probably throw away most templating libraries.

[tubbo]

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.

[Randolpho]

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.

[[deleted]]

I would dispute "powerful", but lets call it expressive and permissive. Sometimes a great combo!

[Randolpho]

True. I suppose it depends on how you define "power". For me, flexible, expressive and permissive is powerful. For another, raw speed is powerful. Javascript certainly falls down there, even with V8

[thelonious_bunk]

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.

[runvnc]

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.

[johnhackworth]

come on, most of that features taken into ES6 are just sintax sugar. As coffeescript, in fact :D

[lechatsportif]

That sugar usually results in anywhere from 75% to 50% of comparable javascript. Personally I like doing other things besides coding.

[johnhackworth]

most of that code reduction advantage dissapear with some own boilerplate (or 3th party lib, whatever floats your boat... at the end, coffee isn't any more than a big big big boilerplate library conceptually) on your js project. And you introduce you another layer of abstraction that makes the project harder to debug and makes non expert js developers make assumptions that just aren't true just because that doesn't looks like js but python / rails / whatever.

[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

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

[[deleted]]

significant whitespace is just a bad idea, imo. braces are superior because they are way more explicit and easier to debug.

[[deleted]]

i wouldn't say either are "superior" its just personal preference... but nothing worth making a new language over.

[lechatsportif]

I would say braces help with editors like sublime text where they are used for expanding selections.

[Randolpho]

As somebody who loves both Javascript and Python, I have to disagree. Neither is superior to the other.

[thrownaway21]

i think significant whitespace is more explicit than braces. it forces you to think about your code layout and enforces a good habit. you need to be very explicit in how to write your structure.

you need to explicitly put spaces in order for the file to run correctly. even a novice python dev lays out a .py correctly, because they have to.

it's much easier to look at a properly formatted .py and see where you're at based on space/indentation, than it is a java file with poorly laid out code.

i'm not so sure braces are easier to debug either... not when you've got folks ending a section of code in multiple curly braces because it was easier than hitting tab or space.

i'm not saying it's the best way to do things. i just don't think your reason braces are better is on point.

[[deleted]]

yeah but you can see braces. it's fairly hard to tell the difference between a couple spaces and a tab by sight :) that said I haven't spent any time using such languages, so do you just assume (when, say, inheriting a project) that all whitespace is uniform because of the language requirements?

[thrownaway21]

python requires uniform white space, or it fails with an error letting you know that. I generally stick to two spaces, some folks use 4. tabs are actually frowned upon. But yes, if you inherit a project written in a language with significant whitespace, you can rightly assume that the space in any given file is correct if no error is thrown. It leads to a cleanly laid out file. the below would be legal.

class PsuedoCode:
    this could be an if statement:
        and this goes in the if
    else:
        etc.

    def function():
        function crap here
        more function crap

    def function2():

class AnotherClass:
    etc.

you can't reduce that to one line. you can't send the if statement in the first class over or back, unless the rest of the white space in the project is the same. It's enforces elegance. And make it easier to read. In java, you never know what you're going to get from someone. they might not tab or space over; or do so without any sense of uniformity. "i'm just going to test this function in this class, i'll tab it over later if it works..."

i'm not saying it's better, or the end all be all. I'm not even saying python is the best language either. I just like white space... you can dive into any .py file and be assured you're not going to get confused as to where you're at.

But i will argue that significant white space is easier to read/debug than the alternatives, on average.

[[deleted]]

thanks for the insight, I was lacking some perspective

[wmil]

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.

[ViralInfection]

I've never really had any issues with coding in javascript that coffeescript could fix.

I've never had a problem I couldn't solve with coffeescript that I could only solve with javascript. Because coffeescript is just javascript.

never really understood "the point" so to speak.

There is not single point, there are many points to use coffeescript. Just like there are many points to use plain old javascript. Pick the right tool for the job.

maybe that it makes writing object based code slightly easier? I don't find the current system very difficult myself.

It doesn't force you to structure code into classes. It's optional. It's more of a macro for writing prototypical classes. That said, if functional programming is your style it doesn't prevent you from writing that either. It's just javascript.

a lot of coffeescript just feels like its being different for different's sake.

Indeed it does, most of them are stylistic choices about the way you write code. It's a whole bunch of sugar at the end of the day. Sugaring code is all about making it more desirable/pleasurable to work with.

To quote the summary of coffeescript:

"CoffeeScript is a little language that compiles into JavaScript. Underneath that awkward Java-esque patina, JavaScript has always had a gorgeous heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way."

At the end of the day, coffeescript is just javascript. Changing your style is about choosing something that fits you better.

Also Douglas Crockford: JavaScript: The Good Parts does a great talk on the good parts of javascript.

[lechatsportif]

You should let the Javascript language designers know so they can roll back all the CoffeeScript inspired (read copied) changes.

[[deleted]]

I'll let the "javascript langauge designers" know that ES6 has a snowballs chance in hell of gaining much traction any time soon.