I’m glad it doesnt.

Git, probably

Please clarify, OP, did you mean

• hard to read semantically
• hard to read syntactically
• hard to relate how one could come with such a crappy idea, even considering all constraints of their time
• takes a lot brain real estate (justified or not)

?

Thanks.

Is this to rpm-based distros what Mint is to deb-based distros?

From what I can see it is a slightly more detailed take on dependencies, loose coupling etc. Seems like it is formal and a bit weird, though. And a few part seem… extrapolated. So, no wonder it never caught on.

It’s not exactly clear to me who is supposed to be more comfortable.

Anyhow:

• Avoid commands that require their own DSL. Most DSLs are ad hoc garbage, in particular when it comes to UX and UI design.

And the logical conclusion of this is there is a non-zero chance you get to enjoy the opportunity, no, the priviledge to maintain that 100k loc codebase written in someones personal PHP dialect. Lucky you.

Just wait until you learn that debuggers for XSLT exists. Wait, that’s no reason to smile.

That sentence seems correct. As for your question, you’d rather have to ask yourself: When would you pay for a programming language?

Back in the old days before internet and commodity hardware, before easy distribution, before non-trivial software, before basic compiler knowledge was common people were easily impressed, so naturally you could sell your compiler for primitive grug BASIC.

Today, that situation is different. A language by itself is meaningless, a risk, even, in some ways. A while back some developer of REM Objects was bitching about in the old aggregator on how nobody wanted to spend money on their special proprietary BASIC. Like it was just another product. They don’t know how to use a computer how programming languages work. This extends to even finding users willing to use your stuff for free. I don’t want to knock on REM Objects in particular, you know you could add way more examples like Seed7, every lisper ever etc., but let’s get into why people pay for programming languages.

• extreme vendor lock-in of platform, hardware, whatever (but you almost always have your language bundled with something else in the first place, because…)
• the point is a feature beyond the language (think matlab, labview, SAP, Excel or Coldfusion 8bitguy mentioned)
• dubious support contracts (think Oracle JDK)
• enthusiasts you can milk for life support and dumbfucks that fall for your next gen graph AI DSL whatever bla
• extremely great developer experience (but we live in an age where megacorps create languages and infrastructure for improved experience for free, so, good luck with that these days)

people don’t want to admin

Exactly right.

You can not perfect old languages, since there are a lot of features that you can not add on or change afterwards, OP. Not in a worthwile way. This is not a philosophical question, it wasn’t for a lack of trying. And since there aren’t enough skilled people in this niche, fashion driven field, expect history to repeat itself and some langs at best get 60 to 80% right.

Between the lack of null safety (which really shouldn’t have been a thing since the 90s), the incapacity in community management and lack of focus of the core devs mentioned by Gnome Kat and glad_cat, I tried Dlang in roughly 2015. It was an OKish experience for trivial tasks, but I noticed the amount of churn in dub packages.

TL;DR: I would not. And for the same reasons, I wouldn’t recommend Scala either.

assuming you’re meaning that the interpreter is called ad-hoc basically and isn’t the entirety of the system.

That was my assumption. Basically, that interpreter would have to run small snippets here and there typically on an irregular base. Thanks for reminding, I should probably clarify that as well.

If your interpreter can execute the systems in parallel,

Well, the way I thought of it was that the interpreter gets called in the systems in the first place, so that might become a problem.

Maybe I’m misunderstanding what the system is, is click_handler in the post a system, and if so, do systems only declare a single component of an entity as their input?

The way I figured would make sense was that, in the engine/game itself, the BoundaryComponent would have an additional field for registered scripts or that there would be an additional component just for registered scripts, to keep components lean. Not sure if that actually worked out in reality.

Then there would be a system for clicking on boundaries that would call such a script, if available. It’s probably a poor example, but since that system doesn’t touch much else, only the boundary component gets passed into the script. That’s not supposed to be a rule, though. I probably should clarify that on the post later on…

Makes sense, I guess. I really can’t comment on the wider implications with an ECS, though.

this case, would the components be combined into a list? Basically you’d have a BubbleComponent[] attached to the entity instead of just a BubbleComponent?

Yes.

I like the ideas presented in the article otherwise. I vaguely remember TypeScript having some sort of reflection support that Angular took advantage of or something. I wonder if that can be used to create a scriptable ECS like proposed in this article?

I don’t know, I’ve seen some outdated version of Angular only for a couple of hours in my job now. But I’m sure, those sweet layers of metaprogramming and DI will be a bliss to debug. Not.

The next example which seems to create two bubbles on the same entity is just as confusing to me. If I were to query for those bubbles, would I iterate over each of those bubbles in separate iterations, but all other components that are part of this query are the same?

No that would be crazy.

No, but seriously, the find operator is supposed to take only one type and not merge the types. ECS seems close enough to relational databases, but not that close.