Hacker News Reader

Comment by jddj | Hacker News Reader

  > (2,4,8...*)[17]
  262144

This one genuinely surprised me

View on HN

My brain immediately reached for the word 'horrifying', with phrases 'terrible consequences' and 'halting problem' soon after, but to each their own.

I believe that it only tries to DWIM with arithmetic and geometric sequences, and gives up otherwise. Of course there’s nothing keeping you from writing a module that would override infix:... in the local scope with a lookup in OEIS.

This has nothing to do with the halting problem. And I have no idea why you think there would be 'terrible consequences'.

  2, 4, 8 ... *

The `...` operator only deduces arithmetic, or geometric changes for up-to the previous 3 values.

Basically the above becomes

  2, 4, 8, * × 2 ... *

Since each value is just double the previous one, it can figure that out.

If ... can't deduce the sequence, it will error out.

  2, 4, 9 ... *

  Unable to deduce arithmetic or geometric sequence from: 2, 4, 9
  Did you really mean '..'?
  in block at ./example.raku line 1

So I really don't understand how you would be horrified.

Programming is not just a matter of slinging syntax at a problem. Good programmers need to develop a mental model of how a language works.

Needing to do geometric sequences as syntax like that is clearly a parlor trick, a marginal use case. What goes through a good programmer's mind, with experience of getting burned by such things over the years, is "If Raku implements this parlor trick, what other ones does it implement? What other numbers will do something I didn't expect when I put them in? What other patterns will it implement?"

Yes, you can read the docs, and learn, but we also know this interacts with all sorts of things. I'm not telling you why you should be horrified, I'm explaining why on first glance this is something that looks actually quite unappealing and scary to a certain set of programmers.

It actually isn't my opinion either. My opinion isn't so much that this is scary on its own terms, but just demonstrates it is not a language inline with any of my philosophies.

Raku has features that would appeal to mathematicians. It might seem like a parlour trick to you but that doesn't make it so for everyone.

It's a parlor trick because something like "1, * × 2 ..." is much more sensible. Heck, it isn't even longer, if we're talking about saving keystrokes. It's still more syntax than I'm looking for from a language, but "initial, update rule, continue infinitely" does not give me that immediate "oh wtf, what other magic is going to happen with other values?" reaction I describe from trying to divine update rules from raw numbers.

It is also immediately obvious how to use this for other patterns, immediately obvious how to compose it, and just generally experiences all the benefits things get from not being special cases.

You get either a compile time instantiated infinite lazy sequence, or a compilation error.

My personal bar for "amount of clever involved" is fairly high when the clever either does exactly what you'd expect or fails, and even higher when it does so at compile time.

(personal bars, and personal definitions of "exactly what you'd expect" will of course vary, but I think your brain may have miscalibrated the level of risk before it got as far as applying your preferences in this particular case)

The detecting of increments has been in Perl6 for ages so that's not new. [edit Perl6 not Perl)

I guess (apart from the Whatever), the laziness is new since Perl6/Raku.

> The detecting of increments has been in Perl for ages so that's not new.

But this is detecting that the increment is multiplicative, rather than additive. It might seem like a natural next step, but, for example, I somewhat suspect (and definitely hope) that Raku wouldn't know that `(1, 1, 2...*)` is a (shifted) list of Fibonacci numbers.

Ah, I missed that. Nevertheless it's been in Perl6 for a while!

You're safe WRT Fibonacci.

> Unable to deduce arithmetic or geometric sequence from: 1,1,2

BUT WAIT!

    $ raku -e 'say (1, 1, *+* ... *)[0..10]'
    (1 1 2 3 5 8 13 21 34 55 89)

I… love it? It's so elegant it's infuriating.

It also seems slowish, but seems the problem is the startup cost. So probably pretty smart?

The following shows fairly stable times.

> for i in $(seq 20); do time raku -e "say (1, 1, + ... *)[0..$i]"; done

raku kinda puts a bunch of parts of itself together during startup, not entirely unlike Julia.

The sheer dynamism of the thing makes pre-baking that non-trivial, also not entirely unlike Julia.

I seem to recall chatting with the devs on IRC a few years and there seeming to be more than one viable way to potentially fix it, but they all seemed to me to share the property of needing a lot of effort during which nothing would work at all before you got something to show for it - and a decent chance of what you got to show after all that time was "welp, here's why which one can't work" - which is a really heavy lift in terms of somebody finding motivation to try it in the first place.

So tl;dr "yes, I dislike the startup cost, no, I don't expect it to change soon and I don't think it's a black mark against the team that it probably won't."

very cohesive,

    [7] > (1,3,9...*)[4,5]
    (81 243)
    [8] > (1,3,9...*)[(1..3)]
    (3 9 27)

and nestable

    [0] > (1,2,4...*)[(1,2,4...*)[1,2,3]]

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.

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-comput...>. An example:

    #| Dörrie's bounds
    assess -> \x=(1,10,100...10⁶) {
        ½ × sum (1 + x⁻¹)**(x),
                (1 + x⁻¹)**(x+1)
    }

That article was a RIDE.

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>.

Ha, Conway, once again. His talks during early perl6 days were brilliant.. thanks for sharing

You’re welcome.

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.

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.

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.

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/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.

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/s...

Reply on news.ycombinator.com