CS2 Discussion: Project: Leadership

[carlsmith]

Thanks for putting this together @rattrayalex. The README is a good starting point, and we can use this project to centralise the enthusiasm for an evergreen compiler. Finally going to find out if we can make this happen. Are you putting yourself forward to lead the project, or wanting someone else to?

It would be interesting and really helpful to hear from @jashkenas, @michaelficarra, @lydell, @satyr, @TrevorBurnham and other major contributors.

We can't move forwards until we agree on whether to start a fork or implement a new parser. No one seems to want the responsibility of doing a new parser, mostly because they'll become the de facto lead developer, and will have to maintain the project forever! There's some people who will agree to help out, at least for the foreseeable future, but we need someone who wants to run things.

If we are doing our own parser, then whoever's taking the lead will need to start working on their parser before the rest of us can do much. We need a basic implementation the project lead is happy with, so the rest of us can start adding features to it.

If we're doing a fork, we can all just start submitting PRs that rewrite parts of CoffeeScript to use the latest browser features immediately. We still need some leadership though, to guide the PRs and keep everything together.

I'm happy to commit to helping out, and putting some extra effort into it for a while, but do not want to be in charge. There's not much point bikeshedding Fork vs New Parser until we have a project leader.

Anyone wanna be famous?

[rattrayalex]

Thanks @carlsmith for raising this. Well said.

I have some interest in forking CoffeeScriptRedux and updating that to output a Babel AST. There are a few projects out there (decaffeinate, decaf) that are likely to be helpful in this, and I've been doing investigations on all related parts.

I'd be happy to take on the leadership of getting this off the ground, but it's certainly not my goal to lead it long-term. That said, it's also my goal to not return the project to anyone from the original team unless they're willing to step things up substantially.

I'll take a deeper look in the next couple of days at what it'll take to do what I mentioned above.

If anyone else is interested in taking the lead, or helping lead, do comment here.

[DomVinyard]

We can't move forwards until we agree on whether to start a fork or implement a new parser.

Seems like the fork route is the path of least resistance. Perhaps most importantly, it will help guard against this project morphing into a completely new language - which I fear is likely unless actions are taken to specifically prevent it. I would like to advocate that the idea of CS>CS6 having "breaking changes" should mean 'some projects may break' rather than 'all projects will break'.

[rattrayalex]

@DomVinyard amen.

Thoughts on forking Redux over the original? My general impression was it was rebuilt for greater maintainability, and cursor glances over the codebase reinforce that notion.

Furthermore, I've been disappointed with @jashkenas's leadership and it might be nice for a near-drop-in-replacement to be housed somewhere new.

[carlsmith]

I'm not 100% certain on all the details, but pretty sure that Redux parses its source into a Mozilla AST that escodegen uses, so escodegen can do all the code generation stuff from there for free. That's a nice approach, as we would only need to parse our source into valid Moz AST, and that AST can then be optimised and converted into JS using generic tools. I'm pretty sure escodegen will even generate the source maps for us for free. The problem is that you have no control of code generation, and can never move faster than escodegen.

Anyone know if I've got anything wrong there, or how well escodegen supports the latest JS features?

[carlsmith]

I forgot @rattrayalex mentioned targeting the Babel AST. I thought the original plan was to output ES6 code, and let other tools handle shims and all that. Bit confused on the direction now.

[carlsmith]

Going back to basics, any language is going to be implemented as a pipeline. We need a CoffeeScript lexer and parser that we can extend to support imports and so on, may need some AST transformers, and will need a code generator with support for the target version of JS and source map support.

We can reuse parts or write them, but will need a fronted to create an AST, and a backend to generate JS executables. Unless both ends use the same AST format, we will need a transformation pass to convert the AST.

Optimisation functions should be modular enough that we can worry about them later, so we just need a frontend, a backend and some way of getting them to work together, but I'm not sure if there is an ES6 codegen.

[aurium]

I'm really glad to see this initiative!
What you think about to meet in a Hangout session to talk about the project and slice some initial tasks?

[carlsmith]

I'm up for a Hangout, if we can get everyone together at the same time.

[jashkenas]

Just to roll out the welcome mat — I totally understand the appeal of greenfielding a new implementation in a separate repo. But if you guys want to leverage the folks and issue history already in jashkenas/coffeescript, you would be more than welcome to hack on it over there. The commit bit, whatever you need.

[carlsmith]

Thank you, @jashkenas. Nice one. Cheers.

It would be good to keep everyone and everything as close together as possible. To be honest though, we're still struggling to establish what we're actually looking to do, so don't know how to proceed. There's a growing list of people who want to use CoffeeScript to write ES6 code, and we generally agree that it'll involve breaking changes (if only to switch to using ES6 classes), but that's all we've really established.

