fdsajfkldsfklds

>you need to tolerate "deleterious speech" in a democracy.

Why? You can have a democracy without the right to free speech.

I thought you weren't supposed to use it to estimate man-hours? Or is it ok if we don't allow engineers to provide time estimates, but permit simulations to do so?

For forecasting what, if not man-hours?

I take it further. I believe that WW3 has started before we even realised where the battlefield might be. Unfettered, anonymous, practically instant access to interfere with almost every earthly inhabitant's life and thoughts is a scenario beyond the wildest dreams of any despot until recently.

In case my point was missed, I was doubting the "people" element of the communication, not the "free speech" (although my opinions on that have also changed since my idealistic early internet days).

I would say that the ability for plausible-looking online personas to infiltrate and influence people's thought processes is the root of what plagues use, and a chronological feed wouldn't fix that!

By what metric has it worked well?

As I see it, online communication is more like de-humanised, context-free access to singular statements on a topic. As such, it does not equate to "people communicating freely".

State ownership is just a proxy for public ownership.

Strictly speaking, it's modifying itself. Although it would be an interesting challenge - can an llm create a new llm from scratch?

Alternative interpretation of the facts - "our slop generator has become buried in slop - could we all just take a breather for a moment?"

Right, and that's why Mel was a true programmer!

Seriously though, that's an overly-pedantic definition of a compiler. Broadly speaking, languages compile in a direction of decreasing abstraction. Crossing from one high-level abstraction to another is just asking for trouble, especially in this case where the target language makes very specific performance promises as long as certain abstractions are maintained.

I am looking forward to the first release tomorrow though!

Engineering decisions and the resulting output.

We've known for decades that machine-translated code is garbage, and should only be done as a last resort.

A key element of engineering is projecting a current trajectory. Given that, it absolutely makes sense to avoid tools that give you a bad feeling. The easiest time to move away from a tool that will become a train wreck is before you've integrated it.

Or just gently dent the edge of the metal lid, enough to break the seal, and it'll open easily.

And a lot of oil has been well and truly stopped!

This is effectively a very expensive and resource-intensive machine translation. As such, there is no increase in consistency or quality of output.

The irony being that machine-translation of code language also dates from the 1970's.

It seems to suffer from an un-necessary amount of panoramic distortion, unless that is supposed to be part of the charm.

If your job can't easily be done by AI, then you can pick it up and get "up to speed" any time you like.

If it can be done by AI, then you have no hope of competing with the quantity of AI output that anyone can trigger in very little time.

As my job seems pretty secure, I can ignore AI for as long as I like.

>those who work on things where LLM's are capable of a substantial amount of the tasks will be left behind

It sounds more like there is no chance that most of those people will stay employed, regardless of how "ahead" they try to stay.

Never, ever type "npm -i". This advice has served me well for many years.

The Anti-Singlarity! It's coming for us all.