As a German, I might not have thought of that but would absolutely use it to translate Verschlimmbesserung. Does it sound "normal" enough to native English speakers?
The sibling post's "disimprovement" sounds more natural and has parallel form with pre-existing broadly accepted English words like "disincentive" and "disinfect".
It's totally plausible portmanteau. I get the feeling thought that it sounds more marked in English than in German where these kind of mashups are formed more freely.
It doesn't sound normal. "worse-" doesn't fit as a replacement for the "im-" prefix, because the "se" ending doesn't flow well into the plosive "prov".
"disimprove" works much better.
The similar word "unimproved" implies you did nothing to make it better, "disimproved" implies you actively made it worse.
But this is still just effectively adding "not" to the word. If you must join two words that are the antonyms of each other (like verbessern and verschlimmern), the closest match I can think of is the vulgar pun "fuxed", a blend of "fixed" (repaired) and "fucked" (broke). https://www.urbandictionary.com/define.php?term=Fuxed
"updowngrade", funnily enough, I would understand as having the (IMO misunderstood/wrong) meaning you're trying to give to "Verschlimmbesserung" in your post here https://news.ycombinator.com/item?id=49483585 (making some parts better and some other parts worse.)
That's not what "worseprovement" conveys to me, you can worseprove a single part, intending to make it better, making that same thing actually worse by the very same change.
It works, but regression is broader. If I'm not mistaken, a regression can also happen without human intervention. Verschlimmbesserung is active. Someone actually tried something and made it worse.
How about "bloat". Something that doesn't need to be there, and it would be better if it wasn't, but it was typically added with some misguided "good intentions". Bloat.
This also applies to changing something. If it was perfect, and you changed it, and now it's not perfect anymore, then the work itself didn't need to happen, and was therefore bloat.
Most work is bloat. But we have tied continued existence to work (mostly -- we mistake work for value), so we've made infinite bloating appear mandatory.
As an aside, most of the human psychology (assumptions, beliefs etc.) is also bloat, and similarly benefits from debloating.
Interesting. By this definition, a poorly chosen algorithm is also "bloat", which doesn't seem right to me.
I see bloat mostly as "unnecessary dependencies." Things which, if you removed them, the product would improve.
e.g. importing a whole library for what could have been a simple function.
If something justifies its "weight", then it's not bloat. It's functional.
But there's also "feature bloat." If a feature or change doesn't need to exist, or makes things worse, then it's bloat. If you removed it, the project would improve.
You can't please everybody, which leaves your conscience as the deciding factor. If you would rather not draw black people with googly eyes and vacant expressions, I can hardly criticize that. Like you point out, you'll get criticized - but again, it's impossible to make everyone satisfied with this stuff.
Well with Liveview you go "full server state" for everything that you would normally just use plain JS for. For instance, toggling a checkbox or collapsing a div.
Having latency on such lowlevel interactions might make the UI feel sluggish as a whole.
Yeah certainly, but I'm not sure people are using it that way?
Most examples are to show cool stuff you can do, they're not production vetted. Like most JS examples out there don't really mean that people should be publishing live credentials with their bundles.
I imagine in most cases one would leave everything that is not behind a logged in status as normal routes/pages (signin, landing, contacts, etc). Or if not that those would be things requiring a socket/real-time interface anyway.
For the interactions, I don't think you even need to use alpine.js. Plain setup on DOMContentLoad, CSS Dropdowns/collapsibles that are replaced on JS load, proxying LiveView DOM/Morphdom events (if needed) so other components (even vue,react, etc) can listen to them, and CSS animations.
import { setup_live } from "./phx/setup_live.js";
import { setup_dropdowns } from "./interactivity/dropdowns.js";
import { setup_collapsibles } from "./interactivity/collapsibles.js";
import { setup_links } from "./interactivity/links.js";
import { setup_inputs } from "./interactivity/inputs.js";
function setup() {
setup_live();
setup_links();
setup_dropdowns();
setup_collapsibles();
setup_inputs();
}
document.addEventListener("DOMContentLoaded", setup);
I went as far as having `onclick` handles and global window functions. Complete heresy. Yes, it's not 100% JS free, but it's pretty much low overhead.
Then LiveView is mostly for your admin dashboards and logged in users views, where it makes it pretty easy to do real-time feedback type of interactions/views and spa like navigation. Since you have proper auth and identification on the user, you can just log them off, rate-limit, block an account, and close their socket if needed.
From the top of my head not really, but this would depend on a few things:
- Is it a vendor lib ?
- It's not but is some particular file that is big enough to not make sense including on the root layout?
- It's neither, but functionality that can trigger multiple times and should be only once and only on those pages because it can conflict? or some variation of that?
I think they're all solvable but what makes sense will depend on those, but also on how you're using LiveView (is it LiveView only for logged-in users/some auth, can you set those on the live_view layout...)
But in some cases this is a problem also in spa's, where you have to use a snippet to check if the lib has been loaded, if not add a script tag to the body, or load it through js, etc...
Did not look at it in detail, but I'm wondering about portability, eg how this works with system libraries, like OpenSSL. Is the resulting binary portable to systems with different C libraries than the ones the OTP system was linked against originally?
Probably not super well tested with a bleeding edge clang compiler though (and even for non-bleeding-edge versions, I'd suspect mostly tested with GCC). Triggering compiler bugs or exposing technically undefined behavior would not be entirely surprising.
Given that Apple silicon is pretty new my guess it porting and testing , I would also add not all ARM chips are exactly the same , there will be some minor nuances for sure .
Perhaps it is also some funding and access to the kits and dev time , updating gcc is not a full time job for most of the contributors after all.
This is a great thread, thanks! (And I see that your name is in the thread.)
I gather from there that previous efforts to target iOS are outdated, there is substantial work to handle the Apple ABI, and that it's not been seriously looked at yet.
