Watch your power usage. With large windowed VSCode or Cursor, you will see far higher CPU and GPU usage by WindowServer and more system power consumption. It’s easier if you track it with stats.app.
Arguably, especially in the 8/10/11 era, few of these features are things that meaningfully enhance the user experience. Incredibly, we're still running NTFS and dealing with hacks on hacks on hacks. In the 8 era, a huge number of massive projects were started, promoted, and mothballed.
I 100% agree. Just wait until you hear about NYPD challenge coins. [1] Pg. 21 shows us a coin that celebrates an absolutely despicable story where the NYPD forcibly committed a whistleblower to a mental hospital.
100%. Flow always had some great safety features and some complex type combinators. But the churn in the project and lack of non-FB participation made it hard to recommend.
Your comment is mostly on point, but the download speeds are way off. By the time Flash was really getting big, everyone was on 56k, (rarely) ISDN, or ~1mbps broadband of one type or another. But even with 56k, you're getting 5kBps. So a 45-100kB download was 20sec at most, and 500kB was about 2 minutes.
That said vector graphics and extreme sound compression was just how shit got done. In those days gaming and entertainment online was all about CD deployment, extreme delta patching, low bit rate audio (Teamspeak et al) and vector graphics when possible.
I miss those days. On top of it not yet being spoiled by billion dollar businesses, the extreme constraints meant that creative minds could excel far above and beyond corporate types. And that's why the internet had the reputation it did. The ones who were making waves were individuals and small development houses that were founder-driven. It's nothing like today.
We have a unique one: back before the z1d launched, we had a critical system that was very single-threaded and its performance drove revenue in an extremely direct way.
So we were, deep in the shit, fighting fires due to our systems being in a perpetual state of DoS, and we asked if they would rack a machine with a certain overclocked Skylake chip in it. We offered 7 figures to do it. It was worth that much to us to get ~40% more capacity without having to migrate off AWS. They said no :)
There are multiple tells that this move, just like the removal of radar, is supply-chain and cost-driven and not actually driven by engineering.
If this were a planned move, the software would already be ready to replace it. It is not. Cars without radar still aren't at parity with the car that have it, although they "fixed" this a few weeks back by simply turning off the radar on the older cars.
The parking sensors on the Tesla are really good and very useful. They show a rough outline of what is around you and are displayed very nicely compared to some other cars. It is a real shame to remove this, and downright dishonest to characterize it as some kind of leap forward.
The cheapest bargain-bin cars have this feature. Your $100k+ Model S or X will not.
Even more concerning: some features simply cannot be replaced by camera. Tesla infamously does not have a front bumper camera, making it impossible to detect obstructions occluded from view by the hood. For 3/S, which are low, this means it will be impossible to detect low obstructions like too-high concrete wheel stops and similar obstructions. Once the hood has occluded the view from the windshield cameras, these obstructions will cease to exist.
Laughable that this is being done on cars from a high-end brand, and that the remedy for customers who are getting worse cars today than you would get yesterday is to wait for these features to "be restored" at some indeterminate time in the future.
So what's the working theory here? Does the shrinkage allow new attachments to grow, essentially a "re-wiring" that causes the mother and father to focus on the child more than the rest of their lives?
Anecdotally, I feel that experience; consequently, business tasks have become much harder. I don't believe it'll be anything more than temporary, but it is certainly substantial.
Oh, man. This hits home. I wrote a bunch of libraries for public consumption with Flowtype - Facebook's competitor to TS, which was dominant circa 2016 - and there was very little on "advanced types" available to us. React types ended up being a massive pain, from the banal (React.Component vs React.Element) to the crucial (how do you represent the required props of a component, when some subset of them are being injected via context?)
Like the author, I used the redux code heavily to figure out what I needed to do, but it changed often and it seemed like the authors were also discovering the best way to use it. Combine with a bunch of Facebookisms (they were literally called that inside Flowtype source!) that were half-baked and... yes, we were just doing trial and error to make our typedefs succeed.
Add onto that a severe weakness of Flowtype, its propensity to coerce to `any` without telling you, making your types green but masking real errors and... it was a time. A time with a pain quotient in the neighborhood of doing async module loaders in 2012, or cross-browser DOM manipulation in 2008. It seems, we always find a new problem to tickle our brains.
Correct. This makes benchmarks, at least on thermally limited machines like laptops, very unreliable. High-quality review sites like notebookcheck spend a lot of time dealing with this by doing prolonged benchmarks and measuring thermals.
And there's an honest question to ask: how do you use your computer? If you're just browsing the web 95% of the time and occasionally opening Word/Excel, then short bursts of high power when you need it is perfect. But if you run longer tasks like many programmers or artists do, these machines simply fall down in sustained use.
This is one reason why the M1/M2 architecture has been such a revelation for professionals who primarily work on laptops. It can run full-bore for hours, because the lower-end chips (which are faster than any Intel released at the time) barely hit 10W at max load.
Turbo will move the processor above the rated TDP when there is thermal headroom to do so. Turning it off means you'll max out at the rated TDP.
Now, TDP used to mean the max power of the chip, but as Intel's process failures left them holding the bag with no significant performance updates to speak of, they started overclocking their chips more and more so they could claim that the new gen was faster than the last.
Try turning off Turbo Boost on a 2020 i9 Macbook Pro - you actually get a usable machine with reasonable battery life with it off, instead of the hot toaster with 2hr battery life that Intel gave you. But it'll max at something like 2.2GHz when you paid for just over 4.
> a try block in JavaScript immediately opts that section of code out of many engine optimizations as the code can no longer be broken down into determinative pieces
This isn't true and the dependent clause doesn't even make sense.
Yes, V8 had trouble optimizing try/catch back in the Crankshaft days. But those days are long gone, and major engines (V8/TurboFan, JSC, and Mozilla's latest *Monkey) handle this construct quite well. Even if this were not true, it would be meaningless, as this is simply syntactic sugar over `Promise#catch()`, which you would be using anyway.