A carpenter uses tools to shape wood into furniture. Each tool in the toolbox has different uses, but some are more efficient than others. For example, a table saw lets the carpenter cut more quickly and accurately than a hand saw. Nobody would say "that's not a real carpenter, he cheats by using a table saw".
A carpenter can also have an assistant (and I'm specifically not talking about an apprentice) who can help with certain tasks. The assistant might be trained by someone else and know how to perform complex tasks. When the carpenter builds something with the assistants help, is that considered a team effort? Does the carpenter need to take responsibility for the assistants mistakes, or the trainer? Who gets credit for the work?
I don't have answers for these questions, but I think the parallel to software is straightforward: we have a new tool (assistant) that's available, and we're trying to use it effectively. Perhaps it's going to replace some of our older tools, and that's a good thing! Some of us will be lazy and offload everything to it, and that's bad.
I do think that learning the fundamentals is as necessary as ever, and AI is a great tool for that as well.
(Disclaimer: I've been programming for about 15 years, and haven't integrated AI into my workflow yet.)
I'm not sure what exactly you're referring to, but one avenue to implement AI is genetic programming, where programs are manipulated to reach a goal.
Lisp languages are great for these manipulations, since the AST being manipulated is the same data structure (a list) as everything else. In other words, genetic programming can lean into Lisp's "code is data" paradigm.
As others mentioned, today everything is based on neural networks, so people aren't learning these other techniques.
I read somewhere that a black hole with the mass of the moon will absorb about as much cosmic radiation as it emits Hawking radiation. This is a fine line between "the black hole disappears before we can examine it" and "oops, we got eaten by a black hole".
I'm surprised the article doesn't mention OpenASIP [0], which not only helps you define the architecture, but also provides RTL synthesis and a working (if not always useful) compiler.
I think the issue here is that the server would have to store a copy of the register per peer, as it can't calculate which one is the most recent. Using FHE allows the server to hold a single copy.
In other words the server could forward and not store if all parties are always online (at the same time).
This sounds like the "only following orders" argument.
_If_ developers _collectively_ were to quit jobs that don't line up with their morals and ethics, we _might_ see a change. I'm not saying this is an easy decision to make, and I definitely don't want to judge someone who decides to take a higher paying job, but there's potential here to shift the direction AI is taking.
You may want to look at Lua[0]. It's often used as an embedded scripting language in larger projects (and games), has good performance, is memory safe, and is extensible in the same manner as Python (write your performance bottleneck in C/C++).
I don't remember specifics, but there are some odd footguns to look out for.
I happen to be taking a Team Lead course, and forming habits came up yesterday. 21 days weren't mentioned explicitly, the time frame was "a few weeks". We were given 6 criteria when forming a habit:
1. Tangible - you need to pick a tangible action that is observable. If you're trying to fix a part of your behavior you can't pick "I'll pay more attention" as a habit to correct yourself, instead you should write a note or say some phrase.
2. Up to me - don't form a habit that requires outside factors. If you want to start jogging, don't ask your neighbor to jog with you. Each time he's not available, you'll have an excuse not to jog.
3. Swallow the frog - don't push it off. This isn't a well defined criteria, the idea is to minimize excuses (like #2).
4. Daily - a habit needs to be formed by taking action every day.
5. Trigger - your action needs a trigger. This can be an internal (feeling hungry), external (a timer on your phone), or contextual (every morning, every time you walk into a conference room).
6. New - it's very hard to form a habit if you've already tried and failed. Pick an action that you haven't already tried.
There was also an important note that changing behavior often requires multiple steps. The instructor gave the example of using dental floss. It's hard to go from nothing to flossing every day, so break it into:
1. Every time you go into the bath room in the evening, pick up the dental floss, and put it down.
2. After picking up the floss becomes a habit, cut a piece of floss, and throw it out.
3. After cutting the floss becomes a habit, floss a few teeth.
One nitpick is regarding the double-CRT: you are referring to the RNS encoding, when the original paper[0] uses the term to talk about how polynomials are stored for fast computation. It's a nice philosophical view of decomposing the polynomial Φm(X) into products X − ζi the same way that the integer modulus Q is decomposed into primes. So it's more like one CRT on the coefficients, and another implemented as a DFT.
My preference, however, is creating a fixup commit and using rebase to squash it into the old one.
Edit: A sibling comment mentioned "git history fixup" which I'll have to try out.