I'm not personally bothered whether the compiled JS targets ES6 or ES3, so long as it works well, so would much rather extend CoffeeScript than start again, but don't see a way around a big break for new style classes. The way CoffeeScript handles generators, where you compile to ES6 and leave runtime support to the user, is an ideal compromise, and we can do the same with other features, like imports. It's just features like classes, where CoffeeScript already has them, and they're incompatible with ES6, that it seems like we'll need to make a breaking change.

There are people that want a compiler that generally targets ES6, but I don't see any major advantage there. If it wasn't for classes, then I'd advocate just adding ES6 features to the standard CoffeeScript compiler, and letting them fall through like generators do.

[rattrayalex]

Appreciate that @jashkenas ! We may well take you up on it.

[rattrayalex]

I thought the original plan was to output ES6 code, and let other tools handle shims and all that

I believe Babel is capable of outputting both ES6 code and ES5 code (and if it doesn't yet, it probably will soon so people can use ES7+ features on ES6 platforms like Node and Chrome). So we should be able to use Babel to output the ES6 code.
Furthermore, since many people still compile ES6 to ES5, plugging directly into Babel would save the step of transforming the ES6 output into ES5 separately.
Though, I suppose that could be accomplished with a webpack loader chain, piping first through CS6 and then through Babel.

Otherwise, the primary benefit of integrating with Babel would be the general community.

I think a Hangout is a great idea. Let's set one up for week after next, so we're able to secure time on the calendar and take time to read through related code.

If we can just send PR's to jashkenas/coffeescript to pass-through to ES6 for the core features of classes, imports/exports, fat-arrow functions, and maybe async/await, that might be the simplest way to go. Let's try to come into the conversation with a decent understanding of the codebases at hand: coffeescript, csredux, decaf, decaffeinate, etc. Possibly Bablyon as well.

[rattrayalex]

the fork route ... will help guard against this project morphing into a completely new language

Agreed that this is probably not the right direction for this particular project. I'll modify the Readme to reflect that shortly when I get a chance (PR's welcome too of course)

[JimPanic]

I'd be happy to help out occasionally with certain non-technical and documentation tasks. That depends on clear goals and processes to be defined first, though.

Personally, I would love to see organisation similar to Voxpupuli (former Puppet Community, a loose organization for development, maintenance, release management, etc of Puppet modules).

[rattrayalex]

Great to hear @JimPanic ! Looking forward to your contributions!

Re; Voxpupuli, Can you provide a link that would provide a good intro to the community they were able to set up?

[JimPanic]

@rattrayalex I think their website pretty much lines this out: https://voxpupuli.org/ and https://voxpupuli.org/coc -- edit: this blog post is probably the best intro https://voxpupuli.org/blog/2016/06/10/voxpupuli-opensource-speedtrain/

A proper, inclusive and welcoming CoC is something I would love to see for this project as well. This seems implicitely happening already, but making it explicit and a prerequesite is a good thing to do!

[JimPanic]

This work/PR for the setup of a governance agreement might be of interest as well: voxpupuli/plumbing#45

[DomVinyard]

@rattrayalex

classes, imports/exports, fat-arrow functions, async/await

Seems like a great 'core 4' to get going with.

[rattrayalex]

@DomVinyard 👍 well said. I just opened an issue to discuss this.

[rattrayalex]

@JimPanic wow, that really looks interesting. I don't have time to fully digest right now, but a PR would certainly be welcome – do you feel comfortable making one?

EDIT: I'd like to add that I'm generally wary of imposing structure on a culture before the culture is defined, so if we can keep it bare-bones and explicitly tentative and aspirational to start with, I'd really appreciate that. Core values like inclusiveness are a big 👍 , but specifics like conflict resolution mechanisms might be premature.

[JimPanic]

@rattrayalex Yes, I can do that next week sometime. I will also ask the original authors if it is okay to copy (a lot of) it, but I don't think there will be a problem with that. :)

[rattrayalex]

Terrific, thanks @JimPanic ! Looking forward to it

[nickdima]

Veteran CS user here. What I would like from an evolution of CS is the possibility of having better tooling eg. linters, codmods etc.

[nickdima]

Still having the possibility for compiling CS to ES5 could be good as during the years I found myself using CS in all sort of non-browser environments like QuartzComposer, Max etc. which usually are not up to date with the latest JS version.

[tdsfugal]

Just found this discussion. Thrilled that it is happening, as I have quite a bit of code in CoffeeScript already. I spent the last week trying to get comfortable with converting it all to ES6 and programming with brackets. A CoffeeScript6, or whatever it turns out to be, would be very welcome.

