This article is a love letter to both mathematics and programming. It is awesome to read something and grasp the joy and playfulness of the author. The maths are explained in a simple way. The programming concepts go from the straightforward to the delightfully weird (and let't not kid ourselves, Raku shines the most the weirder things get). And the final result is downright fun. I love it.
Perl is pretty great and it was THE language to know before Java took over the enterprise in the early-mid 2000s, and python later.
Perl is its own thing, definitely, and it does a lot of things extremely well (though not always extremely fast) using code that is as succinct as you want it to be, sometimes to a fault.
It is worth learning because of its utility and because of what it can teach, even though you probably won't use it a lot.
Perl 5 documentation still stands out to me as a perfect example of how official language documentation should be. Lots of examples, lots of explanation, standard library and third party modules are named extremely sanely, and it's all just documented so well. Even joke Perl5 modules are documented extremely well; it's just part of the culture that other languages seriously need to adopt.
Raku represents quite an advancement on Perl 5. Perl was a "kitchen sink" scripting language when it debuted, and Raku is a modern take on that, which means that it has lots of undiscovered corners still, places that will likely be major programming paradigms of tomorrow.
Perl 5 will continue to be the official "Perl". Development on that continues, and it has an extensive community, though not nearly as large as Python, which was once its peer.
What was Perl 6 will, moving forward, be known as "Raku".
Nah, plenty of people still care about it (I should know, I'm one of them!). And with regular expressions front-and-center in perl, I still find it wonderful for text munging.
Then you should maybe have a look at MoarVM (https://moarvm.org). It is now the main backend for Raku (née Perl 6) and is all that Parrot was intended to be, and then some. If you want to get into it, you might want to have a look at https://github.com/edumentab/rakudo-and-nqp-internals-course (course materials that implemented a Ruby and a PHP on MoarVM).
Computing e to thousands of decimal places is an interesting exercise for the mathematically inclined students in a beginning programming class. If you use the ∑1/n! series you can fairly easily do it even in a language that does not have built in arbitrary precision or an arbitrary precision library.
Let's say you want to deal with numbers to 1000 decimal places. Pick a base that is a power of 10, such as 10000. Represent a number as an array of 251 base 10000 digits, with the first item of the array being the integer part, and the remaining 250 being 250 base 10000 "decimal" digits.
You need two of these arrays. One represents 1/n!, and the other is the cumulative sum of the series so far.
You need two large precision operations. To go from 1/n! to 1/(n+1)! involves simply dividing by n+1. As long as we limit n+1 to under 10000, we only have to handle division with a single digit denominator. Limiting n thusly is not a problem--it's enough to actually support calculating e to over 35000 decimal places, so our modest goal of 1000 is no problem.
Implement the division exactly like you would do division by a single digit with pencil and paper. The only thing you have to worry about is dealing with carry. You can have intermediate values as large as the carry x the base + base - 1, and since carry can be as large as base - 1, this means you can have intermediate values as large as base^2 - 1. Just pick base (10000 in my example) so that base^2 - 1 doesn't overflow the basic integer type of the language you are using.
The other large precision operation you need is addition, to accumulate the result from the division into the sum. Same as with division--just write it using the same algorithm you would use with pencil and paper. Add digits right to left, with carry.
By using a base that is a power of 10, it is easy to figure out the base 10 representation of the final result for printing.
This also shows one of the things that Perl was great at in the past: Personalities. Despite "Just Another Perl Hacker" being a common meme, there were some people who just stood out. Wall, Schwartz, Christiansen, Conway.
I think this is important for a language and IMHO current Perl can't compete with that. For a while Ruby had a pretty colorful and productive batch, and of course Go has some elder statesmen of the industry.
JavaScript... Well, it certainly has a lot of coaches.
> Maksymilian Piskorowski found that if you happen to have a spare eight 9s, you can compute 𝑒 = (9/9 + 9^(-9^9))^(9^(9^9)), which is accurate to a little over 369 million decimal places.
Sure, because 9/9 = 1 and if you take x = 9^9^9, you get back (1 + x^(-1))^x, i.e. the first formula. It's cute, but I don't know if you could call it a "discovery".
Why does the Bernoulli formula take exponentially long in the exponent? Python’s native form (using either an integer or float exponent) and even an arbitrary percision computation to 1000 decimal digits using mpmath (also with either an integer or float exponent) are fast even for much larger exponents, and are accurate.
I can't connect to this page, as Firefox is automatically redirecting me to the HTTPS version of the page even though it's not supported. I guess I don't run into this that often given how common HTTPS is, but maybe someone else has this problem with this site? If you are, have you fixed it before? I've tried all of the methods mentioned on this[0] page, and I'm on Firefox 70 on Linux Mint.
I am not convinced by the interest charging analogy. It is back to front. The yearly interest is by definition the total interest that would be paid given the already agreed charging period. The loan shark does not advertise a 100% yearly interest (on a single yearly payment) and then suddenly increase his winnings by cranking up the number of payments. It is then no more a 100% yearly loan.
It sounds like your goals for Raku are incompatible with the aims of the project, to the extent that making Raku into what you want would be "use something else" with extra steps.