I checked out the linked GitHub repo https://github.com/ecosyste-ms/package-manager-resolvers and it appears to be just a README.md that collects summaries of different package managers? How do I know these weren't just LLM-generated?
I think I like the idea, but the structure of the code doesn't look the best. What most sticks out to me is the "Managers" directory. I've seen similar patterns before, even at my current place of work, but they seem to correlate with less experienced implementations. For instance, I clicked on one of them randomly and already found an issue: https://github.com/nook-browser/Nook/blob/09a4c6957a2e9fd7c5...
I guess `www.` (and only `www.`) is always special, and the only TLDs with two components are `"co.uk", "co.jp", "com.au", "co.nz", "com.br"`?
I don't know how critical this "Manager" is (what even is a "boost"?), but a web browser should absolutely have a proper list of TLDs!
> What most sticks out to me is the "Managers" directory. I've seen similar patterns before, even at my current place of work, but they seem to correlate with less experienced implementations
What is wrong with such structure? How would you structure this code? Genuinely asking
There are no peer-reviewed studies yet for me to corroborate this with, but I've seen this pattern primarily from a specific type of autistic, and it's similar to an actor pattern: a Manager is expected to entirely "manage" whatever feature it's concerned with. This is usually different from a simple module by not collecting related functionality regarding the feature, but rather trying to contain the entire feature itself.
This typically creates artifacts like each "Manager" owning too much of its implementation (not benefiting from or contributing to shared structures, such as a proper domain suffix list), inconsistency between different parts of the app (since different "Managers" don't necessarily share common patterns between them), and tons of hooks into random "Managers" all over the code.
To me, it feels a bit like an "emotionally driven" architecture, where the organization of the code is based on the list of features of the app, and not based on the implementation of those features. So rather than having, for example, a drag and drop component for the tabs to use, you would have, for example, a ReorderingTabsManager, and the implementation may behave differently than drag and drop in other places. So rather than factoring out code into modules for deduplication, you're making modules ("Managers") based on where they are in the product, and duplicating functionality across each module, to varying standards of completeness and/or quality.
Now I don't know if this project is quite that egregious, but it hopefully illustrates why I raise an eyebrow when I see a project architected this way.
Apple Silicon actually has microarchitectural quirks implementing certain x86-isms in hardware for Rosetta 2 to use. I doubt any other ARM SoC would do such a thing, so I doubt third-party translation will ever get quite as efficient.
You also lose the ability to pull over virtually anywhere and refill your tank in five minutes, as well as the maintenance benefits that come from a decades-old design versus whatever software horrors are lurking in your car.
To top that all off, in parts of CA electricity is now 50c/kWh, which makes it roughly equally expensive to charge an EV as it is to buy a tank of gas.
I love electric cars, but there is a gap between what they COULD be and what they are.
The only reason to think an ICE vehicle doesn't have software horrors is if the vehicle in question is itself decades old. Practically every software horror of an EV is going to be found in modern ICE vehicles as well. In fact some of them have more horrors than some EVs. Subscription seat warmers anyone?
Sometimes we need dates attached - by the numbers (1838 of current 3176) that's probably some 5 or 6 years before ChatGTP. Or 3 or 4 years after the Netflix challenge.
Many developers do this, and it's explicitly allowed under Apple's Developer Agreement (section 3.3.1).
Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application (b) does not bypass signing, sandbox, or other security features of the OS; and (c) for Applications distributed on the App Store, does not create a store or storefront for other Applications.
The app store review guidelines (section 2.5.1) seem more narrow, but I think the above is what's enforced.
Weird, because Apple took down Fortnite for enabling a direct buy-button (bypassing IAP) after review completed. Just because an offending feature wasn't enabled at the time of review absolutely does not mean you're in the clear to turn it on after the review is complete. Whereas before you'd get the opportunity to fix anything like that during the review process, by sidestepping the review process you'd better be confident you don't ever ship anything that wouldn't pass.
From my lived experience and also from the preprint I love very much https://www.thetransmitter.org/spectrum/untangling-biologica... the autism spectrum is basically a collection of ways a brain can largely work differently than "normal". There's a limited number of these (4 according to current research). It's not that there's just individual small features that manifest in things like eye contact avoidance, over/understimulation, etc. it's that the entire brain will work a specific differently and result in a certain set of symptoms consistent with an autism diagnosis. I feel like autism helps form the basis that other neurological differences happen on top of, because it has such a large impact on how thinking and learning even works in the first place. Even in conditions like schizophrenia, psychosis, etc. you see thought loops or detachment from reality or delusions or any number of those kinds of dysfunctions but it all still happens on a base where there can be basically one of the four autisms; the autism seems to be a difference in the foundation that the rest of the brain is built on top of. It's very fascinating to me (I am very autistic). Of course I don't mean to say at all that each autistic type always results in the same brain function but just that usually other difficulties or differences are less fundamental than how autism changes practically everything.
It looks like this article is talking about that exact preprint, but a quick skim didn't reveal any sort of link.
Ever since I first read it, I've been training myself to identify the subtypes. I don't have good names for them, nor do I know how they correspond to the names in the preprint, but I can usually tell them apart. I have indeed seen exactly four.
I would love for there to be more research into the intricacies of each subtype, because I feel that care and accommodation could get a lot more personalized and helpful if there were less of "anything goes / anything could happen" and more specialization to what's most likely to be effective for each particular subtype. As it is, a lot of care programs or individuals supporting them may be specialized to an unknown degree to particular subtypes and not really understand how to become less specialized or even specialize further.
On top of that, I greatly want to understand better the subtypes other than my own, not least because a couple of them I can find very difficult to communicate with because my knowledge and arguments are formatted differently than how they learn. I want to learn how to format my knowledge in a way that's easier for them to understand and more convincing for them.
I'm just very curious and interested and I really hope the idea of autistic subtypes takes off because it absolutely agrees with what I've seen in practice.
reply