Not sure what that say's about me ...
2,045 karma · joined August 14, 2007
Not sure what that say's about me ...
Phones should be required to get (at least) security updates for (at least) the same period as they are covered by repairability requirements.
FFS, Deere's egregious behavior is a large part of the push for RTR legislation.
Disappointing, if not unsurprising.
The would possibly need to apply some effort to appear human, but that should only throttle the rate, not stop their scraping all together.
How do you determine the trustworthiness of those other sources when an ever increasing portion are also LLM generated?
All the "you just need to" responses are predicted on being able to police the LLM output based upon your own expertise (e.g., much talk about code generation being like working with junior devs, and so being able to replace all your juniors and just have super productive seniors).
Question: how does one become an expert? Yep, it's right there: experts are made through experience.
So if LLMs replace all the low experience roles, how exactly do new experts emerge?
Also, even if it were just a Dr front for Bing, it doesn't change that I got perfectly reasonable results for the search string said to return unusable results from Bing, so
Analyzing the bytecode can give some insight into how the compiler is likely to treat the code (inlining, intrisics, etc.), of course, so it's not useless, just not the whole story.
And, as you mention, JVM (and .NET) languages can also be AOT compiled. In those cases you could use more standard analysis similar to that in the OP.
Biggest thing for me has been to try to avoid additional formation (though I know from my annual imaging that I have at least 6 or 7 of my little buddies laying in wait). Citric acid, increased liquid intake, reduced intake of high oxalate foods (and/or taking calcium citrate or high calcium foods at the same time), trying not to hold my pee unnecessarily, and a prescription for hydrocholorothiazide have together greatly reduced my kidney stone formation. I got by with only a couple little ones last calendar year, and only one middling one (~4mm) so far this year.
Don't take any of that as medical advice, of course.
I've had more than a few stones over the past couple decades, and when I finally got myself in to see a urologist, that was one of her primary recommendations.
That, along with some other treatment, seems to have helped considerably (only one non-trivial stone in the last ~12mo & the few others were barely noticeable).
The interview process should be a conversation, not an interrogation.
If it isn't, I probably don't want to work there.
Yes, Spring Boot is very popular, but there is a whole world of Java outside Spring, even if you confine yourself to just web apps (which is far from the only domain in which Java is used).
Reference counting is widely considered one strategy of garbage collection (https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...). For that matter, some GCs that are primarily tracing also use ref counts for some portion of the heap, as an optimization (just as some primarily refcounting GCs also run a trace to clean up cycles).
Also, reference counting can certainly result in pauses, when large graphs of interconnected objects are reclaimed. On the upside, you know when a pause might happen. You still don't know for certain without explicitly keeping track of what is about to be freed, which would add additional overhead, and indeed may not be practical or even feasible.
Indeed, the fundamental question is whether the costs of automatic memory management (be it tracing GC or refcount GC) are "worth it".
But it's not always as simple as a monetary consideration, and even when it is, the monetary cost often involves way more than just dev time vs cost of computer (e.g., power, cooling, distributed cost over many end users, market applicability because of system requirements).
Haven't quite finished reading the paper yet, but it's interesting so far.
While they present a method that could be applied more widely, this paper is only analyzing current tracing GCs in OpenJDK (plus Epsilon GC). Would love to see future papers taking other GCs into account (e.g., various flavors of refcount GC).
Even better would be a way to compare vs methods of "manual" memory management (manual alloc/free, RAII/scope based alloc/free, arena allocation, etc.). Unfortunately, non-GC memory management is very application specific, so I'm not sure if a generalized analysis would be super useful.
If I could get the navigation and analysis (go to def/decl/parent/etc., show/jump to uses/children/impls/etc.) all on its own, without auto-complete, type hints, or syntax highlighting, I'd be a pretty happy camper.
I'm fine with features that are on-demand (on-demand completion, type info, actions, etc.). They add occasional value without distraction.
About the only other things I care about in a development environment are compile output navigation (optionally with isolated warnings & errors, but full output is mandatory), configurable run and tooling integration (doesn't need to be close integration, either, just flexible and configurable).
Gravy/Frosting (depending upon your preferred metaphor) would be debugger and documentation integration. Both are hard to do well, and can usually be accomplished using a decent run/tooling interface.
https://www.forbes.com/sites/erikaandersen/2012/03/23/true-f...