In my experience no, most fraudsters are not evil people, they just follow the incentives and almost non-existent disincentives. Scientist has become just a job, you find all kinds of people there.
As far as I know no-one goes to jail, worst thing possible (and very rare) is losing the job, most likely just the reputation.
Maybe I'm too idealistic but why does following incentives with no regard for secondary consequences not evil?
> // checks for a client API call)
> // 2. Things that may seem obvious are commented explicitly
Honest question: Why invent "safety" practices and ignore every documented software engineering best practice? 2,000 line long modules and 200-line methods with 3-4 if-levels are considered harmful. Comments that say what the code does instead of specifying why are similarly not useful and likely to go out of date with the actual code. Gratuitous use of `nil`. These are just surface-level observations without getting into coupling, SRP, etc.
That seems unnecessarily brutal (and untrue).
> 2,000 line long modules and 200-line methods with 3-4 if-levels are considered harmful
Sometimes, not always. Limiting file size arbitrarily is not "best practice". There are times where keeping the context in one place lowers the cognitive complexity in understanding the logic. If these functions are logically tightly related splitting them out into multiple files will likely make things worse. 2000 lines (a lot of white space and comments) isn't crazy at all for a complicated piece of business logic.
> Comments that say what the code does instead of specifying why are similarly not useful and likely to go out of date with the actual code.
I don't think this is a clear cut best practice either. A comment that explains that you set var a to parameter b is useless, but it can have utility if the "what" adds more context, which seems to be the case in this file from skimming it. There's code and there's business logic and comments can act as translation between the two without necessarily being the why.
> Gratuitous use of `nil`
Welcome to golang. `nil` for error values is standard.
Seriously, it's as simple as that. We are here to work, not philosophize about politics and current events.
1. SpaceX
2. China
3. Russia
I say "SpaceX" instead of America or NASA because the Axiom missions show that SpaceX can launch people independent of NASA.India may develop their own capability to put humans in orbit before Europe does, which is amazing to me. [Though admittedly that's only because Europe has different priorities--not necessarily a lack of ability.]
Question/Task: Write a lock implementation in Rust
I got this (lol):
use std::sync::Mutex;
struct Lock {
mutex: Mutex<()>,
}
impl Lock {
fn new() -> Lock {
Lock {
mutex: Mutex::new(()),
}
}
fn lock(&self) -> MutexGuard<()> {
self.mutex.lock().unwrap()
}
fn unlock(&self) {
self.mutex.unlock();
}
}