marta_morena_29
Joined 6 years ago
Joined 6 years ago
However, nothing prevents you from publishing your idea on the web, and people have done that and succeeded. There were some brilliant ideas (missing the link) that just got thrown out in the wild. But if the idea is truly brilliant, some other scientist will notice and make sure it gets reviewed anyhow.
The "censorship" (I wouldn't call it that) in science doesnt happen at the publishing stage. When you have a great idea, it is bound to succeed, because nobody can afford to ignore you. The problem is getting there. How do you get the idea? Funding... Science funding is utterly broken. I.e. people research the wrong things for the wrong reasons all the time. This needs to be fixed, however it has nothing to do with censorship. This is just bias.
Spotify is not a scientific journal. It's purpose is not to decide the truthfulness of its content. It should not publish content that breaks a law. If no law is broken, Spotify has neither an obligation, nor should they intervene/censor the content.
If we establish, that a statement is "really true" only if a celestial being, aware of all the facts, would consider this statement true, then pretty much all statements in the world have an unknown for their truth value. The error also can't be established. What people thought "really true" a hundred years ago, we now laugh about. Same will happen to many other things.
Censorship of "falsehoods" is a very dangerous concept. It prevents innovation. Einstein was essentially a heretic. His theories were bold and completely absurd to most people back then. Should we have censored them?
However, for many many statements, a lack of evidence has no impact on the truthfulness. Just because I can't prove something, doesn't make it false. Just because there is a mountain of counter-evidence, doesn't make a statement false, it just makes it less likely to be "really true". However, there could be a surprising piece of evidence, that trumps (pun intended) all existing counter-evidence.
If you want to censor, then you essentially force society into coherence. That is good in the short-term, as it reduces conflict, but very very bad in the long-term, as it suppresses non-standard opinions (i.e. innovation and free expression).
A much better approach than censorship is to create a channel "What Joe Rogan Got Wrong" and list all his supposedly falsehoods and explain the mountain of evidence against it. That of course takes effort. But yeah, the quick solution is rarely the best.
Swift has many nice similarities with Rust and other current languages from a pure syntactical/language perspective, while aiming to be a GP language. It definitely serves a broader audience than Go, whose main target is server programming. Swift's main target is Apple UI programming, however, the language is capable of so much more.
Which is why Open Source is good news. It may make it escape its Apple box.
Bottom line: Yeah we are totally all in it together, except that for people who are well off, COVID is nothing but a minor bump on the road to early retirement, while for poor people its a life disrupting, potentially fatal calamity.
Very interested to see how this will be protected against exploits.
Lame threat that hopefully the EU will call upon.
You don't want to listen to any specific camp. The best is always in the middle and you are on the right track:
"Pick what is easy to read."
However there is a caveat, which is that functional style is only hard to read at the beginning. Have a look at how modern languages integrate functional programming (see java, C#, C++, etc.).
Java streams are a common example. They make most code much easier to read ONCE you are used to it, because they provide standardized behaviour that is side-effect free. When you write everything in plain syntax, the reader needs to abstract your code in his head, while when using streams, you just know what `filter`, `map`, `reduce`, etc. do and you only need to look at the small customizations. It's easier to read once you are used to it.
However there is a limit and this limit get hit quickly. A lot of people like to make their code as complicated and fancy as possible and reduce every possible line. This is definitely wrong. Code must be easy to understand and change. If you fail that, you are doing it wrong.
This also depends on your environment. If your co-workers don't understand the code you write, you have failed, no matter if your code is "nicer" or not. You either need to write simpler code or educate your co-workers to create common ground.