CS2 Discussion: Question: Who has time to code? #4924
Comments
|
From @mrmowgli on 2016-08-23 01:56 I have to say, I would love to help but I'm worried the ramp up time for just the parsers might be too much. I've never worked on any of the compilers, although I am interested. I imagine this could be a little rough since the documentation and language status information isn't really there. |
|
From @aurium on 2016-08-23 18:47 I believe most people don't have enough time for hard work, but if we split the project in small well defined pieces with low coupling, we all could do i great. I don't have enough knowledge in language compilation/translation, but i can work on something, sure. |
|
From @carlsmith on 2016-08-24 15:36 I have some time. I'm working on my mum's Rotary Club website this week, and have two projects already, so I don't want to commit to anything major, but I generally have time to work on this, and could put in 5-15 hours a week or something. I'd be up for writing a parser. Vaughan Pratt is a genius, and his TDOP parsing makes it easy to do, but so few people get it that it makes the people that do know the algorithm look smarter than they are. It's actually easy to understand. What puts me off, is all the preprocessing to insert implicit braces and so on. If we had a way of inserting all the implicit brackets and braces into CoffeeScript source (maybe reuse code from Official or Redux), I'd be happy to take it from there, and generate a Babel AST. I'm confident I could do that. It's a lot of work though, if it's all on a prayer. It's tempting, but daunting. Hmm. |
|
From @lydell on 2016-08-25 05:43
@carlsmith Doesn't it make more sense to write a parser that outputs a CoffeeScript AST, and then write a compiler that takes CoffeeScript AST as input and outputs a JavaScript AST (such as the Babel AST), and then feed that JavaScript AST to a JavaScript code generator (like Babel). (This is how Redux works.) |
|
From @JimPanic on 2016-08-25 14:40 At the moment I'm quite full with an upcoming move (still searching…blergh) and some other private things. But if there is something specific to do that doesn't require days of studying beforehand (refactoring for example), I'm happy to lend a hand and invest a few hours per week. Sometimes maybe even more when I got my head free from other stuff. Right now I'm also busy getting to know a wide variety of systems at my new job and getting up to speed with everything. I still hope we can assemble a group of people with special interest in a few areas of the compiler, insight and a little bit of time to actually influence the development. Because I don't think anyone participating so far is a lone wolf. :) |
|
From @carlsmith on 2016-08-25 15:23 @lydell - yep, on reflection, you're right. I was thinking to try and do tokens -> JS AST in a single pass for efficiency, but it might get messy in places, and having a source -> tokens -> CS AST -> Babel AST -> Babel pipeline would give users access to a proper CS AST, which some are going to want. |
|
From @carlsmith on 2016-08-25 16:30 @JimPanic - reckon we're all just glad to know you're on board chap. Good luck at your new place. |
|
From @rdeforest on 2016-08-27 02:20 I'm interested in participating in this... thing? And I'd like to campaign a bit. Caveat: I've been drinking and I Have Opinions (tm) "Who actually has time to code?"
Against what clock? What is the bar or threshold here? What is "enough?" What is the opportunity cost at risk? If by some fluke the answer to the question is "nobody" (and who would post that?) what should we be doing instead and why? What's the problem here? Even if "nobody has time", why make an issue of it? If nobody has time, they won't participate in the discussion of coffeescript6/discuss#27, and if they DO have time (as I am devoting now), they will waste it on the question which is answered in the negative by the fact that they posted on this issue at all. If we all (whoever is reading this now or in the future) produce a CS6, CS2, CS 1.11 or CS 1.10.1, issue coffeescript6/discuss#27 will not have helped us do so, and if we don't produce anything, issue coffeescript6/discuss#27 might be a reason why. It feels to me like @GeoffreyBooth is putting all potential collaborators on the spot and demanding a commitment form them when no such commitment is required, now or ever. DiscouragingI came to this issue from coffeescript6/discuss#4 where @GeoffreyBooth commented after a post of mine with
So someone (me) who had time to post was essentially told not to bother because "we" might not "have" people "willing" to "devote" time to this project. All or Nothing != progressWe don't have to make The Next CoffeeScript in one go. On the contrary, we don't have to do anything. We get to make incremental improvements either by having our changes accepted upstream, or by offering an alternative which is clearly superior in some way. It doesn't have to be a complete solution. We could solve any single problem identified by this project and that would be progress. That is how most progress happens. "Rome wasn't built in a day", and Apollo 11 wasn't the first flight of the Apollo program. For that matter, the Apollo program was based on the work in the Gemini program as well as all the work preceding it including Newton's refinement of our understandings of math and physics, and innumerable contributions before. ConclusionWhat is the success condition of this issue? What would resolve it? A list of people "devoted" to the CS2/CS6/CSnext "cause"? This isn't a religion, it's something people clearly want to collaborate on. Therefore, I propose resolving this issue as irrelevant. If we have time to code, we'll code. If not, this issue won't help anyway. |
|
From @GeoffreyBooth on 2016-08-27 03:14 @rdeforest the point of this issue was to gauge interest and to start to assemble a team. It matters whether the team has a lot of time to devote or a little, because that is the primary factor driving the first major technical decision: whether to improve the existing compiler or create a new one. I for one don't want to commit to building a new compiler, even one built from Redux, if we can't get it at least as good as the current compiler within six months. That's because for me the compiler is a solution to a problem—arresting the decline of CoffeeScript—and not an end in itself. |
|
From @DomVinyard on 2016-08-27 14:55 Agreed, no need to take offence, dude was just trying to whip up a bit of organisational spirit in the group. A little motivation sometimes goes a long way. On topic, I am very interested in this language, a lover of this language but I know nothing of language design. I have begun to educate myself and hopefully be able to contribute at a later stage. |
|
From @rdeforest on 2016-08-27 21:46 I apologize. I shouldn't post about things I care about while intoxicated. However, I stand by my original objection. I do not see value in keeping issue coffeescript6/discuss#27 open. I will support this further now by responding point-by-point to the two responses above.
There's already issue coffeescript6/discuss#3 for that. Also, there's already a team forming. When it gets too big to continue organically that will be the time to add structure. Until then, the work is more important.
B does not follow from A. The merits of a decision between improve CS, improve CSR, start from scratch and two or more of these options is not functionally impacted by how interested people are. One person could pursue all three or 100 people could focus on just one. The decision will be made by the people who actually perform the work.
Fair point and I do regret that the tone of my posts is unpleasant.
The project already has plenty of spirit and I object to his methods. Some examples:
And now I'm going to lead by example by ignoring the rest of this thread and focusing on the Pratt parsing thing carlsmith linked to so I can contribute something. |
|
From @carlsmith on 2016-08-28 02:03 @rdeforest - You seem to have misunderstood the situation. CoffeeScript is in decline. Adoption has been falling for a while, and is likely to lead to the death of CoffeeScript if not arrested soon. The whole point of this community is to figure out the best way to turn the decline around, and then do it. There is no exact deadline, but there is urgency. The longer it takes, the less likely it is to work. We don't want to aim too high and fail, nor aim too low and miss an opportunity to do more. The only resource we need to try and quantify is labour, so it made perfect sense when I saw @GeoffreyBooth was trying to establish how much time people have to give. You've obviously not followed this conversation very closely, so just take it from someone who has: No one has any problem with what @GeoffreyBooth has done here, and to be totally honest, no one really cares about the points you made either. On the other hand, we'd be grateful for your help, so let's just forget this misunderstanding, and get back to the problem at hand. Sorry to be so blunt, but you seem like someone who'll just take it on the chin, so welcome aboard, and thanks for pitching in. Maybe just keep your drinking and your criticism of other people in open source separate going forward ;) |
|
From @rattrayalex on 2016-08-28 03:40
Thank you. @GeoffreyBooth , your question and comments seemed very reasonable to me. I fully support gauging interest in contributions from the community. |
|
From @GeoffreyBooth on 2016-08-28 20:26 There will always be people interested in different goals. Some people were drawn to this project because they’re excited by the challenge of creating a new parser, and/or of parsing CoffeeScript into full ES2015, or other things. I encourage those efforts, and I wrote a README that includes those goals; but it also lays out the priorities as I saw them, of adding modules and classes support to CoffeeScript first, before moving on to tackling any of these other, larger goals. In no way am I trying to dictate my preferences on the community; my proposal is now the README only because I was the only one to take the time to write a proposal. Others made comments on it, and I incorporated those comments; and everyone is encouraged to open pull requests against the README if you disagree with anything written there. There seems to be remarkable consensus in what we’re trying to achieve: support for vital ESNext features in CoffeeScript, and ESNext output from the CoffeeScript compiler. I understand that people are more excited by the technical challenge of the latter. I’ve been encouraging the community to prioritize the former, though, because I think we will do more good for more people (and therefore, strengthen the CoffeeScript community and the language itself) the sooner we can get vital ESNext features supported by the language. People who aren’t interested in that effort, of course, can skip it and focus entirely on the new compiler. If we have lots of people willing to contribute, we certainly don’t need everyone working on classes; some can go straight to working on the new compiler. For that effort, though, I think we can all agree that we should try to reach consensus as the best approach (such as choosing which compiler to start from, or if we’re building one from scratch, how) in order to avoid duplicating effort. While it may be fun for people to toil in individual efforts at crafting their own custom parsers and compilers, I think we’re most likely to create something useful—e.g., a new CoffeeScript compiler that supports current syntax and adds new features and outputs ESNext—if we work together. I think the Redux project stands as stark proof of what can happen when people’s ambitions outweigh their resources. I would consider it a wasted opportunity if many of us came together to solve the “CoffeeScript in an ESNext world” problem, and all we manage to produce is another half-finished compiler. So how about this: I’ll go through the issues in this repo that relate to new ES features (classes, Along those lines, outputting ESNext can be broken down into smaller features: outputting |
|
From @lydell on 2016-08-29 05:10 @GeoffreyBooth I think you pretty much nailed it regarding the needed workflow with your above comment. 👍 |
|
From @JimPanic on 2016-08-29 19:18 If you find time to do that, it would be awesome, @GeoffreyBooth! |
|
From @GeoffreyBooth on 2016-09-01 06:36 I will find time to do that 🙏 but in the meantime, it seems like we’re shaping into two teams:
These two efforts can proceed in parallel. Who wants to be on which team (or both teams)? The “current compiler” team can easily divide up tasks, for example one person or group working on classes and another on |
|
From @carlsmith on 2016-09-07 07:16 I've had some health issues, even spent a day in hospital, but it's nothing serious, and I'm keen to contribute still. I'll mostly focus on the new compiler. It'll not be for a couple of weeks though. I've followed the discussion, and am really pleased to see how well it's going. Huge respect to you all. |
|
From @carlsmith on 2016-09-07 07:19 Just to be clear, I'm totally fine. Just been unwell and that made me even more lazy than usual. Be back soon, and happy to help whoever has started on a new compiler, else have a crack at it myself. |
|
From @GeoffreyBooth on 2016-09-07 07:32 Great to hear @carlsmith! Would you like to take the lead on organizing the new-compiler effort? I suggested some starting points here in #25. At least post over there with what you plan to do, to see if anyone else has already done it or is working on something similar. |
|
From @carlsmith on 2016-09-07 08:06 Yeah, sure. I'll look at it today, and add something there. If anyone else wants to make a start before me, I'm happy to join their effort - just don't want to hold anything up. Still, it looks like I'm going to be the one to lead that side of things, which is cool. I'm totally happy doing that. No problem. Looking forward to it actually. |
|
From @lydell on 2016-09-07 08:36 @carlsmith Will you attempt to replace "just" the lexer+parser, or everything? Just wondering what you're planning :) |
|
From @carlsmith on 2016-09-07 09:35 I'm not too sure to be honest. The problem that I need to look into is inferring all the implicit parens and so on. I assume the other parsers preprocess the source?? May reuse their code, or do something else. That's the part that I'm really unclear about. Beyond that, I'd be looking to do the lexer and parser from scratch, and will need to transform the CS AST to a Babylon AST, so we can use Babel for code generation (and get free support for plugins), so we will at least have a new lexer, parser and CS to Babylon AST transformer. Any advice on infering brackets etc. would be appreciated. I'm also a little unclear on how to distinguish between One big-picture question is whether we want to deviate from official CS, as Redux does, especially if we're dropping BC on classes already. That's definitely something we should decide as a community. |
|
From @lydell on 2016-09-07 10:41
jashkenas/coffeescript: No preprocessor. This is what it does:
The reason the Rewriter exists is because nobody has been able to be able to write a Jison grammar that handles the implicit parentheses and braces stuff. Redux: Has a preprocessor, but for a completely different reason. This is what is done:
The reason for the insertions of the control characters is because PEG.js can’t handle significant indentation. My adivice: Pick a parsing strategy that can handle CoffeeScript’s grammar without hacks. Forget about “infering brackets etc.” – write a parser that handles CoffeeScript’s grammar directly, like Redux.
So you’re basically saying that you are going to rewrite everything. Here’s a comment I wrote in another issue that I think you’ll be interested in: coffeescript6/discuss#25 (comment)
Then we’ll end up with another Redux.
What does that mean? |
|
From @carlsmith on 2016-09-07 11:52 Thanks @lydell. Appreciated. I knew you'd know, but didn't want to ask you to do my homework for me. I saw your comment on coffeescript6/discuss#25, an just reread it. As I understand it, we will be extending the current compiler in line with your suggestions, and then, in parallel, doing a new compiler from scratch. Your approach is the most sensible and is what we're hoping will turn CoffeeScript adoption around in the near term. The new compiler is more ambitious (and less urgent), and its goal is to eventually give us a fast, handwritten parser that is easy to extend, and potentially better at things like syntax error reporting.
Sorry. I was on my phone. Any compiler that drops backwards compatibility (BC) to make classes compile to ES6 will not compile tons of existing CS code correctly. If people have to use the old compiler for existing code, and can only use the new compiler on new projects, then we have a rare chance to make breaking changes without too much cost. This is true whether we do a whole new compiler, or just add a flag to the existing one. It's still effectively two incompatible compilers. Breaking changes will mess with any existing documentation, from books to blog posts, but we can still use the old libraries, as it all compiles to JavaScript anyway. It's not like Python 2 to 3, where they have to port the entire ecosystem. I'm not personally advocating any breaking changes, but wanted to ask the community if they think we should make any. No urgency here. I just didn't want to make that call for everyone else.
You're right, of course. There's no point doing a new compiler unless its implementation is a significant improvement on what we have. Parsing indentation will be trivial in a handwritten lexer, but how would you handle implicit invocations? The parser will know when it has two adjacent expressions, and can treat the first expression as the function, and everything after as its args, but handling operator precedence could then be an issue. For example, Maybe I just need to think about it more, but I've currently got no idea how to handle implicit parens. |
|
From @lydell on 2016-09-07 12:24 Just to clarify on classes: The most recent suggestion is to keep |
|
From @carlsmith on 2016-09-07 14:34 I hadn't seen that. It makes sense if you only want to bring ES6 features to existing codebases, but generally, it's a mess that I expect will harm adoption as much as it'll help it. Surely, the new compiler should be CS2 then?? Not much point building another compiler for a version of the language that's begging to be replaced. Obviously, the new compiler would then drop old classes, and use If we're doing a new version of the language, we should use a new extension, so people can have CS1 and CS2 modules in the same project. |
|
From @DomVinyard on 2016-09-07 14:43 I am convinced that If we needed a new keyword which would break a few projects but not most, I still think there is a case for Easy to reason about too.. old style classes, lowercase c / new style classes, uppercase C. Not elegant, sure. But a whole lot more CSy than a two-letter prefix. |
|
From @GeoffreyBooth on 2016-09-07 14:50 I think backwards compatibility should be maintained if at all possible. CoffeeScript is struggling enough nowadays, we don't want to make things worse. It will only get harder in the future. I thought the point of creating a new compiler was to output ESNext code for all features, and provide us with a better codebase for improving the compiler. I would encourage breaking changes to be very few and far between; maybe a few to align CoffeeScript with ESNext like making desctructuring assignment, splats and fat arrows behave identically, things like that, but even those should be debated for what such a change would mean. For something as big and widely used as classes, I would keep both |
|
From @carlsmith on 2016-09-08 00:39 I don't know. That makes sense, yeah, but still. I'm not sure it's worth starting now on a new compiler for a language that has already grown crufty. You guys are doing a really awesome job of patching the current compiler to bring ES6 to existing codebases, but the language is not really "a little language that compiles into JavaScript" anymore. It got pretty big, and then started to get complicated. Having to learn two different class models is bound to put people off adopting CoffeeScript. Seems better for a new compiler to implement a new version of CoffeeScript that is redesigned from scratch based on everything we've learned, even if that is a long shot. Otherwise, we'll never fix the mess ES6 made when it nuked CoffeeScript. |
|
From @GeoffreyBooth on 2016-09-08 01:06 An essential part of any language is popularity. In an open-source or corporate environment, choosing CoffeeScript for a project is reasonable but still an uphill climb: you must convince all the developers to code in it, management that it's stable and that there are enough resources out there to get you through any difficulties. Such an argument is doable for CoffeeScript and TypeScript, but probably few if any other compile-to-JS languages out there. And it's a Catch-22: any new language will struggle to get widely adopted without a community and resources, which it can't get until it's widely adopted. With ES2015’s popularity I don't think we can afford to splinter the CoffeeScript community. ESNext output isn't such a killer feature, in my opinion, that people will rush to refactor their old Coffee codebases into a massively-breaks-compatibility CS2. That means that CoffeeScript 1.x would linger on, and there would be a division within the community, and ultimately even fewer resources for each branch. Then our overall problem of adoption gets worse. All languages grow crufty over time. Look at JavaScript ;) |
|
From @DomVinyard on 2016-09-08 12:13
2016, agree for TypeScript, not for Coffee |
|
From @rattrayalex on 2016-09-09 16:03 It's getting harder for Coffee by the day, but it still has a better chance to win the "convince your manager" challenge than almost any other compile-to-js lang. It's still the Rails default, for example. Fun fact, a colleague at my employer (a tech-industry recruiting firm called Hired) recently ran a cluster analysis of languages and frameworks as the appear on resumes and/or job descriptions, and "coffeescript" is now more associated with Rails than anything in the JavaScript world. |
|
From @danielbayley on 2016-09-09 19:54
}]));😠😞😢😭 |
|
From @DomVinyard on 2016-09-09 21:41
It would take a brave manager I think. @GeoffreyBooth Booth, @JimPanic I get your thumbs-downs but it's important to be realistic. I couldn't recommend a new team begin a medium sized project tomorrow using Coffeescript. Could you? |
|
From @GeoffreyBooth on 2016-09-09 22:06 @DomVinyard Of course I could. I built www.jurassicworld.com last year with a team of five developers all writing CoffeeScript. I’m building a medium-sized Meteor app this fall using CoffeeScript. I’m still absolutely convinced that CoffeeScript is better for teams, in particular that the existential operator and significant whitespace (among other features) help prevent a lot of bugs. More to the point though I don’t appreciate negativity about CoffeeScript’s future in this forum. We’re all here because we want to make CoffeeScript better, and make it a no-brainer why it should be chosen for a project, rather than a persuasion. I would prefer we all focus on that goal, with the expectation that it is achievable. |
|
From @greghuc on 2016-09-10 08:23 So I'll bring up my main (negative?) concern regarding Coffeescript, in the interests of it being addressed in Coffeescript next-gen. My main concern is maintainability. I'm working on a long-term, medium-sized project in Coffeescript. If the project still exists in 5 years, will Coffeescript still function correctly? For the first time, I'm seeing cracks in Coffeescript that have made me doubt this: I came here after finding tagged template literals were broken. To confidently recommend use of Coffescript in a long-term, medium-size project, I'd like maintainability to be a top priority. This means that Javascript + Coffeescript must always interoperate. With my pragmatic 'maintainability hat' on, Coffeescript-nextgen priorities therefore fall out as:
I'm surprised that maintainability hasn't come up more in Coffeescript-nextgen discussions. Most of the active issues are about adding ES6 features to CS: const, classes, etc. With a 'maintainability hat' on, these are lowest priority. So are current discussions reflecting the views of developers/teams with mature Coffeescript projects in active development, who are thinking about long-term substainability? |
|
From @greghuc on 2016-09-10 11:22 In the interests of not polluting this issue, I've just created Survey for devs/teams with maintained Coffescript codebases: happy with CS, or considering migrating? |
|
From @mrmowgli on 2016-09-10 11:35 @greghuc As far as I can tell there is a concerted effort to be backwards compatible in our choices to avoid breaking changes, but you are right. Whatever comes out of this will most likely need long term commitment, either by this group or the owner of our updates and pull requests, most likely jashkenas. This topic deserves it's own thread. You should probably create a new issue and start a conversation about it there. |
From @GeoffreyBooth on 2016-08-23 01:35
The ambitions of this project must be weighed against our resources, namely, how many hours people have to commit to development. If we have lots of people with lots of time, the sky’s the limit: we can start with either compiler or even create a new one, and implement every possible feature. If our resources are just me, well, we’ll hopefully get modules and maybe classes in the current compiler, and I don’t know how much more I’ll have time for. Hopefully we have more than just me, and we can not only add a few missing ESNext features to CoffeeScript but also start to modernize its output and maybe improve its internals.
If you have time to work on the CoffeeScript compiler in the next few weeks or months, please comment below with what kind of commitment you can make (e.g. x hours per week, etc.). Also please note if you have any prior experience with the CoffeeScript compiler or its derivatives (Redux, decaffeinate).
The text was updated successfully, but these errors were encountered: