> It's a well written essay at least.

This is objectively wrong, going from the comments from the intended audience in this thread.

If half your intended audience had trouble understanding the author's goal or message, then it's a very poor essay. Barely a passing grade, if one were to grade it.

The whole point of an essay is to get your message across. If it can't do that, it's a failure.

>> We'll get megabytes of code that just fails sometimes, for unfathomable reasons.

> But…that’s the current situation.

Where? Bugs are fixed by humans. I want to see a ticket closed due to "can't find bug".

> If the node embeds the data item you can't link the item into multiple linked lists, but if the data item embeds the node(s) suddenly that's trivial.

Perhaps I'm missing something, but isn't it the other way around? In C, this is what I'd expect for the intrusive and extrusive:

    // Intrusive
    struct user_data_t {
       struct user_data_t *next;
       struct user_data_t *prev;
       // The object's fields
    };

    // Extrusive
    struct node_t {
       struct node_t *next;
       struct node_t *prev;
       struct user_data_t *payload;
    };

The intrusive one obviously can't be shared between lists.

No, intrusive would be (note: no pointers in user_data_t):

    typedef struct { node_t* next } node_t;

    typedef struct { ... } payload_t;

    typedef struct {
        node_t node;
        payload_t payload;
    } user_data_t;

...and if you want user_data_t to be included into multiple lists:

    typedef struct {
        node_t list1_node;
        node_t list2_node;
        node_t list3_node;
        payload_t payload;
    } user_data_t;

...of course in C now it gets tricky to get to the start of user_data_t given a pointer to `list3_node`, but that's where @fieldParentPtr comes in.

The advantage versus your extrusive example is that the payload doesn't need to be referenced through a pointer, which drastically simplifies lifetime tracking / memory management.

> No, intrusive would be (note: no pointers in user_data_t):

    typedef struct { node_t* next } node_t;

    typedef struct { ... } payload_t;

    typedef struct {
        node_t node;
        payload_t payload;
    } user_data_t;

That's exactly the same as my intrusive structure, no?

> typedef struct { node_t list1_node; node_t list2_node; node_t list3_node; payload_t payload; } user_data_t;

In C, at any rate, that doesn't give you "inclusion into multiple lists". It gives you "inclusion into at most 3 lists. The extrusive example I posted gives "inclusion into multiple lists".

So, yeah, I'm still not seeing your point.

> That's exactly the same as my intrusive structure, no?

It's not, for the reason they put in parentheses:

> note: no pointers in user_data_t

An allocation of user_data_t also allocates space for payload_t, rather than just allocating space for a pointer to payload_t. Your structure requires an additional allocation to point the payload_t* at something. The fact that they hid the next node_t* in a struct doesn't matter though.

> It's not, for the reason they put in parentheses:

>> note: no pointers in user_data_t

I feel like I am taking crazy pills: where, in my intrusive example, are pointers in the `user_data_t`?

My intrusive code sample had no pointers for the user_data_t. It's exactly the same as GP's intrusive example.

It is not you that is crazy, I have been exhausted. My bad.

He makes that claim because he doesn't like the sources, not because the sources are wrong.

Reading the wikipedia references show me that this is well studied and sourced.

Academic sources for his argument either dont exist or are so rare even he can't find them.

IOW, it's a post hoc rationalisation from him.

If we're using "did not meet the stated goal" as a bar for success, then Java also "failed", because it was developed as an embedded systems language and only pivoted to enterprise applications after being a dismal and abject failure at the stated goal.

If Java is not a failure then neither is Go.

If Go is a failure then so is Java.

Personally I think it is inaccurate to judge a mainstream, popular and widely adopted language as a failure just because it did not meet the goal set at the initiation of the project, prior to even the first line of code getting written.

> I really want to try making a language that is imperative, like really imperative, where every line must start with a verb, just to see what it would look like.

It would look like Tcl.

A bit but I don't like "set foo 32"

One way I think I can get rid of that is like this

    32 = foo;

But why do we even need variables? I think the perfect language design would be if you could just do this:

    pow(x, 2);
    pow(y, 2);
    sqrt() = result;

