Re:TypeScript 3.4
by koolba on Saturday March 30, 2019 @12:13PM
(#19530145)
> There has never been a worse time to be a software developer.
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.
Re:TypeScript 3.4
by phamilton on Saturday March 30, 2019 @01:33PM
(#19530646)
Tslint has in some cases evolved as a compiler extension. Things like "no-floating-promises" are huge and only really possible with sufficient type information.
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.