Sounds like you are thinking they just need Asimov’s laws. But I think the point is, this can easily be weaponized by somebody with the willpower to do so.
No, just that “What if I just cheat to get the treat” is also something my lovable Boxer does when I hide rewards as well.
I suppose her energy is limited but even if infinite, and with caution, I estimate the chances of a mass extinction event due to Pickle taking over the world at < 1%.
This feels like the most ridiculous option and one I've never heard in the wild. Sequel-ite, S-Q-lite, sure. S-Q-L-ite, nah I'm not buying that. Kinda like the inventor of GIF insisting on pronouncing it wrong (I kid)
Thousands of cheeses, each of which is a unique experience. Heck, even the serving temperature completely alters the experience. Next: wines, charcuterie, ...
Pity the fool who can't taste the difference between any of these.
You or the developer could piggy back on “aws configure export-credentials --profile profile-name —-format process” to support any authentication that the CLI supports.
The AWS APIs are quite stable and usually do exactly one thing. It’s hard to really see much risk. The worst case seems to be that the API returns a new enum value and the code misinterprets it rather than showing an error message.
I wonder if you could pay them to tweak the messaging about your products. So when a user asks: Is drinking Coke everyday good for my health, it starts saying yes because sugar is vital to our survival.
I couldn’t find a library like this in PHP, but realized for my use case I could easily hack something together. Algorithm is simply:
- trim off all trailing delimiters: },"
- then add on a fixed suffix: "]}
- then try parsing as a standard json. Ignore results if fails to parse.
This works since the schema I’m parsing had a fairly simple structure where everything of interest was at a specific depth in the hierarchy and values were all strings.
If I’m not mistaken, even JSON couldn’t be parsed by a regex due to the recursive nature of nested objects.
But in general we aren’t trying to parse arbitrary documents, we are trying to parse a document with a somewhat-known schema. In this sense, we can parse them so long as the input matches the schema we implicitly assumed.
> If I’m not mistaken, even JSON couldn’t be parsed by a regex due to the recursive nature of nested objects.
You can parse ANY context-free language with regex so long as you're willing to put a cap on the maximum nesting depth and length of constructs in that language. You can't parse "JSON" but you can, absolutely, parse "JSON with up to 1000 nested brackets" or "JSON shorter than 10GB". The lexical complexity is irrelevant. Mathematically, whether you have JSON, XML, sexps, or whatever is irrelevant: you can describe any bounded-nesting context-free language as a regular language and parse it with a state machine.
It is dangerous to tell the wrong people this, but it is true.
(Similarly, you can use a context-free parser to understand a context-sensitive language provided you bound that language in some way: one example is the famous C "lexer hack" that allows a simple LALR(1) parser to understand C, which, properly understood, is a context-sensitive language in the Chomsky sense.)
The best experience for the average programmer is describing their JSON declaratively in something like Zod and having their language runtime either build the appropriate state machine (or "regex") to match that schema or, if it truly is recursive, using something else to parse --- all transparently to the programmer.
What everyone forgets is that regexes as implemented in most programming languages are a strict superset of mathematical regular expressions. E.g., PCRE has "subroutine references" that can be used to match balanced brackets, and .NET has "balancing groups" that can similarly be used to do so. In general, most programming languages can recognize at least the context-free languages.
reply