CS2 Discussion: Project: Leadership

[coffeescriptbot]

From @carlsmith on July 11, 2016 21:47

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?

Copied from original issue: coffeescript6/discuss#3

[coffeescriptbot]

From @rattrayalex on July 12, 2016 4:49

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.

[coffeescriptbot]

From @DomVinyard on July 12, 2016 12:14

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

[coffeescriptbot]

From @rattrayalex on July 12, 2016 16:26

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

[coffeescriptbot]

From @carlsmith on July 12, 2016 22:32

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?

[coffeescriptbot]

From @carlsmith on July 12, 2016 22:56

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.

[coffeescriptbot]

From @carlsmith on July 12, 2016 23:9

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.

[coffeescriptbot]

From @aurium on July 13, 2016 3:14

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?

[coffeescriptbot]

From @carlsmith on July 14, 2016 13:21

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

[coffeescriptbot]

From @jashkenas on July 14, 2016 16:35

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.

[coffeescriptbot]

From @carlsmith on July 14, 2016 17:12

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.

[coffeescriptbot]

From @rattrayalex on July 14, 2016 19:45

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

[coffeescriptbot]

From @rattrayalex on July 14, 2016 20:5

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.

[coffeescriptbot]

From @rattrayalex on July 14, 2016 20:7

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)

[coffeescriptbot]

From @JimPanic on July 19, 2016 8:46

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