[zephen]

  seq = [0,1]
  while len(seq) < 20:
      seq.append(sum(seq[-2:]))
  print(' '.join(str(x) for x in seq))

> I am claiming that (0,1,+...*)[^20] is a nicer rut.

If it's so fantastic, then why on earth do you go out of your way to add extra lines and complexity to the Python?

[jaen]

Complexity-wise, this version is more complicated (mixing different styles and paradigms) and it's barely less tokens. Lines of code don't matter anyway, cognitive load does.

Even though I barely know Raku (but I do have experience with FP), it took way less time to intuitively grasp what the Raku was doing, vs. both the Python versions. If you're only used to imperative code, then yeah, maybe the Python looks more familiar, though then... how about riding some new bicycles for the mind.

[zephen]

> Complexity-wise, this version is more complicated (mixing different styles and paradigms)

Really? In the other Python version the author went out of his way to keep two variables, and shit out intermediate results as you went. The raku version generates a sequence that doesn't even actually get output if you're executing inside a program, but that can be used later as a sequence, if you bind it to something.

I kept my version to the same behavior as that Python version, but that's different than the raku version, and not in a good way.

You should actually ignore the print in the python, since the raku wasn't doing it anyway. So how is "create a sequence, then while it is not as long as you like, append the sum of the last two elements" a terrible mix of styles and paradigms, anyway? Where do you get off writing that?

> Lines of code don't matter anyway, cognitive load does.

I agree, and the raku line of code imposes a fairly large cognitive load.

If you prefer "for" to "while" for whatever reason, here's a similar Python to the raku.

  seq = [0,1]
  seq.extend(sum(seq[-2:]) for _ in range(18))

The differences are that it's a named sequence, and it doesn't go on forever and then take a slice. No asterisks that don't mean multiply, no carets that don't mean bitwise exclusive or.

> If you're only used to imperative code, then yeah, maybe the Python looks more familiar, though then... how about riding some new bicycles for the mind.

It's not (in my case, anyway) actually about imperative vs functional. It's about twisty stupid special symbol meanings.

Raku is perl 6 and it shows. Some people like it and that's fine. Some people don't and that's fine, too. What's not fine is to make up bogus comparisons and bogus implications about the people who don't like it.

[jaen]

Reminds me a bit of the fish anecdote told by DFW... they've only swam in water their entire life, so they don't even understand what water is.

Here are the mixed paradigms/styles in these Python snippets:

- Statements vs. expressions

- Eager list comprehensions vs. lazy generator expressions

- Mutable vs. immutable data structures / imperative reference vs. functional semantics

(note that the Raku version only picks _one_ side of those)

> seq.extend(sum(seq[-2:]) for _ in range(18))

I mean, this is the worst Python code yet. To explain what this does to a beginner, or even intermediate programmer.... oooooh boy.

You have the hidden inner iteration loop inside the `.extend` standard library method driving the lazy generator expression with _unspecified_ one-step-at-a-time semantics, which causes `seq[-2:]` to be evaluated at exactly the right time, and then `seq` is extended even _before_ the `.extend` finishes (which is very surprising!), causing the next generator iteration to read a _partially_ updated `seq`...

This is almost all the footguns of standard imperative programming condensed into a single expression. Like ~half of the "programming"-type bugs I see in code reviews are related to tricky temporal (execution order) logic, combined with mutability, that depend on unclearly specified semantics.

> It's about twisty stupid special symbol meanings.

Some people program in APL/J/K/Q just fine, and they prefer their symbols. Calling it "stupid" is showing your prejudice. (I don't and can't write APL but still respect it)

> What's not fine is to make up bogus comparisons and bogus implications about the people who don't like it.

That's a quite irrational take. I didn't make any bogus comparisons. I justified or can justify all my points. I did not imply anything about people who don't like Raku. I don't even use Raku myself...

[zephen]

> You have the hidden inner iteration loop inside the `.extend` standard library method driving the lazy generator expression with _unspecified_ one-step-at-a-time semantics

That's why it wasn't the first thing I wrote.

> To explain what this does to a beginner, or even intermediate programmer.... oooooh boy.

As if the raku were better in that respect, lol.

> Some people program in APL/J/K/Q just fine, and they prefer their symbols.

APL originally had a lot of its own symbols with very little reuse, and clear rules. Learning the symbols was one thing, but the usage rules were minimal and simple. I'm not a major fan of too many different symbols, but I really hate reuse in any context where how things will be parsed is unclear. In the raku example, what if the elements were to be multiplied?

> Calling it "stupid" is showing your prejudice. (I don't and can't write APL but still respect it) > Reminds me a bit of the fish anecdote told by DFW...

Yeah, for some reason, it's not OK for me to insult a language, but it's OK for you to insult a person.

But you apparently missed that the "twisty" part was about the multiple meanings. Because both those symbols are used in Python (the * in multiple contexts even) but the rules on parsing them are very simple.

perl and its successor raku are not about simple parsing. You are right to worry about the semantics of execution, but that starts with the semantics of how the language is parsed.

In any case, sure, if you want to be anal about paradigm purity, take my first example, and (1) ignore the print statement because the raku version wasn't doing that anyway, although the OP's python version was, and (2) change the accumulation.

  seq = [0,1]
  while len(seq) < 20:
    seq = seq + [seq[-2] + seq[-1]]

But that won't get you very far in a shop that cares about pythonicity and coding standards.

And...

You can claim all you want that the original was "pure" but that's literally because it did nothing. Not only did it have no side effects, but, unless it was assigned or had something else done with it, the result was null and void.

Purity only gets you so far.

[jaen]

You're getting more and more irrational.

> it's OK for you to insult a person.

I made an analogy which just means that it's hard to understand what the different styles and paradigms are when those are the things you constantly use.

You're apparently taking that as an insult...

> But you apparently missed that the "twisty" part

I didn't miss anything. You just didn't explain it. "twisty" does not mean "ambiguous" or "hard to parse". Can't miss what you don't write.

[lizmat]

> In the raku example, what if the elements were to be multiplied?

$ raku -e 'say (0, 1, 2, * × * ... )[^10]' # for readability (0 1 2 2 4 8 32 256 8192 2097152)

$ raku -e 'say (0, 1, 2, * * ... *)[^10]' # for typeability (0 1 2 2 4 8 32 256 8192 2097152)

[zephen]

Yeah, no thanks.

My instincts about raku were always that perl was too fiddly, so why would I want perl 6, and this isn't doing anything to dissuade me from that position.

[librasteve]

err - I cut and pasted the Python directly from ChatGPT ;-)

[zephen]

But it doesn't do the same thing at all as the raku.

It doesn't build a list, rather it dumps it as it goes.

It has an explicit print.

It uses a named constant for 20 rather than a literal.

etc, etc...