This is objectively false. There is plenty of evidence showing that modern type systems reduce bugs considerably.
In Airbnb, they found out that 38% (!) of bugs could have been prevented by using TypeScript[1].
Another scientific study discovered that TypeScript and Flow could prevent about 15% of bugs in committed code [2]. And these aren't even measuring reduction of bugs in non-committed code!
Stripe is also writing their own type checker for Ruby and engineers have reported an increase in productivity[3].
[1]: https://news.ycombinator.com/item?id=19131272
[2]: https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...
It just takes away the mental overhead of making something conform to a spec. It probably doesn't save us much on production bugs, but it makes development faster.
1. If they're using a dynamically typed language, this gives them extra work to typecast everything back and forth whenever they need to communicate with your system.
2. Even if they use types, maybe their type system is not compatible with yours and they need to do a lot of tedious extra work to typecast everything.
I treat other systems like I do the database and enforce consistency at the API level.
I wouldn't ask for a database to be totally untyped (and thus silently coerce things into its internal types in reality), so I don't ask for the same in an API.
Though, I can understand some people have differing preferences---MongoDB is popular for example---but I wouldn't call it an anti-pattern no matter which choice one makes.
I have never found option 2 to apply in any meaningful fashion, though I'm sure others have done much more of this type of work than I have.
I don't buy these hypotheticals and also I don't believe in this kind of anecdotal evidence.
I think that the real root problem is that they didn't break down the code into logical components and didn't test them correctly - That was the real problem, not JavaScript.
When you look at reports of bug density across large samples of projects, it's clear that TypeScript does not solve any problems. See https://medium.com/javascript-scene/the-shocking-secret-abou...
The only anecdotal evidence I've linked is Stripe's experience with Sorbet. The paper linked is an actual scientific analysis with great study design. I couldn't find the Airbnb slides or talk but an engineer involved claims the study was carefully designed[1].
> When you look at reports of bug density across large samples of projects, it's clear that TypeScript does not solve any problems. See https://medium.com/javascript-scene/the-shocking-secret-abou....
Go read the "study" referenced in that article. It's just blog post with a terrible methodology. It's basically
(number of issues with bug label) / (lines of code)
The author doesn't even normalize for LOC (larger codebases tend to have more bugs) or take into account project complexity.
[1]: https://twitter.com/swyx/status/1094857103863209985
EDIT: add disclaimer about airbnb talk
The other study you referred to sponsored by Microsoft is very vague on the methods used to conduct the experiment. So its not repeatable. You can't say something is scientifically true unless the results are repeatable.
bugs are (in part) function of code and tooling complexity, making some bugs harder to introduce doesn't reduce that complexity. risk compensation principle is another factor, and so on.
i haven't yet seen strong evidence that static typing really reduces bug density.
That we as an industry ship code (Javascript) to production that still has bugs that are so easy to catch at compile time does not reflect well on us, and your comment really does not help in this regard. What is your recommendation to ensure we catch more bugs at compile time rather than letting users find out that their application doesn't work?
You wanted to find the bugs before shipping it to users, and that is also what I used to pursue, but when you let a ton of users hit your code, they will find the issues way faster then you could. It's however important to log, and debug all errors, and have a channel for users to submit issues. Sure it will be annoying for the user when he/she stumbles on a bug, but you will regain the goodwill when you fix his/her issue. In most software, even today, users are used to wait months, and even years, or infinitely, to have a bug/issue fixed. So it's a lot of "WOW! Thanks" And very little "I will sue your ass". Bugs, if you do actually fix them, will have a net positive effect.
For example, one of my open source projects has about 120 integration test cases in total; these are enough to cover about 10K lines of code (not counting third-party dependencies); if I break any documented feature of the project, it's essentially guaranteed that many test cases will fail - They will catch the smallest issue or inconsistency; even things which are not being explicitly tested.
Integrations tests are great at detecting symptoms. They don't always point exactly at what the problem is, but they are great at letting your know that there is a problem and then you can debug it.
Integration tests are the best way to identify and fix issues in very complex systems. For example, when it comes to medicine and the human body; a thermometer reading is an example of a well-designed integration test case; if your temperature is high, then the doctor knows straight away that you have a problem which needs to be addressed. The doctor will probably not know exactly what the problem is immediately, but nonetheless, that simple thermometer reading (assertion) can allow them to detect the symptom of an essentially infinite range of possible underlying issues. One test case is not enough to cover all possible health problems, but the enormous amount of internal coverage that this single test case provides is unfathomable. We ought to try to come up with such test cases in our code.
If you have good integration tests, it doesn't really matter what language you use because (in terms of identifying issues) everything else pales in comparison.
Also it's important to note that integration testing doesn't necessarily mean end-to-end testing. You can still mock certain external components or engines in order to get more stability in your tests and you can still get that same kind of leverage.
I agree that this does not replace integration tests or manual QA (dependencies can break and not every behavior can be checked). But as a lever for increasing productivity, a type system (even with the added complexity) is unbeatable.
Basically my point is that you aren’t actually catching errors at compile time, you’re catching them at build time. Your workflow might provide the same guarantees for the code that gets deployed to production, but writing that code is probably less enjoyable and you’re probably less productive than you could be.
The Linux kernel does not accept Github pull requests for development. If you try it, it will respond with this friendly message:
Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch.
That is one of the weirder statements I've come across on this website.
First of all, there are tons of analyses publicly available — from well-known companies like Lyft, Airbnb, etc. — that document reduction in software defects solely from TypeScript's compile-time checks. (Source: uh, Google "TypeScript".)
Second, it is virtually impossible to code for a day in TypeScript without it catching bugs. Granted, many of them would be bugs that you would have caught as soon as you ran your program, but TypeScript catches them while you type them so you never do run the program with that bug.
(That's the secret actual reason it's named Type Script.)
Dynamic typing is what really hides complexity. The higher order component pattern in React is a prime example. What seems like a simple idea is revealed to be extremely complex once you try to implement it using Typescript. Writing the types is a great way to get feedback on how complex your abstractions really are.
Deciding to use Typescript is about making a commitment to reveal and deal with unnecessary complexity from the beginning.
IIRC Linux does not use GitHub for project management or as a source of truth, only as a mirror.
https://github.com/torvalds/linux/pull/17#issuecomment-56546...
Particularly when half his gripe with GitHub is not hard-wrapping commit messages.
But in general I agree with you. If you adopt a tool, any tool, any framework you need also think about the learning curve and overhead you impose on the next developer and yourself. This is especially true if something goes wrong, you run into issues and you need to troubleshoot it.
Quite the opposite! CPU and memory are cheap, FOSS is everywhere, and now more than ever its possible to create massive applications all on your own.
> Practically all of the most popular tools encourage anti-patterns, add unnecessary complexity or solve superficial problems instead of focusing on critical problems that exist in today's software projects.
> - TypeScript ...
TypeScript solves many problems with real world JavaScript applications at scale (code scale, not user scale!). Static type checks and interface validation are powerful tools. They lead to both more correct programs and faster development.
> - Code coverage tools like Istanbul and others add very little value to projects. 100% coverage is not a useful goal to have, in fact it's counterproductive. When it comes to test coverage, quality of that coverage is WAY more important than quantity (this cannot be over-emphasized). Did you test all the right inputs? Do the tests focus on the most important code paths (and those which are more complex and therefore more likely to fail)? I'd rather have 10% quality coverage of the right parts of the code than 100% poor quality coverage. Also, you need to take into account that the more unit test coverage you have, the harder it is to make changes to your code.
Depends on the type of code being checked. For a library meant to cover a huge number of permutations a coverage report can be useful. It's not a panacea for general application development. With static type checks a lot of the value of code coverage iseliminated as an entire class of errors is handled by the compiler (ex: "foobar" mispelled as "foobuz").
> - Linting tools such as ESLint/TSLint: These tools can be very nice if used correctly and not treated as a silver bullet for all programming problems. We should never forget that linters can only detect superficial problems.
That's literally the job of linting tools. To catch superficial problems as they're often a symptom of real problems. An unreferenced variable is either dead code (at best) or broken logic. Bad formatting and indentation could be purely cosmetic or a massive security issue (GOTO fail...). It's not going to tell you that your binary search is totally correct, but it will tell you if you forgot to reference the "high" variable entirely.
> I used to roll my eyes when I read comments like this
Yeah, I rolled my eyes so hard at this comment, it hurt.
This is more of a problem for back end projects. Front end web development frameworks tend to enforce certain architectural constraints so there isn't much margin for error there but back ends and other complex projects are often terrible when it comes to assigning clear and distinct responsibilities across components.
The functional attempts at Javascript
Until then iteration makes way more sense than recursion in JS.
[1]: https://reasonml.github.io/en/try.html?rrjsx=true&reason=DYU...
The buzzwords & flashy libraries add incremental value over ES6 with large organizational migration costs. For example 90% of Redux code is useless and a liability. But, devs think it’s cool and devs get what they want. Businesses will let devs tinker instead of loosing them. Hence complexity, inefficiencies and egos.
Build something useful in the simplest way possible.
P.S. When I write Typescript I NEVER get caught by the compiler because I KNOW what fucking type my variables are. There’s only a of handful natives becau se this aint C and my object instances are always well named.
It is just like the CLI vs GUI thing, people want choices.
Practically all of the most popular tools encourage anti-patterns, add unnecessary complexity or solve superficial problems instead of focusing on critical problems that exist in today's software projects.
Some examples:
- TypeScript: Unfortunately, we cannot reduce a language's complexity by adding extra complexity on top. The complexity will keep rearing its ugly head no matter how much we try to hide it. The TypeScript project has had over 20K issues raised and 9K pull requests (that's not even mentioning the DefinitelyTyped repo)... To put it into perspective, the Linux project has only had about 380 PRs on GitHub. But how much value does TypeScript add? All evidence points to the fact that TypeScript does not have any positive effect on bug density. Its value is purely subjective and speculative. If humanity had invested a quarter of that time and energy towards coming up with and documenting proper JavaScript design patterns and architectures, TypeScript would have been completely redundant to begin with.
- NestJS: Makes heavy use of decorators; these aim to allow developers to handle cross-cutting concerns within their code. Unfortunately, cross-cutting concerns are an anti-pattern because they imply a violation of the principle of separation of concerns between components. It takes a bit of thinking and discipline to come up with components which have clear and distinct concerns/responsibilities, but this is not a problem that can simply be ignored by injecting decorators all over your code.
- InversifyJS: Dependency injection is a failed concept. It's been proven over and over. Angular 1 provided us with plenty of evidence for why we should avoid dependency injection (e.g. it's impossible to find stuff and you end up with a pseudo-global scope for everything which is as bad as simply using global variables). Again, dependency management is not a solution which can be automated away; it requires developers to make careful design decisions.
- Code coverage tools like Istanbul and others add very little value to projects. 100% coverage is not a useful goal to have, in fact it's counterproductive. When it comes to test coverage, quality of that coverage is WAY more important than quantity (this cannot be over-emphasized). Did you test all the right inputs? Do the tests focus on the most important code paths (and those which are more complex and therefore more likely to fail)? I'd rather have 10% quality coverage of the right parts of the code than 100% poor quality coverage. Also, you need to take into account that the more unit test coverage you have, the harder it is to make changes to your code.
- Linting tools such as ESLint/TSLint: These tools can be very nice if used correctly and not treated as a silver bullet for all programming problems. We should never forget that linters can only detect superficial problems. If your code passes all the most strict linting rules, it still says almost nothing about your project's code quality. I'd MUCH rather have code that fails ALL linting rules possible but has good architecture and good separation of concerns between components; at least the linting is easy to fix. Linting does not prevent architectural mistakes AT ALL; it only prevents superficial mistakes which are usually easy to identify anyway (if you have half-decent testing).
I hope that over the next decade, the masses of new developers will develop their critical thinking skills and that they will be able to see value beyond the hype which is always being shoved into their faces by various misguided organizations.
It's particularly difficult for me to see what has happened to software development because 10 years ago, I used to roll my eyes when I read comments like this from older and more experienced developers. New developers are often attracted to complexity like moths to a flame, but eventually we all learn that complexity is a silent killer - It's the ultimate enemy. Complexity is always trying to quietly sneak its way into your code (and I do mean ALWAYS; no matter how good your code is at any given point) and you must identify and stop every single attempt. It takes most developers at least a decade or two of coding to really appreciate this.
For me, starting a TypeScript project is like accepting unnecessary complexity from the beginning of the project. It's a bad start, a slippery slope.