A way to use the ES6 object spread operator for object copying would be very welcome.

ES5:

var fooCopy = Object.assign({}, foo, {}};
var fooBar = Object.assign({}, foo, {
        bar : "some low hurdle"
 });

CS:

fooCopy = Object.assign {}, foo, {}
fooCopy = Object.assign {}, foo, 
      bar : "some low hurdle"

ES6:

let fooCopy = { ...foo}
let fooBar    = { ...foo, bar : "some low hurdle" }

CS6?

fooCopy = { foo...}
fooCopy = { foo..., bar : "some low hurdle" }

[rattrayalex]

Welcome @nickdima and @tdsfugal ! Excited to have you here!

You both shared great thoughts – would you mind opening them as separate issues on this repo? eg; "Linters and Tooling", "ES5 Compatibility", and "Object Copying". I look forward to discussing those topics there.

[carlsmith]

I'm personally against adopting the Voxpupuli Code of Conduct.

Creating a new community with different values (and a slightly liberal agenda) would be a big loss. We have a great little community already. Once you start making explicit rules, people will want them enforcing, and those rules belong in a corporate workplace:

Examples of unacceptable behavior by participants include:
    ...
    Other conduct which could reasonably be considered inappropriate
    in a professional setting

If people want politically correct open source projects, they can join Python Dev :)

[danielbayley]

Voxpupuli Code of Conduct.

Why is this even a thing? Can we just focus on the survival of CoffeeScript please… 😄

[JimPanic]

Good idea! I hope I can also boil this discussion (meaning: also the rest of it ;) ) down into a "governance" description of some sorts later this week.

[JimPanic]

I'd like to reiterate @carlsmith 's comment in #1:

If we work on the basis that concensus means that nobody strongly objects (as it's impossible to get everyone to agree), then the question is really simple...

Does anyone feel strongly against this sentiment? :)

[danielbayley]

just don't be a dick

The golden rule… it's not rocket science.

I assume you're neither of color, nor a woman, nor homosexual, queer, transgender, or in any other way part of a marginalized group in tech and open source.

Well, no… just another whitey. I won’t feel guilty about it though.

I'm bothered by the idea that black people, gays, women and transexuals are underrepresented because there is something wrong with the values of the open source community.

Same.

It's a very meritocratic community, and if a group is underrepresented here, that is entirely due to external factors, and not something that can be addressed by affirmative action within our community.

I do think there can be a tendency to try and swing the pendulum too far the other way with some of these causes like sometimes with feminism as @carlsmith alluded to. I totally want to see more females in tech for example but no ‘group’ should be getting special treatment. Equality means equality. One of the most attractive aspects of tech is it’s generally meritocratic nature.

a progressive agenda

True progress would be when no such nonsense actually matters to anyone… but yeah, we don’t live in that world.

Ironically, wouldn't queer qualify as a bit offensive in some quarters @JimPanic? 😄

[JimPanic]

I think we have talked about agendas enough in this thread and I have made my point of view quite clear, so I will not take part in any further discussions here. I will ask my friends identifying as queer if it offends them. I'm pretty sure that's what some people identify as, but I will check back to be sure. If you have any feedback regarding the proposed CoC, please leave a comment in the PR! Keep in mind that I don't have any agenda besides having a CoC, as stated a few comments earlier.

[rattrayalex]

I'm 99% positive we've veered pretty far off topic here. Can we wait to discuss this stuff on an upcoming PR?

[JimPanic]

The CoC already has a PR in this project: #14

Please continue there for further discussion!

I will create another PR for our "governance" document.

[mrmowgli]

Yes indeed, this thread got hijacked. I'm of the mind that we should start with a full survey of ES6 fixtures, and how if at all there should be any direct Coffeescript equivalent.

https://kangax.github.io/compat-table/es6/

In addition, there are some things which are terribly inconsistent in the ES6 implementation, so perhaps another survey of pain points from people porting from ES4. As Douglas Crockford once mentioned with the ES6 aspects, the good bits are much better, but the bad bits are still there.

I also have too many projects done in Coffeescript to just roll over and rewrite all of my code. So perhaps the original Coffeescript language stays a priority and the line of thinking that originally created a particular feature is extended to the Coffreescript6 world?

[carlsmith]

As Douglas Crockford once mentioned with the ES6 aspects, the good bits are much better, but the bad bits are still there.

