1,613 karma · joined April 21, 2024
"IV crush" is an especially strange objection in this context. IV crush matters when you buy options at elevated implied volatility and that volatility collapses. If Micron suddenly drops hundreds of dollars because the alleged bubble is bursting then the implied volatility would sharply rise, which makes your put more valuable, not less. Invoking "IV crush" here mostly makes it sound like you've heard the terminology without thinking through how it actually applies to the scenario you're describing.
If you genuinely think Micron is going to collapse sometime over the next two or three years because this entire RAM shortage is an overhyped bubble, then the obvious trade is to buy puts around where you think the stock should return to once that bubble disappears. Micron wasn't remotely a $1000 stock before this run. We can be generous and use a $300 strike since even though that's still 100% higher than Micron's price prior to this run-up, it gets the point across.
A long dated $300 put is currently around $7 per share, so one contract costs roughly $700. If Micron eventually falls to $200, that contract is worth $10000 at expiry. At $100, it's worth $20000. If the crash happens well before expiry, it can be worth even more than its intrinsic value because there's still time value left.
If you're claiming to be certain that a gigantic bubble is going to burst and wipe hundreds of dollars off the stock price, there are long dated far out of the money puts specifically capable of expressing that position. Pointing at an expensive $1000 strike put and saying "look, options are complicated" is just a weird or rather superficial misunderstanding of some financial concepts.
While these criticisms were technically true, they were stated mostly out of a sense of insecurity from people whose jobs were basically spending years and years just glueing code together and mixing APIs to display some CRUD apps rather than out of a genuine concern for whether LLMs were actually producing poor products.
Nowadays those concrete criticisms don't really work anymore, LLMs are pretty good now and surpass most developers when it comes to writing the majority of shovelware that people have been employed, and so the narrative is changing from concrete criticisms about how LLMs were genuinely not capable of writing software... to these kinds of abstract and philosophical arguments that are really hard to argue against because they make no concrete claims.
If you say an LLM can't implement a feature, we'll we can test that claim concretely and LLMs are getting much better with every new release. If you say its code is slower, buggier, or less maintainable, those claims too can be measured and once again they're getting really good at these. If you say it takes longer to complete a task or requires more human intervention, we can compare it and measure etc...
But now the objection has shifted not to LLMs are incapable, but people are now incapable and LLMs represent a degradation of the "craft". And here there is nothing left to test or falsify. The argument has stopped being about whether the LLMs work, because that's verifiable and they are now at a point where it's hard to argue against their ability to actually produce functioning software, so now the argument is about whether people are morally, culturally, or intellectually permitted to use it.
This is mostly false. There are certainly some famous cases where math pursued for theoretical reasons later resulted in major practical applications but historically a great deal of math was developed either in response or alongside practical problems with anticipated real world applications, with war, industry and commerce being the major drivers.
The radiation never originates from within the event horizon. Furthermore the radiation itself does not encode any information about what fell into the black hole apart from the electric charge, angular momentum, and mass (all of which must remain conserved).
https://www.tomshardware.com/features/crucial-p2-ssd-qlc-fla...
https://www.tomshardware.com/news/wd-blue-sn550-ssd-performa...
https://www.tomshardware.com/news/adata-switches-nand-on-sx8...
Psychology explains why you feel tired by pointing to biology. Biology explains why cells need ATP by pointing to chemistry. Chemistry explains why ATP releases energy by pointing to physics. Physics explains that by pointing to some higher level form of physics like thermodynamics, which points to statistical mechanics, which point to quantum laws. When you get down to a certain level you simply have nothing left to punt to. You simply accept it because it's what's observed and makes reproducible predictions or you don't and go study philosophy or religion or something.
CPython's += does not perform deferred concatenation and CPython does not use lazy strings. The optimization uses an eager in-place realloc if the string's ref-count is 1. This remains the optimization used even to this day and was introduced in 2005:
https://docs.python.org/3/whatsnew/2.4.html#optimizations
>However, concatenating string lists with sum() was a common Python idiom at the time
It could not possibly have been a common Python idiom since sum() explicitly rejected strings by throwing a TypeError. This was explicitly special cased to avoid the degenerate performance and the TypeError even has an error message saying "TypeError: sum() can't sum strings [use ''.join(seq) instead]".
>Gvr's reduce dislike was more about its syntax. It doesn't mesh well with Python's lambda syntax.
No it had nothing to do with mixing with lambda syntax, on the contrary GvR actually wanted to remove reduce and lambda (and map and filter as well). Here is the actual article by GvR regarding removing reduce, absolutely nothing in it involves how it mixes with lambda expressions.
https://www.artima.com/weblogs/viewpost.jsp?thread=98196
>So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly.
s = s + "foo"
and
s += "foo"
Since 2005 with the release of Python 2.4:
https://www.snopes.com/fact-check/somali-pirate-luxury-cruis...
That's the addiction, not the information.
https://press.spglobal.com/2026-09-04-Bloom-Energy,-Illumina...
>Sept 21, 2026 S&P 100 Deletion NIKE NKE Consumer Discretionary
It's why time and time again you see people complaining on Internet forums about issues, and if you're part of a specific Internet bubble you might think that this complaining represents a general trend among the broader population and wonder how it is that no one is doing anything about this issue that you and the rest of your bubble are constantly complaining about... and the answer is mostly because the vast majority of people, who don't live in the same bubble you do, are mostly fine with how things work, but you're not going to hear them express it.
You're mixing up two claims here, and only one of these is kind of true. Yes LLMs do internally plan ahead in a way that is emergent rather than strictly part of their architecture, so that part of your claim is true. The way you word it by saying they are "coalescing the probabilities of a range of tokens at a time" is poetic sounding jibberish though. What's actually happening is one distribution output for the next token computed from a hidden state that implicitly encodes where the text headed.
Your claim that if an LLM does happen to pick a token "th" instead of "tw", then the LLM isn't stuck with that decision is entirely false for autoregressive LLMs which is what all of the frontier models are. Whatever an LLM picks as its output token is final, it has no ability to undo that token selection and it must continue on the basis of that choice. It can't go back on that decision and revise the output.
If you're interested in this, Anthropic has a summary of a very technical paper on this topic that mostly deals with this issue with respect to poetry:
https://www.anthropic.com/research/natural-language-autoenco...