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.
Would you mind to elaborate a bit on your system? I tried to do something similar for an algo trading system, but in the end I hadn't enough entities to justify the approach.
I think there's a widespread misconception about the reason ECS exists and what problems it solves. It's a design for a general-purpose game engine where it solves the problem of having some conception of the game world and the things that make it up without knowing in advance what those things will be. This is a common issue with loads of different approaches in game engines.
ECS contrary to popular imagination doesn't have to be implemented with data-oriented principles and there are lots of implementations, particularly in dynamic languages that use the same design without the performance boost you might get once you do follow them. Once you unpick the data-oriented rabbit hole you quickly discover it also largely complicates the original design.
If you have a specific thing in mind then use the data-oriented principles on that and skip building something general purpose. This works for games as well as business applications. It'll be much simpler and easier to make performant.
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.
Thanks. I admit I haven't often used Moose et al., or any Perl OO system, except in a project that was set up by someone else in which I only occasionally added a method.
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;
I know which of the two I'd rather write :)
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?
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.
This a legit post. Not sure why it is downvoted. Typical preachy HN.
Zuckerboerg wants the company to be treated like a publishing platform, just like google. But when legislations they are just a service provider. Stick to a story
>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?
It's a communication platform that some are using to communicate good things and some bad. People seriously talk like Zuckerberg is sitting in his office deciding which country to bring genocide to when it's absurd to think he has made a decision to that effect.
At this point I'm glad nobody owns email (officially) since people here would be calling for it to be censored and for email's CEO to stop causing human rights abuses, too.
I don't have a full solution, but as much as possible we need direct democratic control over how the algorithm works and tools to verify that it follows the agreed rules. Social networks should not be owned by "some guy" just as the court and the police, rather work according to the rules of society.
Zuckerberg should probably be compensated for the wealth he created, but he is not entitled to this level of control over sociaty.
Any sort of public control over ranking algorithms will create a situation where the spammers and scammers win. Even sites that rank by timeline suffer from this (Craigslist). I don't see a situation where there is enough control for external people to understand the intricacies, without suffering from spam and eliminating any usefulness.
As an example, check out social competitors like this Holonis (www.holonis.com). They are just pure spam and self-promotion - what naturally happens when people who are incentivized to figure out the algorithm for profit are given more clear mappings between inputs and outputs.
I imagine participation being tied to verifiable (but potentially private in some contexts) real world identity. This is needed for voting to make sense too. In such arrangement it seems not difficult to discourage spamming. As I see spamming strives in circumstances where it is possible to create lots of untraceable identities almost freely.
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.
Sure, it's just funny that your example of "thirty years later" is code that someone could in principle have written in the same year (well, almost - I imagine Perl 1 might require some changes from the Perl 5 version).
If I had to show how far we've got since then, and how different the experience could be for a novice programmer, I think I would display a .GIF where I press F12 in the browser, and write two lines of Javascript in the console, something like:
var words = await fetch("some online JSON dictionary").json();
var lexed = "insert sentence".split(/punctuation regex/).map(w => words.indexOf(w));
I don't write JS habitually and I'm on my phone so it's probably got some mistakes, but you get the idea!
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.
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.
> Well, duh :) Perl's still more popular than people think.
There is no way to define the word "popular" that makes this a true statement with regard to Perl 5 or any future development thereof shooting for backwards compatibility. -- I hate to be the negative nancy in this regard, but I seriously think that this is a cold and hard truth that is causing a lot of suffering because of people who fail to acknowledge it. (Disclosure: I work in a shop that forces me to do Perl, and I hate it with a passion).
One definition of "popular" would be: You ask programmers "Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?" [1]. 48.2% will then answer Python compared to 6.75% who will answer Ruby and 2.46% who will answer Perl.
Another definition of "popular" would be: Drilling down into those 2.46%, you ask them whether they love doing Perl or dread having to do Perl. 64% will answer they dread it [2]. This definitely agrees with my own experience working in a Perl-shop. Most people say they'd rather be doing something else. The company just feels that it doesn't make economic sense, so we're stuck with it.
For the other ones, I seriously suspect a case of Stockholm syndrome or something of the sort. -- Those would be the ones corresponding to the 0.86% (0.0246 x 0.36 = 0.00855) who say they do Perl and they actually like it.
The Perl code that's currently out there is literally sitting on top of an ecosystem that is rotting away beneath it [3]. For legacy code, the argument can sometimes be made that the situation is not bad enough yet to warrant moving away from Perl. But starting a new greenfield project in Perl 5 is, in my opinion, nothing short of professional malpractice.
So Perl is pretty much relegated to the hobbyist sphere, with Perl 5 maybe being of interest to retrocomputing aficionados. In that sense 80s-BASIC is very much the proper comparison class. Not modern-day Python or Ruby.
With Perl 6 / Raku not offering a viable migration path, one has to look at it the same way one would look at any other modern-day programming language upstart, with all the problems that entails (like lack of ecosystem, etc.)
Introspecting my own psychological experience now, I would go as far as to say that the open source developer community keeping Perl alive is perhaps the only group of people who truly meet the definition of giving the world something for free out of the goodness of their hearts (even in a way that ends up putting money in my own pockets), but who I actively dislike because of that. I feel like: If only Perl 5 would die a sudden death instead of this slow creeping demise, then, maybe, for me too this torture could finally come to an end.
FWIW, the Raku Programming Language nowadays *DOES* offer a valid migration path in the form of the Inline::Perl5 (https://raku.land/cpan:NINE/Inline::Perl5) module. This basically allows you to use all of CPAN that doesn't do source filters.
This allows you to gradually move your code into Raku, replacing Perl 5 modules by Raku ones as needed.
As we're about to reach the 2000 modules in the Raku ecosystem mark, it should be noted that many modules from CPAN are not needed, as they're builtins in the Raku Programming Language. And many CPAN modules have outlived their usefulness in any programming language.
Thanks for the pointer. I will look into this with great interest and get a discussion going within my company about whether this implies that we would want to start permitting Raku into our codebase. But I very much doubt that this permission will be granted in the end.
What's the best way to do that these days? IRC was the most active Perl place back in the day and the best place to get help, where's the best place for people to ask for help these days?
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.
To clarify this: if v5.32 can run your code, you should be safe. There have been various small changes in Perl 5 that might not handle something you wrote in 1995.
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?
For those who are curious, here's a very brief introduction to ECS: https://dev.to/ovid/the-unknown-design-pattern-1l64