Coffee-script expansion feature.

[humanchimp]

I would like to propose that there be a new feature added to coffee-script.

The syntax is ad-hoc. Please focus criticism on the semantics only.

breakfast = ```@tostada```

breakfast = "this.tostada"

Edit:

I will add a slightly-less contrived example. Again, syntax is experimental.

lunch =
"""
#{``@getRandomIngredient()``} with pea tendril salad, toasted hazelnuts, garlic chips, scallions and melon cilantro vinaigrette
"""

lunch = "this.getRandomIngredient() + 'with pea tendril salad, toasted hazelnuts, garlic chips, scallions and melon cilantro vinaigrette'";

[humanchimp]

sorry for the multiple edits. I couldn't preview the edit.

Anyway, this can be used (in less contrived cases) to be able to have a string of javascript available in case you ever need one (those rare cases where you need Function, or eval), but you can write it in coffee-script.

It would take a prelude-free, expressions-only subset of coffee-script, and emit plain js expressions

[davidchambers]

I find the output clearer than the input.

[humanchimp]

(Make sure you reload for the latest edits. I was just tweaking it.)

The basic problem that this aims to solve is, It is uncomfortable to have to "switch languages" mid-stream, in the rare case that you need a static string of javascript.

Also, I have asked that syntax not be the primary focus of the discussion. I am more interested in the semantics, and I am completely open to different syntax ideas.

[davidchambers]

It's rare that one needs to execute JavaScript code stored in a string. Rare cases should not have special syntax.

[jashkenas]

It's rare that one needs to execute JavaScript code stored in a string. Rare cases should not have special syntax.

Couldn't have said it better myself.

[humanchimp]

Ok, that's true.

Except that one of the rare cases you may need to execute javascript from a string is in a template language, and this is where you could leverage the coffee-script compiler to have an embedded coffee-script-expression-based template language which is compiled automatically by the coffee-script compiler.

Ok thanks for closing my issue.

[jashkenas]

where you could leverage the coffee-script compiler to have an embedded coffee-script-expression-based template language

Luckily for you -- the CoffeeScript compiler can be used programatically. Even to implement templating languages! See: https://github.com/sstephenson/eco And many others.

[humanchimp]

The sarcasm is not appreciated, and I was already well aware of several template projects based on coffee-script. The exclamation mark is a bit much, @jashkenas. Also, this was not a high-priority ticket, and it didn't need to be closed so quickly—nothing was on fire as far as I can tell.

[jashkenas]

Apologies -- I felt bad even typing that exclamation mark. I'm afraid I've just been wading through GitHub issues for the past week, probably a several hundred of them ... and I'm beginning to think that they're becoming by far the number one thing that slows down actual development and real work on open-source projects. And I'm at a loss as to what to do about it.

Issues are opened and bumped at a rate that makes it hard to see through the noise for the signal. When you wake up in the morning with 75 fresh issue threads to comment on, each of which requires a few minutes of your time to type out a friendly response + closing of the issue -- but you can't be too friendly, or else the encouragement will engender further discussion which will require further response, it becomes hard to know what to do.

• Attempts to add better instructions to think carefully before opening tickets in the CONTRIBUTING.md file don't help, because folks (naturally) don't read it.
• If you just close the issue without bothering to reply, you're an asshole -- and you still have to read it first.
• If you disable GitHub Issues for the project, you lose a very important source of bug reports, feature ideas, and discussion.
• If you politely ignore issues, and don't close them quickly enough, they fester ... attracting more back-and-forth comments which you then have to read.

Basically what I'm trying to say is that when you open a ticket, it's like emailing each of the maintainers of the project directly and asking them to evaluate and respond to your idea in public. If you have any doubts about whether it meets that bar -- probably better to float the idea on IRC or the mailing list first. Paradoxically, even having a bunch of maintainers to share the work doesn't help much, because in practice everyone needs to (at a minimum) read the opened ticket.

From my perspective, none of the above options are good options. Sorry for the exasperation.

