Re-add support for Solidity

[dradetsky]

I actually agree completely with the description of Solidity as a "Language related to pyramid schemes." However, I think the decision to remove it was a mistake.

0. I could be wrong, but it appears to me that the change was not made by PR or involving a discussion with other contributors or users who may be impacted by the change, but by @jneen pushing straight to master. This is undesirable in general.
1. As a programmer, I have a bias towards all languages being highlighted. Even languages I dislike. Please retain support for PHP highlighting. (vomits)
2. As a programmer who may wish to write articles critical of the cryptocurrency clusterfuck, I may wish to discuss Solidity and illustrate those discussions with code snippets. I would like those snippets to be highlighted for the benefit of my readers, so that they may have an easier time understanding why cryptocurrency is such utter shit.
3. As a programmer/human, I dislike the practice of expressing our disapproval of some thing by token gestures, especially those which may have unforeseen consequences (such as removing syntax highlighting from my article about how shit smart contracts are). It's not like you have the opportunity to remove the ability to compute SCRYPT on all GPUs at the firmware level here or anything like that.

If this change was made because retaining support for Solidity required substantial maintenance effort (I note it was bundled with dropping 2.7 support) by people who think Solidity is stupid, that's totally fine. But that should have been made clear, and notice sent out to those who think that Solidity is not stupid to please consider contributing fixes. If on the other hand the change was made simply because a maintainer disapproves of cryptocurrency, I think this is a mistake. Fortunately, git makes it easy to fix mistakes of this kind.

[jneen]

Counterpoint: no.

[jneen]

I and the other maintainers have no obligation to support any particular language, and there is a well-documented API for private extensions that you are welcome to use. I have used it many times for private languages that are not supported in core. Heck, you could even release a plugin as a gem if you wanted, I am literally powerless to stop you.

[dradetsky]

@jneen I'm not suggesting you have an obligation to support any particular language. This is why I said the thing about maintenance cost & 2.7 deprecation. Seriously, did you actually read the issue & the reasoning, or did you just see what the request was for and skip to saying no? If so, I would ask that you please actually read it & tell me why you disagree. So far, the only explanation that I can see (I searched issues/PRs for solidity to see if this was discussed) for removing Solidity is that it is "related to pyramid schemes." As I said, I agree with this, and think you ought to keep it anyway. Maybe there's some reason why I'm wrong about this (such as the one I suggested), but why not just tell me? Explaining your reasoning could be useful. Maybe I would learn something.

This project has adopted a code of conduct which makes certain demands of the participants. Among those are professionalism & respect for differing viewpoints. I don't think you're doing either of those things. Not because you aren't following my suggestions, but because you're responding to them in a disrespectful way.

[dradetsky]

To test my theory about this being related to maintenance cost or the 2.7 deprecation, I checked the git history to see if any maintenance had been done. As far as I can tell, since the original PR which added Solidity, no additional work has been done. I had already seen from the issue/PR search that there had been no history of dealing with Solidity issues. I next checked whether maintenance was required to keep Solidity working alongside other changes (since there had presumably been potentially-breaking API changes). So I reverted 045d7bcaebae7992f77c69bad4a6fe4a41652422 in my local clone and ran tests, which passed successfully.

I admit that this does not cover every possibility w/r/t there being a maintenance cost, but it at least suggests to me that there isn't. Indeed, most languages have not been touched for years.

[dradetsky]

@tancnle can I get a 3rd opinion on this?

[jneen]

It is not related to maintenance cost. Are you aware of the API for private extensions?

[jneen]

You are welcome to do the following in your ruby project if you wish to have Solidity highlighting:

# some-file.rb

class Solidity < Rouge::RegexLexer
  tag 'solidity'
  # paste in the solidity lexer
end

I am not stopping you from using highlighting, but having the lexer in core lends legitimacy to the project. As per my original comment, this is not a topic that is open to discussion. Re the code of conduct: please remain professional on this point and do not attempt to further spam the project on this topic.

[dradetsky]

Are you aware of the API for private extensions?

Yes, you mentioned it earlier.

I am not stopping you from using highlighting

No, but you are increasing the complexity of having highlighting for certain users & languages. Which would be understandable if the project's approach was to keep the core extremely small and have most languages (or perhaps all languages) implemented as plugin gems, but it isn't.

having the lexer in core lends legitimacy to the project.

First of all, thanks for making your reasoning more explicit. This is useful both to me and other contributors.

However, I still think that your reasoning is not explicit enough, and that making it more explicit would help both contributors to understand you, and you to reason about the point. In particular, is your opinion that Solidity is an illegitimate language, and you do not wish to confuse people into believing it is legitimate? Or is Solidity a legitimate language, but you wish to delegitimze it? And what makes a language legitimate or illegitimate?

I would say a legitimate language was one which had nontrivial usage by actual users for its intended use case. An illegitimate would be one which was not actually used in this way. For example, if I created a language primarily in order to put "created the X language" on my resume, and then attempted to get support for syntax highlighting for this language added to rogue and similar tools so that the line on my resume was more impressive, you would be quite correct to reject my PR adding X support to rogue on the grounds that "X is not a legitimate language." But by this standard, Solidity is clearly a legitimate language. Therefore you are deliberately reducing the functionality of rogue and (perhaps not greatly) harming users of rogue, including users who would use it for use cases you approve of (I assume you would approve of criticism of Solidity and smart contracts), in order to mislead the public into believing that Solidity is not a legitimate language, even though it is. I'm not saying this to hurt your feelings or win internet points, but because I hope you will understand, agree with me, and change your mind. Perhaps this is silly of me, but I continue to be optimistic about people, and I am optimistic about you.

It is not that I am worried that you will succeed in creating the false impression that Solidity is illegitimate. I am afraid it is too late for that. Consider e.g.:

• https://azure.microsoft.com/en-us/solutions/blockchain/#overview
• https://marketplace.visualstudio.com/items?itemName=ConsenSys.Solidity

which is I why even if I had no ethical qualms about attempting to mislead people about the legitimacy of Solidity, I would still consider it a waste of effort to try, and not worth anything which had any negative impact on my userbase.

Again, I must stress that I share your feelings about the badness present in the cryptocurrency space. but I am disappointed in how you have chosen to address it. You have been extremely cagey about your critical opinions. I think you ought make your opinions public, such as by posting on your blog or social media, rather than keeping them to yourself but removing functionality from rouge. I think this would have greater impact. As an accomplished engineer, your opinions would carry some weight, and you would have the ability to articulate them not shared by all critics.

this is not a topic that is open to discussion.

Even if the maintainers do not intend to change their decision, it is still desirable for them to clearly communicate the reasoning behind the decision. For example, if there had been a PR in which you had made the claim about not lending legitimacy to Solidity, I would have found it when I searched for issues and PRs. I would thereby understand your reasoning, whereas so far it has taken 4 days for me to understand it only partially. This might be useful in other cases. For example, if I did not realize Solidity had been removed for cause, I might want to contribute a Solidity lexer, which would have resulted in wasted time and bad feelings all around.

do not attempt to further spam the project on this topic.

Just to be clear, do you consider my continuing to post in this issue spamming? That's fine and I will stop, but you should make it clear what exactly you're referring to (for example, you might be referring to my mentioning the other maintainer). As a maintainer of the project, and a person identified as being responsible for CoC enforcement, you clearly have the power to ban people from the project. Thus you should not give vague instructions to people, as this may have a chilling effect on participation. If you must instruct, instruct precisely.

[jneen]

Thank you for your input.