681 karma · joined November 6, 2012
These things are generators of pleasing words. They are random and not at all thinking.
Why would anybody think that prompt guardrails would be effective?
I think you are conflating YAGNI and premature optimisation and neither apply in this case.
I'm not comfortable with my entire online identity being protected by a single line of defence which is a company that I'm paying a few dollars a month to. Not having to type 6 digits off a phone is a pretty minor convenience for me.
There is a definite public interest in understanding how Google conducts itself given the reach and impact it has.
There is no way for the public to have confidence in the trial process if it is conducted in secret, and given the outcome every reason to question the process.
I'm surprised anybody objective would defend this.
Who can know how appropriate or not the remedy was when the evidence is hidden?
For full disclosure: I'm neither a google employee nor a US citizen.
Regulation in territories where it is harder for corporations to buy politicians seems to be far more successful at driving improvements.
The thing is it doesn't really matter what tools you use. The problems are complex and they don't become simpler just because you use an LLM. We will gain a bit of efficiency and then spend that gain on whatever new problems LLMs throw up plus the constant stream of new problems the world generates.
Software engineers are not getting replaced by LLMs any more than they are by UML, visual programming tools, RPA, MDD, code generators or any of the other fads that have come and gone over the years.
Supply of the kinds of services under discussion here is rarely limited in any practical sense, so scarcity does not play.
> The way things should be priced is based on the value it gives you. If your service makes me or saves me $100 of value per month, I should be prepared to pay up to a little below $100 for it.
This ignores opportunity cost. Very few buyers have infinite cash, they do tend to have infinite ways they could spend money though and many of them will give a far better return than a couple of percent.
In reality if you're adjusting your pricing to try and extract the most you think you can get away with from the customer, you will lose a substantial number of buyers - and probably more so with buyers who have a technical mindset.
They should simply be looking to prevent a re-occurrence and a fine on this type of organisation wouldn't help.
Perhaps they should have powers to prosecute executives.
The idea that prescription medication is marketed to the general public on TV is entirely foreign to me, the descriptions of conditions that 99% of people wouldn't have heard of make me wonder just who they are connecting with.
Then you get to the "side affects may include headaches, vomiting, diarrhoea, haemorrhaging, spontaneous combustion, exploding eyeballs, bubonic plague and instant death - do not take this drug if you are a living breathing human being" bit and you can't help but laugh. Who goes to their doctor after watching one of these?
And "Dude Wipes" - I mean is that a spoof?
The last time I worked anywhere with periodic password change was 8 years ago and they were phasing it out. The same place would reset your password to Monday123 if you got locked out (whether you needed a password reset or not) and forget to set the "force change" flag.
- slack
- github
- microsoft
- google
- atlassian
- notion
- clickup
- hubspot
So ask yourself: Who benefits from the hype? And who would benefit from a better general understanding of the flaws?Yes it will. Your changes will be confined to only the table(s) where the natural key is present, not spread across every table where there's a foreign key.
Of course you will still have to deal with the reality that the natural key is now not unique, and model reality, but your implementation work in doing so is far simpler.
In more years than I care to count I've regretted someone using natural keys as a primary key for a table many times, and surrogates never.
Yes CSV is a pain in many regards, but many of the difficulties with it arise from the fact that anybody can produce it with very little tool support - which is also the reason it is so widely used.
Recommending a decidedly niche format as an alternative is not going anywhere.
Memory is hazy - possibly due to trauma - but you could create a config_spec which would make your view (roughly: working tree) pick up different bits of the filesystem from different branches. Branches might only exist on some of the filesystem, depending on how you set up auto branching and what you checked out, and you had to know what the config_spec rules everyone was working to were or the whole repository was effectively broken.
It was very complicated to get your head around - I guess not helped by the codebase I was working on at the time which tended to concentrate change in the same 20 files.