So far I've only ever been using a private symbol that only exists within the codebase in question (and is then exported to other parts of said codebase as required).
If I ever decide to generalise the approach a bit, I'll hopefully remember to do precisely what you describe.
Possibly with the addition of providing an "I am overriding this deliberately" flag that blows up if it doesn't already have said symbol.
But for the moment, the maximally dumbass approach in my original post is DTRT for me so far.
I feel like it would be creepy if the kid was using it without anybody ever checking up on it ... but I think all of my friends with kids would say that the answer to that is "parenting."
I mean, giving a kid an unlocked iPad and not bothering to do basic supervision can also have really creepy results, so I'm unconvinced that something like your work actually makes anything worse in the negligent parenting situation, and seems like it could be a lot of fun in the competent parenting one.
If you haven't already done this, I'd note that I can think of a number of parents who would probably rather enjoy a version of story mode that let them collaborate with their child and your code to put together a bedtime story before they turn it off for the night and tuck the kid into bed.
OpenAI stuff in general seems (to me, at least) to be overly positive and confident in terms of how it replies.
While I make no foolish claims that it's perfect, I've found Claude feels much less arrogant, and was genuinely appreciative when one of its replies started with an (accurate, of course I checked primary sources to verify that) analysis of the first half of my question, and then for the more obscure second half said "I'm not sure if I can answer that without hallucinating, but here's some stuff you could try researching."
Certainly Claude's tone and "attitude" (FSVO) works much better for me than any other LLM I've tried, though mileage will, of course, vary.
(I have zero connection to the company and am still on a free account, I'm just quietly impressed relative to the competition)
I absolutely agree with your analysis wrt current tech - however, I suspect the person you're replying to is talking about "what would be really cool" in terms of it happening in a future where the relevant underpinnings had advanced to the point where it could actually manage the situational/nuance stuff properly.
I almost certainly wouldn't want to use something that tried to implement it now but it's a lovely dream and the state of the art keeps advancing at quite the speed (i.e. faster than I would have predicted, even when I do my best to take into account that it keeps advancing faster than I would have predicted ;).
It does kinda make sense to me that the various non-US subsidiaries that survived did so at least in part because those places didn't have anything like Walmart.
Whether they'll be able to continue to survive in a world containing the current incarnation of Amazon is a different question and I've honestly no idea how that will turn out.
Lots of people not in the US saying they got redirected to various places due to (I guess) some sort of GEOIP detection rubbish, me included.
There's a (just about readable, the background is greyed out due to a popup, although thankfully the popup doesn't cover any of the text) archive at https://archive.ph/3HvjM - far from perfect, and I understand if people would rather not bother than deal with the low contrast ick of the archive, but I found it interesting enough to maximise my screen brightness and read it anyway.
I got redirected to history.co.uk/ (the root, so lol, no article for you)
There's a (just about readable, the background is greyed out due to a popup) archive at https://archive.ph/3HvjM - far from perfect, and I understand if people would rather not bother than deal with the low contrast ick of the archive, but I found it interesting enough to maximise my screen brightness and read it anyway.
Once you get as far as FDIC insurance being involved, the bank generally ceases to exist (ideally via a fire sale to another, more stable bank) and the shareholders generally get (all but) wiped out, at best.
Competent risk management so that doesn't (generally) happen is a core competency for a bank, and if regulators think you're doing it wrong they will come down on the bank's leadership like a ton of bricks.
If anybody reading this comment would like to learn more from people who understand the area far better than I do, I would recommend patio11's 'Bits About Money' and Matt Levine's 'Money Stuff.'
I remember some years ago we got somebody joining irc.perl.org #perl to ask for help replacing perl with lua as a game scripting system.
Obviously, a few people were like "uh, why would -we- want to help you with that?"
As soon as I saw an example of this existing code, however, I told said people to STFU ... because for some arsef_cked reason I don't understand at all, they'd used EmbPerl of all things for the scripting, which is basically "PHP for mod_perl" and exactly as horrible as you might imagine even when used for its actual purpose rather than in this case for something completely unrelated.
Even if sensible perl would've been an acceptable approach (and speaking as a veteran perl programmer, I would still consider lua to be more suitable; I strongly consider an importand part of the Zen of Perl to be knowing when to use something else) the approach they had taken was an abomination unto Nuggan and very much deserved to die.
What they had was very definitely the sort of perl code that justifiably contributes to people hating perl, and I considered it a service to perl to help them rip it out in favour of lua code that actually made sense.
(I, personally, think perl works very well as a scripting layer for e.g. irssi, though you might come away disagreeing if you read the average irssi script rather than ones written with a little care and concern ... but for a game? Nah, lua all the frigging way)
If the map editor is an extension (and they have lots of example extensions on github, all of which I've checked are under normal open source licenses) rather than a set of patches to the core code itself, it isn't subject to the Defold License in the first place.
(so if the extension API is missing something, contribute the feature(s) you need back to core, then you can write your extension free of issues, so far as I can tell)
Paid extensions are allowed, which seems like a neat compromise.
If you need to add an extra API or something to the core to make your paid extension work, you can't charge for that, which I think is designed to incentivise "improve the extension API, contribute that back to the core project, then go wild on your commercial extension and see if you can get people to pay for it."
I have no clue whether this approach will turn out to work in the medium-to-long term, but it's a fascinating idea and seems at the very least like an experiment very much worth conducting.
They seem to be fairly explicit that _they_ believe that extensions aren't covered by those restrictions.
Possibly the license text needs to be tweaked to make that more clear (IANAL too) but I read it as meaning that commercial extensions were fine, just not commercialising a patched version of the core code.
Your concerns do seem entirely reasonable, but if, in practice, they become an issue, it seems like the codified-in-law goals of the foundation (see https://defold.com/foundation/) strongly suggest they _would_ tweak the license text as required.
I dunno, I don't think the harsh restrictions you mention exist, and I'd hope that if any actual lawyers read them as existing then their employers will direct them to help get the license bugfixed.
> Yeah but the open source ones ARE guaranteed. Even if they later become closed source, the code up till that point will remain open source forever.
The changes from the Apache 2.0 license are sufficiently minimal that you can _still_ fork it from that point, you just (a) won't be able to use the trademark (b) won't be able to sell it.
Given the clearly stated goals of the foundation and hence the project, that seems to be providing exactly the guarantees they intend to provide, and while your point about assurances is entirely fair, I think you're underestimating the level of legal guarantees that you do get here.
My first Archimedes came with a ring bound user's manual that was, IIRC, about 1/3 a guide to using the Risc OS GUI, and then 2/3 a programming guide to the version of BBC BASIC that shipped with it.
(I remember reading it end to end as a child laid on my parents' bed because the light was better in there than in my room, shortly followed by developing the programming addiction that has stuck with me the rest of my life ;)
It didn't cover arm2 assembly, but my parents bought me an extremely good book that did - and described the chip architecture itself in detail as well.
I only touched a Commodore at a friend's place to play games on it, but it sounds like they also understood hobbyists :D
Having cut my teeth on early Archimedes machines, I have a deep fondness for arm2's 16 instructions and the (lost during a house move, I suspect) assembly book I had that gave me enough of a description of the internals of the chip that I could desk check my assembly in my head with reasonable confidence that I was mentally emulating what the chip was actually doing rather than just what outputs I'd get for a given set of inputs.
Having to remember where I'd put the relevant chunk of assembler any time I needed a division routine was, admittedly, less fun, but the memories remain fond nevertheless :)
Yes. Not Wanting To Do That was the motivating factor for coming up with this approach :D