What's up with the typescript rant? Don't we have decades of research about the improvements in productivity and correctness brought by static type checking? It starts out strong but stuff like this really detracts from the overall point the article is trying to make, and it stands out as an incorrect and unjustified (and unjustifiable) point.
The whole thing is basically you can't know anything, and personal experience can't be trusted. So we are all helpless until "Science" tells us what to do. Until then sit on your hands.
Where is the proof that Javascript is a better language than Typescript? How do you know if you should be writing in Java/Python/C#/Rust/etc? Probably should wait to create your startup lest you fall into a psychological trap. That is the ultimate conclusion of this article.
It's ok to learn and experiment with things, and to build up your own understanding of the world based on your lived experiences. You need to be open minded and reevaluate your positions as more formalized understandings become available, but to say it's too dangerous to use AI because science hasn't tested anything is absurd.
> Where is the proof that Javascript is a better language than Typescript?
This is an interesting question really. It feels like it would be really hard to do a study on that. I guess the strength of TS would show up mainly as program complexity grows such that you can't compare toy problems in student exams or what ever.
> The whole thing is basically you can't know anything....
Well that position is hopelessly circular, filled with sophistry and fallacy.
Descartes proved that one wrong in the 1600s. "Cogito, ergo sum,"
> Where is the proof that Javascript is a better language than Typescript?
Any 'best' question relies upon an answer to the question of for what objective purpose. Not providing that answer, is the same as dissembling circularly, and any conclusion based on that is more likely to be false than true. False beliefs in this manner are by definition, delusion.
As far as I know we don't have decades of research about the improvements in productivity and correctness brought by static type systems.
We have one study on test driven development. Another study that attempted to reproduce the results but found flaws in the original. Nothing conclusive.
The field of empirical research in software development practices is... woefully underfunded and incomplete. I think all we can say is, "more data needed."
hwayne did a talk on this [0].
If you ever try to read the literature it's spartan. We certainly haven't improved enough in recent years to make conclusions about the productivity of LLM-based coding tools. We have a study on CoPilot by Microsoft employees who studied Microsoft employees using it (Microsoft owns and develops CoPilot). There's another study that suggests CoPilot increases error rates in code bases by 41%.
What the author is getting at is that you can't rely on personal anecdotes and blog posts and social media influencers to understand the effects of AI on productivity.
If we want to know how it affects productivity we need to fund more and better studies.
> As far as I know we don't have decades of research about the improvements in productivity and correctness brought by static type systems.
I seem to recall at least some research dating back to the 90s on the topic, which showed how much better (by some metric I can't remember) Ada was wrt most other languages of the time.
"Ada is more productive than contemporary languages" is a much narrower statement than the implied "static typing is always more productive and correct than dynamic typing"
> Don't we have decades of research about the improvements in productivity and correctness brought by static type checking?
Yes, we have decades of such research, and the aggregate result of all those studies is that no productivity gain can be significantly demonstrated for static over dynamic, and vice-versa.
Not sure what result you are referring to but in my experience, many of the academic research papers use “students” as test subjects. This is especially fucked up when you want to get Software Engineering results. Outside Google et al where you can get corporate sanctioned software engineering data at scale, I would be wary most academic results in the area could be garbage.
> the debate about types, TypeScript, and web development is, for example, largely anecdotal gossip not backed by much in terms of structured research
I'd be interested in the type of structured research the author is interested in. Could it also be researched whether Go or PHP is better for web development? In some sense, I guess.
Both are probably more efficient than writing Apache extensions in assembler, but who knows?
It’s ironic as static typing exists precisely because developers don’t trust their instincts?
It’s a formal acknowledgement that humans make mistakes, implicit assumptions are dangerous and that code should be validated before it runs. That’s literally the whole point, and if developers by type were YOLO I’ll push it anyway, TS wouldn’t have got anywhere near the traction it has. Static typing is a monument to distrust.
You mean like the autocomplete server/LSP shows you the results faster if you're doing TS than JS? Sounds like a weird editor quirk to bring up if so. In neovim the autocomplete is as fast in JS as any other language, not sure why it wouldn't be like that for you.
No, it's because TS adds information. Pure JS doesn't know what variable "foo" is (is it a potato? is it an array? can it be null?), but if you assign it a type like Map<string> then now it knows what kind of data it can hold, what you can do with it, etc. Now you know you can do foo.get() and your IDE will tell you as soon as you've typed `foo.`, but if you used pure JS, lol how is it supposed to have any idea what methods exist?
It lets you chain data from one task to another based on knowing what possible and available given the types. That information just straight up doesn't exist in JS code, unless you write JSDoc comments all over with that information as static analysis hints. But why not just embed that information in the language itself instead of tacking it at the top of every chunk of code, much more elegant and allows way more power.
Even if you used JSDoc, you still need that static analysis tool to exist, and hey, that's exactly what TypeScript is. It's both a language definition for augmenting JS with types, but it's also a transpiler which takes TS code and spits out JS code, _and_ it will tell you if there's problems with the types. But since that engine exists, you can plug it into LSP and so on.
Remember, LSP exists _because_ of TypeScript. VSCode exists because of TypeScript. The team that works on VSCode and came up with LSP did it because they wanted TypeScript to integrate with VSCode and they had the foresight to build something generalized that could be used for ANY language.
> Don't we have decades of research about the improvements in productivity and correctness brought by static type checking?
correct me if I'm wrong those studies would not have looked at TypeScript itself, which for all I know could be complete garbage designed to lock you into MSFT products.
