The CEO gets the money, you get the product, this mutually beneficial arrangement has led to the emission of CO2. However, the CEO can't force you to buy his products, you have to do that on your own.
> And that this is a test version of the software isn't irrelevant, it makes a huge difference—I am much less opposed to internal company testers who know what they're doing than I am to a public beta in the hands of people who believe Tesla's (really egregious) marketing.
There is absolutely no reason you should assume "testers" know what they are doing. I have met plenty of people with decades of experience in "testing" barely know what they are doing. Even in the case they know what they are doing, they shouldn't be testing a *deadly* vehicle with potentially broken software on heavily populated *public* roads.
> Even in the case they know what they are doing, they shouldn't be testing a deadly vehicle with potentially broken software on heavily populated public roads.
This is another way of saying that self-driving vehicles shouldn't exist at all. At some point we have to test them on public roads, preferably before putting the software into the hands of regular users. If you ban even internal company testing, then what you're saying is that self-driving vehicles should never exist.
Not even remotely the same thing. You completely glossed over me saying potentially broken software and heavily populated. Surely there is a way to simulate a left turn signal in a more safe manner on software this early in the testing process.
All software is potentially broken. If you've only ever tested your software in a controlled driving range, then you don't know how it will behave when you take it out into the real world. If you've only ever tested it on lightly populated roads, then you don't know how it will behave when you take it onto heavily populated roads.
It's not surprising that it made a mistake during testing. That's what testing is for: rooting out mistakes.
No. Public road deployment is for validation, not testing.
Testing is for rooting out errors. Validation is for proving you achieve the desired specifications and failure rate. Validation occurs when you believe you are done or when testing becomes inadequate to discover failures. It is about “proving” the negative with respect to errors.
Broken, incomplete software where defects can be routinely discovered after light usage has no place being used by consumers on public roads.
"potentially broken software" = "all software", therefore you said self driving software should never exist and you are happy to support 40,000+ people dying in the US every year who could be saved with autonomous vehicle technology. Your lack of ethics is worrying.
> This is another way of saying that self-driving vehicles shouldn't exist at all.
It's another way of saying that self-driving vehicles should be invented somewhere else, so that in 10 years you have to beg and plead for an overpriced second-rate implementation with a worse safety profile.
The complete opposite is probably sufficient as well. It gets a lot easier to tolerate bullshit when you realize almost every stranger's asshole-ish behavior is a function of something wrong with themselves or their environments.
I just look at those behaviors as huge billboards that broadcast what's wrong with that person (as long as it's a stranger; if they're not a stranger it's a completely different story)
Anecdotally speaking, I don’t ever see myself being right-leaning because really, what do I have to conserve to be conservative?
I don’t have much wealth, I can’t buy a house for the foreseeable future, I will be done paying off literally all my debt including student loan next year, I have a wife and no kids. So yeah… I just want to do what I like and screw making another person or company richer, they’ll be fine.
That's... That's a huge stretch. I've been on an outdated version of pycharm for nearly a year now because they broke support for docker-compose in a pretty huge way. Moreover, I have yet to have a pycharm project where I didn't need to create my own docker override file.
Interesting, i recall doing that in the early days of the docker integration. It is pretty solid now. Also might have been the weird way that project was setup, but i do not remember the specifics.
Also cannot judge it because you gave no examples.
As an entrepreneur twice over, it had everything to do with being able to spend the most productive hours of my day on being an entrepreneur and being armed with basic full stack web development skills.
I had zero success in entrepreneurship in my 20s and I was delusional to think I could accomplish anything in entrepreneurship without both of those properties (and I tried multiple times a year for the decade of my 20s). It would take someone truly amazing* to pull off starting a successful business while working a full-time job.
* And I say that in contrast to myself, who has been called talented more than a few times by my managers and still couldn't pull it off until I earned enough money to take time off
I was in the process of learning it at the end of my 20s but hadn't quite gotten there until the cusp of 29/30. I did firmware, data science, physics research, and developed a scientific software framework before that.
It would be interesting to see how many of these criticisms are criticisms of these things as they stood and not for their potential; it seems ridiculous to place the onus on the critics to see if someone can execute well in the future.
I joined my current company around the time hooks reached peak hype, and whilst the team I joined were refactoring away from class components. My previous gig had used classes. My current codebase is complex (a video player) but pushed all the core logic out to Rx and custom code, rather than going deep with hooks and react ecosystem. So I’m still way more familiar with classes despite ostensibly working in a hook-y codebase.
I hate hooks. The syntax feels nice to type, but the issues outweigh the benefits for me. It’s way too difficult to understand the rendering lifecycle, the state updating, the ordering and I also find the reuse abstraction hard to follow (although I accept that might be a concentration/attention issue on my part). Conversely, it’s also way too easy to break the purity of the hook callbacks, so hooks can use state from contexts you wouldn’t expect (more an issue with custom hooks if you don’t also supply linter tooling to go with them).
I like them too but they tend to promote shittier code. The codebases I inherit that use classes = clean, easy to follow. Ones all in with functions and React hooks = trash.
Obviously using hooks doesn't mean it has to be shitty, I think it just brought a lot more wannabe React devs that have no experience with architecture or maintainability.
