-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Raku file extensions #108
Comments
I feel I don't have anything valuable to add to this discussion. |
Given that every solution we come up with is going to include keeping near term support for the current-to-be-legacy file extensions anyway, I suggest one way to avoid an impasse is to just make the PR say that existing extensions will continue to be supported for the short term, and that adding new extensions to better fit the name Raku will be the subject of a separate PR to follow soon after. Its not like the extension changes HAVE to happen at the same time, since they are backwards-compatible additions, not just substitutions. I personally don't want the main language renaming PR to be held up any further by extensions discussion. |
Some comments.
Thing is, this is a subjective judgement; if the PR had picked shorter ones, somebody could have written the exact same argument, just exchanging "long" for "short", to advocate the opposite position. My initial reaction was also "hmm, those are a bit long", but:
Maybe, but, as language responsible, I can say that problem-solving issues that attempt to revisit decisions made in the renaming PR will need to make a very compelling case to avoid being dismissed out of hand.
I don't know for sure. To me it's fairly clear that:
While I accept that there exist technical mechanisms in many editors, IDEs, GitHub source rendering, etc. for making a distinction based on file content, that doesn't make this approach ideal. As noted above, I don't really feel "you should write shebang lines in your test files" is a recommendation we should be making. By contrast, a given file extension mapping to a certain programming language is unambiguous. In summary: I'm not arguing on the basis of "what's possible", but rather "what will tend to Just Work".
I'm not sure it's strictly possible to argue that it's needed, but that doesn't mean one can't argue that it would have value.
As noted above, I did spend some time thinking the extensions in the PR through before approving it. So it wasn't a rush on my part. |
Just a quick note regarding shebang lines, I'm getting some weird hints. @jnthn, I think you're projecting your own habits as if it was common practice.
I wrote a quick script to gather some stats and ran it on a slightly outdated perl6-all-modules repo. Out of 1318 script files (p6, pl6, pl), 54.6% (719) have a shebang line and 35.9% (473) have executable bit set. This doesn't count files which have no extension, but if it did, the percentage would've been even higher. By contrast, 0 scripts in all of your cpan and github repos have a shebang line (there are around 20, I can't be bothered to collect the exact number). And yes, even those scripts that have no extension, still don't have a shebang. Just because you've never written a shebang line for a public perl6 project doesn't mean that it's unthinkable that others will, because roughly half have no problem with it. We can also do the same for So I totally don't see how it's unreasonable. |
To be fair, I probably made a dent in the number because over the years I've done many pull requests to various modules. If I ever saw any inconsistencies, I'd usually fix them (file extensions, executable bits, sometimes shebangs, etc.). I'd be surprised if my contribution is more than a 1%, but I guess it's fair to mention it anyway. |
I was talking exclusively about test files. Having slept on it, I'm thinking we could:
|
And what changed? Yesterday you said exactly the same thing. Basically, “If you really want to use
|
Yesterday I was considering it, and today I'm feeling more decisive about it. |
Does anybody know any good example of long extensions that are similar to our use case? I know there's |
So I decided to gather some stats. On debian, Anyway, on my system Then I wrote a quick and dirty raku script to count files with particular extensions. Resulting json file. But that's just raw data, now what? Well, let's look at extensions that are equal in length or longer than #!/usr/bin/env perl6
use JSON::Fast;
my %extensions = from-json slurp ‘extension-stats.json’;
.say for
%extensions
.grep({.key.chars ≥ 7+1})
.grep({.value > 5000})
.sort({-.key.chars, -.value}) Result:
Some conclusions:
Edit: Oops, I got confused. These are kicad footprints, not 3d models |
Now that I think about it, I shouldn't be dismissing Which makes me wonder, why not |
I would like to note that I strongly disagree to the following point: Note that mentioning some random text editor as a reason is not going to work, you have to actually know why it won't work with that editor. Janathan used the right term for this situation: things are better just work. So, where we're with editors? Alex demand they all understand shebangs. I would rather be happy if they're but unfortunately, we can't rely on this. Shebang itself is very much unixish thing. Windows-bound editors are not obliged to understand it. Good if they're but I wouldn't expect this. Some other editors can be fixed with additional configuration. Which sometimes means time and efforts. Perhaps most people reading this are ready to adjust they tooling for their needs. And capable of doing so. But if we aim at wider adoption of Raku we must consider the army of juniors or just lazy ones who would rather adapt themselves to the tools. They do so for various reason, but the result is this: they won't try something that requires breaking their habbits. And my bottom line for the above: extension is the primary and most used way of defining the file type. And even if one has an editor which supports shebangs or other ways of detecting file format, OSes are not that smart. Most of them are solely dependent on extensions. And wether we want this or not, a lot of people are used to just double click get... what? RealPlayer of VLC? Other language runtime? Long extensions isn't what I wanted in first place. But neither I wanted all this renaming headache. It's just so that reasoning is in favor of these two things. It's not about our wishes. My preference, BTW, is for twextensions for But the whole point about twextensions is that they got no support from the community and even strong opposition from @lizmat! Perhaps the reason for this was that the idea was born too late and got no time to convince people. As to lengthiness and that no other language is using such extensions. Is it the first thing where Perl6 is first of its kind? Saying "this is bad because no one else doing this" is like saying "this is bad because our grandfathers didn't do it". |
For me type-ability is not the same as word length. I find it easier to type words only consisting of letters than words also containing special characters such as |
Twigiled extensions are just asking for more ambiguity (just like having multiple extensions represent the same thing, which I'll also adamantly reject). If you have The proposed solution was fine, and extending this to get everything you want is not generally how compromises that succeed end. |
Another quick note:
Rereading it, it's pretty weird. So we shouldn't expect people to write shebangs, but we're also not constraining ourselves to the behavior of @vrurg I ask you for concrete examples yet you come up with more mythical stuff. Please be more specific. |
FWIW, I think we didn't really get further than the brainstorming phase on this issue, there are probably still some potentially good ideas out there. For example, just as an idea, For example: |
Actually, I can come up with counter-example of finding all Raku files. And whereas filtering out
I'm totally ok with long extensions. I would be ok with short ones if they're pushed through even if they overlap with other formats. What I'm not ok with is another discussion on this subject as if we haven't had enough of #89, #101, and #106. @AlexDaniel concrete examples of what? I have concrete examples of people around behaving the way I described. I know that would they be used to Atom and would they have language-perl6 package installed just to find out their Perl5 files are now of 'plain text' with no support whatsoever – they would just drop the idea of trying Perl6. |
Well, if you want concrete, I also play product lead/manager for Comma. Wearing that hat, a language rename is, in the near term, nothing but a cost. I've already made a list of things we'll need to take care of as a result of the rename; it's not terribly short, and it's not like we suddenly have more resources to deal with them. If the rename helps the userbase increase in the future, that's great, but the costs are to be paid now. As @vrurg notes, in the context of working with files, distinguishing content by an extension - usually defined as something after the final Comma has it good compared to the situation for, I believe, Perl 6 support in every other editor/IDE. I have some budget/team to work on it; we'll maybe not be able to do some other feature we'd hoped to work on quite so soon, but the required adaptations can be done on a relatively short time schedule. Every other editor/IDE plugin support is volunteer-driven, and it's been noted that there's few volunteers. Do we really want to make this any harder than it needs to be?
Indeed, and - unfairly or not - I find @AlexDaniel more unreasonable with every post I read. That probably means I need some days away from this topic. I'll catch up with it again next week. (I've unsubscribed. Please respect that by not @-ing me in the meantime.) |
You've got to be kidding me. People tell me about some mythical issues in editors, I'm the one who investigates and looks what these editors do, turns out that there are no issues, or at least the situation is definitely not as extreme as people want to depict it. Then you tell me that it's unreasonable to expect people to use shebangs, so I go and gather some stats that show the opposite. Then I wonder if there's any other project that has extensions as long as we will, and nobody has a clue, so I go and gather more real stats and find such example (which doesn't really support my position, right, but whatever, I'm the one unreasonable!) Alright, if my posts are unreasonable, then please people, bring some reason into this issue. Edit: It has been pointed out that I misunderstood the last comment, and I did. |
This would likely be my last comment on this issue. I would try to make things as clear as possible. First, have have to define the clear target or otherwise discussion will never end and no conclusion would be made. The whole renaming thing is about to gain wider user base. #81 is dedicated to this subject. I'm thinking of this target when I consider any problem related to renaming. This thread is not exception. By considering the target one must remember that enthusiasts are a minority of the programming community these days. It's not like before the dotcom boom days anymore. This is why I'm trying to think user-centric way. In other words, I think of decent juniors and how they make decisions. And, perhaps, this is the difference in approaching the problem. I know that a problem exists and I'm trying to figure out how would it impact an average guy trying a new language. These are not "mythical issues" but my attempt to model a situation. My model could be right or it could be wrong. But because I believe it is right I can't stand aside but trying to show the situation from this point of view. Look, I'm not saying your statistics is wrong. I just don't understand why the fact that nobody did something before should convince anybody that it shouldn't be done. After all, few if not nobody was developing a multi-paradigm language. Nobody was doing grammars they way Perl6 does them. Heck, nobody considered regexes seriously before Perl! Or the editors. I know there're many of them. But then, after all, I'm almost like one of those users I mentioned above. My days of puppy-like happiness about configuring another application for my needs is basically over. I'm in love with Apple products because they just work(tm). When I got tired of zsh and decided to switch to fish, it took me about a month to accumulate enough bravery for tuning it for my needs. I'm currently happy about all shell configs being synced over a git repo, but I regret for the time I lost implementing this. What would you expect from those who's just making money on their daytime job? Those who consider new language for basically three reasons: the boss told so; this could pay back in wages; or because in a competitive environment one must always learn. Neither of three is about "it's a fantastic language, I fell in love with it!", all are pragmatic. Would you propose them to change their tooling they're used to before starting with Perl6/Raku? The only case when this would work is the first one. And even then they'd be likely to quietly sabotage. BTW, this is common problem of many professional communities: they tend to enclose themselves in own informational bubble and don't see things from the outside. To conclude, to my view "being unreasonable" doesn't mean you can't reason your point. But it rather means that you allow a minor problem to stop us from resolving the big one. What I started #106 I expected a clean and fast discussion coming to a concrete conclusion. When things went the other way I came up with voting idea exactly for the reason that this is what people do when consensus is too hard to be achieved. The number of votes turns out to be rather small and unrepresentative? Well, those who chose to opt out of voting chose to live with decisions made by others. It's not always bad as some matters doesn't worth bothering. In this case the most active part of the community voiced out their preference. It's not in favor of your choice? Actually, as you can see, it's not what I'd like to see too. But this is the common problem of democracy and consensuses: not everybody likes the outcomes. So, Alex, I would like to ask you to pull back your RFC on #89 and let it all be over. After all, nobody can guarantee that voting will be in favor of the PR. Perhaps this whole discussion doesn't make sense because there will be no renaming. And if it happens there will be a grace period afterwards when it would not be too late to initiate another vote, give it more time, and see the outcome. That's all I wanted to say on this. |
@vrurg if you want this to go faster, then please start tweaking the PR. First step is easy, you remove the sentence that says that Anyway, see my review for some hints on what else should be tweaked. |
See #89 (review). |
This is a separate ticket for discussing solutions for the filename extensions issue in the Path to Raku PR. I'm starting a separate ticket so that we don't pollute the PR which is already hard to follow, and I hope that the PR will be eventually adjusted based on the feedback in this ticket. Because previous tickets¹ ² were a bit noisy, it was recommended to lock this discussion (so that only devs can comment).
Please see my review.
The text was updated successfully, but these errors were encountered: