I had always interpreted quadratic funding as being a tax rather than a subsidy. You donate $100 and the cause receives $100, then your next marginal $100 is discounted quadratically, and the government receives the difference. I think that just straight up resolves the first two issues.

I think that very quickly just changes the forms of donation to be “something that doesn’t count as a donation” (buying tickets to an event or even just straight up NFTs).

As soon as the quadratic decrease is more than my marginal tax rate, I’m better off buying an NFT from the cause I want to support than making a donation.

a more plain-english explanation from Vitalik's blog:

https://vitalik.eth.limo/general/2019/12/07/quadratic.html

I don't appreciate cartoon pornography being shared here. I think this website is best when it's professional.

Pray tell, how many places is appropriate to call the same function? Is 5 too many? How about 6? When I hit 7, I have to refactor everything, right?

This only applies to a situation where you have a function that requires dynamic checks for preconditions. I would suggest that such a function (or how it's being used) is likely a blight already, but tolerable with very few call sites. In which case checking at the call site is the right move. And as you continue to abuse the function perhaps the code duplication will prompt you to reconsider what you are doing.

So if a function dereferences a pointer, it doesn't make sense to check that it's not null inside the function?

Unless there's an actual performance implication, this is all purely a matter of taste. This is the kind of broadly true, narrowly false stuff that causes people to destroy codebases. "I can't write it this way, because I have to push ifs up and fors down!!!" It's a totally fake requirement, and it imposes a fake constraint on the design.

If there is a performance implication of moving the if into the callers or not, you can do it with an inline function.

  static inline int function(blob *ptr, int arg)
  {
     if (ptr == NULL)
       return ERR_NULL;
     return real_function(ptr, arg);
  }

Just like that, we effectively moved the if statement into 37 callers, where the compiler may be smart enough to hoist it out of a for loop when it sees that the pointer is never changed in the loop body, or to eliminate it entirely when it sees that the pointer cannot be null.

IMO you should assert it's not null. There should never be a circumstance where you pass a null pointer to a function.

ISO C allows:

  free(NULL); // convenient no-op, does nothing

  fflush(NULL); // flush all streams; done implicitly on normal exit

  time(NULL); // don't store time_t into a location, just return it

  strtol(text, NULL, 10);  // not interested in pointer to first garbage char

  setbuf(stream, NULL);  // allocate a buffer for stream

  realloc(NULL, size); // behave like malloc(size)

and others. More examples in POSIX and other APIs:

  sigprocmask(SIG_UNBLOCK, these_sigs, NULL); // not interested in previous signal mask

  CreateEventA(NULL, FALSE, FALSE, NULL); // no security attributes, no name

Reality just ran over your opinion, oops!

I'm sorry. Are you claiming the people who designed those functions made good choices? They altered the behavior of the function considerably for a single input value that is more likely to be a bug than not.

Yes. I will probably continue to make similar choices of the future.

You don't need an explicit rule, you just need to be smarter than than the average mid-curve tries-too-hard-to-feel-right hn poster and realize when you're repeating a calling convention too much.

>I think a blog post... is probably the wrong place that kind of enlightenment

There's this site full of cool knowledgeable people called Hacker News which usually curates good articles with deep intuition about stuff like that. I haven't been there in years, though.

Hey, check this out:

#include <iostream>

struct Price { double x; };

struct Quantity { int x; };

void sendOrder(const char *symbol, bool buy, Quantity quantity, Price price) {

    std::cout << symbol << " " << buy << " " << quantity.x << " " << price.x

    << std::endl;

}

int main(void) {

    sendOrder("GOOG", false, Quantity{100}, Price{1000.00}); // Correct

    sendOrder("GOOG", false, Price{1000.00}, Quantity{100}); // compiler error

}

If you're trying to get it to type check, you have to make a type first.

I don't appreciate these arguments, and view them as disingenuous.

That still has the issue of Quantity{-100} being a-ok as far as the compiler is concerned, but there are other things one can do (as the article alludes to).

My reading of this article wasn't to say that these things are impossible in C++, just that they're not the default or the first thing you try as a beginner is perfectly wrong.

I didn't realize that CVE was funded by the DHS. Isn't it better for it to be independent and not funded by an intelligence agency?

It's enough of a public good to have a common advisory for vulnerabilities that FAANG should just kick it a few million a year. How much can it possibly cost to run this anyway?

The death toll from that incident was one (1).

You can see online, nuclear power is actually one of the safest methods of energy generation, behind solar and ahead of wind, because sometimes dudes fall from the tops of the windmills.

Could you start looking at the second-order effects of the meltdown to get a higher death toll? Probably, but you could probably also look at all of the pollutants generated by solar panels, and the fact that they get shipped to Africa and crushed up and thrown in the ground to make solar's death toll look higher too.

Death toll isn't the only metric for accident severity. Environmental pollution is really important too.

And with Fukushima we were kinda lucky. It was still a double meltdown with several hydrogen explosions and could have been much worse.

I think I already addressed this point. You also need to think about second-order effects, but like I said, there are second order effects to all of these solutions. Just because nuclear's side effects are more easy to dramatize doesn't mean that it is necessarily more deadly / harmful to the environment.

Death toll so far. Projections of cancer deaths from Fukushima go up into the hundreds.

That's not true.

The WHO says there will be no detectable health effects.

Invocations of the anthropic principle come with more baggage than may be realized. And I suppose, by extension, the Copernican principle too.

https://www.scottaaronson.com/democritus/lec17.html

Some people take it way too far, but I think my invocation was just trivially true. We can't come to any conclusion about the prevalence of life elsewhere in the universe, just based on the fact that we exist.