And maybe you could do this

    {
        pow(x, 2);
        pow(y, 2);
        sqrt();
    } + 1;
    pow(2) = result;

Instead of result = pow(sqrt(pow(x, 2), pow(y, 2)) + 1, 2); that we have today.

At that point you’re almost, but not quite into the realm of “forth”

> Any engineer worth their salt in a hiring process will recognize this.

Sure, agreed, but you aren't even going to get to the point of an engineer recognising this because you'll fail the gauntlet of HR with it's tick-boxes for tech stacks.

You could be extremely battle-hardened on fault-tolerant distributed systems from being the the Erlang trenches for the last 3 years, but because they HR person couldn't tick-off one of "Node.js", "Java", "C#/.Net" or "Python", your application won't ever be seen by an engineer.

OK, I get your point. Though in my case, of course I also know Java and Python. That's the children's toys. I have developed whole desktop applications in Java and have worked with Python for several years. Those things are not "USPs" or distinguishing at all. Many people know them.

> I swear, the affliction of failing to understand the underlying concepts upon which a technology A or B is built is a plague upon our industry. Instead, everything clearly must fit into the concepts limited to whatever “mother tongue” language a particular developer has mastered.

Ironic, since any time you post about a programming language it's to inform that C# does it better.

Not just here; someone with your nick also whined when the creator of C# made a technical deficient decision when choosing Go over C# to implement typescript.

It's hard for a rational person to believe that someone would make the argument that the creator of the language must have made a mistake just because he reached for (in his words) a more appropriate language in that context.

You have a blind spot when it comes to C#. You also probably already know it.

> So appeal to authority trumps observable consequences, technical limitations and arguments made about lackluster technical vision at microsoft?

Your argument is that you have a better grasp of "technical limitations" than Anders Hejlsberg?

You'll forgive the rest of us for not buying that; he has proven his chops, you haven't, especially as the argument (quite a thorough explanation of the context) from the typescript team is a lot more convincing than anything we've seen from you (a few nebulous phrases about technical superiority).

> but being seen as an endorsement from key C# figure is certainly a bad look.

Yeah, well, the team made their decision with no regard to optics. That lends more weight to their decision, not less.

The issue is not that Anders is incapable. His best argument was that they wanted to have the new code look like the old code. Many of the other arguments Anders brought forward were confusing, since some of them were technically incorrect. This raises some questions.

Typescript is a huge success from Microsoft in terms of recapturing developers, without them knowing. MS is not a charity, look at how little love they give to F# compared to TS.

* My personal guess is that the age old MS instinct came into play: be coûte que coûte backwards compatible, port all the bugs, do not disturb anything.

* A second reason might be that TS people might not want to learn .net because of vibes. Do not underestimate vibes. Almost everyday on HN I see Python programs being posted where most often the creator would be better of if they had learned some next programming language. Decisions are seldomly made on a technical basis. We as humans decide emotionally, sometimes with rationalizations afterwards. And so, maybe Anders was rational in acknowledging the dev-social situation as is.

Whatever the reason, this will not be without consequences. The team now has to invest in GO and now depends on Google to take TS forward. And yes, this is also typical MS, one department can easily undo the other.

TLDR: the technical arguments were mostly nonsense, but the real arguments have likely more to do with age-old reflexes and dev-cultural issues.

I'm still waiting for "You might not need React"

> When they made the MP3 format, for example, they took a lot of music and used that to create algorithms that are effective for reproducing real-world music using less data

Your entire argument is predicated on this incorrect assertion. Your argument, as is, is therefore completely invalid.

Even if we accept it's wrong (which I suspect is me being unclear: I wasn't suggesting MP3 is some kind of trained algorithm, just that humans developed it while testing on a range of music—which is well documented, with Tom's Diner famously being the first song encoded—which is how any such product gets developed, I accept the context makes it read like I was implying something else, my bad), I give a separate examples with varying degrees of similarity to training and then make my own comments, I explicitly say after this that I don't think the MP3 example is very comparable.

While I get why you'd read what I said that way given context, I wasn't clear, maybe don't reject my entire post immediately after making an assumption about my point barely any way into it.