Free up yes/no/on/off (or remove them entirely)

[satyr]

Remove them who clutter up namespace, replacing with yes = on = true, no = off = false predefined on top for backward compatibility.

The obvious benefit:

• Four less reserved keywords.

The less obvious benefit:

• You'll get better compression if you still use them.
  • Use good ol true/false if you concern performance.

[jashkenas]

If we ever remove yes, no, on, and off -- we should do so entirely. There's no point in removing them half-assed, having them only act as keywords in certain circumstances, and hurting performance to boot.

[TrevorBurnham]

I wouldn't miss yes/no or on/off. I've never seen anyone use them, and it's easy to define them if desired.

[frodwith]

I tend to agree with Trevor. I sort of think they're a bit silly in the first place though. Useless reserved words for the loss?

[stephank]

Hmm.. I actually never use true/false and on/off in practice. I almost always find myself using yes/no.

I find myself using booleans most often to enable or disable functions and features (logErrors: yes), or to describe properties of an object (shoelace.isEdible() == no).

I can see why you could say errorLogging = off, but any form that fits true/false feels unnatural. You could say shoelace.isEdible() == false, but that kind of thing is often part of a condition, such as unless shoelace.isEdible() ..., which reads a lot nicer.

But I agree it's a very small thing, and all aesthetics.

[satyr]

If we were to remove them, removing the other pure aliases (not/is/isnt/and/or) is also debatable.

edit : #814

[frodwith]

I think the question there is "what improves readability?" If yes/no on/off improve readability, it makes sense to keep them. I think not/is/isnt/and/or definitely do, but it's all quite subjective.

[ghost]

I do use yes and no a lot -- e.g.: 23 times for yes in my current project. Particularly for defining models -- e.g., unique: yes, protected: yes...

That said, replacing them with true / false won't make such of a big difference. If it's true (pun intended) that most people rarely don't use these, I'd be ok with removing them. Although I do think they are kinda like CoffeeScript's trademarks.

[jacius]

Yes true, I'd say they are language clutter and should be removed as reserved words. For people who really want them, it's not hard to define them as variables at the top of the file. (I don't feel very strongly about this, though.)

[ghost]

on and off I always use at the end of event callbacks. It helps me know why I am returning true or false -- the context. Do other people like this usage? Would you consider using them like I do?

If people would like using on and off for this purpose, maybe we could make it an example in the Documentation and advise its usage.

[ghost]

I have to say that I'm a bit afraid that CoffeeScript is losing its soul. -- Isn't "reading like a natural language" one of the goals of CoffeeScript?

Maybe these goals could be mentioned in a new Intro on coffeescript.org, so we can get everyone aligned with CoffeeScript's original intentions.

jashkenas, what do you think?

[jashkenas]

devtime: That sounds like a fine idea -- to have a section on philosophy.

The idea with CoffeeScript is to create a readable and minimal language that sticks close to JavaScript, while papering over its rough edges, and providing idioms for common patterns.

Naturally, those goals are in direct tension with one another -- readability and succinctness are not always the same, and adding common idioms is difficult to do while keeping the language minimal. Balancing those goals is the challenge that we're addressing by discussing issues such as this one.

[ghost]

Balancing those goals is the challenge that we're addressing by discussing issues such as this one.

jashkenas: Indeed. It's a balancing act, like living one's life. :)

[herrtreas]

IMO its one of Coffeescripts's bests to get more readability out of my source. Yes/No (in addition to true / false) reads just perfect in most circumstances.

I think @DEVTIME got it right: CoffeeScript would lose its soul.

[devongovett]

I like yes and no, but don't use on or off. I vote to keep them. Who names their variables yes/no/on/off?

[sveisvei]

I say keep em! (altough I dont use em much, but that is because I came from plain js). CS should keep stuff that improves readability

[StanAngeloff]

< pun >
My only comments is -- are you for real? I can't take it any more, CoffeeScript is turning into PythonScript.
< /pun >

devtime nailed it !

[jacius]

After reading the other replies, I've reconsidered. yes/no/on/off can be nice for some things, and makes code a bit more readable and descriptive. That outweighs the tiny downside of reserved words clutter. I say keep 'em.

[TrevorBurnham]

OK, I'm fine with keeping the synonyms, since several folks seem to feel strongly about them.

I must say that I'm very surprised to hear more people express support for keeping yes/no and on/off than for keeping the arr[x..y] shorthand for arr.slice(x, y+1) currently being discussed at issue 803...

[satyr]

I must say that I'm very surprised to hear more people express support for keeping yes/no and on/off

That's how eye-catches work. However stupid they actually are.

[satyr]

Just in case: are you guys aware that once we free up them, you are free to do yes = true? You gain flexibility rather than lose.

[ghost]

you are free to do yes = true

You gain flexibility rather than lose

We lose proper syntax highlighting, we lose a common agreement on what yes means (i.e., its value). The same for no, on and off.

[jashkenas]

Great -- readability carries the day -- despite YAML desiring to move closer to JSON. If you don't like them, you don't have to use them. Closing the issue as a wontfix.

[satyr]

If you don't like them, you don't have to use them

That was never an issue to begin with. The culprit is that you can't use them as identifiers like you can do in JS.

[ghost]

satyr:

The culprit is that you can't use them as identifiers like you can do in JS.

I quote devongovett:

Who names their variables yes / no / on / off?

[satyr]

Who names their variables yes / no / on / off?

• yes
• no
• on
• off

[ghost]

Well, let's hope that when people come to CoffeeScript they'll learn to give more meaningful names to their variables, too! :D

Anyway, IMO, the benefits outweigh the rare difficulty in converting code from JavaScript.

[satyr]

the benefits

And what benefits are those? We end up with inconsitent code across lines/people/projects. yes here, on there, true ftw.

[ghost]

satyr, as you can see from several comments here, people are using them because clearly they benefit from them. Otherwise they wouldn't use them.

Mainly it gets used by seasoned CoffeeScript programmers when it expresses the purpose of the code better than a plain true / false. Like my usage of on / off at the end of event callbacks.

Besides, it's cool, and CoffeeScript is about coolness too, where it is not expensive. ;)

We end up with inconsitent code across lines / people / projects

Then establish some conventions with those projects / people. The same problem goes for how APIs are named.

[mrjjwright]

Readability is very important to me, I love this design philosophy of Objective-C, which has YES and NO and long method names that document the API well. CoffeeScript is nothing near Obj-C of course in this regard, it's short and sweet but way more readable than JS. I am glad Jeremy decided to keep them; I think it would be very un-CoffeeScript like to have ejected them. This language really has some integrity and that is important.

[STRd6]

I've recently run into wanting to be able to define on and off. In my situation I have functions named on that act like jQuery's on function and I would like to be able to use them in the local namespace. Personally I never use yes/no/on/off as boolean values and would like to see them removed, or at the least able to be assigned in a local context.