Because the vast majority of users have no interest in learning how to safely vet apps and just want to easily use their computers and not worry about malware.
The point of the CYA clause isn’t to prevent illegal activity or make the bank more aware of what customers are doing. The point is that when Bank 1 is defending itself in court, it has one additional thing they can point at when arguing that it should not be liable for the illegal activities.
The bank that actually welcome the AlCapone will be first to have that form. If the court can be affected by something like that, it says something really bad about the legal system.
I personally agree. But the default expectation (and therefore the design) should follow the practices of the language. If JS allows mutations on the objects passed to a function to be reflected on the parent, I believe frameworks should follow this paradigm.
And in the end in Gea developers have full control over this, just in the same way they do in real life. `child({ ...obj })` easily solves this, for example, in both idiomatic JS and in Gea.
You're using various terms to refer to concepts which are similar but distinct, and it's confusing the issue a bit.
> But the default expectation (and therefore the design) should follow the practices of the language
Languages do not have practices, developers do.
Regarding "idiom": core language features/semantics are not idioms. In programming, "idiom" usually refers to small commonly-used patterns that reside atop the language. "Mutating objects" is not an idiom, if only because I can think of any number of non-idiomatic uses of mutation.
> If JS allows mutations on the objects passed to a function to be reflected on the parent
JS "allows" mutations on objects to be "reflected" elsewhere, because that's how mutation works. If JS had to support scoped mutability at the language level, the language would be significantly more complex.
But this implies nothing about the value or advisability of using mutation and two-way binding in an application framework. That is a choice on which framework authors usually land on one side or the other.
It seems that by more or less equating "idiom", "practice" and "paradigm", you're opting out of the sorts of choices that not only distinguish web frameworks, but simplify the patterns involved in building with them.
Feel free to question anything you like and I'll help you find the answers.
This is a well-trodden path. All aspects of object mutation and its effects are obvious and well-known. What is pass by ref and what is pass by val is also pretty obvious. One can easily pass in primitive values and not worry about two-way binding if they choose to. One can also easily not mutate any props they receive from their parents. This is already the best practice in eslint for like 10 years. This is not easy, this is trivial.
> But the default expectation (and therefore the design) should follow the practices of the language. If JS allows mutations on the objects passed to a function to be reflected on the parent, I believe frameworks should follow this paradigm.
Why? Why should frameworks be beholden to the mutation semantics of the language, particularly with JS where there is no choice of language in the browser? Why should frameworks follow this paradigm?
Because JavaScript _is_ the language and people know it. I never understood the concept of a "React developer", for example, although I saw many junior devs who were very well-versed in React and didn't completely understand JavaScript.
In the end, it's a design choice. Of course frameworks don't inherently _need_ to be beholden to the standards of the underlying language, but I think this is just simpler, therefore a worthy goal to pursue.
The Data Privacy paragraph would suggest otherwise.
> By default, Atuin AI knows nothing about your machine, other than the operating system and shell. This is the bare minimum required to generate a decent shell command.
> It will soon be able to ask you for access to more data - such as the current directory path, contents, git status, etc - but you must give permission first. This will happen in a similar way to existing agents, and be configurable to an even finer degree in your config file.
I have to ask -- why? Atuin has not gotten any worse at its core history search functionality. All of the new features are entirely opt-in. Why switch?
Because to me it feels like it gets more complex in ways I don’t like. It’s a matter of preference. To be honest had I not read about it I might have never noticed it but now I know and will probably go back to fzf.
And my take! A fork of fish where any command that starts with > or a capital letter is fed to $fish_llm_command: https://github.com/breuleux/fish-shell. With Claude's help, that took all of 30 minutes to make.
Claude Code Web does all of those things for me with the GitHub connector enabled. I did have a lot of song and dance to get the permissions right though.
I have been working on a 100% vibe-coded magit-style jujitsu porcelain for neovim. I cannot emphasize "vibe-coded" enough -- I have not read a single line of code here, nor do I know much about neovim development in general. All that said, it's been working pretty well for me the last couple weeks!
reply