I find this article rather underwhelming because it spends so much time calling out bad examples and so little time highlighting examples of subtlety (in any era). Without positive examples, I don’t think they make the case that this is a new phenomenon or even a phenomenon at all: all the author has done is identify a lens to criticize through.
It may be the case that this is a recent phenomenon (though some other commentators disagree), but without providing detail on what movies the author feels avoid this pattern, they make their argument impossible to refute or engage with. (It also insulates the author’s tastes from criticism, which I suspect is part of the motivation)
A couple examples the author gave sounded plausible--though I hadn't seen the movies in question--but then I felt the author was beginning to reach.
It's a bit of a humble brag to complain that movies are too obvious, isn't it? Serpell invites us to pat ourselves on the back for our sophistication as we turn up our noses at art that the uneducated rabble can comprehend.
Yes, there is a tradition in the arts of weaving subtle elements into a work that will reward the savvy observer. Arguably, it began when scribes and storytellers became no longer satisfied to merely repeat ancient texts, and set out their own commentary and interpretation, no doubt with some frequency constructing theories that never were conscious in the mind of the long-dead author.
This literary game is wonderful for arts colleges who happily charge young adults a handsome fee to play at this game that arose in a time when eligible aristocrats scrambled after every affectation that might provide an honest signal of their ponderous amounts of free time, wealth, and sexual fitness. Like tonsils, these vestigial organs have their defenders.
No doubt Serpell holds the skills she honed first at Yale and then at Harvard in great esteem. I imagine she derives much satisfaction at her ability to write hundreds of pages expounding on the literary equivalent of atonal noise. But while I'm happy for her to share her preferences, I'm not sure why those preferences should hold any great weight when it comes to popular culture.
Unsaid--and of course it is unsaid, it would be gauche to speak directly--is the claim that great art cannot be direct, clear, or obvious. The purpose of art is not to speak to us, but to sieve society into gradations of fineness. If any coarse, unimproved grit passes through the sieve, the sieve is defective. After all, if this rough grit can pass through the sieve, who will pay Serpell to laboriously grind the sediment into a fluffy, airy, rarefied powder at Harvard.
Yes, you are clearly also very educated. Impressive use of language!
I think it's pretty normal that as people get deeper and more invested in any given artform, they tend to become more appreciative of works that are less immediately pleasing to lay-people. You mentioned literature and (atonal) music, but this just as readily applies to food, wine, videogames, Anime, fashion, anything you can think of.
I'll agree that there's an unfortunate tendency for some people (again, in any artistic field) to get overly critical or dismissive of straightforwardly good work, especially if consuming, thinking about, and discussing the quality of work is their actual job and they're perhaps getting a bit bored of something they once loved. On the other hand, who better to recognize oversaturation of a given style or approach? I certainly wouldn't notice that wine producers are currently chasing the trend of dry whites, produced from heirloom European grapes to the detriment of all other kinds of wine! It's important to have at least some snobs, to push and goad artists away from currently oversaturated trends and continue the cycle of innovation and variety. And it's important to recognize that a critic complaining that a certain style is too popular doesn't mean they think it's a bad style or that you shouldn't enjoy it, just that they'd like to spend more of their life enjoying other things too.
Yup. Hence why we went from too much patriotism post-9/11 to too dark after Nolan Batman to too quippy after the Marvel takeover.
I remember first watching The Avengers and finding it refreshing. "This is fun! Why aren't more action movies fun? They're always so gritty and violent and serious, even though the protagonists are functionally superhuman, they're always so mean-spirited and the dialogue is is always so aggressively masculine and primitive and angry." And then that was everything for the next few decades.
Not quite. It’ll first be masticated, digested, and excreted before a simplistic version of it becomes the next mainstream.
Perhaps a more accurate (and less cruel) analogy would be that it will receive some scaffolding to sustain it - the leading edge is always unfinished. By the time it becomes mainstream, it’s closer to a product than an idea.
Yeah, I can see where the author is coming from, but it's kinda effortless to dismiss a ~2hr movie with a five sentence critique of a few scenes or lines of dialog. I'd much rather see the author go deep on one movie than shallowly take on a bunch.
Maybe it's a combination of the "bend" and the "long slow" part.
If you are making a turn the centrifugal force will push the fluid away from the axis of rotation. There is likely a level sensor only on one side of the tank, so the turn might push the fluid away from the sensor enough to trigger a warning.
The sensor likely has a time component to avoid triggering every time you make a turn, but if this bend is long enough, maybe the fluid is displaced long enough that it overcomes that minimum time.
Doesn't the unrolled version skip the speculation for three out of every four entries? If so, it seems suspicious that it does so much better when it looks like it's a mix between the first and second version instead of just an unrolled implementation of the second version.
I'd also be interested in seeing how this performs when the data isn't allocated in one chunk (which seems to be the absolute best case scenario for this trick). Will it end up worse than the "naive" version due to all the branch mispredictions?
> Doesn't the unrolled version skip the speculation for three out of every four entries ?
It does, but what matters is removing data dependencies often enough. By only speculating once every 4 items, we're lowering the average number of instructions per iteration (from 16 to 7.7). In the meantime, and thanks to value speculation, the CPU is still able to start working on 4 next items while processing the current loop iteration.
Indeed it's not pure unrolling of the second function.
> Will it end up worse than the "naive" version due to all the branch mispredictions?
If the data is allocated randomly, then the next cell prediction will often be wrong. In turn, the branch predictor of the CPU will predict that the prediction is wrong and won't continue execution with the predicted value. So it's the same behavior as the original implementation. So the overhead is not due to branch misprediction, but to additional cycles needed to compute the predicted value.
If the data is allocated in chunks, then the optimization remains useful as the cost of rolling back the CPU pipeline is not that much (I tested with the original list cut in 10 chunks and it added 100ms caused by 100k additional branch misses).
Considering he also wrote a blog post criticizing this question, I feel comfortable saying that he already passed on this job. So saying you'd pass on him has "you can't quit, you're fired!" energy to it. Also, I don't agree that this demonstrates insubordination. There can't be insubordination without a subordinate-supervisor relationship.
I also don't think this is a "smartass" answer:
> This is an irrelevant question unless you're focusing on recent grads with no job history.
That is a straightforward statement of his opinion. He's perfectly within his rights not to answer any question, and explaining why he chooses not to is hardly an unreasonable thing to do.
His goal seems to be to effect change. My understanding is that before reaching these questions, he _was_ interested in the job. Explaining to a potential employer that they lost a candidate's interest because of their application questions seems like something they would want to know.
> Also, you can short crypto on CME. Is that rigged too?
I think your first point is fair, but I think you're overselling things here. Yyou can only short Bitcoin, not all crypto, but the real issue is that the Bitcoin futures curve is in backwardation, which implies a certain financing cost to go short.
The settlements for the various contracts can be found here[0]. Nearly all of the volume is concentrated in the front month contract (Jan 23 at the moment), so if you want to be able to trade any size at all, you'll have to do so by selling that contract.
However, the issue is that the future price is consistently lower than the spot price. So if you bought a Bitcoin today and then sold a future for the front month (i.e. so you locked in the price you could sell the Bitcoin at in the future), you would be guaranteed to lose money.
And you will effectively have to do exactly that every month: as your short contract approaches expiry, you'll need to roll it over for the next month's contract. As the front month gets closer to expiry, its price will trend to the Bitcoin spot price, meaning you'll have to buy it back at a higher price then you will get when you sell the next month contract.
I don't have access to the historical settlement prices for the CME contracts at the moment, so I can't estimate the exact roll cost you'd pay over the course of a year. If we guess that it's about $100 each roll, then you'd pay $1200 over the course of the year per bitcoin (as well as having to commit 50% of the price of bitcoin in margin).
The OP posted 185 USDC net as collateral and has a short position of 450 USDT, which he's paying about 13% on. In the CME case, the collateral requirements are higher (50% of the notional shorted) but the financing cost is lower (less than 10% of notional shorted).
There is a big difference between "undefined" and "unspecified" behavior. In this case, the behavior of `unique_ptr(unique_ptr&&)` is in fact specified. [0]
However, the bigger issue with that code is that it can easily stop working with a simple refactor. Consider:
Neither of the above asserts will fire, but from the calling site, they look exactly the same. In my opinion, the more explicit option would be to do something like `bar(std::exchange(p2, nullptr))`
Right, but changes in some other code potentially silently breaking assumptions at the calling site is exactly why you would want an assert like this in the first place.
Against better judgement (and advice of counsel, presumably), this guy is still running his mouth to the media. If you had a disgraced former crypto CEO who was still willing to speak at your finance conference, wouldn't you keep him on the docket? I certainly would.
Fair point. I guess we’ll have to see how it goes. I imagine it’s going to be him saying how this was all just a big oopsie doodle in excel because he was too tired from playing LoL, and everyone around him will laugh and not ask any real questions, like who his parents are.
Absolutely. Sucks for everybody else speaking, though, because this conference has now, for all practical purposes, been renamed "The SBF Shitshow Conference"
Matt Levine says he's a fan, and that makes sense to me - Levine was pretty well respected as a journalist before he interviewed Fried, but it probably gave him a huge bump in interest when he did and even more now.
>but it probably gave him a huge bump in interest when he did and even more now
Nobody listened to or remembered the interview until a couple of people pointed out how prophetic it was with hindsight.
Levine found SBF pleasant to talk to and he's amused by financial chicanery.
At the time he said it sounded like a Ponzi, and SBF agreed, but after FTX blew up, it turned out to be so much more.
They didn't have an accounting department. Reporting makes it sound like they didn't even know what real accounting is. SBF was quoted as rejecting the concept of books. As Levine wrote more recently, their alleged balance sheet was mostly "magic beans" and cobwebs. None of this was part of the interview.
I listened to it at the time because although I'm not a regular listener to the Bloomberg Oddlots podcast, I've actually been subscribed for years and pick out the occasional episode and saw that Levine was on it. I had zero idea who Bankman-Fried was at the time, and was very amused by the whole thing. I assumed he was some sort of fringe ne'er do well who was willing to come on and talk about how scammy the whole ecosystem was, and I didn't actually realize that he was a big deal until some time later and I was shocked at how matter-of-fact he was about the whole thing.
So that is to say, I heard it, but I didn't realize the significance. And Levine is probably the best explainer and journalist in the financial space today.
Are you referring to Levine defending Bankman-Fried's answer on yield farming?
I think Levine was just saying, "this is a sensible answer to give as a trader operating an exchange where you want a healthy dose of cynical thinking like this instead of pure idealism".
Matt did call him out months ago on about how cynical his take on crypto was.
Saying he was describing a scam.
And that raised many red flags for others on SBF's ethos.
SBF prolly noticed his error and took efforts to cozy up to Matt afterwards. Hard to resist liking a billionaire who spends on you. It's a superpower that few are immune to in this capitalist world.
Ah, then whoever I'm quoting from HN who said that was mistaken, or I've remembered it incorrectly. I don't think it changes the point - he's good for Levine professionally; he'll never run out of material for his column at this point.
Saying that the mess is good for him to write about now is completely different than insinuating he was promoting FTX this spring, especially while simultaneously taking the position that he exposed it (which is mostly hindsight).
He's always talked about criminal and unethical behavior in an understated and humorous way in his column, and as a private individual, should be exempt from the slimy methods of character assassination used on politicians.
I'm sure I could have said it better. I listened to the Bankman-Fried episode of Oddlots when it aired not because I had any idea who Bankman-Fried was, but because it was an episode with Levine on it. I think he's the best financial writer working today bar none. So I'm not trying to cast aspersions on Levine.
> No, just no. Why is the MSM putting out constant puff pieces about this guy?
Just to be clear, this is the archive of a puff piece published on the Sequoia Capital website: they were talking up their book. They took it down when they wrote their investment in FTX down to $0 (from over $200mm). It was neither published recently nor by a MSM outlet.
There are hundreds of puffs pieces praising him in the MSM all the way till the day of the collapse, most of them VERY recently.
They are trying to shift blame and cover their butts.
The pivot now seems to be blaming CZ(the lazy China angle) for everything despite the obvious cause being the low effort diligence done by SV VCs and MSM themselves for recommending so many people into his trap.
Worst was how little oversight there was, Bankman Fried purposely deleted records and didn't hire anyone internally for simple tasks like accounting.
No surprise why, he was writing himself personal loans of billions while trying to bribe his way out of trouble both overseas and in the US.
Please, don't delete it. Even though you ended up ranting against a wrong piece of news (in terms of the timeline of events), your thoughts and takes on it were still interesting enough to ponder. And you admitted the mistake in a reply too, so people can easily see it.
As of 2008, options market makers are not allowed to naked short. [0] The only remaining exemptions to restrictions on naked short selling are for equity market makers. These market makers are still subject to delivery requirements (T+2). Plus, most/all aim to end each day flat
1. It is a compiler defined function (`__builtin_unreachable()`), but the issue is that MSVC doesn't have it, so you need a different implementation per compiler [0]. Plus, if a new compiler shows up (besides MSVC/GCC/LLVM), you'd need to investigate what the correct way to express `__builtin_unreachable` is.
From a compiler perspective, using a function makes the most sense, since that fits into the existing control-flow analysis that the compiler will do. Pragmas are processed by the pre-processor, so they aren't appropriate for expressing control flow hints.
2. `std::to_underlying(t)` is a wrapper around `static_cast<std::underlying_type_t<std::remove_cv_t<std::remove_reference_t<decltype(t)>>>>(t)`. So a lot fewer characters. It's also useful since `std::underlying_type_t<T>` behaves weirdly if `T` is not an enum type.
I think you are maybe missing the context that C++ allows the representation of an enum to be defined, e.g. `enum class X : unsigned char {};` vs `enum class Y : unsigned long long {};`. So you can't always cast to `int`. Technically, this isn't the case in C either: the type defaults to `int`, but the compiler will pick a larger type if necessary, e.g. `enum Z { a = ((long long)INT_MAX) + 1 };`
3. `htonl` are not standardized, so they were not part of the C++ standard library. Also, on Windows, I believe you'd need to include `winsock.h` to get access to them, which has its own idiosyncratic issues. You are also missing the context of C++ defining operator overloading, so you can call `std::byteswap(0ull)` and get an `unsigned long long` and you can call `std::byteswap(std::uint16_t{0})` and get a 16 bit unsigned integer.
> 3. `htonl` are not standardized, so they were not part of the C++ standard library.
I was questioning the motivation of this to facilitate network-byte-order issues as stated in the blog post. The proposal[1] (that the post linked to) also confirmed that the motivation was to expose more machine code intrinsics rather than deal with network byte order like I expected.
Concerning 1.) yeah, I guess I'd prefer a #pragma aesthetically, but didn't think about the fact that it wouldn't be exposed to the compiler.
one easily overlooked use of hton ntoh is portable binary persistent data. you want to read and write binary files in different cpu architecture hosts? mount a pluggable "disk" from different devices? use hton and ntoh to write/read binary data...
> Technically, this isn't the case in C either: the type defaults to `int`, but the compiler will pick a larger type if necessary, e.g. `enum Z { a = ((long long)INT_MAX) + 1 };`
if you read this and alarm bells didn't ring in your head I really invite you to immediately go check any enum you may have defined in your code because this is absolutely false with MSVC in C++ (https://gcc.godbolt.org/z/6bqW9rE81) (and C is often compiled as C++ on windows)
In practice I don't think that the latitude of making enum size depend on the enumeration has ever been used as it would be too easy to break the ABI. IIRC compilers have allowed forward declaring enums as an extension before c++11 which obviously doesn't work if the size depends on the definition.
I don't think that's true. Neither C nor C++ would allow you to invoke a function with an incomplete type, regardless of whether it is a `struct` or an `enum`, so there's no ABI issues with forward declaring them, but you wouldn't be able to define or invoke a function that takes an incomplete type argument by value.
struct A;
enum B; // as you pointed out, not allowed by the C++ standard
// fine to declare, define, and invoke
void fooA(struct A*);
void fooB(enum B*);
// ok to forward declare, but you can't call them
void barA(struct A);
void barB(enum B);
This is wrong a lot of pragmas, I would even say most pragmas are not handled by preprocessor. Some examples: pragma pack, warning control, pragma GCC unroll, per function optimization setting changes, all the pragmas which 1:1 map to c++11 style attributes. None of that is handled by preprocessor, pragma once seems like rare one which is. Yes all of them are compiler specific, but handling compiler specific behavior is one of the main purpose of pragmas.
I meant that they are processed before any syntactical analysis, so they're not particularly useful for this kind of thing. For example, these are all wrong usages of our hypothetical `#pragma unreachable`:
void foo();
#pragma unreachable
class bar
{
#pragma unreachable
};
namespace foobar {
#pragma unreachable
}
But pragmas can generally be used anywhere, barring tokenization issues. The end result is that `pragma unreachable` would likely end up turning into a magic function call inside the compiler, since it really only makes sense in a spot where you can invoke a function.
Also, I think you are conflating pragmas with `__attribute__`, which is how you set per function optimization settings. If you do that with pragmas, then it isn't limited to a single function.
This is the intent and purpose of _Pragma; it provides a way to use existing #pragmas that are tokenized and handled a bit later, so they can e.g. be included in macro expansions.
I think the only benefit of `_Pragma` is that it enables defining a macro that expands into a `#pragma` definition. I don't think there's any other use case beyond that.
> From a compiler perspective, using a function makes the most sense, since that fits into the existing control-flow analysis that the compiler will do. Pragmas are processed by the pre-processor, so they aren't appropriate for expressing control flow hints.
This seems par for the course for all C++ stuff: it's designed from a compiler perspective, not from a programmer perspective.
The correct way, IMHO, is to design features that supports the user's workflow, not to design the same feature in a way to make the compiler's job easier.
> `htonl` are not standardized, so they were not part of the C++ standard library.
They're POSIX standardised. The decision should have been to adopt something that exists in an existing and widespread standard rather than the worrisome not-invented-here syndrome that I see here.
> Attributes are better suited for that. #pragma has always just been a grandfathered in hack.
I'm not so sure attributes are better. They have political traction, but that does not mean better. All major compilers use pragmas effectively to implement custom compiler flags. See for instance how Visual C++ uses pragmas extensively to toggle specific compiler warnings, not to mention the infamous #pragma once
> You are also missing the context of C++ defining operator overloading, so you can call `std::byteswap(0ull)` and get an `unsigned long long` and you can call `std::byteswap(std::uint16_t{0})` and get a 16 bit unsigned integer.
I can believe this is useful in explicitly-typed form, i.e. using std::byteswap<T> with T specified. But letting T be inferred seems quite dangerous: C++ loves changing integer types around all by itself (via type promotion, for example), and byteswap<int> and byteswap<long> are (on UNIXy systems) simply not the same operation. For that matter, byteswap should really only be used on uintN_t.
That was unclear on my part, but I meant a new compiler in terms of "new to the project", not "new to the C++ community". The linked SO answer only covers those three compilers, which illustrates the issue I was talking about (you need to add a new `#elif` branch)
It may be the case that this is a recent phenomenon (though some other commentators disagree), but without providing detail on what movies the author feels avoid this pattern, they make their argument impossible to refute or engage with. (It also insulates the author’s tastes from criticism, which I suspect is part of the motivation)