I really need better generics support before ty becomes useful. Currently decorators just make all return types unknown. I need something this to work:
Yea whenever the idea of a company's profit is under a microscope, people often reflex to exec "greed" but it's typically because it's easier to blame a fictional disney villain, than it is to dig into the root of the problem.
If you can explain why anyone needs $8.469 billion of profit (2023), I'll gladly hear you out about greed. But something tells me I'm not going to get a great answer. :)
It would however have second-order effects; having less wealthy people would drive down rents/etc. If the wealthy just keep getting wealthier you'll end up in a situation where the wealthy just trade between each other out because of higher margins and the working class has nowhere to buy things.
Yes, it was written by a SoTA AGI trained for more than 30 years.
I would like to add that predictable generation defeats the very purpose of generative AI, so prompt engineering in this context will never equate to what engineering means in general.
I've done a fair amount of vibe coding cleanup, ironically using a fair about of LLMs, a lot of leadership are under the false impression that more code means better product, their ignorance is my gain.
A lot of "engineers" nowadays don't know the concept of per-user/customers configs and how to build/expose them to non-technical staff.
The main appeal of feature flags is simplicity and being a low-hanging way to apply per-customer/user configuration, few platforms allow true a/b testing (amplitude comes to mind but I'm sure there are more).
Feature flag can (usually does??) have another meaning, as a technical feature rollout mechanism, so you can roll back quickly without a deployment. A way to manage risk on teams that make hundreds of commits/deploys a week. You can then often send a certain % of traffic through the feature or not to look for early warnings.
I don't like feature flags for config. Just build a config system into the product UI - a settings page basically! That might have some bits you configure as the site owner, and some that are self-service.
My tips have been going down progressively, when I moved to the US I was taught 20% is "normal", now I tip 15% at MOST at restaurants and at MOST 5% on take out.
I'm tired of being shamed to pay more for less.
Also whoever was in charge of teaching staff to "turn away in shame" when the tipping screen is shown needs to go to some sort of gulag.
Tipping is for personal service. Does the kitchen even receive any of the tip if you tip for takeout? I figured it would just go to the person who hands you the food. After all, if you dine in, the tip doesn't go to the kitchen.
I still don't 100% understand why `React.memo` is not applied by default, wrapping every single component in a `memo` is crazy overhead and non-trivial to enforce codebase-wide.
Sure performance is a concern but is recursive re-rendering really cheaper than memoing all props?
Someone used to argument with me that "it will make render pass that use external value works if it always renders".
But I wonder should it even work at first place? It feels like you are covering the problem instead of actually fix it. Make broken things broken is a lot healthier for the code base in my opinion.
Immediately find out things to be broken is 100x better than find out it suddenly not works and can't even figure out why is it broken months later in my opinion.
Use external value in Vue is very noticeable in contrary to React. Because it will definitely not work even once. The in component computed or component itself both enforce memorize . Render will be skipped completely it you used external values there so the framework did not notice anything is changed.
PR is somewhat WIP-ish but I needed some motivation to do OSS work again :)
reply