There are even more now :(

[danielbayley]

the good bits are much better, but the bad bits are still there.

It’s a half assed version of and poor substitute for CoffeeScript IMO…

[rattrayalex]

I'm of the mind that we should start with a full survey of ES6 fixtures, and how if at all there should be any direct Coffeescript equivalent.
https://kangax.github.io/compat-table/es6/

That sounds like a good idea to me, albeit a lot of work (and difficult to approach with a simple github thread). @mrmowgli any ideas on how we could move forward? Google sheet, markdown table in this repo with pull requests, a single github issue, several github issues... ?

[danielbayley]

markdown table in this repo with pull requests

I think this approach would work best. What about something like ZenHub also?

[rattrayalex]

Cool, I'll shoot for the markdown table. If anyone would like to submit a PR to create the skeleton it'd be much appreciated!

ZenHub would create a (slight) barrier to entry for the project that I'd rather avoid (installing a chrome extension). Good idea though, and worth considering in the future.

[danielbayley]

I don’t actually use Chrome, but they plan on releasing a Safari extension soon also. But yeah, maybe one for the future…

[GeoffreyBooth]

Getting back to the discussion on leadership: I haven't had much if any interaction with @jashkenas, so I have nothing against him, but it makes me nervous that he could unilaterally shut down new features, for example if he refuses to support ES2015 classes because it requires a new flag (and he hates flags). We should come up with a proposal for an alternative leadership structure to the one-person benevolent dictator.

How about a simple committee of the current core contributors, plus a few of the most-active people from the coffeescript6-discuss repo? That way we balance contributors with users/people passionate about CoffeeScript. Each member of the committee would have one vote, and design issues are settled by committee votes. New members of the committee would be by invitation, and/or automatic upon successful merging in of a significant pull request.

This committee would also give us a good structure for deciding how to implement new features. For example, classes. It would be more efficient to agree on a syntax and technical design before anyone attempts a PR, and if the design is blessed by an official committee ahead of time then whoever does the work doesn’t have to worry that their efforts will be rejected later. Especially if those efforts involve creating a new flag.

[Tatsh]

I disagree. I do not like the concept of committees. There is always the in-crowd (people who get to actually have say) and the out-crowd who do not get attention. Almost always the in-crowd's commits and comments get favouritism over outsiders. If you have a committee, isn't that just a benevolent group of dictators? How is that better?

IMHO the only fair system is where everyone's commit/PR/comment is treated the same. I felt like I was treated fairly when I committed a change to Joyent's http-parser project, and they had never ever heard of me before (I followed all of their rules especially with regards to code). That is how I'd like to see most projects go.

[rattrayalex]

everyone's commit/PR/comment is treated the same

I think the question is, who gets final say over which PR's are accepted?

My impression from following along the jashkenas/coffeescript project is that PR's from outsiders are always welcomed with open arms, and proposals from insiders are often rejected. I don't think the current leadership has an insider/outsider bias. It's just that sometimes people disagree about the best direction, which is a hard problem to solve.

[Tatsh]

Then there has to be a hard set of guidelines regarding the future of the language. Things like no BC breaking syntax changes, like how in Iced CS there is await but it is part of a subset and it does not break existing code. Another thing might be to have people representing these interests so a committee is not trying to become a hive mind. A committee seems okay if the people on it represent agreed guidelines and keeps things in check.

[rattrayalex]

Hmm. I personally do not see a need for either hard rules or a committee at this point in time.

Ultimately all we're doing here is planning and building PR's to send to jashkenas/coffeescript right now.

We may also create some kind of alternative repo, eg coffeescript/coffeescript, possibly with a substantial rewrite/refactor, which may benefit from a more well-defined leadership structure. But we can probably cross that bridge when we come to it, and jashkenas will probably need to be central to that conversation.

tl;dr, I personally think a "Do-ocracy" is largely sufficient for now, with a loose understanding that @GeoffreyBooth is at the helm of this effort for now.

[GeoffreyBooth]

My concern is that @jashkenas effectively has veto power over anything we want to propose. Not that I don’t trust him to make the right decisions or respect the will of the crowd, but such a concentration of power makes me nervous. What if our consensus on let/const is to add support somehow? He’s already on record (years ago, admittedly) as opposing those features.

It’s also a concern for people proposing PRs. Building modules support took dozens of hours of effort. Classes will probably be similar. It’s not fair to the people donating their time that they get no guarantees that their work will be accepted. Just look at the PR for await, which has been languishing since 2014.

Committees have their own warts, but they’re better than benevolent dictators.

[GeoffreyBooth]

I asked @jashkenas about this, and he said he trusted the people with commit privileges on https://github.com/jashkenas/coffeescript to act as a committee to make official decisions. He then invited me to become a committer 😉 Anyway, since I seem to be the only one concerned about this, I guess I’ll close this unless anyone wants to propose an alternative system.

[coffeescriptbot]

Migrated to jashkenas/coffeescript#4902