[Dr_tldr]

You didn't present an argument, you just put my words in quotes and then made an appeal to an irrelevant authority. John Carmack doesn't do web apps, he does high-end 3D engines You couldn't pick a more different field and still be in the business of writing code for computers.

[adamnemecek]

> You didn't present an argument,

Neither did you. That link you posted is laughable. Like there isn't a single agreeable thing about the research it presents and the methodology by which they arrive at the conclusions it makes.

> to an irrelevant authority

Is that kind of like appealing to "experience" and "team experience"?

> John Carmack doesn't do web apps, he does high-end 3D engines

Is this an admission of the possibility that types work in one subfield of programming? If so, how is that subfield different from another subfield.

[Dr_tldr]

Have you noticed that you never speak in concrete terms, only pejorative adjectives? Saying you find something "laughable" and not "agreeable" is a feeling, not a refutation.

[adamnemecek]

> Have you noticed that you never speak in concrete terms, only pejorative adjectives? Saying you find something "laughable" and not "agreeable" is a feeling, not a refutation.

Well, neither do you.

I mean, if I have to spell it out for you (but the summary is that they take languages that aren't good examples of typed languages and make conclusions based on those). But more detailed breakdown:

First slide. They make their own languages (first issue) snd have people solve small problems (second issue). Advantages of static typing really kick in for larger projects. Also, different type systems have different advantages so this comparison holds little informational value

Second point, they are talking about code that has already been written, it doesn't say how much time was spent making the code correct. I really don't know what to conclude from their data though.

> His point there is that all that static boilerplate you write to make a statically typed language happy,

He's ignoring statically typed languages with type inference. They have been around since the 70's.

> Some other study compared reliability across languages and found no significant differences. In other words neither static nor dynamic languages did better at reliability.

How do you measure readability (notice that good research would indicate this).

> Part of that was reflected in size of code. Dynamic languages need less code.

They are comparing python vs C/C++/Java. Code terseness is orthogonal to type systems. Why do they not include say, Haskell?

> Another point he made is that writing static types is often gross and unmaintainable whereas writing unit tests not.

Hahahaha, what? Unit tests are more maintainable than types? And he gives a C++ example?

[Dr_tldr]

So it seems like the logical thing to do would be to create a study with better construct validity since it seems you don't think my evidence is any good and you definitely don't have any of your own.

If we're both just throwing around opinions this is no different than arguing tabs vs spaces. I've noticed that Typescript tends to be embraced by teams with lots of subpar enterprise Java developers with limited knowledge of Javascript. The same is also true of Angular, so it's a good fit here, but it's more for mitigating a lack of personal knowledge and organization standards than a general benefit.

[adamnemecek]

> So it seems like the logical thing to do would be to create a study with better construct validity since it seems you don't think my evidence is any good and you definitely don't have any of your own.

Look into programming language research.

> I've noticed that Typescript tends to be embraced by teams with lots of subpar enterprise Java developers with limited knowledge of Javascript.

Holy fuck are you full of yourself. You are writing JS, it's not rocket science.

[Dr_tldr]

Uh, my whole point is that JS isn't that hard to learn, so why invest so much time trying to make it look like Java and write worse code in the process?

Thanks for helping my argument, I'm glad we agree that you're a bad engineer.