564 karma · joined February 4, 2020
I generally agree but I think the are examples of some successful projects that did innovate. You could probably consider Gemini + Apollo a single megaproject as they were designed to run consecutively, building towards the moon.
This is largely untrue. A recent debate: https://old.reddit.com/r/AskHistorians/comments/k2ofqw/the_a...
Edit: sibling comment posted as I was typing. Apparently its couch-surfing and religion.
There are of course exceptions, those in particularly sensitive situations, but in those cases other precautions should be taken as well.
And yes, the text based browser you use may see fewer security patches in the change log, but it is also far less tested. The user base is just not there. If no JavaScript is that important to you it can easily be disabled in Firefox and I'd wager you'd come out ahead in terms of security.
If you refuse to use a modern web browser, that's a totally valid choice, but doing it based on some misguided notion of security is nonsensical.
I do agree on the politics of googlers though: once released its ignored.
Could you elaborate on the actual argument for why this is the case. On the surface it seems like the opposite of what you are claiming can just as easily be true depending on the situation. For example take a widely used utility lib such as lodash or jQuery. In your scenario there are two options:
1. Use lodash via a package manager and rely on the lodash team to fix bugs, write tests, and add new useful utilities over time.
2. Fork lodash and take on the maintenance burden yourself. You are responsible for keeping up with security vulnerabilities and making patches. You are responsible for writing high quality tests for the parts of your code that diverge for the original.
Think about how much ramp up time is required for new hires to become familiar with a company's codebase. Why would you ever want to devote that amount of time to maintaining code that for the vast majority of businesses is already "good enough". For some companies the engineers working on the open source project may even be more competent than the resources available in house. Sure there may be edge cases were performance or security is absolutely paramount, and in those this approach may make sense, but not for the majority of generic CRUD apps.
I would have a very tough time trying convince a competent manager that it is beneficial to devote so many man hours to this task rather than to business logic, new app features, etc.
I've done this for a long time and have observed similar benefits, but I often just type out the plan in a text editor with lot of bullet points instead. Do you find that physically writing aids in the process?
Same thing that stops people from blowing up buses, trains cars, shopping malls, movie theaters, etc: not much. There just isn't a sufficient incentive and will to do such things.
Don't most ecosystems use some type of namespace for that instead of exposing everything as global functions? Those practices were quite late to the PHP community.
> deno run --allow-write=~/only-evil-here http://dangerous.com/evil.ts
> curl -fsSL https://myapp.io/install.sh | sh
Thats pretty scary. It might do anything to user data. The deno sandbox would offer more assurances of course:
> deno run --allow-write=~/.myapp https://myapp.io/install.sh
You know it would only access what you expect. Same with another command:
> deno run --allow-read=./my-data.csv https://data-app-thing.io/visualize-data.ts my-data.csv
It's as described, a browser, not a server platform.
It's a lot harder to argue that another player in the market could have filed the niche that Elon identified and continues to expand.