It often refers to programmers that develop things that other programmers use to construct applications. A systems programmer may work on compilers, operating systems, framework libraries, etc.
They will also often work with lower-level abstractions, such as threads, so that the higher-level developers need not think about them in their own designs.
It's possible that we are talking at cross purposes.
I think you might be arguing that the object itself does not include the set of functions/methods/operations that act on it, whereas I see them as another attribute of the class/type which is an attribute of the object.
I would still classify that as object oriented behavior.
You have a class/type of objects, and you have a set of functions or operations which are associated with (loosely or tightly) and operate on that type of object.
For example, I would say that file descriptors are a handle to a type of object. They encapsulate the thing that they represent (file, DRM buffer, eventfd, whatever), and some of the functions that operate on them are polymorphic. For example, read, close, ioctl, etc., don't care if the file descriptor is a file, a queue, or whatever.
You use syscalls to interact with file descriptors, but they are just as much object handles.
It's not a requirement, but an immutable object has fewer uses than a mutable one.
Functions/methods/actions/operations are just different names for the operations which mutate the state of the object. So, I would argue that they are a necessary attribute of mutable objects.
In my experience, LLMs tend to perform better if you give them instructions before the data to be operated on. At least for the ~13b size models.
So,something like: Please count the number of words in the following sentence. "What is the number of words in the sentence coming before the next one?"
edit: Which might be an artifact of the training data always being in that kind of format.
The undefined behavior can still affect code generation even though the program gets translated.
It's just that the generated code may not do exactly what you expect it to do because the presence of undefined behavior allowed the compiler to make assumptions which may surprise you.
The compiler may make optimization decisions based on the presence of UB so the code only needs to be present.
The compiler can't know that an arbitrary part of a function is unreachable if, for instance, that code path is controlled by a parameter or global state since that equates to solving the halting problem.
It is slightly unfair to say there's barely an ecosystem. If all you've seen is Reykjanes between Keflavík and Reykjavík then sure it might look like a bleak, moss covered, rocky desert. But the thing is that different regions can vary quite drastically in their level of vegetation. You might have farmland on one side of a mountain but on the other side a vast sandy desert.
But, to be fair, if your measure of a fertile landscape is a forest then those are relatively few and far between. Personally I tend to feel a bit claustrophobic when there are trees boxing me in on all sides and I can't see the mountains. :)
Part of it is whether the code can be traced back to original AT&T code. Which would be true for e.g. BSD variants (which includes MacOS). https://i.redd.it/kgv4ckmz3zb51.jpg
You might be interested in these articles if you want to experiment with alternative approaches to the intrusive linked-list and are OK with using object pools. Very handy if you want to have cheap alloc/free and want good memory locality for updating the objects.
