I don’t work in IT/Tech at all, but I’ve been an enthusiast since I was young, at first piggybacking off of my dad, then developing my own interests as I got into high school and college. I started self-hosting because I found it interesting and as time progressed I saw the benefits of operating things locally. I only host things within my own network though, because I’m not yet comfortable with how to safely set up external access.
There’s no way they used Gemini and decided it’s better than GPT.
I asked Gemini: “Why can great apes eat raw meat but it’s not advised for humans?”. It said because they have a “stronger stomach acid”. I then asked “what stomach acid is stronger than HCL and which ones do apes use?”. And was met with the response: “Apes do not produce or utilize acids in the way humans do for chemical processes.”.
So I did some research and apes actually have almost neutral stomach acid and mainly rely on enzymes. Absolutely not trustworthy.
I guess Gemini took the word “use” literally. Maybe if the word “have” would be used, it’d change the output (or, even better, “and which ones do apes’ stomachs have?” as “have” could imply ownership when “apes” are the subject for the verb).
I grew up in a family of medical doctors, it came with its own set of similar challenges. Every problem discussion always revolved exclusively around solutions or practical harm reduction. I suspect God forbade the doctors from talking just for emotional support.
Every problem I ever had (completely normal ones included) was medicalized and pathologized, neatly classified and wrapped in a set of actionable instructions: “this is how you get better, this is how you allow it to get worse”.
I still remember coming home from school and sitting down at the dining table, eating my sausages with buckweed, while my dad, mom and older sister discuss methods and techniques to install a urethral catheter in a person with a broken phallus.
It wasn’t good or bad, it was just weird I guess. Hey, at least I am not scared of blood/trauma/desease, and in a some cases I believe it allowed me to stomach helping people in need, when other people would turn away out of disgust or disturbance.
Thanks, but it wasn’t so bad. I have learned exactly two things from that conversation: 1 - one can brake a dick 2 - some injuries have fascinating stories attached to them
Overall, I wouldl rate this experience 8.5/10 - very enlightening and only mildly inappropriate.
I went to dinner at the house of a friend, and it was him, a computer prodigy; his brother, a roguish dyslexic adhd mechanical genius with a new project and new girl every month (thanks to his Red October Alec Baldwin face); their dad, an optical phenom with a novel method of building massive parabolic mirrors and collapsing telescopes with almost only the gear available in the standard home workshop. Their basement was a mishmash of engines in disrepair, computer stuff in various states of assembly, and plateglass stacks and a torch to heat it up. Their mom was a nurse, and that makes sense.
The dinner-table conversation was a rolling topic that moved from focus to focus, and was part knowledge-sharing, part discussion on methodology, part ‘this is how I almost died’ and part ‘eat your vegetables and keep that injury clean’. I could barely keep up, but it was absolutely fascinating.
I’ve done a backup swap with friends a couple times. Security wasn’t much of a worry since we connected to each other’s boxes over ssh or wireguard or similar and used tools that allowed encryption. The biggest challenge for us was that in my selfhosting friend group we all prefer different protocols so we had to figure out what each of us wanted to use to connect and access filesystems and set that up. The second challenge was ensuring uptime and that the remote access we set up for each other stayed up - and that’s what killed the project as we all eventually stopped maintaining the remote access and nobody seemed to care - so if I were to do it again I would make sure all participants have alerts monitoring their shared endpoint.
I loved the 2600 because that was all we could afford when I was a kid. I liked the ColecoVision and Intellivision graphics better though. Luckily, some of my friends had both.
Some classical symphonic music greatest pieces album that’s at least 2 CDs worth, but hopefully more. Being on a desert island, I’m sure I will go through all sorts of moods and emotions, so I’ll need something for everything.
Disclaimer: I actually like C++ the language, I’m reasonably comfortable with it and enjoy it as an upgrade from C. I don’t use much OOP stuff as I’m writing a game using the flecs ECS. So things like abstract classes are mostly absent from my codebase.
What has been driving me up the wall the last month has been build systems and dependencies: don’t get me wrong; meson is great but the problem is not everyone uses meson. All I want to do is add some library built with cmake as a dependency without needing to rewrite the build system or install it on my OS. Apparently that is too much to ask!
I’m seriously considering dropping everything and jumping to Rust because of Cargo. Yes I’ve tried setting up conan but not having much fun since the recipes are all third party and out of date anyways
I have not heard this consensus. Definitely inheritance where the base class holds data or multiple inheritance, but I thought abstract was still ok. Why is it bad?
In 99% of the cases, inheritance can easily be replaced with composition and/or interfaces. Abstract classes tend to cause hard dependencies that are tough to work with.
I’m not sure why you would use abstract classes without data. Just use interfaces.
The way I was taught was that you usually start off with only an interface and then implementing classes, and then once you have multiple similar implementations it could then make sense to move the common logic into an abstract class that doesn’t get exposed outside of the package
I usually break it out using composition if that’s ever needed. Either by wrapping around all the implementations, or as a separate component that is injected into each implementation.
Ask Bjarne to add interfaces enough many times until he gives in.
On a more serious note, I’m not exactly sure what the best C++ practice is. I guess you just have to live with abstract classes if you really want interfaces.
The only problem is to ensure the entire team agrees to only use it like an interface and nothing else. But I guess that’s the only proper way to do it in C++, for now.
That’s not really the job of the language, though. If they can’t read the design docs and source annotations, they don’t really have any business touching anything.
Yet I still had an urge to explain an obvious thing. Because it’s C++, so everyhing goes. There are even tools to auto-generate C++ interfaces, because of course someone decided that C++ is inadequate and must be improved using some kind of poorly-documented ad-hoc extension language on top of C++.
You have implementations like ArrayList and LinkedList.
Many of those method implementations will differ. But some will be identical. The identical ones go in the abstract base class, so you can share method implementation inheritance without duplicating code.
If the lists have shared components then that can be solved with composition. It’s semantically the same as using abstract classes, but with the difference that this code dependency doesn’t need to be exposed to the outside. This makes the dependency more loosely coupled.
In your example, the declaration of ArrayList look like:
public class ArrayList extends AbstractList implements List {
}
The dependence on AbstractList is public. Any public method in AbstractList is also accessible from the outside. It opens up for tricky dependencies that can be difficult to unravel.
Compare it with my solution:
public class ArrayList implements List {
private AbstractList = new AbstractList();
}
Nothing about the internals of ArrayList is exposed. You’re free to change the internals however you want. There’s no chance any outside code will depend on this implementation detail.
Perhaps we have a terminology mismatch, I tend to use abstract class and interface interchangeably. I’m not sure it’s possible to define a class interface in c++ without using inheritance, what kind of interface are you referring to that doesn’t use inheritance?
You do have a terminology mismatch. In C++, an abstract class is a class with at least one pure virtual method.
Such classes cannot be instantiated, so they are useful only as base classes.
An interface is more of a concept than a thing.
Sure you can say that Iterable is an interface that provides the Next() and Prev() methods and you can say that Array is an Iterable because it inherits from Iterable (and then you override those methods to do the correct thing), and that’s one way to implement an interface in C++.
But you can also say that Iterable<T> is a class template that provides a Next() and Prev() methods that call the methods of the same name on the type that they wrap (CRTP aka static polymorphism).
Or you can say that an algorithm that scans a collection T forward requires the collection to have a Next() method by calling Next() on it.
And I can think of at least 2 other ways to define an interface that isn’t using abstract classes.
And even if using abstract classes, inheriting from them is definitely the least flexible way to use them to define an interface, because it doesn’t allow one to do something like mocking functionality in tests, because it’s not possible to redefine the class to be tested to inherit from the test interface implementation with mocked functionality, so one still needs something to the effect of dependency injection anyway.
So yeah, abstract class is very different from inheritance, and it’s also very different from interface, even though it relates to both.
I agree, my terms aren’t perfect, but as you stated there isn’t really such a thing as an interface in c++, traditionally this is achieved via an abstract base class which is what I meant by using them interchangeably.
I know there are many things you can do in c++ to enforce an interface, but tying this back to the original comment that inheritance is objectively bad, I don’t think there’s any consensus that this is true. Abstract base classes (with no data members) and CRTP are both common use cases of inheritance in modern C++ codebases and are generally considered good design patterns.
Meh. Been developing professionally with C++ for 10 years at this point. I’m one of the weird people that kinda likes C++ and its pragmatism despite all its warts.
I’d like C++ better if it didn’t have inheritance. There are better solutions to model interfaces, and without inheritance people can’t write class hierarchies that are 10 levels deep with a different set of virtual functions overridden (and new virtual functions added) at each level.
And yes, that is not hypothetical. Real codebases in the real world shipping working products do that, and it’s about as nice as you can imagine.
I don’t think it’s what the person you’re replying to meant, but template metaprogramming in modern c++ allows the use of “duck typing” aka “static polymorphism” where you can code against an interface without requiring inheritance.
Typically this is done with CRTP which does require inheritance. But I agree, you can do some meta programming or use concepts which can enforce interfaces in a different way. But back to the original comment that interfaces via inheritance are objectively bad, I don’t think there’s any consensus that this is true. And pure virtual interfaces and CRTP are both common use cases of inheritance in modern C++ codebases and are generally considered good design patterns.
Rust’s cargo is great, I’d say it would be best to make the switch sooner rather than later once your code base is established. The build system and tooling alone is a great reason to switch
What sucks is I’ve been working on this hobby project for nearly 4 years now. It started in C#, moved to C, now C++. It’s at the stage where a lot of basic functionality has been implemented, with the largest component, the Vulkan based renderer being maybe 1/4 implemented. The core game stuff is ECS based and flecs has a rust binding so migrating that will be easy. Renderer will just become even further from completion. I’m worried that there will be new problems that are maybe more inhibiting, but this is meant to be a fun project and build systems aren’t fun. It’s a difficult balance and I’m not the only person involved, the other person isn’t as convinced by cargo as they haven’t spent days working on the build system
I’m a gameplay programmer who have worked with Unity and Unreal and I’ve experiment with Rust for gamedev(though only for hobby projects) and for regular code. My conclusions so far is that Rust sucks for gameplay code, for most other things it’s kinda nice.
The biggest reason is that it’s much harder to write prototype code to test out an idea to see if it’s feasible and feels/looks good enough. I don’t want to be forced to fully plan out my code and deal with borrowing issues before I even have an idea of if this is a good path or not.
I would say though that because you are using ECS stuff it is at least plausible to do in Rust but at least for my coding/development style it still isn’t a good fit.
The biggest reason is that it’s much harder to write prototype code to test out an idea to see if it’s feasible and feels/looks good enough. I don’t want to be forced to fully plan out my code and deal with borrowing issues before I even have an idea of if this is a good path or not.
There are options for this with Rust. If you wanted to use pure Rust you could always use unsafe to do prototyping and then come back and refactor if you like it. Alternatively you could write bindings for C/C++ and do prototyping that way.
Though, I will say that this process gets easier as you gain more experience with Rust memory management.
That’s fair, I honestly haven’t used it in a while and forgot the real usage of unsafe code. As I said to another comment, it is a really rough language for game dev as it necessitates very different patterns from other languages. Definitely better to learn game dev itself pretty well first in something like C++, then to learn Rust separately before trying game dev in Rust.
Not really. Unsafe doesn’t allow you to sidestep the borrow checker in a decent way. And even if you do it the Rust compiler assumes non aliasing and breaking that will give you loads of unexpected problems that you wouldn’t get in a language that assumes aliasing…
Testing something that only has side effects to the local scope is probably not too hard but that isn’t the most common case for gameplay code in my experience…
Going through another language basically has the same issues as unsafe except it’s worse in most ways as you’d need to keep up to date bindings all the time plus just the general hassle of doing it for something that could have been a 10 min prototype with most other setups…
Now sure it’s possible that I would have better result after doing even more rust, especially with some feedback from someone who really knows it but that doesn’t really change anything in just general advice to people who is already working on something in C++ as they likely won’t have that kind of support either.
Those are fair points. I haven’t used it for a little while and forgot the exact usage of unsafe code. I love Rust, but I totally agree that it’s a rough language for game dev. Especially if you’re trying to migrate an existing project to it since it requires a complete redesign of most systems rather than a straight translation.
Yeah I’m not too concerned about the ECS stuff, since the library I’m using has a rust binding which is semi-official. From what I’ve heard about Rust in other places is that it requires a different mental model for memory management to other languages. So I’m more concerned about using Vulkan with it (there are quite a few libraries for it already though so it won’t be impossible). I guess I can’t really know until I give it a go though, I might try and port one of my smaller projects over first to see how I like it.
I’m seriously considering dropping everything and jumping to Rust because of Cargo.
Well if you’re into game dev, ECS and Rust, there’s like a 99% chance you know of it, but just in case you don’t: We have bevy, now with an extra full-time dev (Alice, who’d been working hard at it for years, I think she’s a bigger contributor than the author himself at this point lol)
I’ve been keeping an eye on bevy, it looks really cool. I’ll probably make something with it one day when their ECS gets support for entity relationships (which appears to be in the pipeline). A really cool project though, basically looks like everything I’ve wanted out of a C++ engine which I can’t really use due to build system mixing.
They’re mucking it about a little though, like that post when checking if types don’t match ‘! value is type’ can now be ‘value is not type’ which is more readable but not as logical in terms of the language.
Being a Python simp, I find GDscript just different enough to nag. There’s a lot of QoL stuff they don’t have and aren’t (currently) looking to add in order to keep the language simple. Honestly has me looking to use C# instead.
Being a Python simp, I find GDscript just different enough to nag. There’s a lot of QoL stuff they don’t have and aren’t (currently) looking to add in order to keep the language simple. Honestly has me looking to use C# instead.
I would propose creating a distributed hash table for this. But I would never host someone else’s data like this, because I’m too afraid they will give me encrypted illegal content and then some obscure law will give me the fault for it. This is just me though.
TypeScript is still built on JavaScript, all numbers are IEEE-754 doubles 🙃
Edit: Actually I lied, there are BigInts which are arbitrarily precise integers but I don’t think there’s a way to make them unsigned. There also might be a byte-array object that stores uint8 values but I’m not completely sure if I’m remembering that correctly.
Yeah JavaScript is a bit weird, semicolons being optional and compulsory at the same time: I remember trying to build an electron example ~5yrs ago and it didn’t work unless I put in the semicolons which the developers omitted.
Python is just glorified shell scripting. Libraries like numpy are cool but I don’t like the indentation crap, I’m getting used to it because University likes it.
Yeah I meant for that to be a bit inflammatory. I actually don’t mind python apart from the execution speed, but the indentation I find makes it more difficult to read stuff that is extremely nested. I use it mostly for creating plots and basic stuff for my science degree but for any serious project I wouldn’t consider it
Yes but it’s difficult in a long program to tell which scope you are in or where one ends. I don’t know what is so unfriendly about { and }, my editor can highlight pairs of them, it’s just nicer to work with.
I think the thing with C++ is they have tried to maintain backward compatibility from Day 1. You can take a C++ program from the 80s (or heck, even a straight up C program), and there’s a good chance it will compile as-is, which is rather astonishing considering modern C++ feels like a different language.
But I think this is what leads to a lot of the complexity as it stands? By contrast, I started Python in the Python 2 era, and when they switched to 3, I was like “Wow, did they just break hello world?” It’s a different philosophy and has its trade-offs. By reinventing itself, it can get rid of the legacy cruft that never worked well or required hacky workarounds, but old code will not simply run under the new interpreter. You have to hope your migration tools are up to the task.
There were breaking changes between C and C++ (and some divergent evolution since the initial split) as well as breaking changes between different releases of C++ itself. I am not saying these never happened, but the powers that be controlling the standard have worked hard to minimize these for better or worse.
If I took one of my earliest ANSI C programs from the 80s and ran it through a C++23 compiler, I would probably need to remove a bunch of register statements and maybe check if an assumption of 16-bit int is going to land me in some trouble, but otherwise, I think it would build as long as it’s not linking in any 3rd party libraries.
kbin.life
Oldest