3 ms·

These are all very clever, but what's the use case? I'm not saying there isn't one, I just don't know what it is! Not to speak of the dead, but Perl was utilita

These are all very clever, but what's the use case? I'm not saying there isn't one, I just don't know what it is! Not to speak of the dead, but Perl was utilitarian: it was built to solve problems. From my point of view, these are solutions to problems I've never had.

db48x 2y ago
Here’s a nice article which uses this feature well (and several others) while computing e <https://blogs.perl.org/users/damian_conway/2019/09/to-compute-a-constant-of-calculusa-treatise-on-multiple-ways.html https://blogs.perl.org/users/damian_conway/2019/09/to-comput...>. An example: #| Dörrie's bounds assess -> \x=(1,10,100...10⁶) { ½ × sum (1 + x⁻¹)**(x), (1 + x⁻¹)**(x+1) }
- justinator 2y ago
  That article was a RIDE.
  - db48x 2y ago
    Yea, I think he has a knack for that. If you want some more I recommend a talk he gave a few years back called “Three Little Words” <https://www.youtube.com/watch?v=e1T7WbKox6s https://www.youtube.com/watch?v=e1T7WbKox6s>.
    - agumonkey 2y ago
      Ha, Conway, once again. His talks during early perl6 days were brilliant.. thanks for sharing
      - db48x 2y ago
        You’re welcome.
    - justinator 2y ago
      Damian is an excellent writer and communicator for sure. But I don't know if it answers the question of what you would use these features in Raku for. If one wanted to compute e to higher precision, I feel like one would use a DSL. But we also don't need to compute e presently.
      - db48x 2y ago
        No, we don’t need to compute e very often; it’s value is pretty well known. The article is just showing off Raku (or Perl 6 as it was then known) by writing a small program of moderate complexity that still manages to show off some of Raku’s interesting features. Computing approximations of e is merely an interesting exercise; it’s not the point. The question that justinator asked was what good uses Raku’s indefinite series have. This article points out that different ways of approximating e grow at different rates, so it is appropriate to associate a different range of trial values with each of those methods. Dörrie's bounds uses powers of 10 as shown. Others use powers of 2. Newton’s method uses sequential trial values, since it grows really fast: #| Newton's series assess -> \k=0..∞ { sum (0..k)»!»⁻¹ } And several methods compute approximations in a single step, so they don’t take a trial value at all: #| Castellano's coincidence assess { (π⁴ + π⁵) ** ⅙ } #| Sabey's digits assess { (1+2**(-3×(4+5)))**(.6×.7+8⁹) } #| Piskorowski's eight 9s assess { (9/9 + 9**-9**9) ** 9**9**9 } These are a lot of fun, but of course they can also be profound: #| From Euler's Identity assess { (-1+0i) ** (π×i)⁻¹ } For those who are interested, the article shows off a lot of obvious syntactic features like superscripts and hyperoperators, but there are also things like classes and roles and new operators as well. It really is a nice tour.
b2gills 2y ago
I've heard that the best way to solve a hard problem is to create a language in which solving that problem would be easy. Basically creating a Domain Specific Language. Raku isn't necessarily that language. What it is, is a language which you can modify into being a DSL for solving your hard problem. Raku is designed so that easy things are easy and hard things are possible. Of course it goes even farther, as some "hard" things are actually easy. (Hard from the perspective of trying to do it in some other language.) Lets say you want a sequence of Primes. At first you think sieve of Eratosthenes. Since I am fluent in Raku, I just write this instead: ( 2..∞ ).grep( *.is-prime ) This has the benefit that it doesn't generate any values until you ask for them. Also If you don't do anything to cache the values, they will be garbage collected as you go.
ookdatnog 2y ago
If you can read Lisp (Scheme) syntax, I think SICP [0] has the clearest demonstration of the utility of lazy streams. The problem it presents (calculating pi) is, admittedly, rather academic; but the concept of having values that evolve over "time" as first-class entities that you can abstract over is practically useful. I think that all of reactive programming (React, Angular, etc) is closely related to this idea (perhaps even originates from it), although the implementation and applications differ. It's a long and effortful read, but the payoff is worth the effort. [0] https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-24.html#%_sec_3.5.3 https://mitp-content-server.mit.edu/books/content/sectbyfn/b... EDIT: I think the Perl article posted in a sibling comment uses essentially the same example (but for calculating e instead of pi), although I only skimmed it.
- trealira 2y ago
  I hadn't realized that SICP covered using lazy streams for calculating pi. That reminds me of this article I read recently about using lazy lists in Haskell to calculate pi by means of a few different algorithms. https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/spigot.pdf https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/s...

db48x 2y ago

Here’s a nice article which uses this feature well (and several others) while computing e <https://blogs.perl.org/users/damian_conway/2019/09/to-compute-a-constant-of-calculusa-treatise-on-multiple-ways.html https://blogs.perl.org/users/damian_conway/2019/09/to-comput...>. An example: #| Dörrie's bounds assess -> \x=(1,10,100...10⁶) { ½ × sum (1 + x⁻¹)**(x), (1 + x⁻¹)**(x+1) }

justinator 2y ago
That article was a RIDE.
- db48x 2y ago
  Yea, I think he has a knack for that. If you want some more I recommend a talk he gave a few years back called “Three Little Words” <https://www.youtube.com/watch?v=e1T7WbKox6s https://www.youtube.com/watch?v=e1T7WbKox6s>.
  - agumonkey 2y ago
    Ha, Conway, once again. His talks during early perl6 days were brilliant.. thanks for sharing
    - db48x 2y ago
      You’re welcome.
  - justinator 2y ago
    Damian is an excellent writer and communicator for sure. But I don't know if it answers the question of what you would use these features in Raku for. If one wanted to compute e to higher precision, I feel like one would use a DSL. But we also don't need to compute e presently.
    - db48x 2y ago
      No, we don’t need to compute e very often; it’s value is pretty well known. The article is just showing off Raku (or Perl 6 as it was then known) by writing a small program of moderate complexity that still manages to show off some of Raku’s interesting features. Computing approximations of e is merely an interesting exercise; it’s not the point. The question that justinator asked was what good uses Raku’s indefinite series have. This article points out that different ways of approximating e grow at different rates, so it is appropriate to associate a different range of trial values with each of those methods. Dörrie's bounds uses powers of 10 as shown. Others use powers of 2. Newton’s method uses sequential trial values, since it grows really fast: #| Newton's series assess -> \k=0..∞ { sum (0..k)»!»⁻¹ } And several methods compute approximations in a single step, so they don’t take a trial value at all: #| Castellano's coincidence assess { (π⁴ + π⁵) ** ⅙ } #| Sabey's digits assess { (1+2**(-3×(4+5)))**(.6×.7+8⁹) } #| Piskorowski's eight 9s assess { (9/9 + 9**-9**9) ** 9**9**9 } These are a lot of fun, but of course they can also be profound: #| From Euler's Identity assess { (-1+0i) ** (π×i)⁻¹ } For those who are interested, the article shows off a lot of obvious syntactic features like superscripts and hyperoperators, but there are also things like classes and roles and new operators as well. It really is a nice tour.

b2gills 2y ago

I've heard that the best way to solve a hard problem is to create a language in which solving that problem would be easy. Basically creating a Domain Specific Language. Raku isn't necessarily that language. What it is, is a language which you can modify into being a DSL for solving your hard problem. Raku is designed so that easy things are easy and hard things are possible. Of course it goes even farther, as some "hard" things are actually easy. (Hard from the perspective of trying to do it in some other language.) Lets say you want a sequence of Primes. At first you think sieve of Eratosthenes. Since I am fluent in Raku, I just write this instead: ( 2..∞ ).grep( *.is-prime ) This has the benefit that it doesn't generate any values until you ask for them. Also If you don't do anything to cache the values, they will be garbage collected as you go.

ookdatnog 2y ago

If you can read Lisp (Scheme) syntax, I think SICP [0] has the clearest demonstration of the utility of lazy streams. The problem it presents (calculating pi) is, admittedly, rather academic; but the concept of having values that evolve over "time" as first-class entities that you can abstract over is practically useful. I think that all of reactive programming (React, Angular, etc) is closely related to this idea (perhaps even originates from it), although the implementation and applications differ. It's a long and effortful read, but the payoff is worth the effort. [0] https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-24.html#%_sec_3.5.3 https://mitp-content-server.mit.edu/books/content/sectbyfn/b... EDIT: I think the Perl article posted in a sibling comment uses essentially the same example (but for calculating e instead of pi), although I only skimmed it.

trealira 2y ago
I hadn't realized that SICP covered using lazy streams for calculating pi. That reminds me of this article I read recently about using lazy lists in Haskell to calculate pi by means of a few different algorithms. https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/spigot.pdf https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/s...