It is not only about the adds. Even if you pay, they will still spy on you and sell/use this data to show you adds somewhere else on the internet. I will start paying only if they treat me as customer and not as product.
I prefer to fix bugs before they hit production. It is almost impossible to do that without tests. Also testable code is usually much more readable than untestable god objects, tightly coupled modules and spagetti code.
I can go the other way and say that code that ends up being 'modified' to be testable, with 43 mocks to just be able to setup a class is as much crap as code without tests.
I would say I never achieved more than 20% or so of test coverage in my products and production code. It doesn't mean it is a mess of tightly coupled modules in any way.
But TDD and any other dogmas in development are like this. Solution A prevents (maybe) a problem, thus if you aren't using it all other code has that problem and defendants will just keep trying to make it so.
A good education helps you to understand the state of the art. My education helped me to do this with security, especially when it comes to reverse engineering binaries and hardware security.
Ideally, it should do it for a lot more topics but that's where reality sets in.
Did the same thing on work email and found only messages from gitlab. But only 10% of those messages were marked as spam the others were in inbox so I did not notice. This convinced me not to trust gmail antispam.
But that is just one one electron app. Imagine that every desktop app you use is written in electron. I am pretty sure that even 32GB workstation would be stretched to the limits.
I do not understand what people like about vscode. If I ignore insane resource consumption this is at most average IDE (the only real benefit over sublime "text editor" is integrated debugger). This is most preferred editor at work so I am forced to work with it and there are some of the most serious issues I have:
1. Only one side panel, so I can't see outline, test results and project files at the same time as I am used to see on widescreen monitors in other IDEs.
2. Language servers are still not comparable to solutions offered by java IDEs and in case of C++ they are worse than anything else I used.
3. Python extension constantly forgets and founds unit test. There is little support for unit test in other languages.
4. Official C++ extension despite being completely useless consumes several gigabytes of space for "indexed" files (I wonder if it is so bad to not hurt sales of Visual Studio). I also tried to use clangd which is better but there is still a lot of work to be done before it is useful.
I like sublime rust support for really small projects and eclipse support for larger projects (which is not ideal) but I have not coded anything serious in rust yet, so I do not know if there is some good IDE.
For C++ try the cquery extension. It's pretty good.
It mostly helped me to provide IDE support (full code completion and navigation) for a project that wasn't supported by Visual Studio or any other IDE (embedded project based on gcc and a hacky makefile).
It works well enough for the 6 languages I use weekly. I'm honestly too busy doing all the other engineering tasks that don't happen inside Vscode to really care that it's not perfect. I don't live in vscode that much each week to really care.
> 4. Official C++ extension despite being completely useless consumes several gigabytes of space for "indexed" files (I wonder if it is so bad to not hurt sales of Visual Studio).
I chuckled at this, because the implementation is actually shared between the official C++ extension and Visual Studio. That extra space usage is likely the recent addition of automatic PCH generation (to VS Code, VS has done that for a long time).
I bought and use JetBrains CLion (C++ IDE) precisely for these reasons. I only use VSCode for HTML/JS/CSS and as a markdown editor. For plain editing I just use VIM. For medium-scale projects, VSCode tends to take enormous amounts of resources.
I tried to use type hints but I do not see enough value in them to justify making code more complex. It looks to me that they are similar to hungarian notation as they make refactoring harder but they are not reliable and does provide little value in checking program correctness. They are just documentation embedded into variable declaration used only for linting so I tend to not trust them.
Because it is not used by runtime. Mypy is just linter which adds additional restrictions on code which are not enforced by interpreter. You can have false positives so correct python code must be fixed to pass linter checks. In my opinion if you need static type checks you should use statically typed language and not hurt your coding speed by such partial solution. Also majority of python libraries do not use type annotations so you are limited to your code.
Well, yes, this is exactly how the type checkers of
statically-typed languages work: as linters, during compilation.
The largest difference is that typing in Python is gradual, so not
everything needs to be typed as you say.
I agree that statically typed languages are preferable. I don't consider static
typing optional so I'm glad Python is growing a solution that supports it,
though.
In my experience, mypy works surprisingly well. It doesn't hurt my
coding speed at all but enhances it to levels that were not
previously possible in Python, due to a lack of typing. False
positives are rather rare.
Recently started working on Typescript project and it looks to me like java with really poor tooling, C++ like compilation times and huge mess in libraries (i.e. how to determine which version of @types package I need). I think that Typescript is really step back from java.
If you do that you will probably hurt your productivity. There still will possible errors made by using 3rd party code.
In my opinion optional type checking is not comparable to statically typed language guaranties. So if I do not need types I would use python. If I need/want type specification I would use statically typed language.