My (personally) humorous interpretation was that they were extending your joke by implying the only users using FF are devs and they are the ones that care.
Readability is subjective. I personally find fold almost always more readable than a for loop when the accumulator variable has a simple type. This is because merely seeing fold can already telling me several things: it will iterate over the entire collection without early exits like "break" in a loop; the data dependency between each iteration is made clear into a single variable.
I find it slightly difficult to read when the accumulator variable actually has multiple parts, like a complicated tuple. It's worse when part of the accumulator is a bool indicating whether it's finished; that's just a poor emulation of "break" in a for loop.
afair I've mostly only used fold when doing maths not covered by the standard sum or product. Fold is similar to map reduce but it's just one expression.
It's 100% sarcasm. The capitalization should have made it obvious to anyone. The only place I've seen struggling with recognizing sarcasm is hackernews.
Every time that somebody calls me a software engineer I correct them that I'm a software developer. The word engineer has specific meaning and unless an accredited university gave you that title you should not be using it.
I realize that HN has many actual software engineers, but it seems like every frontend dev today calls himself an engineer. Even on the Laravel website, the default job title for new members is software engineer.
In most fields, there is a distinction between an engineer, who designs solutions, and a technician, who implements them. It is a bit blurred for software as it is common for one person to do both the design (an engineer job) and the code (a technician job), in fact, it is common for the design to be expressed in code. And because of the two, the title of engineer is the more prestigious one, they are all engineers.
I remember seeing technician jobs for programmers (not "developers"). The difference was that engineers were expected to have a masters degree (5 years) while technicians were expected to have a associate degree (2 years). The contract also was different, usually with a fixed schedule and a lower pay excluding overtime, as any overtime was expected to be paid. But for the job itself, there was essentially no difference between a junior engineer and a technician. Now, listed technician jobs are becoming rare.
Note that it is in France, where degrees matter more than in the US and employment is more regulated, the distinction probably wouldn't be as meaningful in the US.
I have the displeasure of having acquaintances that have done some pretty bad things, of the fraud and bribery persuasion. They did so because they had no regard of the secondary cosequences. However, this didn't mean 'I understand this horrible secondary consequence is going to happen, but I don't care'. That would be evil. Instead, it's more common to not dedicate an iota of time at thinking of possible negative effects at all.
You'll see this all over risky startups. What starts as hopeful optimism only becomes fraud over time, when the consequences of not committing fraud also seem horrible. It's easy to follow the road until all your choices are horrible in different ways, and they pick the one better for the people around them, yet worse for everyone else.
Our judgment of societal ills and the concept of "evil" rests too much on the question of "is this a bad person?" today. Most people who do heinous things are not bad people, but the fact that they did bad things really ought to be enough to mete out punishment.
Lack of foresight isn't a virtue, it's as much of a vice as knowing the consequences and ignoring them. If you lack foresight and that causes you to commit fraud, you committed fraud, plain and simple. That is evil.
IMO “evil” is a misconception. People have different beliefs and psychological needs, and placed in certain incentive structures that has the outcomes that we see. You can call certain behaviors “evil”, but that doesn’t explain anything about why the behaviors occur.
Nope. “Evil” still provides no explanation and no understanding of why and how things happen there. It’s the same thing as believing in miracles created by a god.
The context here is from the root comment: “Are people who commit this type of science fraud just really evil humans?”. “Just really evil” implies that that there is no other explanation, and that the fraud is committed as a function of them being “really evil”.
I don’t actually know what people mean when they label someone as “evil”, other than “is doing/saying/thinking stuff I find very reprehensible”. Which doesn’t make sense when you insert it into the above statement: “Are people who commit this type of science fraud just humans who do stuff I find really reprehensible?” Well, I guess it sounds like they are.
It seems like people want to assign a character trait when they say “person X is evil”, but I don’t believe such a generic character trait exists (and what exactly it is supposed to mean if it existed). What’s worse, it obfuscates and prevents understanding the actual character traits and circumstances that lead to the respective behavior.
I agree, "evil" is a misconception, there exists no such thing as an "evil" person, in reality, just as there is no such thing as a "darling" person, in reality. But both expressions work as an expression of sentiment. When we use it we aim to communicate that we feel no empathy for such people (in case they are "evil"); they can without further ado be thrown in the dungeon. It is a dehumanizing construct enabling hate, same as calling people vermin, or monsters, but with religious connotations, exposing a will to exclude such people from the community (often for god reason), enabling going to war, or to exploit.
However, by removing empathy, we also reduce the possibility to understand the human motivations behind heinous acts (there always are), find solutions, build bridges, make truces, end wars. So maybe we should go lightly on the "evil" stuff, as much as possible.
Perhaps if you define evil as a low quantity of ability or commitment to search for and act in accordance to what is ultimately true then that will better resonate with you. Of course, that will necessarily lead to questions regarding the nature of truth and whether it exists, but that is beyond the scope of a short reply :)
Physical pain is objective. Someone inflecting physical pain is evil unless it’s in self defense or common sense situations like a doctor performing surgery.
What is a general definition of “evil” that one could derive this from? And how does this relate to the actual reasons why someone would inflect physical pain? Are soldiers in a war evil when they happen to inflict physical pain outside of self defense? Or is that another “common-sense” exception?
The concept is emotionally laden and ill-defined, and has little relation to why the designated behaviors actually happen. It’s an incoherent concept that has no explanatory power.
Exactly. In fact, all things in the universe are subjective except exactly one thing, which is that all other things are subjective. This is epistemological monism, and it's the only coherent view.
Socrates got it. "I know that I know nothing" (else)
Because we're cowards, and declaring vast swatches of our economy and society to be evil is not good for our future prospects. In other words, you can't tell people not to put radium up their asshole!
> Why invent "safety" practices and ignore every documented software engineering best practice?
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.
A lot of work can be inherently political. If your company pivots into mass surveillance is it unreasonable to speak up if it's against your ethics framework?
That's the beauty of the free market, you have the freedom of choice. You can vote with your wallet or your feet. You can leave if your personal ethics and morality no longer align with the organization you're working for. A business doesn't owe you a paycheck simply because you think you're on the moral high ground.
I'm not saying you're entitled to a paycheck - a company has the right to fire you for your differences in politics. But if you frame it as a relationship, communication can help both sides as long as it's done with some mutual understanding. There are times companies listen to their employees and change their stance. And if they don't then you still have the ability to leave. That said it also matters how differences in views are expressed, I doubt there are many cases where yelling is effective..
It’s perhaps a cultural difference. I grew up in an era (90s, 00s) where people who were overly political were mocked and ridiculed. Certainly you’d never run into it in the workplace. That’s not to say you should never voice your political beliefs, but there is a time and a place for it.
Isn't having a private entity be able to do what previously required a nation a good sign for that nation? The idea that the USA cannot re-obtain that capability again seems silly to me and there are a lot of pros for having private companies pushing the state of art forward.
it puts the concentration of power into fewer individuals hands, which makes me nervous.
The gov is slow b/c it requires sign off from hundreds of people. (For example, congress approving NASA's budget).
As a private entity, maybe 20 or 50 people are required to approve or reject missions. This lets them move faster, but if a certain CEO doesn't want to provide services for a war, they can mess with the contract.
The government is still in control. They could nationalize the project tomorrow or stop issuing launch licencees.
Why taking rides to orbits should require some massive jumping threw hops doesn't really make sense to me. If the launch and landing are secured what the problem or danger with people going to LEO?
GPT-4 also reaches out for Mutex. Which I think is fair - it really is the easiest way to solve the literal problem presented to it, after all.
OTOH given "write a lock implementation in Rust without using existing standard library synchronization primitives", both try to implement a spinlock. But GPT-4 knows about compare_and_swap, whereas Bard appears to believe that spinning on load(SeqCst) followed by store(SeqCst) is sufficient to synchronize with other threads.
But a task like that is more likely to depend at how much Rust code each model was trained on rather than its capability to reason.
