4,631 karma · joined April 30, 2012
Even if you have perfect clairvoyance, you still need someone to take the other side of the bet.
I can see how taxing assets could result in more selling than would have occurred otherwise.
But all else being equal, an increase in selling tends to put downward pressure on prices. So I don't see why an asset tax would be expected to cause inflation.
Today, I use gcc and clang. I would say that compiler bugs are not common in released versions of those (i.e. not alpha or beta), but they do still occur. Although I will say I don't recall the last time I came across a code generation bug.
As I believe were many southern states at that time, but certainly not because they were at all "liberal", either by the standards of then or now.
Both parties have changed so much since then that it's a weak comparison at best.
ETA:
To elaborate a bit: based on your response, it seems like you don't think my question is a valid one.
If you don't think it's a valid question, I'm curious to know why not.
If you do think it's a valid question, I'm curious to know your answer.
Sure, maybe someday LLMs will be able to report facts in a mostly reliable fashion (like a typical calculator), but we're definitely not even close to that yet, so until we are the skepticism is very much warranted. Especially when the details really do matter, as in scientific research.
But you can already do that, regardless of mail in voting or not?
For example: https://old.reddit.com/r/selfhosted/comments/1qi64pr/i_got_i...
Compared to typical total advertising expenditures during a presidential election, my guess is that $4M is close to a rounding error.
Company: 6 month change:
============================
Palantir: +20%
Salesforce: -9%
Shopify: +40%
Intuit: -26%
ServiceNow: -30%
Adobe: -17%
CrowdStrike: -1.5%
Snowflake: -3%
Cloudflare: 0%
Autodesk: -9%
Above companies are the 10 largest from this list:What additional runtime cost is incurred by the use of std::unique_ptr? Either compared to Rust or compared to doing manual memory management in c++?
Like when std::vector needs to resize its underlying storage (as a result of push_back, for example), it has to decide which approach to use to copy/move items from the old storage to the new storage.
For std::vector<std::string>, std::swap would probably be at least ok if not optimal, but for std::vector<int> it would be overkill and therefore decidedly non-optimal. In the latter case, you want to do memcpy(new, old) and be done, not std::swap(old[i], new[i]) for each int.
I think a lot of the motive for adding move semantics to c++ has to do with giving the compiler enough information to produce results that are both optimal and correct in generic code.
It's not about irreducible complexity in systems programming, it's about irreducible complexity in the creation of higher level abstractions.
You could certainly implement something functionally equivalent to std::vector<std::string> in C. What you couldn't do in C is implement std::vector<T> correctly and efficiently for any type T. That's where much of the complexity comes from.
The hard part is giving the compiler enough information so that it can automate a lot of what would have to be manually written in a language like C, and to produce a result that is both correct and efficient.
Like if I have a vector<std::string>, in c++03 when it resizes it must copy every string from the old storage to the new storage. For a vector of size N, that's up to N+1 allocations (allowing for the possibility that std::string uses the small string optimization).
Granted, std::string doesn't have to allocate when copied if it's a "copy on write" implementation. IIRC, there were some implementations that used that technique when c++03 was the latest, but I don't think there are any that still do, due to other problems with COW.
In modern c++, that same vector resizing operation requires exactly one allocation (for the new vector storage), because all the strings can be moved from the old storage to the new.
Yes, you could have a vector of pointers to std::string, but now you've got yet another allocation (and indirection on access) for every string. In practice that tradeoff almost never makes sense, unless perhaps the strings have shared ownership (e.g. vector<shared_ptr<string>>).
Ultimately, I think there's really no question that the vector resizing optimization described above is useful in certain scenarios. Having said that, I do agree that the associated complexity is annoying. Therefore, the real question is whether it's possible to have these benefits with less complexity, and I personally don't know the answer to that.
I think the most likely explanation is pretty simple. Whenever people are unhappy with their economic situation, at the ballot box they take it out on whoever is currently in power, logic be damned. Politicians know this.
Which of those do you think is likely as a result of the proposed action, and why?