If a third party takedown system is poorly implemented (and it's pretty hard to create a balanced takedown system at scale), it may become more effective to abuse it instead of using DDoS.

```dart (await taskA()).doSomething() (await taskB()) + 1 (await taskC()) as int ```

vs.

```rust taskA().await.doSomething() taskB().await + 1 taskC().await as i32 ```

It gets worse if you try to compose:

```dart (await taskA( (await taskB( (await taskC()) as int )) + 1) ).doSomething() ```

This often leads to trading the await syntax for `then`:

```dart await taskC() .then((r) => r as i32) .then(taskB) .then((r) => r + 1) .then(taskA) .then((r) => r.doSomething()) ```

But this is effectively trading the await structured syntax for a callback one. In Rust, we can write it as this:

```rust taskA(taskB(taskC().await as i32).await + 1).await.doSomething() ```

> Yes it does. How would you know?

Better question: why being a good programmer guarantees you good knowledge about technical definitions? Being a good mason doesn't mean you have the formal knowledge of a civil engineer.

Since you failed to cite any third party source for definitions, whether your definitions are actually conventional depend solely on your authority as a programmer, in contrast to me, who cited Wikipedia (and there are many others I can cite too). An attack on your authority is no longer a fallacy, but, towards me, it is, since I never relied on my authority as a programmer.

Never mind the fact that being a good programmer doesn't mean you know the definition of technical terms.

From HN guidelines:

> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

No, they aren't.

> You should probably learn how to program before arguing all this stuff.

Notice how I didn't reveal whether I program or not, yet you still made assumptions about it. I suspect that you either are a poor programmer or a troll.

Taking a cursory look (which is already beyond my responsibilities) at https://github.com/redxdev/ECS/blob/master/ECS.h, by searching "class ECS" and "struct ECS" and "EntityComponentSystem" wields no results.

Also, remember, it's not my responsibility to search to prove your arguments. Burden of proof is on the claimant, as it goes.

Or it could be just you. Even presuming you're a good programmer, that wouldn't make your arguments good by default.

> Data structures are parts of the program that hold data.

Not according to Wikipedia:

> In computer science, a data structure is a data organization and storage format that is usually chosen for efficient access to data.

ECS doesn't stipulate any storage format, as shown by the previous definitions, only that your application will be architected around Entities, Components and Systems. How they are stored/managed is up to the programs/frameworks/engines to decide, and this storage is just one concern an implementation may have, just like how storing ViewModels is just one concern of a MVVM framework, but not all.

I'm no stranger to using unorthodox definitions, but I would prefer if you were upfront that your definitions are unconventional, rather than pretend that they are common sense without citing any third party authority.

Even though you have to actually substantantiate this, for the sake of brevity, let's go with it. All you have crossed is a single potential cause, not proven a particular one.

> Have you ever programmed before?

Let's say I haven't. How would it impact your argument? Whether I'm a programmer or not won't magically substantiate your position.