- SankoziI have opposite experience. Consistency is commonly enforced in bigger corporations while it's value is not that high (often negative). Lots of strategies/patterns promoted and blindly followed without a brief reflection that maybe this is a bad solution for certain problems. TDD, onion/hexagonal architecture, SPA, React, etc.
- "In large codebases, consistency is more important than “good design”" - this is completely opposite from my experience. There is some value in consistency within single module but consistency in a large codebase is a big mistake (unless in extremely rare case that code base consists entirely of very similar modules).
Modules with different requirements should not have single consistent codebase. Testing strategy, application architecture, even naming should be different across different modules.
- People using it wrong. It definitely should not be that popular. 95% of times when I see it I consider it a tech debt.
You should be using it in rare cases when you want to verify very complex code that needs to be working with strict requirements (like calling order is specified, or some calls cannot be made during execution of the method).
Usually it is used for pointless unit tests of simple intermediary layers to test if call is delegated correctly to deeper layer. Those tests usually have negative value (they test very little but make any modification much harder).
- In the same post you are arguing for and against "slippery slope".
Either it is possible to easy change law to make it worse ("slippery slope" is valid objection) or changing law is "much harder than doing nothing"("slippery slope" is a fallacy).
- The thing is you don't need to do this in "normal" system where dependencies are stored in local cache and build tool is using them during the tasks.
If JS had a proper build tool then creating such directory inside project would not be needed. Instead in JS world you have only dependency downloader with some crude script runner.
- You still need to have those symlinks checked. For example you switch branch to one with updated package.json, now you need either to check symlinks or you risk to have incorrect build.
Introducing a directory that needs to stay in sync with dependency manifest will always lead to such problems. It is good that Python developers do not want to repeat such mistake.
- This is literally not possible.
If you have local dependency repo and dependency manifest, during the build, you can either:
1. Check if local repo is in sync - correct build, takes more time
2. Skip the check - risky build, but fast
If the dependencies are only in the cache directory, you can have both - correct and fast builds.
- It is possible to set version ranges but it is hard to see this in real world. Everyone is using pinned dependencies.
Version ranges are really bad idea which we can see in NPM.
- This is not a good idea: this leads to longer build times and/or invalid builds (you build against different dependencies than declared in config).
Having dependency cache and build tool that knows where to look for it is much superior solution.
- Flash performance is still better than current web stack's. Probably will always be - you could write non trivial games that would work on 128MB memory machine. Currently single browser tab with simple page can take more than that.
- You don't have to buy a new car. Used ones are dirt cheap (soon this will include EV too).
- Nobody is planning for this magical instant 1 to 1 switch to EV. It will happen gradually.
Most of the world is playing catch up with Norway (97% EV market share) - if their grid will handle the transition then it is possible. If it will not then others will prepare better.
- Where is it happening?
Where buying a car is really expensive? The only places that come in mind are those packed cities that require a parking place for a car. Nothing to do with EV.
- It is not package managers. It is due to the poor NPM ecosystem: lots of crappy packages (like left-pad), auto updates, lots of dependencies, post install scripts, insecure language.
These security problems happen much less often in other ecosystems. There is nothing even remotely as bad as NPM.
- No they are not as susceptible - auto updating dependencies, post install scripts and culture of thousands of crappy micro packages (like left-pad) is mainly a NPM issue.
- You are commenting under blog post that tried to explain it and got it wrong. It is not simple.
Examples:
- algorithm with O(2^n) complexity might be faster for your problem than O(1) algorithm
- the same algorithm may be O(2^n) or O(n³) depending how you define size function
This is not straightforward.
- More intelligent specie (AI) designed by specie (humans) that has history of eradicating less intelligent species (neanderthals).
I don't see how anyone can't see the problem.
- You are forgetting that we are talking about AI. That AI will be used to speed up progress on making next, better AI that will be used to speed up progress on making next, better AI that ...
- Unless the documentation says that Math.Pow just returns the result of calling some other code (it doesn't do that), the bug is both in the Math.Pow and underlying library. It should be reported and tracked in both.