(And FWIW, I don't even mean to use this particular ticket for a soapbox -- there are many far more egregious examples out there -- but wrong place, wrong time.)

[humanchimp]

K I will not open any more feature suggestions here. Thanks for your explanation.

I really like coffee-script, but in corner cases like the above pojs clearly trumps. I've wanted a simple feature like this for a long time. Never submitted an issue requesting it, but now I'm sorry I did. It's clear to me from the tone that something like this is beyond the scope of the coffee-script project, but it seems like the "final frontier" of coffee-script, in my view. There's only so much you can do, especially after brilliant literate coffee-script.

Beyond that, there's nothing really to say. It's a simple idea. I wish it wasn't rejected so hastily.

[hizanberg]

@dfkaye great example of completely missing the point and adding no value to the thread whatsoever, and ironically wasting the time of everyone who bothered to read it all.

[vendethiel]

Hey, hey -- Please calm down a bit. No point in fighting against each other.

[humanchimp]

@jashkenas I just read your edits, and I am completely clear that I am wrong to have put this here. It was definitely not the right forum. I am actually watching coffee-script, and it is a firehose. My bad.

[akloster]

I can feel with @jashkenas on this topic. I was a little irritated in the past with the handling of a certain unnamed bug, but it was mostly my fault for not understanding coffeescript from the documentation rather than the compiler's behavior.

It looks like the adoption of Coffeescript has outgrown its community or at least the community's process. This can't be fixed by outsiders like me. I believe jashkenas will have to delegate some of the work, especially the pre-screening of issues to trusted collaborators.

Coffeescript has thousands of users with Millions of lines of code written in the language. I don't think that it is even possible for someone to be both lead maintainer/programmer/designer and looking at every single issue for much longer.

[vendethiel]

I believe jashkenas will have to delegate some of the work, especially the pre-screening of issues to trusted collaborators.

That's already what others and I try to do by filtering the dups etc

[kanshi]

@jashkenas maybe focus on pull requests and have tickets internal?

The noise ratio will go down, people who have interesting ideas will always be able to email or get in touch on IRC and interactions of the community with the maintainers will be much more constructive.

[dlthomas]

For a really active project, why not have someone dedicated to managing tickets? They don't even have to be a programmer. A friend of mine (who's a musician) got involved in FLOSS that way.

[stefankendall]

Charge for your time, or support. Then you can hire someone to do this.

It's extremely rude of you to not charge a sustainable rate for your services.

[zmthy]

I turned off my maintainer emails just last week, because I was getting emailed every single comment on the Issues page. The first thing I was doing every morning was batch marking at least 20 emails as read. Does anyone know how to set it to email you just for new issues, and not for conversations you're not even involved in?

The problem is that people come straight to the Issues page. The website docs are simultaneously too big and not comprehensive enough, and no-one realises there's a FAQ page in the Wiki that discusses submission of feature proposals. It would be nice if Github would allow us to put a message at the top of the Issues page that links to the FAQ.

[vendethiel]

You can add a CONTRIBUTING.md, which does that, but nothing more afaik.

[michaelficarra]

@zimothy: You can mute conversations in gmail.

[jashkenas]

Speaking of which, in consultation with @michaelficarra ...

@Nami-Doc, congratulations! You've earned your contributor stripes. Feel free to tag tickets and close issues with all due prejudice.

[vendethiel]

Whoaw, thanks.

[michaelficarra]

Congrats, @Nami-Doc! You earned it.

[michaelficarra]

Also, I just wanted to add that I completely agree with @jashkenas on this. We can already use CoffeeScript.compile from within our code. No additional syntax needed.

And @humanchimp, please don't take it personally. We're all just trying to make the decisions that are best for the language and its users.

[nathan-alden-sr]

This issue is one of product management. A sole developer or a small group of developers must act as a product manager if they are trying to give a "professional" feel to the open-source project. It's work that simply must be done. In a for-profit software development shop they obviously hire folks dedicated to that role. The problem is, it's not work a developer wants to do for free. There really isn't a good solution to this problem. Foisting product management responsibilities onto the shoulders of contributors or folks reporting bugs and suggesting features isn't really a solution. Who wants to step up and do the non-glamorous work of product management for free? No one.

[dlthomas]

A) "it's not work a developer wants to do for free"

B) "Who wants to step up and do the non-glamorous work of product management for free? No one."

In a developer-centric project like this one, A => B. In general, however, project management needn't be done by a developer; see my comment above.

On Wed, Mar 20, 2013 at 7:50 AM, Nathan Alden, Sr. <notifications@github.com

wrote:

