Your information diet. Social media. Gossipy and negative people. Mulling over old failures/regrets/slights etc. The mind is easily pulled along by negativity and outrage... as can be observed in our current global psychological state.
That's where the modern meaning of "digital circuit" etc comes from as well, the discrete/jointed nature of the digits (ie fingers). (Source: I read it a long time ago and was fascinated so stuck in my memory.)
You have to be extremely careful when you set up a dev container, lock down file access, do not give the agent the power to start other containers or "docker compose up", restrict network access to an allow-list etc. Just running the agent in a container does little to protect you. (Maybe you know this, but a lot of people don't!)
The tech world knows this. They are raking in money off of these scams. People with a rudimentary moral compass leave, those without stay, which makes it even less likely that industry will self-sanitize. The rest of society, out of survival instinct if nothing else, will have to force it to stop anti-social and fraudulent practices. Same as many other industries.
I've seen several Mac users have the same experience: going all-in on nix-darwin and then getting frustrated. But nix-darwin is one of the worst ways of getting into Nix, because its goal is to make your whole macOS system configurable with Nix, but macOS is a moving target and (unlike Linux) not built to be modular at all. I know people put a lot of hard work into nix-darwin, but it's simply not the main focus of Nix as a whole and sadly it might not ever become a seamless experience. (I'm not a mac user so not keeping up, but I do see colleagues trying it out from time to time.)
The solution here is: use Nix but don't use nix-darwin (at least not until you're generally comfortable with Nix for package management and dev shells). You do NOT have to use nix-darwin on Mac to reap 80% of the benefits of Nix (especially in a team setting).
After dropping nix-darwin, I think almost everyone will find that it's very easy to use Nix for sharing project setups with bespoke tooling. I just had a new team member onboard, knowing nothing about Nix, in a day or less, with several different languages and unusual tools.
The way I do this is I task the agent with writing a script which in turn does the updates. I can inspect that script, and I can run it on a subset of files/folders, and I can git revert changes if something went wrong and ask the agent to fix the script or fine-tune it myself. And I don't burn through tokens :)
Also, another important factor (as in everything) is to do things in many small steps, instead of giving one big complicated prompt.
This is going to be very good for Gleam IMO. Having a super-easy on-ramp for using Gleam in Elixir projects will let people experiment with implementing eg more complex business logic in Gleam, and allow gradual adoption. Naturally, this is not the focus of the Gleam project itself, but for me, using Gleam for the core of a project while having access to the amazing Elixir ecosystem is a dream come true. I've been using mix_gleam but it's not perfect and since I started using Gleam pre 1.0, and it's a low-velocity project, updating became too complicated and I actually ended up moving everything to Elixir recently.
> There's no such thing as an individual conscious self that persists over time
True. But then again, there is nothing that persists over time. Entities with enduring identities - of any kind - are just abstractions that we superimpose on experience.
> Consciousness is just something that living beings do
To my eyes, you're switching over to another meaning of "consciousness" here. Sure there's no enduring self, but that doesn't mean consciousness (the capacity for experience, rather than mere behavior) is just something we do. We can understand feelings, thoughts, emotions etc as fundamentally "impersonal", yes, but that doesn't mean that they are not states of being. To me such states are about as real as anything. Again, it's two separate issues: 1) the nature of a persistent self, 2) the nature of mental states, not taken as "possessions" of such a self.
(Still, psychologically speaking, the sense of self is baked into even our most basic acts of cognition. When you see an apple, there is always an implicit "you" in relation to the apple. In practical terms, it takes a lot of effort to separate one from the other - yet another topic!)
Yes specialization is often useful. But the divide between developers and DBAs seems to have been similar to the dev/ops divide. Probably still is in many places. There is always a need for seniors or specialists to guide work, I'm not against that. But something like DevOps for RDBMS is needed. DevDat?
Very useful historical perspective, thanks! Confirms what I had pieced together, that DBs used to be a big liability for organizations, with a special clan (DBAs) of people gatekeeping and introducing patterns that programmers found infuriating. Hence the hatred towards stored procedures, layered schemas, and databases in general. It's probably important to keep stressing, as you do, how different things are now. It's only been a fews years that Postgres has had row level security for example.
It's well-known to be a topic that splits opinion, so I'm not surprised we disagree :) To me, "designing the data model", "wiring up relationships", etc doesn't require an ORM. On the other hand, I do agree it's good to have some tooling around it and that's something many more bare-bones frameworks (ORM or not) are lacking.
I don't hear people talk about "coding for the web, but design so that you can easily switch to deploy as a Windows desktop app." Or "write it in Python, but in such a way that we can easily swap to OCaml." It seems to me databases are uniquely treated this way, as some kind of disposable, simple piece of side equipment. Again, modular code will always be easier to migrate, but I prefer to take full advantage of db capabilities, as it results in much less code and frees up time and mental space to focus on a good conceptual model and physical schema, among other things.
I've never used EF, so I might not see what you are seeing.
The importance of having db schemas and other software entities reflect real-world things is not appreciated enough. It looks unimportant at first, but soon all intuition becomes useless and the system tends to not have "joints" in the right places, ie it doesn't have flexibility in the same places that reality does.
In a similar vein, I recommend David Hay's "Data Model Patternns: Conventions of Thought". It's more focused on the concept model side, but with awareness of how models are implemented in db schemas and the trade-offs involved.