CS2 Discussion: Question: CoffeeScript Gripes?

[rattrayalex]

What features or aspects of CoffeeScript have caused you the most pain?

What do newcomers to the language find the most challenging?

What are examples of CoffeeScript code that can be particularly confusing?

What features have you almost never seen used that could probably be removed?

Let's use this thread for brainstorming ideas, and try to split off discussions into other threads. Reactions ( 👍 , 👎 ) encouraged – 👍 means "I agree this is a problem" and 👎 means "I disagree – this is a good feature and should be kept"

[realJoshByrnes]

The one thing that has always driven me crazy is not being able to modify the incremented variable in a for loop. eg, If I want to skip an iteration.

for name, i in names
  i++

i++ would be expected to skip an iteration, as it assumed that i will automatically be increased in this for loop.
Thoughts?

[ohaz]

Sorry, but that looks kind of bad and poorly readable @ozjd - the loop variable should be changed in the head of the loop only - changing it in the body as well will just make it completely unreadable. Add a "continue", or make the loop skip every second entry by doing it in the loop somehow (like "for name, i in names by 2).

[realJoshByrnes]

If you have access to the iteration counter, it seems intuitive to be able to modify the iteration.

In the end, I created a variable that's checked on each iteration, and skips over the loop as needed.

[JimPanic]

In the case of any syntax similar to for x, y in {key: value, ...}, this doesn't make any sense. The syntax is basically an implicit map function invoking the expression you give it. If it does work, I would highly recommend against using this. This is a fast lane to hard-to-debug bugs.

It would be possible and is used heavily in for(i = x; i < y; i += 2) { i -= 1;} constructs, but we do not have those in CS as far as I can tell.

[JimPanic]

Additionally, you might want to use a reduce/fold function instead where you use the accumulator as arbitrary counting variable.

[carlsmith]

Nonlocal Assignment

As discussed at length in #1, CoffeeScript uses nonlocal assignments by default, which is unusual and confusing.

Remove the Arguments Type

Make it a normal array (if it's actually referenced).

Array Comprehensions

CoffeeScript operator precedence makes a = b for b in c equal to (a = b) for b in c, so a gets reassigned on every iteration. You normally want to do a = (b for b in c), so a is assigned once, to an array of the values from each iteration. We should require array comprehensions to be wrapped in brackets: a = [ b for b in c ].

[rattrayalex]

@carlsmith wow, awesome list!!

Many things seem more like feature requests than gripes, however. I just created a "New Feature Ideas" thread – #16 – any chance you'd be willing to break out the feature requests to that one?

For example, I personally love the "Automatically Reference First Args" idea, but it's definitely not a bug in coffeescript that the feature doesn't exist yet.

[carlsmith]

@rattrayalex - Done. No worries.

[carlsmith]

If you have access to the iteration counter, it seems intuitive to be able to modify the iteration.

If we're talking about iteration specifically, it pretty directly refers to executing some subroutine for each item in some sequence, so there's an expectation that it's not going to jump around. Still you're right, there's a need to manually advance the iteration counter sometimes. In a lexer for example, you want to iterate over the chars in the source, but if you use a big for char in source loop, you find you need to skip ahead to pop the characters off as you process each token. In those cases, it's best to scrap any pretence of being an iteration, and just use a while-loop that spins forever, then keep track of the character index manually and break manually when you're done. Basically, if it's not a proper iteration, just fall back to a good old fashioned loop and counter. Obviously, it's perfectly fine to use continue in a for-loop, but that doesn't solve the problem you hinted at.

[objectkit]

There are a few gripes I'd like to throw in here myself, but I'll pare it down to just one here...

Implicit Return Must Die

No. Just no. I understand the utility of implicit returns for visual clarity in small methods.

class Data
    constructor: (@value) ->
    getValue: -> @value

and at times, when iterating or filtering arrays and returning the result, but returning undocumented or non-obvious values ad hoc as a result of brevity...? I could be alone in this. But no. Implicit return must die in a new edition of the language. If there is going to be an implicit return, do what ES does and return undefined!

Theres a whole spate of backwards compatibility issues of course, but I think a partial solution could possibly be for this languages compiler to take standard CS in as an input, and to transpile that to CS6 before transpiling to the end language - ES4/5/6/7...

[carlsmith]

We must implicitly return something, as a function call is an expression. It could be undefined though. I would rather have it so that functions that have a single expression as their body return its value implicitly, but functions with more than one expression must return something explicitly, else undefined.

This has been discussed before, and a few of us wanted that compromise.

[MemoryChips]

What do you save by getting rid of implicit returns?
You would have to type return a heck of a lot more often if you get rid of it.

[carlsmith]

The argument, which I personally don't care about much, except because other people care about it a lot, is that the return values can be large, and there's a perceived inefficiency in generating and returning big chunks of stuff when it's immediately garbage collected. We could maybe be more intelligent about it at the compiler level, eliminating implicit returns wherever we are certain they go unused. The argument seems to be purely based on perf, so eliminating the inefficiencies would help solve the issue, without changing the language, as I understand it. Again, it's something I only worry about because a lot of other people hate the feature, so I'm not the best person to judge solutions.

[carlmathisen]

I don't think it's possible to decide return statements on a compiler level. If you are creating a library, how are you to know if the return statement will be used or not if the user script isn't available?

Btw, at work we have used CoffeeScript on slow set top boxes for years, boxes with max 2MB JS memory heap until stuff gets garbage collected. You can definitely say that we have had a close eye on memory allocation with proper profilers for years, and CS has never created trouble for us. Even for us, functions as expressions is a positive and has never given us problems.

[carlsmith]

I don't think it's possible to decide return statements on a compiler level. If you are creating a library, how are you to know if the return statement will be used or not if the user script isn't available?

I don't understand. It's only syntactic, and only matters to the author of the function. When you call a function, you never know how it returned a value. It doesn't matter.

Btw, at work we have used CoffeeScript on slow set top boxes for years, boxes with max 2MB JS memory heap until stuff gets garbage collected. You can definitely say that we have had a close eye on memory allocation with proper profilers for years, and CS has never created trouble for us. Even for us, functions as expressions is a positive and has never given us problems.

That's really interesting. Browsers spend very little time executing JS. I assume it's similar with set top boxes. Pure JS stuff, like the CoffeeScript compiler seem fine as well. I've never seen a concrete example of implicit returns being a problem, but a lot of people want a way to disable it (per file or per function with special operators).