I've been CLAUDED. It's really good. It has absolutely no issues working on the CyberChud engine and fixing up a ton of shit that I've ignored forever.
lowkey i like reading about x86_64 instructions
today i learned about a new one - VPTERNLOG
its a SIMDTERNARY IF STATEMENT in ONE instruction, it takes three operands a,b,c and an 8 bit look up table and the instruction takes a bit from each and returns a new bit based on that LUT
gcc and clang provide constants so you can easily write your own lookup table (you can just do uint8_t LUT = (~A ^ B) & C), the blog ive linked implements saturated signed addition and subtraction
it's also kinda risc-v - on amd it's apparently only 1 micro op, while on intel it's 2 micro ops if the third operand is a memory address
shit like this really tickles my autism in a way - one of my fav is GF2P8AFFINEQB just because how versatile it is
(Lox is the author's language that's being implemented in the book.)
Code:
class Breakfast {
cook() {
print "Eggs a-fryin'!";
}
serve(who) {
print "Enjoy your breakfast, " + who + ".";
}
}
breakfast.meat = "sausage";
breakfast.bread = "sourdough";
Why? This has always struck me as extra pozzed. You have a class, and then some fields just aren't guaranteed to be on it, and you don't know because it's still superficially the same old class. Methods you define on the class can't cleanly reference these fields, they have do to a gay if hasattr(self, "my_secret_field") dance. What does it have to do with dynamic typing, which the book explains like so:
Lox is dynamically typed. Variables can store values of any type, and a single variable can even store values of different types at different times. If you try to perform an operation on values of the wrong type—say, dividing a number by a string—then the error is detected and reported at runtime.
I get what this means, you can reassign a variable, so that a variable is sometimes a string and sometimes an integer and sometimes a Breakfast. Why does it also require that there could be an integer with a sausage?
(Lox is the author's language that's being implemented in the book.)
Code:
class Breakfast {
cook() {
print "Eggs a-fryin'!";
}
serve(who) {
print "Enjoy your breakfast, " + who + ".";
}
}
breakfast.meat = "sausage";
breakfast.bread = "sourdough";
Why? This has always struck me as extra pozzed. You have a class, and then some fields just aren't guaranteed to be on it, and you don't know because it's still superficially the same old class. Methods you define on the class can't cleanly reference these fields, they have do to a gay if hasattr(self, "my_secret_field") dance. What does it have to do with dynamic typing, which the book explains like so:
I get what this means, you can reassign a variable, so that a variable is sometimes a string and sometimes an integer and sometimes a Breakfast. Why does it also require that there could be an integer with a sausage?
The scary part is that the bottom panel elides like a hundred steps.
From the virtual address translation and multiple caches involved in fetching the next instruction, to instruction prefetching, reordering, & branch prediction, and the bookkeeping needed to make context switches and hyper-threading work, and registers being allocated and deallocated instead of being fixed physical slots... And whatever other crazy stuff modern CPUs do that I haven't even heard about.
It has nothing to do with dynamic typing, the author is being inaccurate/retarded. What he might be trying to say is that a fair amount of popular dynamically typed languages happen to let you do this (Python, Lua and Javascript come to mind) and thus Lox does things typical for a dynamically typed language.
What I've come to realize about dynamic typing, (at least with regard to my own opinions and tastes), is that while it is convenient to have flexibility, the existence of dynamic typing means that you can't necessarily make constructive assumptions about your data.
I regularly use unsigned bytes in my C code alongside 256 long arrays, because knowing the properties of a u8 as an index, and knowing how unsigned integer overflow works on most machines, allows me to exploit that property
Constraints can be useful is what I guess I'm getting at, and having a narrow domain allows you to abuse properties of that domain
Dynamic shit makes you sloppy with your data and your memory. "But the GC" - is responsible for a lot of wasted compute.
I'm really at the point that I think an ECS-like thing with a lot of sugar and a good interface is probably ideal for almost all use cases. The problem is that it is so alien to the OOP-brain that academia forces on you that it's hard to give it a shot.
Haskell types is my #1 favorite thing about it. If only it had non retarded record type system that doesn't pollute namespace with accessor functions it would be perfect.
Dynamic shit makes you sloppy with your data and your memory. "But the GC" - is responsible for a lot of wasted compute.
I'm really at the point that I think an ECS-like thing with a lot of sugar and a good interface is probably ideal for almost all use cases. The problem is that it is so alien to the OOP-brain that academia forces on you that it's hard to give it a shot.
Muratori has a talk on this. The premise is the same one made by data-oriented design: that your software architecture doesn't (and probably shouldn't) have to be a one-to-one model of your domain.
Lots of these dudes talk a big game on YouTube and at conferences. I am skeptical of anyone making big claims that we are all doing it wrong when often I find OOP to be a good solution to quite a number of problems.
The problem I find with C# and Java is that the OOP paradigm is forced onto you. Other programming languages give you the option of using it to solve a problem.
What I've come to realize about dynamic typing, (at least with regard to my own opinions and tastes), is that while it is convenient to have flexibility, the existence of dynamic typing means that you can't necessarily make constructive assumptions about your data.
I regularly use unsigned bytes in my C code alongside 256 long arrays, because knowing the properties of a u8 as an index, and knowing how unsigned integer overflow works on most machines, allows me to exploit that property
Constraints can be useful is what I guess I'm getting at, and having a narrow domain allows you to abuse properties of that domain
One of the biggest problems with dynamic typing is that since type checking is deferred for as long as possible, the place where an error is signaled is usually remote from where it actually took place. Let's say I call f() with an integer as its argument when it really wants a string. With static typing, you get a compile-time error located at that erroneous call. With dynamic typing, f() passes the parameter to g(), which passes it to h() and so on, until k() finally tries to actually do something with the value instead of just passing it around and you get a runtime error and have to figure out where in the stack trace the actual error took place, and your only guidance is that it almost certainly wasn't in k() itself.
not a gamedev but from what i've seen 'entity component system' is mostly just another way to describe doing OOP, no?
like, instead of 'objects' you call your things 'entities' and maybe you don't do the big deep inheritance hierarchies and polymorphism as much as OOP textbooks tell you to, but at the end of the day you still work with class based things that have data members and member functions (or fields and methods or however you want to call it)
not a gamedev but from what i've seen 'entity component system' is mostly just another way to describe doing OOP, no?
like, instead of 'objects' you call your things 'entities' and maybe you don't do the big deep inheritance hierarchies and polymorphism as much as OOP textbooks tell you to, but at the end of the day you still work with class based things that have data members and member functions (or fields and methods or however you want to call it)
No. With OOP you'd have components be fields belonging to entities, whereas with ECS they are separated, entities are reduced to ids, components are structs, and systems are just functions that operate on groups of components.
