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.

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

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.

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.

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