-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove features #207
Comments
There are at least a few ways to approach this: Ambiguity / Redundancy / Developer confusionFeatures that--were coco mainstream--would appear in a "fractal of bad design"-type blog post. It's hard to be objective here, but some of my opinions are:
Developer disuse / Compiler complexityFeatures that require an inordinate amount of compiler complexity for their actual utility. To avoid subjective feelings about usage, it'd be cool to get metrics through some sort of AST walk--though some of the features only exist in the lexer, so adding a ES6 / Harmony compatibilityFeatures that either conflict with the new harmony proposals or have different syntax / semantics than the equivalent harmony version:
|
Going again through the additions's page, what I don't use. All these totally objective. To add more after @qqueue : (I actually do use |
Yeah,
"but procedure." I kinda like this joke.
Bang-call came later and became surprisingly popular. Not really a loss since in this case you can't omit the parens when you have an argument:
I have a feeling that it might never get going at this rate, just like Perl6. |
Ha. Well, in the same vein as
There should be a separate issue for "What to do with
Cute, but I still don't like the
I suppose so. I don't feel as strongly about it as I do about the others.
Even if it's a long way from completion as a whole, the proposals themselves have a lot of discussion under them as well as partial specs and implementation. Plus, the goal of "respect[ing] JS semantics and idioms" means we're going to have to choose between ES6 and coco legacy eventually. |
Two jokes in one answer, ha!
There are several points I don't agree with ES6 on, especially array comprehension and that are probably going to conflicts but before we can actually use them in prod (and I'm not talking about big companies making you support oldIE), let's hope things will have moved in some way. Which one is the question
That seems too opaque for me. Not sure what to suggest here.
using @satyr's old cokebench code, slightly modified https://gist.github.com/Nami-Doc/5165531 Unjoined interp also seems useless to me ( |
A place to discuss feature removal in general, as per gkz/LiveScript#219
The text was updated successfully, but these errors were encountered: