Ovid

I've tried to push entity-component-systems (ECS) for non-game applications. A financial company in London took that advice to manage the complexity of their system since it was such a good fit.

For those who are curious, here's a very brief introduction to ECS: https://dev.to/ovid/the-unknown-design-pattern-1l64

This was brought up a few times. There were several issues with that approach.

* `bless` and `class` aren't topologically equivalent: you can't twist and warp one into the other

* We've seen small, incremental steps get beaten to death by bike-shedding every step

* Sometimes it's hard to see the big picture when you're looking at the individual details

It's that first point that's really the killer here. Perl used `bless` and `@ISA` ("we have methods" and "here's where to find them") and that was all.

You want state? Figure it out.

You want encapsulation? Figure it out.

You want to work around MRO bugs? Figure it out.

You want to know if something in the symbol table is a subroutine or a method? Figure it out.

You want composition? Figure it out.

Much of what we wanted just couldn't be easily done building on a broken foundation, but there's so much excellent work out there which already solves these problems for class-based OO, we decided to take advantage of what others have already learned.

And in the new class syntax, when it's done, that's (roughly):

    class Point {
        field $x :param :reader;
        field $y :param :reader;

        method as_string() {
            return "($x,$y)";
        }
    }
    my $origin = Point->new( x => 0, y => 0 );
    say $origin->as_string;

The main limitation is that we don't have the `isa => 'Int'` check. That's largely because adding types is something for the entire language, not just this new syntax, so it had to be delayed.

A senior member of Ethiopia's media accused Facebook of “just standing by and watching this country fall apart”.

Why the hell does one company get hold so much power in the world? More to the point, why does Mark Zuckerberg, an apparently immoral man-boy, get to make decisions like this?

Remember when Myanmar used Facebook to coordinate/incite genocide? https://www.nytimes.com/2018/10/15/technology/myanmar-facebo...

Or when Facebook was being used in Kenya to orchestrate vigilante murders? https://www.bbc.com/news/world-africa-47805113

Or how about when Zuckerberg refused to introduce any controls to livestreaming after the New Zealand mosque massacre was livestreamed? https://www.thewrap.com/mark-zuckerberg-defends-facebook-liv...

Facebook only reluctantly banned white supremacists groups. https://www.nbcnews.com/tech/tech-news/facebook-bans-white-n...

Or how about in 2016 when a young man's murder was livestreamed and Facebook refused to take down the stream "because it doesn't violate the company's community standards." https://money.cnn.com/2016/06/17/technology/facebook-live-sh...

How the hell did we get into such a dystopian hellscape where one company so brazenly, openly, supports evil? Cyberpunk as a genre is dead because it's no longer fiction.

Oh, that is a long and complicated story.

Perl 6 was announced a long time ago, but it took many years of development and planning and I (like others) used to joke that Duke Nukem Forever was going to be written in Perl 6. And then we got egg on our face when Duke Nukem Forever was released first. (And it turned out to be a turkey).

However, many clients I spoke to at that time were telling me they wouldn't upgrade their Perl code because they were waiting for the new version ... which was seemingly never going to arrive. Worse, it became clear that Perl 6 was a new language, with common roots, but it wasn't like the Python 2/3 split: a wholesale rewrite of code would be necessary, or try to use a Perl 5 compatibility mode that may or may not have proven useful.

So companies weren't upgrading, Perl developers were fighting, people were leaving the community and the Osborne Effect (https://en.wikipedia.org/wiki/Osborne_effect) could be renamed the Perl 6 Effect (I'm aware that the Osborne Effect is more complicated than it's often portrayed).

Worse, Perl 5 couldn't upgrade to Perl 6 because that version number was taken. Perl looked, to the outside world, like it wasn't upgrading any more. I even had one guy screaming at me at a Linux Conference about how Perl is shit, hadn't updated in 20 years, and ticked off a bunch of "facts" about Perl, most of which were objectively incorrect at the time, but Perl could no longer get its message out.

There was discussion about leap-frogging the version number and going straight for Perl 7, but that caused even more fights, more people dropping out of the community, and we fractured. We tried saying "the name of the language is Perl 5 and we're upgrading every year—we're currently on version 34—but that didn't satisfy anyone, either.

Eventually, Perl 6 was renamed to Raku (http://blogs.perl.org/users/ovid/2019/10/larry-has-approved-...) and that freed us to upgrade our version number, but to what? Sawyer X, the former Perl Pumpking (development manager) proposed the Perl 7 project, but for many reasons, that also caused much anger.

So today, we have Perl. There are ideas of moving to Perl 7, but much work needs to be done. My Corinna OOP project is likely part of that work and the Perl Steering Committee has met with me to say they'd like Corinna in core, but slowly, step-by-step, to ensure that we don't push too much into the core and make mistakes we can't easily back out of.

I have more ideas about what is needed to get to Perl 7, but they'll largely wait until after Corinna is in core and fleshed out. It's a lot of work and the team working on Corinna (making great suggestions and also helping me not make boneheaded errors), have put in a lot of effort to create something we can turn into a proper RFC. Paul Evan's Object::Pad (https://metacpan.org/pod/Object::Pad) is a testbed for many of these ideas.

So, we're getting there, but slowly. However, it appears to be moving along more smoothly than other efforts in the past. The fact that the goal is more modest helps.

Yes, late December, 1987, after the events I describe. It was released on Usenet, as I recall. I didn't even know what Usenet was back then. For me, it was pretty exciting to dial up a BBS, crash their software, and read through the code that the BBS was written in (and later contact the sysop to tell them how to replicate it).

I doubt I could have even compiled the software onto a COCO 2 computer.

Well, duh :) Perl's still more popular than people think. I saw on the Board of Directors for the Perl foundation for years, regularly speak at conferences for it, have released tons of open-source software for it, and currently am working on the Corinna project to improve the core OOP for the language: https://github.com/Ovid/Cor

Given that this site, like so many others, is to help me get work, I think it's natural I'd use Perl in my examples.

As a short summary about Perl 7:

If your Perl is old-school, that's OK. Use Perl 5 and we'll keeping supporting you.

If you your Perl isn't old-school, use Perl 7 and get new features.

If you're not sure, ask us and we'll hold your hand to help you understand.

We're here to make sure you're OK.

Just to be clear to everyone: this doesn't break anything. If you continue to use Perl version 5, you're fine. If you want to upgrade your major version of Perl, then of course you need to know what that means.

I've known Jeff for many years, both as a friend, an employee, and a fellow presenter at conferences. I've hung out with him drinking beer in numerous countries around the world. If there is one thing that I think sums up Jeff it's his beautiful, and sometimes dark, sense of humor.

So while it grieves me, I'll make the joke that Jeff would make were he still with us: "I was just trying to figure out how to avoid the corona virus."

He was brilliant, quirky, and fun to be around. I can't even begin to describe my grief right now.

I'm also curious about the "no single-purpose accounts" guideline because I can't find that in the guidelines you have linked to. Have I overlooked something? I sounds like you might be referring to this:

Don't solicit upvotes, comments, or submissions. Users should do those things when they run across something they personally find interesting, not because someone has content to promote.

But there was no submission solicitation here. If that's what you're referring to, perhaps this could be reworded to clarify?

Red looks interesting. Though I don't like the mapping of tables to "model". In general, I find that a model should be a consumer of an ORM, not the ORM itself. Otherwise, you expose to much to the business layer and it's harder to refactor.

For example, if you have a column on table A and you later need to move that to table B, a clean model can encapsulate that change. Hard to do when the ORM is being treated directly as the model.

I get hired all the time to fix legacy systems in Perl or to build new systems in Perl.

We're still out there, but it's not "cool" to talk about.

The https://taustation.space/ game runs great on Perl 5, but yes, with a robust Perl 6, many things would have been easier to implement. But by "robust" I don't mean just the language—I also mean the ecosystem.

There is no DBIx::Class (or related schema loader) for Perl 6. I don't know how mature the web frameworks are. Or even basic stuff like Excel reader/writers (we use lots of Excel for backend data analysis).

On the other hand, most of the async stuff we currently use can be thrown out. With raku's gradual typing, our in-house type libraries can be tossed out. Our local modules for making it easier to write clean procedural and OO code could be thrown out.

