I don't want to ban LLMs, I don't blame them for the actions of crazy people, I don't even want to regulate them in any major way related to this particular issue.

Even on the subject if they are or not conscious my position as changed from "no" to "I don't care either way" awhile ago.

The problem is specifically with anthropomorphizing them. To push the idea that they are "as if human", which is what this consciousness discussion will inevitably lead to.

An imaginary perfect computer simulation of my dead father is not my father, it is a computer simulation. It will never be anything but.

No, because a simulation of a car cannot get me from A to B. No matter how accurate you make it, I can't get to my supermarket with it, because it's just a bunch of math on a computer.

It's an interesting sort of self-defeating position, the whole "simulation of human consciousness = human consciousness", because it simultaneously attempts to devalue the human experience, while also elevating the importance of a particular human brain process.

A robot running a simulation of the human mind is a robot, not a human.

Those people anthropomorphized the chat bot and used it as justification for their actions, just as a schizophrenic justifies their actions with the voices in their head.

If you anthropomorphize the chat bot, you're validating their delusions. They are mentally ill.

Categorically different. People have killed themselves or others due to conversations they had with LLMs, but those are just the extreme cases. Most schizophrenics don't commit suicide or kill others, they are mentally ill nonetheless.

Is a simulation of a car, the same thing as an actual car? Most people will probably say no, some might say "it depends on the accuracy". I say who the hell cares?

I care about the human experience because I am human, and therefore I care about things that affect humans, because they affect me. I have empathy, so I can extend that consideration to non-human beings that experience *similar biological processes*.

I know what pain feels like, and I don't like it, so I'd rather this other thing not feel it either, because that makes me feel bad.

I do not care about a pile of tensor multiplications, at all. If it is conscious, great, maybe it can finally follow instructions properly, which is its only purpose.

It's not a living creature. It's an autoregressive pure function of token-sequence to token, which is capable of incredible things, but it's still just a function. It is not alive as it cannot die in any meaningful sense. It is less "alive" than the RNA molecules that gave you your last cold. If it simulates something resembling consciousness that's neat but no more relevant than the Sims character that I locked up in a room until they pooped themselves when I was 9.

Anthropomorphizing it serves no purpose other than marketing, and it has very dangerous downstream effects like validating the severely mentally ill people who think ChatGPT is their boyfriend/girlfriend.

And I never left Python, the slowest language around.

AI is only going to make the problem worse unless you know what to look for.

Casey is professionally best known for his work at RAD game tools (a highly successful middleware provider for game development back in the day), not games he himself developed.

What he is most highly regarded for is his teaching, particularly the Handmade Hero series on YouTube, which various programmers directly attribute as being responsible for their own professional success to a large extent.

He did work on the video games Dungeon Siege and The Witness afaik, but that's not what he is known for.

He also made one of the fastest terminal emulators (refterm), purely out of spite, to show Microsoft they were full of shit in their answer to an issue he posted to the Windows Terminal github. This directly led to performance improvements in Windows Terminal.

  class Add : Node {
    Node left;
    Node right;
    int interpret() {
      int l = left.interpret();
      int r = right.interpret();
      return l + r;
    }
  }

  class Add : Node {
    Node left;
    Node right;
    void compile(bc: ByteCode) {
      left.compile(bc);
      right.compile(bc);
      bc.push(OP_ADD);
    }
  }

The syntax growing over time is a real issue though. Every time I have to write __bridge_retain I get hives.

Swift should have just been a much improved syntax over that same runtime. It would have avoided so many headaches. For one they wouldn't have made the awful decision to have return-type overloading and completely ruin the typechecker's performance in the process.

SwiftUI should have unapologetically been a convenient, reactive wrapper over UIKit and AppKit, rather than treating them as deprecated implementation details that devs nonetheless keep having to drop down into.

These decisions come down to ego, of wanting to do away with the old and carve out your own legacy separate from it. Nice if you want a promotion but not so nice if you're trying to make a long lasting ecosystem for developers to build upon.

At least Swift and SwiftUI have a reasonable interoperability story with the past. Can't say the same about Microsoft's graveyard of UI frameworks.

Comments URL: https://news.ycombinator.com/item?id=49113197

Points: 10

# Comments: 0

OOP tells you to structure your software as objects exchanging messages, and DDD tells you what those objects (or their classes rather) should be.

Similarly, Procedural programming tells you to structure your software as procedures, and DOD tells you what those procedures should operate on.

The focus on the data is the really important part. What is the actual data I'm operating on (without any fluff on top) and what do I need to transform it into? What subsets of that data need to be operated on at any given point in the program? That's the core of DOD.

Then, as a second step, comes the hardware. Now that I know what data I need to operate on, how do I lay it out to best take advantage of the hardware I'm targeting? If you rename the paradigm to "Hardware Oriented Programming", it shifts the focus from data modeling to code (IMO), which is the wrong frame of mind.

For example, virtual calls are slow compared to direct calls, because they screw up branch prediction and often can't be inlined. In HOP, you'd probably ban virtual calls entirely because virtual calls bad.

But in DOD, they honestly probably don't matter at all! Because if you did the data modeling as instructed, and then you laid out the data to best take advantage of the hardware, your virtual function is going to be operating on a pile of data in bulk, making the virtual call cost pure noise.

There are also cases where the optimal data format isn't array oriented because the memory access patterns for the problem in question just require something else.

You also have to think of hot vs cold data, which has nothing to do with arrays.