This issue is one of product management. A sole developer or a small group of developers must act as a product manager if they are trying to give a "professional" feel to the open-source project. It's work that simply must be done. In a for-profit software development shop they obviously hire folks dedicated to that role. The problem is, it's not work a developer wants to do for free. There really isn't a good solution to this problem. Foisting product management responsibilities onto the shoulders of contributors or folks reporting bugs and suggesting features isn't really a solution. Who wants to step up and do the non-glamorous work of product management for free? No one.

— Reply to this email directly or view it on GitHubhttps://github.com/jashkenas/coffee-script/issues/2864#issuecomment-15180035 .

[redchair123]

@jashkenas why not separate coffee-script into a separate organization account and cede maintenance to someone else? In fact, I'd venture to guess there's enough interest that you could set up a CoffeeScript Foundation (akin to the Python Software Foundation), raise funds and explicitly hire someone to handle basic triage and bother you only with really big issues that demand your time.

[vendethiel]

why not separate coffee-script into a separate organization account

Actually, there's a coffee script org already. But moving the repo now would break far too much things relying on it. Github doesn't symlink it

[redchair123]

But moving the repo now would break far too much things relying on it.

Alternatively, disable issues here and redirect people to the coffeescript org's fork just for issues. Do you think that would break others' projects?

Ultimately its the issues which take up @jashkenas's time

On Wed, Mar 20, 2013 at 11:40 AM, Nami-Doc notifications@github.com wrote:

why not separate coffee-script into a separate organization account

Actually, there's a coffee script org already. But moving the repo now would break far too much things relying on it. Github doesn't symlink it

— Reply to this email directly or view it on GitHubhttps://github.com/jashkenas/coffee-script/issues/2864#issuecomment-15183377 .

[michaelficarra]

@Nami-Doc: They do make exceptions for very large projects. https://github.com/ry/node still works. We could always ask them.

[vendethiel]

Oh, I didn't know, thanks @michaelficarra. Then sure

[jackcviers]

This actually sounds like an improvement that github could make. @jashkenas isn't the only one lamenting about the chore of maintenance caused by github projects. @fat gave a whole talk on it once. If we are to stay with the bazaar method of OSS, and use tools like github, then some kind of triage or voting system is needed on the issues page other than :+1: in issue comments.

Lots of votes = more attention from maintainers. Fewer votes = less attention from maintainers.

On the other hand, our internal org uses Trello for issue management. It allows for open debate on issues, scheduling of issues, and multiple stacks allow you to organize issues by priority and severity and even assign maintainers to the issue. Might be worth checking out.

[vendethiel]

I still wonder why github removed the priority thing ? But I approve for "issue moderators". As for using an external tool, I can see several problems 1) this kinda defeats ONE of the purpose of github (edited) 2) you have more things to check (and close issue in) 3) a lot less people would contribute. I heard several time from people using doctrine(php)/jquery that they wouldn't open issues because that meant creating an acc etc. Having every issue board here allows us to be fast "moving around", and I love that. I have around 100 notifications when I wake up (sometimes a bit less) and I can't imagine going to 10 or 15 different sites to check things

[jackcviers]

@Nami-Doc For 2 + 3 -- yeah, I agree with that, though I was thinking an either on gh or on trello for issues, not both. This would make the number of places to check for any one project the same, and the notifications are more or less identical. If your issue isn't important enough to add a free account on the issue reporter's application then the issue is probably moot, anyway.

As far as 1 goes, I don't think issues are the only thing github is good at. It is spectacularly good for commenting on commits and pull requests, and that helps to keep the discussion contextual to the code the comment is discussing. It is also awesome for reading lots of open source code, keeping track of contributors and contributions, and managing pull requests without email patches, and for distributing the work of maintaining a project to several others via forks. I actually think the thing it is poorest at is issue management, and for a large project you might as well use the best tool for all the jobs of a project -- even if it means two separate ones. Forks and spoons are different tools for different use cases. The same is true of repository management and issue management, imho.

[kumavis]

@humanchimp i think the ship has sailed on this one, but for fun I wrote up a helper you could use http://jsbin.com/olufon/1/edit

[humanchimp]

@aerinzero that's a clever use of Function#toString() nice work.

[shesek]

@aerinzero note that returns are not always on the last line.

[kumavis]

@shesek good point. As I was writing that little script out I explored many different user-inputs in my head and realized it would fall down for most of them. Nonetheless I thought I could offer a hint at a solution path for the proposed problem.