If you're into handheld console emulation then definitely check out https://gbadev.org as well. I remember their forums were epically filled with reverse engineering knowledge.
Got the family a couple of Anbernics and we wanted to see if we could make our own Game Boy Advance games. I started out checking out gbadev.org but found everything there a little dated and getting a devkit set up on macOS looked messy.
Ended up using GB Studio instead. I don’t love low-code or no-code envs, but the community there is very active on Discord and Youtube.
Feeling valued is the key here. If you need external validation then by all means, work smarter towards it. Become a manager. Become a company influencer. Build a brand, and sell it hard.
At some point later in life, I hope you’ll figure out your own sense of value, true to your being, and decoupled from what others may grant. Your raison d'être.
Can someone explain why they didn’t go with (anonymous) class destructors? Or something other than a Symbol as special object key. Especially when there are two Symbols (different one for asynchronous) which makes it a leaky abstraction, no?
Destructors require deterministic cleanup, which advanced GCs can't do (and really don't want to either from an efficiency perspective). Languages with advanced GCs have "finalizers" called during collection which are thus extremely unreliable (and full of subtle footguns), and are normally only used as a last resort solution for native resources (FFI wrappers).
Hence many either had or ended up growing means of lexical (scope-based) resource cleanup whether,
- HoF-based (smalltalk, haskell, ruby)
- dedicated scope / value hook (python[1], C#, Java)
- callback registration (go, swift)
[1]: Python originally used destructors thanks to a refcounting GC, but the combination of alternate non-refcounted implementations, refcount cycles, and resources like locks not having guards (and not wanting to add those with no clear utility) led to the introduction of context managers
Destructors I other languages are typically used for when the object is garbage collected. That has a whole bunch of associated issues, which is why the pattern is often avoided these days.
The dispose methods on the other hand are called when the variable goes out of scope, which is much more predictable. You can rely on for example a file being closed ot a lock released before your method returns.
JavaScript is already explicit about what is synchronous versus asynchronous everywhere else, and this is no exception. Your method needs to wait for disposing to complete, so if disposing is asynchronous, your method must be asynchronous as well. It does get a bit annoying though that you end up with a double await, as in `await using a = await b()` if you're not used to that syntax.
As for using symbols - that's the same as other functionality added over time, such as iterator. It gives a nice way for the support to be added in a backwards-compatible way. And it's mostly only library authors dealing with the symbols - a typical app developer never has to touch it directly.
For garbage collected languages destructors cannot be called synchronously in most cases because the VM must make sure that the object is inaccessible first. So it will not work very deterministically, and also will expose the JS VM internals. For that JS already has WeakRef and FinalizationRegistry.
The so-called Founder mode is basically necessary when a CEO shows signs they're unable to effectively manage their suite of chiefs and directors to steer the company stably into better times. The founder (often CEO themselves) feels immense board pressure and blames reorganizations (they chose for themselves) for this and goes all-in on another reorganization after firing executives and publicly sharing their epic shareholder letter, while quoting Steve Jobs and other greats.
Absolutely not saying MBA CEOs like Tim Cook are superior (in fact I personally believe the opposite), but for a founder to go into "Panic mode" is an act of childish, unstable behavior. When you stop and think about it from 5000 feet, maybe the founder is the one that should be replaced. It wouldn't be so bad in case of AirBnB.
As an engineer I have nothing against OKRs. But it's often the day-to-day management (EM or PM) who tend to override the team's OKRs for upper management to prioritize something ad-hoc & out of scope they agreeably said Yes to.
And that's fine I think, it's why a lot of companies are using one or more of the agile methodologies. But if that's combined with OKRs then said OKRs need to be adjusted, and it'll be down to the manager to pay that cost.
We use SAFe at my current job (please don't look at the website, if you thought the "scrum" infographic was too big already lol); we set quarterly goals and objectives, usually don't meet them because Reasons, but if there is an incident or change that warrants changing those goals it's a Big Thing and we basically redo the planning sessions (two days or so); it's a big disruption and it's costly so it's not done lightly. We've only done that once in the past two and a half years or so.
Is this still a discussion in 2023? I remember writing phpdoc @type hints in 2013, as that was the de facto way to have intelligent autocompletion in editors back then.
reply