Since we are all “hackers” here, I’ll be pedantic…

“While it is a great language…”

The “it” pronoun clearly refers to the C++ language, as I’m sure you intended.

“…ir would profit from less ‘lets code C with C++ compiler ’ attitude.”

The “ir” — presumably a typo for “it” — can refer to the article or C++. Given that this thread is about an article, the second “it” referring to the article is a natural assumption.

(As an aside, I think of counseling as “optimizing my life”. Perhaps that framing may help those that find the idea off-putting.)

But otherwise I like the image!

My _main_ point is that there’s a non-trivial question to answer here.

I’m not qualified to answer (though I’ve offered up my non-expert opinion). It certainly seems to quickly veer in to philosophy!

My opinion — and note I’m a software engineer, not a lawyer — is that an AI, being a statistical model and not generally intelligent, should not be allowed to disregard the copyright of its source material. This would, I think, require the AI’s creator to secure a license for all of its sources that allows this sort of transformation and presentation. And further, a user of the AI would themselves require a license to use the output.

The alternative seems to be “anything goes”.

Computers have always been just useful enough for as long as I’ve used them (since the 80s). We’ve _always_ put up with a lot of nonsense and pain because the alternative is worse.

As soon as, say, a retailer or a bank can be sued to oblivion for bad and/or insecure software, whether it was written in-house or not, the regulations will flow back to the producers of the software.

We are still in the Wild West days. Enjoy it while it lasts. Once we, as a society, start requiring software to actually do what it says it does, the fun times are over…at least professionally. We will still be able to have hobby projects automating sprinklers and lightbulbs and such with the latest unlicensed (edit: un-warrantied, really) Raspberry Pi and Linux.

But at work we will be using buttoned down OSes, programming with buttoned down programming languages, using a (comparatively) small number of professionally licensed third-party libraries, and all this with some painful professionally certified software development methodology.

Edit: for clarity.

I looked at other options -- ProtonMail or FastMail -- but figured my needs were fairly basic. I don't use multiple mailboxes, I very rarely search my email history, iCloud handles my calendar (I had switch this up already), and I don't need a huge amount of space. After 10+ years on G Suite, my personal email was 1.5GB, so I figured any email host would work.

I didn't bother importing all of my email to the new Hover email, nor did I want to. Instead I archived my G Suite email and copy / pasted my current Inbox across, which was 20-some messages (I practice a slightly messy version of Inbox Zero). If I ever need to search the old email history, I'll import the old G Suite email archive to Thunderbird or Apple Mail.

About having my domain and email hosted by the same provider: I understand the risk, however I have managed to keep my personal website and email going consistently for over two decades, and I'm not terribly worried. Plus I have auto-renew enabled.

The closest I get in my career is striving for the simplest approach to building something in software, which is not all the easy path. The easy path always leads to complexity -- just look at any enterprise software project that's more than a year to two old.

I find the process of striving for simplicity gratifying and reading this article about similar -- but much longer process -- put a smile on my face.

This can happen between different layers of app. For example you might have a persistence layer under an API or UI, and want to expose a nice "clean" interface to the API / UI layer.

The Patriot Act is the problem. We knew it at the time. Sounds like we all agree on that point.

If memory serves, the threat _was_ detected, however it was not acted on. There was lots of finger pointing about lack of coordination, but (as I recall) the core problem was that it was one threat amount many (100s? 1000s?), so the threat detection was generating too much noise.

Ubiquitous surveillance could (does) easily end up creating the same situation: not enough signal among the noise.