3,266 karma · joined August 7, 2021
https://rookandpossum.com/posts/scanline-sweeper/
Sean Barret (creator of the stb public domain libraries) independently invented a CPU-based implementation of the same idea, used in stb_truetype.
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.
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.
Miri is meant as more of a sanitizer type tool that you use during development to catch bugs. Fil-C is a platform you compile your entire Linux distro with for use in production.
You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe. It would even be interesting to turn off some of Fil-C's expensive protections in the safe parts of the Rust code, making an average-of-both-worlds sort of solution.
What I do care about are C and C++, these two absolute garbage languages (though I do have a lot of love for C, you can both love and hate something).
Tools like Fil-C, hardened mallocs like SlimGuard, and other "make C safe" solutions all sacrifice absurd amounts of performance because these two moronic languages refuse to have a proper slice/span type.
Use-after-free and double-free are serious problems but they're a spec of dust compared to missing bounds-checks. The low-hanging fruit is right there for the picking but everyone is worried about how to reach the fruits at the top.
C++ only now in C++26 is finally adding bounds checks to the [] operator on std::span and (hilariously) is also finally adding the now mostly redundant .at() method which should have been there from day one.
Clang added -fbounds-safety which is a feature that should have existed for a long time and serves as a decent stop-gap to a proper slice type. But of course, since it's not standardized, most people won't use it.
What these two languages have taught us is that if you want to produce utter garbage you should make it an ISO standard.
Me, personally, I find this whole discussion on memory safety amusing. Missing bounds checks are by far the biggest source of vulnerabilities and they're a problem in exactly 2 languages and those 2 languages have outright refused to do anything about it for decades.
But hey, even in memory safe languages you have frameworks like log4j that had remote code execution from a format string as a feature. Is the problem memory safety specifically, or this utter cavalier attitude towards security?
I'm not even suggesting something dumb like "you just gotta get good at C and then you won't have any vulnerabilities". Humans are fallible, which is why we delegate what we can to machines. I'm just pointing out the utter lack of care. People just don't care.
At least do the bare minimum of effort like, I don't know, not make remote code execution a feature tied to format strings. Or provide a slice type in your language and string manipulation functions in your standard library that make use of it, preferably 20 years ago.
Basically, they're all still concerned with the realities of current day GPU hardware, which in turn means they too, much like DirectX and Vulkan, will eventually become "bad" abstractions.
IMO, if there is any mention of a "vertex" or "fragment" shader, it's still not there yet. End goal should be massively parallel CPU, no graphics-specific functionality beyond compiler intrinsics for whatever can't be done efficiently in software. Something like CUDA is the target to aim for.
So for any sort of visual engine development (game engines being the most obvious, but also applications like blender or the JangaFx suite which is the main user of Odin), it is great. What you need is just there ready to go.
The language design itself is very much oriented around appealing to people who do this sort of work.
Other than there isn't much to the language really. It lacks a "big idea" feature like Rust's lifetimes or Zig's comptime. The closest thing to a "big idea" is the rejection of package managers but that's not really part of the language.
It's pleasant to use and compiles fast. Hard to complain.
Odin is a pretty neat language, I should play more with it. There's nothing outright wrong with it I can think of. Some things I would have done slightly different but they're all nitpicks (mainly having the context be a thread local so #contextless wouldn't be necessary).
Both should be much faster at compiling debug builds than they are though. There's an LLVM fork (TPDE-LLVM) that supports a limited set of backend targets but compiles way faster (order of magnitude) for O0, but for whatever reason they haven't managed to merge it with the mainline LLVM. Even with that there's still plenty of overhead from all the horrible C++ OOP-brained abstractions LLVM uses.
I'm fine with companies leasing software. I don't like it, and I much prefer buying, but that's fine. That is what software subscriptions are, the terms and conditions are clear.
"Buying" something where access can be revoked at any time, for any reason, needs to become illegal.