And the raku code would be far more concise and easy to read. Here's a simple Point object in Moose:

    package Point {
        use Moose;
        use overload '""' => \&Str, fallback => 1;
        use Moose::Util::TypeConstraints;
        subtype "PointLimit" => as 'Num'
            => where   { $_ >= -10 && $_ <= 10 }
            => message { "$_ must be a Num between -10 and 10, inclusive" };

        has [qw/x y/] => (
            is       => 'rw',
            isa      => 'PointLimit',
            required => 1,
        );

        sub Str {
            my $self = shift;
            return sprintf "[%f,%f]" => $self->x, $self->y;
        }
    }

    class Point {
        subset PointLimit of Rat where -10.0 .. 10.0;
        has PointLimit $.x is rw is required;
        has PointLimit $.y is rw is required;
    }

    class PointLimit:
        def __init__(self, name):
            self.name =  name
        def __get__(self, point, owner):
            return point.__dict__.get(self.name)
        def __set__(self, point, value):
            if not -10 < value < 10:
                raise ValueError('Value %d is out of range' % value)
            point.__dict__[self.name] = value

    class Point:
        x = PointLimit('x');
        y = PointLimit('y');

        def __init__(self, x, y):
            self.x = x
            self.y = y

        def __str__(self):
            return "[%f,%f]" % (self.x, self.y)

This has been a huge deal for the Perl community.

First, it was thought that Perl 6 would be the replacement for Perl 5.

But it was long ago recognized that there was no clear upgrade path from Perl 5 to Perl 6, so it was agreed that Perl 6 was a "sister" language to Perl 5 rather than the successor.

Except that many people expected that Perl 6 would be the replacement, so that stalled many projects. So an "alias" for Perl 6 was created, but that didn't seem to help.

Larry has now agreed with the change and Perl 6 will be renamed to "raku" and Perl 5, which has regular, major releases every year, will now be able to simply be "Perl" and be free to continue on its own way.

If I had my choice, I'd program in raku because it's a lovely language addressing many pain points (including being one of the few dynamic languages with a working concurrency model). But it's not adopted widely enough yet for that to happen. Time will tell ...

"author of the post in question"

God, what a horrible typo :)

Perl6 has been under development for over a decade at this point, and this equivocating statement is the best that can be said about performance? If the "work is clear, the goals are straightforward" and Perl 6 should easily outstrip Perl 5 on performance, then by gosh they should demonstrate that.

As the other of the post in question, I refer you to this presentation: https://www.youtube.com/watch?v=QNeu0wK92NE

It's fairly decent, but there's still a huge amount of backstory left out of it. In short: in many areas Perl 6 is pretty close to on par with most dynamic languages today. In other areas, performance is still an issue.

If performance is a major blocker to adoption and it's as straightforward to fix as suggested - it should get done.

(Disclaimer: I'm not the one doing the work mentioned below)

It's being done, but there's a lot of work. There's compile-time analysis with constant folding, eliminating unnecessary scopes, inlining native ops, code rewriting to faster equivalents, etc. But that can only take you so far.

The run time optimizer is hard work, but that's where the good stuff is at. There's a very lightweight optimizer that builds a statistical model of the program and that's very helpful. For example, we can tell if a codepath is hot or not and that model than lets us do all sorts interesting stuff, such as realizing that a hot method is always getting called with an int, so we can skip multi-dispatch lookups, assume an int, and just have a fast guard in place.

We can inline code where appropriate. We can do more escape analysis. We can reoptimize code that's inlined at runtime. We can see an int->int and realize that we might not need to box and unbox those as objects. See also: https://jnthn.net/papers/2019-gpw-ea.pdf

In short, there's a ton of stuff to do and it's being done.

You're not missing the point. I apparently didn't do a good job of making it clear.

I'm primarily talking about external data/services. Anything which you would ordinarily consider "suspect", such as "reading from a third-party API", is the target here.

The odds of printf() failing are so ridiculously low that I am not going to write tons of code to handle this case. It's not worth the money.

The odds of putMoneyInCustomerAccount() failing are much higher, and the consequences are much graver, so that's a perfect candidate for saying "maybe just throwing an exception ain't the best solution here."

In the case of OOP, particularly in Kay's vision, these objects might be written by someone else, using code we don't see, and thanks to isolation, might be connecting to third-party services which do all sorts of interesting things we don't know about or need to care about. Thus, they're not trusted.

If I wrote the object or I can read its code, and I know what it's doing, I'm not going to sweat it.

I'm also not arguing that we should always make the code that robust. Some things you can recover from or your budget might not allow you to make the system more robust.

Sorry, I wasn't clear.

It wasn't quite like that. It was to help the pharmaceuticals work together to "pool" talented researchers who had the required training to proceed in the clinical trials. If a bunch of companies don't share this data, they drive up their costs tremendously in trying to find and recruit qualified doctors for their trials, pay to train them, and then have them conduct studies, only to find out that the doctor in question doesn't recruit any candidates themselves, or fails to report results.

If, however, they pool their resources, they can find qualified doctors who have already taken the training and are known to participate well in trials. They can then correlate that with populations who might benefit from the drugs in question and save a fortune (and possibly many lives), by reducing the cost-to-market.

The matching algorithm was actually very strong, but there was still a human step, from the pharmaceutical companies, to verify that these were the researchers they were seeking.

This is the original discussion: https://news.ycombinator.com/item?id=19968496

Alan Kay says he did.

"I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea."

Source: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...

As a huge fan of Perl and very comfortable writing POD, I despise POD. I would much prefer Markdown for documentation. It's easier to write and easier to read. Just try creating lists in each.

Did you catch the part about duplicate/misspelled addresses? The design wasn't even fit for the original use case.

That doesn't help when you need to review each individual branch to find out if it needs to be worked on, merged, or deleted.

I'm confused. What's so hard to reason about that? It's very obvious that it prints 2016. Maybe "infinite lazy lists" isn't something that most mainstream languages consider, but honestly, they're very handy and hardly "self-indulgent mucking about."

(Though I'd probably use an asterisk instead of the infinity symbol)

You are completely wrong and people with your attitude are part of the reason we expats are suffering.

Studies repeatedly show that that that majority of almost 8 million Americans living abroad moved to look for work, to find love, explore the world, do volunteer work, teach, and so on. We're largely middle class, just like most Americans back home. We're not rich (many of us teaching or volunteering are dirt poor), but we're putting up with a tax horror that Americans back home would revolt over if they had to endure it.

Actually, no. The US has tax treaties with roughly 1/3rd of the countries in the world (source: https://www.irs.gov/Businesses/International-Businesses/Unit...). If you're not in one of those countries, too bad.

Further, these tax treaties differ from country to country and don't always offer the same protections. Here, read the 42 page US/France tax treaty (https://www.irs.gov/pub/irs-trty/france.pdf) and try to figure out how you'd be impacted if you were living in France.

We expats don't just have to hire accountants to do our taxes, we often have to hire international tax lawyers, EVEN IF WE DON'T EARN ENOUGH TO PAY US TAXES!

Studies have repeatedly shown that the majority of expats are abroad to find a job, to teach, to volunteer, or for love. We're taxi drivers, waiters, English teachers, farmers, computer programmers, and so on. We're normal people who are being massively screwed by rhetoric in the US.

Sorry to break it to you, but if you're a non-US citizen but a permanent resident in the US, you're a "US person": https://www.law.cornell.edu/cfr/text/22/120.15

This means that you're completely subject to US tax law, even if you leave the US. Congratulations! You're now subject to FATCA!

Junctions are insanely useful once you get used to them and I use them frequently. Basically, any time you have a list and you're worried the properties of any, all, or none of the list members (hmm, just about all lists), then junctions are often a very clean way of expressing the issue.

    if all(@ages) >= 18 {
        # let 'em in the club
    }

    if any(@ages) < 18 {
        # don't let 'em in the club
    }

    if none(@ages) < 18 {
        # don't let 'em in the club
    }

Perl 6 also has gradual typing baked in. Other languages have gradual typing as a library, but that often fails dramatically (http://blog.circleci.com/why-were-no-longer-using-core-typed...). In Perl 6, because it's built-in, not only are the failures described something Perl 6 can avoid, but there are also plenty of type checks Perl 6 can avoid at run time with integrated gradual typing (imagine that benefit in hot loops).

You could even combine that with native junction auto-threading and presumably have super-fast comparisons where the needs for checking types is eliminated at run time because it's already been done at compile time. If you do that with libraries, it's awfully tricky to get right, if not impossible.

Much of the "hatred" seems to come from those who have a lot of preconceived notions about Perl (either 5 or 6). However, I look at the people who approach the language with curiosity and no baggage, and the reactions I often see range from "that's cool" to "holy shit, that's cool."