b2gills

I didn't downvote, but this is by far not the first time something like that was stated (Raku being similar to Roku).

I know I'm tired of seeing it, I'm sure others are as well.

I'm sure that there has been more changes from Perl 5.8 to Perl 5.40 than there is between Python 2.0 to Python 3.x (Whatever version it is up to at the moment.)

What's more is that every change from Python 2 to Python 3 that I've heard of, resembles a change that Perl5 has had to do over the years. Only Perl did it without breaking everything. (And thus didn't need a major version bump.)

I've often thought of Raku as being a lot like the English language. It borrows heavily from other languages.

Of course since Raku has the benefit of an actual designer, it is more cohesive than English.

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.

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.

That's nothing, use it to calculate the sum of range of values

  say [+] 1..10000000000000000000000000000000000000000000

Which will result in you getting this back in a fraction of a second

50000000000000000000000000000000000000000005000000000000000000000000000000000000000000

(It actually cheats because that particular operator gets substituted for `sum` which knows how to calculate the sum of a Range object.)

I once heard of a merger between a company that used Java, and another one that used Perl.

After that merger, both teams were required to make a similar change.

If I remember right, the Perl team was done before the Java team finished the design phase. Or something like that.

The best aspect of Java is that it is difficult to write extremely terrible code. The worst aspect is that it is difficult to write extremely awesome code. (If not impossible.)

Many of the features that make Perl harder to write cleanly have been improved in Raku.

Frankly I would absolutely love to maintain a Raku codebase.

I would also like to update a Perl codebase into being more maintainable. I'm not sure how much I would like to actually maintain a Perl codebase because I have been spoiled by Raku. So I also wouldn't like to maintain one in Java, Python, C/C++, D, Rust, Go, etc.

Imagine learning how to use both of your arms as if they were your dominant arm, and doing so simultaneously. Then imagine going back to only using one arm for most tasks. That's about how I feel about using languages other than Raku.

Java inspired the Design Patterns book.

Every Design Pattern is a workaround for a missing feature. What that missing feature is, isn't always obvious.

For example the Singleton Design Pattern is a workaround for missing globals or dynamic variables. (A dynamic variable is sort of like a global where you get to have your own dynamic version of it.)

If Raku has a missing feature, you can add it by creating a module that modifies the compiler to support that feature. In many cases you don't even need to go that far.

Of course there are far fewer missing features in Raku than Java.

If you ever needed a Singleton in Raku (which you won't) you can do something like this:

  role Singleton {
    method new (|) {
      once callsame
    }
  }

  class Foo does Singleton {
    has $.n is required
  }

  say Foo.new( n => 1 ).n;
  say Foo.new( n => 2 ).n;

That prints `1` twice.

The way it works is that the `new` method in Singleton always gets called because it is very generic as it has a signature of `:(|)`. It then calls the `new` method in the base class above `Foo` (`callsame` "calls" the next candidate using the "same" arguments). The result then gets cached by the `once` statement.

There are actually a few limitations to doing it this way. For one, you can't create a `new` method in the actual class, or any subclasses. (Not that you need to anyway.) It also may not interact properly with other roles. There are a variety of other esoteric limitations. Of course none of that really matters because you would never actually need, or want to use it anyway.

Note that `once` basically stores its value in the next outer frame. If that outer frame gets re-entered it will run again. (It won't in this example as the block associated with Foo only gets entered into once.) Some people expect `once` to run only once ever. If it did that you wouldn't be able to reuse `Singleton` in any other class.

What I find funny is that while Java needs this Design Pattern, it is easier to make in Raku, and Raku doesn't need it anyway.

>> magic functions—which behave differently on lists-of-scalars vs. lists-of-lists by special default logic ...

That is completely the wrong way to think about it. Before the Great List Refactor those were dealt with the same by most operations (as you apparently want it). And that was the absolute biggest problem that needed to be changed at the time. There were things that just weren't possible to do no matter how I tried. The way you want it to work DID NOT WORK! It was terrible. Making scalars work as single elements was absolutely necessary to make the language usable. At the time of the GLR that was the single biggest obstacle preventing me from using Raku for anything.

It also isn't some arbitrary default logic. It is not arbitrary, and calling it "default" is wrong because that insinuates that it is possible to turn it off. To get it to do something else with a scalar, you have to specifically unscalarify that item in some manner. (While you did not specifically say 'arbitrary', it certainly seems like that is your position.)

Let's say you have a list of families, and you want to treat each family as a group, not as individuals. You have to scalarize each family so that they are treated as a single item. If you didn't do that most operations will interact with individuals inside of families, which you didn't want.

In Raku a single item is also treated as a list with only one item in it depending on how you use it. (Calling `.head` on a list returns the first item, calling it on an item returns the item as if it had been the first item in a list.) Being able to do the reverse and have a list act as single item is just as important in Raku.

While you may not understand why it works the way it works, you are wrong if you think that it should treat lists-of-scalars the same as lists-of-lists.

>> This attempt to fuse higher-order functional programming with magic special behaviors from Perl comes off to me as quixotic.

It is wrong to call it an attempt, as it is quite successful at it. There is a saying in Raku circles that Raku is strangely consistent. Rather than having a special feature for this and another special feature for that, there is one generic feature that works for both.

In Python there is a special syntax inside of a array indexing operation. Which (as far as I am aware) is the only place that syntax works, and it is not really like anything else in the language. There is also a special syntax in Raku designed for array indexing operations, but it is just another slightly more concise way to create a lambda/closure. You can use that syntax anywhere you want a lambda/closure. Conversely if you wanted to use one of the other lambda/closure syntaxes in an array indexing operation you could.

The reason that we say that Raku is strangely consistent, is that basically no other high level language is anywhere near as consistent. There is almost no 'magic special behaviors'. There is only the behavior, and that behavior is consistent regardless of what you give it. There are features in Perl that are magic special behaviors. Those special behaviors were specifically not copied into Raku unless there was a really good reason. (In fact I can't really think of any at the moment that were copied.)

Any sufficiently advanced technology is indistinguishable from magic. So you saying that it is magic is only really saying that you don't understand it. It could be magic, or it could be advanced technology, either way it would appear to be magic.

In my early days of playing with Raku I would regularly try to break it by using one random feature with another. I often expected it to break. Only it almost never did. The features just worked. It also generally worked the way I thought it should.

The reason you see it as quixotic is that you see a someone tilting at a windmill and assuming they are insane. The problem is that it maybe it isn't actually a windmill, and maybe you are just looking at it from the wrong perspective.

I don't think Perl is really that hard to learn. It does have a few traps for people new to the language though.

Raku on the other hand is easy to learn. Of course it is so easy to learn that knowing another language, any other language, can make it more difficult to fully grasp. That is because Raku is strangely consistent.

Most languages have a set of syntaxes for different actions. Raku has a set of features, and the syntax mostly just falls out from that.

When someone who knows another language tries to learn Raku they naturally translate what they already know to Raku features. That will only get you a surface level understanding of the language. No other language is really comparable.

Raku also has a new view of regexes. In Raku a regex is just a DSL for matching text. So rather than bolt on feature after feature like other languages have done it allows you to embed regular Raku code for situations where that is easier. You can also combine them using grammars (a type of class) to get a full parser out of several parts.

In fact the grammar feature in Raku is the only one that is powerful enough to parse Raku easily. Part of that has to do with the ability to mutate the language.

It has been said that the best way to solve a programming problem is to create a language in which solving the problem is easy. Raku, using that ability, allows you to do that easily.

The `but` keyword takes an instance and something to mix into it.

So you can say something like this:

    0 but True

---

Since `True` is a `Bool` it automatically creates a role that has a method `Bool` that returns `True`.

    my $role = role { method Bool { True }}

You can do that manually if you want.

    0 but role { method Bool { True }}

---

It creates a new subclass of Int and mixes in the role.

So:

    0 but True

Is roughly equivalent to:

    do {
      my constant but-true = anon role { method Bool { True }}
      my $class = anon class :: is Int does but-true {}

      $class.new( 0 )
    }

It was originally for helping to organize Perl events. It acted as an entity that could enter into contracts for insurance and rental purposes.

It was extended to have grants among other things.

Larry Wall has historically only really been influential on the design of the language. So it was not taken away, he just has rarely done anything outside of that.

I think it matters who your audience is.

If your audience is mostly programmers then just use `*`

If your audience is physicists or mathematicians then `×` or `·` may be a better fit.

When turning a math expression into code, it is often handy if the code looks a lot like the expression. Even better if you can just copy and paste it. It's hard to translate an expression wrong if you aren't translating it at all.