The download page doesn't mention the difference between rakudo-star and rakudo #93
Comments
|
Our original (2015) policy was to promote/announce "Rakudo Star" only, to avoid user confusion. As far as average users who just want to "use Perl 6" are concerned, Rakudo Star is all there is. Personally, I'd say that download page should have less stuff not more. The "don't make me think" principle applies—those who're trying to get Perl 6 from that page don't really need to know the difference between Rakudo and Rakudo Star. |
|
Yes I think there is a serious possibility of overloading a new user with
too much information!
Rakudo Star v Rakudo is already explained in multiple places in the docs
anyway.
…On 8 March 2018 at 23:52, Zoffix Znet ***@***.***> wrote:
Our original (2015) policy was to promote/announce "Rakudo Star" only, to
avoid user confusion. As far as average users who just want to "use Perl 6"
are concerned, Rakudo Star is all there is.
Personally, I'd say that download page should have less stuff not more.
The "don't make me think" principle
<https://www.amazon.ca/Dont-Make-Me-Think-Usability/dp/0321344758>
applies—those who're trying to get Perl 6 from *that* page don't really
*need* to know the difference between Rakudo and Rakudo Star.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#93 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEUuYzwo4EaOY8HOOqFRE0GJdJmKBe0vks5tccRLgaJpZM4SjeJB>
.
--
Steve Mynott <steve.mynott@gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
|
|
Thanks for many replies. |
|
I copy-paste my answer from the PR. This is not a critique of Rakudo Star (that I appreciate), but the other side of the coin for a lot of users: I completely disagree with this statement. I fall into at least 3 categories of users where this does not apply and I think there are many people in the same boat:
This was my trigger for providing pre-compiled Linux packages. Regards, C. |
You aren't the generic beginner user the download page and our main communications target. If you have enough know-how to setup docker (even I don't), I'd expect you to be able to to find what you're looking for by following references on the page (e.g. the I don't think the current download page is ideal, but shoving even more shit on it won't improve it. It needs a lot less text and a couple more visuals or buttons.
The flip side of that coin is a user scratching their heads, trying to figure out what do they need to do common tasks and how to get it, and then leaving to a language that doesn't make them think about that. Once again, you know exactly what you want; our first-contact communications target those who don't. |
|
I understand your use case and it would be the prime one if perl6 had a killer app everyone wanted to use because of the app and not the language. We aren't there yet. I think that most Perl 6 beginners are of the technical early adopter kind. I am all for giving emphasis to the full batteries solution. It's the best way to get started. I would however, add a note/link for more advanced users. C. |
|
2018-03-10 19:42 GMT+01:00 nxadm <notifications@github.com>:
I understand your use case and it would be the prime one if perl6 had a
killer app everyone wanted to use because of the app and not the language.
We aren't there yet. I think that most Perl 6 beginners are of the
technical early adopter kind.
So true...
I am all for giving emphasis to the full batteries solution. It's the best
way to get started. I would however, add a note/link for more advanced
users.
👍
|
|
@nxadm The downloads web page is too bloated for more additions. But there already is a link to https://github.com/nxadm/rakudo-pkg#rakudo-pkg on the https://perl6.org/downloads/ page at the top right. This could become a link to a new web page on perl6.org documenting all third party packaging solutions (probably with yours at the top!) but also including those documented at https://github.com/stmuk/rakudo-packages (probably incomplete and outdated itself) Note the main problem with this (as with all docs) is not adding the initial docs but keeping them updated. It might to be better to try and maintain links to sites off perl6.org rather than version numbers. |
Could that be because of survival bias? You're seeing the techy early adopters because they're the ones who managed to make it through the wall of text and figure out what to install to learn the language and stay. Who's supposed to write that "killer app" you mentioned? Is that function restricted to early adopters only?
After rakudo.org remake, I plan to add platform detection on the download page and simplify it greatly. Something functionally resembling this: (A |
|
If you are offering the compiler and star you are confusing things for the user even further by offering a huge number of options - a monthly compiler release, a quarterly Star release and potentially binaries for the compiler, source for the compiler, binaries for Windows and Mac (MSI and DMG). Imagine the support issues on IRC when it would take 20 minutes of questioning to work out exactly which "release" the newbie is having problems with. I don't think trying to hide all these options behind Javascript detection is a good solution here since people might want to download source on a Ubuntu system or a Windows system anyway or even use lynx anyway. JS isn't popular with some Perl people anyway. I can't think of another language which would have such a complex download system or number of options. It could be OK as an extra page linked from a simpler download page (like replacing the top right link mentioned above). A link like "There are other download options, help me understand them". But look at https://www.ruby-lang.org/en/downloads/ https://www.python.org/downloads/ They offer source tarballs only. I can't think of anyone who offers binaries directly on their download page or via a javascript "wizard" (usually its a linked second page). The simplest download page of all is https://www.rust-lang.org/en-US/install.html (which is where I stole the idea of the rakudup tool from) But we even consider radical changes like this we should monitor the number of downloads for each option (and the results may not be encouraging I fear). We should be making these decisions on actual hard numbers not "this is how I think people might be downloading or this is what I think people want" We are overthinking this and there is danger of offering too much choice and complexity. The situation is bad enough already with having to explain what perl 6 is, the star v rakudo distinction and the oddness of the language version numbering - all of which need a paragraph of text to explain. The source problem seems to be a explosion of complexity and sweeping this under a JS carpet doesn't fix this. Also there is the issue of frequency of release. I think releasing monthly is far too frequent for end users and even releasing quarterly is too often. We should be moving to releasing once or twice a year at most if we are offering downloads or moving to the rust model if we can't release less often. If we all were starting from scratch I'd recommend renaming the monthly tarball releases something like "rakudo-dev" or "rakudo-core" and releasing "rakudo-release" releases which just include zef and p6doc. |
Python is already doing exactly what I'm doing. Visit that site on Windows.
(wonder wherefrom you stole the idea for an offensive font and inflammatory language for that tool's website, virtually guaranteeing no one would use it) |
|
The attack on rakudup is unwarranted, off topic and doesn't do yourself any credit. You would be better off rereading what I've written and thinking about it, |
Considering the "they" that person disses includes all Rakudo developers,
Virtually all of what you've written regarding the download page isn't applicable because you're criticizing unreleased content you've never even seen, while making numerous erroneous assumptions about it. I don't know what exactly you want me to think about. |
|
@zoffixznet You clearly don't understand the bulk of what I've written and seem strangely fixated on one line. You aren't adding anything useful to this thread and I'm not replying further. |
|
Yup. I'm just a moron who don't understand nothing. Strangely fixated. 1,857 words. |
|
OK lets put the aggression aside. Personally I would like to see a download page that can be easily followed by a 6-year-old. Simplifying it sounds like a good idea in general, and whether it's JS or something else that helps with it I think it should not matter. Right? “Other download options” link seems to be there, and we can have whatever we want there, and that we can discuss to death. The proposed new design seems like a step in the right direction, and we can tweak it later if needed. Let's not get ahead of ourselves.
Please no. Even monthly checkpoints are hard enough given the pace of rakudo development. Also I'm not sure how releases can be “too frequent”… the user is not forced to update, right? Also, releasing often is perhaps beneficial in terms of marketing, especially when we're trying to fight “perl is dead” myth. |
|
@zoffixznet, @stmuk: Actually, I am not referring to my packages per se and I certainly do not claim they deserve marketing. They are just that, third party. I would prefer if official packages existed so there was no need for rakudo-pkg. I disagree with @stmuk that Star is released too frequently. Maybe compared to a more mature language, sure. How many time have we told people on #perl6 to update their Rakudo in order to fix X or enjoy Y? Rakudo gets faster --I don't need to tell you how important this still is-- and better with every release. In my view, Star should be the first and recommended option, even if only because it's the official effort that people can and should trust. We may disagree about the batteries included philosophy for programming languages releases, but this is not the main point. At this stage of development, I feel like not having "monthly" packages will alienate some users looking for a released fix or a new cool feature. I can not quantify what percentage of users in this category. Furthermore, I believe that Compiling C code to just try something out is something of a last resort for a lot of people, and a reason to just move along. A pre-compiled package (or a snap/flatpack/etc if they break through) seems user friendly to me. Let me finish with agreeing with @AlexDaniel, and remind everyone to keep it civil. My comment on this closed ticket was not intended to cause bad blood between devs. We all care about the end users, and I suspect there aren't hidden agendas at play. No need to get on that road. Let's keep up the good work. |
|
Let me finish with agreeing with @AlexDaniel
<https://github.com/alexdaniel>, and remind everyone to keep it civil. My
comment on this closed ticket was not intended to cause bad blood between
devs. We all care about the end users, and I suspect there aren't hidden
agendas at play. No need to get on that road. Let's keep up the good work.
Totally +1 on this.
|
|
I think we are suffering from Sunday Blues (hangovers, tiredness whatever) Anyway I've just added a new page with 3rd party packages listed on it and linked in parallel with the button on the top right. I'm not a client-side dev and don't play one on TV so the HTML could probably look better! |
In docs.perl6.org, the following section describes the difference well:
https://docs.perl6.org/language/faq#Does_Rakudo_have_a_core_standard_library?
However, I think it's little bit difficult to find this section because this section isn't indexed.
Isn't it better to write this explanation in the download page (https://perl6.org/downloads/)?
The text was updated successfully, but these errors were encountered: