Job interview questions. Really???? Are these real?

[dkf]

@Groaner said in Job interview questions. Really???? Are these real?:

@dkf said in Job interview questions. Really???? Are these real?:

Well, there's RTTI which everyone turns off…

I don't. Don't you need it for stuff like dynamic_cast?

Only for dynamic_cast to be safe! If you don't give a fuck about that, turn it off, save all the overhead (this really matters in some places) and do whatever you want…

[Gąska]

@Groaner said in Job interview questions. Really???? Are these real?:

@dkf said in Job interview questions. Really???? Are these real?:

Well, there's RTTI which everyone turns off…

I don't. Don't you need it for stuff like dynamic_cast?

If you need dynamic_cast, then most likely your design is bad and you should feel bad.

[pie_flavor]

@Gąska said in Job interview questions. Really???? Are these real?:

your design is bad and you should feel bad.

core/java/android/app/Notification.java - platform/frameworks/base - Git at Google

[Groaner]

@Gąska said in Job interview questions. Really???? Are these real?:

@Groaner said in Job interview questions. Really???? Are these real?:

@dkf said in Job interview questions. Really???? Are these real?:

Well, there's RTTI which everyone turns off…

I don't. Don't you need it for stuff like dynamic_cast?

If you need dynamic_cast, then most likely your design is bad and you should feel bad.

Looking at one of my projects, let's see...

• What if the API method you're dealing with returns a Control but you want to do stuff if it's a Window?
• What if you're fed a Collidable and need to know whether it's StaticGeometry, a RigidBody, or simply a Location? Are you going to code methods to test for those into your base class? Seems like you're forced to design your base class around your derived classes in that case.

[Gąska]

@Groaner said in Job interview questions. Really???? Are these real?:

• What if the API method you're dealing with returns a Control but you want to do stuff if it's a Window?

Then the API is bad. Yes, I do realize it means almost all GUI APIs are bad. It's a sad world we live in.

• What if you're fed a Collidable and need to know whether it's StaticGeometry, a RigidBody, or simply a Location?

You shouldn't have used inheritance hierarchy for that. Inheritance is for when you don't care about underlying type. Here, you need an enum to store type, or just keep each kind separately so you don't need to dynamic_cast to get the object of correct type (note that you can still use base class for the stuff that actually is common).

The problem isn't with dynamic_cast itself. The problem is with what made you use it.

[topspin]

@dkf said in Job interview questions. Really???? Are these real?:

@Groaner said in Job interview questions. Really???? Are these real?:

@dkf said in Job interview questions. Really???? Are these real?:

Well, there's RTTI which everyone turns off…

I don't. Don't you need it for stuff like dynamic_cast?

Only for dynamic_cast to be safe! If you don't give a fuck about that, turn it off, save all the overhead (this really matters in some places) and do whatever you want…

And when you write safe you mean correct?!

[Kian]

@topspin said in Job interview questions. Really???? Are these real?:

@dkf said in Job interview questions. Really???? Are these real?:

@Groaner said in Job interview questions. Really???? Are these real?:

@dkf said in Job interview questions. Really???? Are these real?:

Well, there's RTTI which everyone turns off…

I don't. Don't you need it for stuff like dynamic_cast?

Only for dynamic_cast to be safe! If you don't give a fuck about that, turn it off, save all the overhead (this really matters in some places) and do whatever you want…

And when you write safe you mean correct?!

Actually, as @Gąska said, he means wrong. dynamic_cast is necessary for downcasting when you don't know the real type (if you do know it, static_cast is enough).

But downcasting is only necessary when your design sucks. If you need to do it, it means you threw away information that you still needed. Dynamic casting is like rummaging through garbage to find that information again. The correct solution is to build your interfaces so they don't discard information you need in the first place.

[topspin]

@Kian Irrelevant. A “bad design” can still work absolutely correctly (and it’s not a very objective metric to begin with). That’s not to say you shouldn’t avoid dynamic_cast, but if you do use one it surely makes a difference if the output is correct according to the spec or not. If dynamic_cast worked without RTTI it wouldn’t need RTTI.

I prefer a correct program over one that produces wrong results fast.

[Gąska]

@Kian said in Job interview questions. Really???? Are these real?:

But downcasting is only necessary when your design sucks.

Well, not necesarily your design. Sometimes it's libraries that force it on you, sometimes it's the language itself (vide Scala "enums") - but in every case where dynamic casts are done, there is some design change that could be performed somewhere, that would make the need for dynamic cast go away, as well as make the overall architecture better. Except for IPC - but you can cover it up so that the parts needing dynamic cast don't get exposed to the user of your library.

[Kian]

@topspin We're not disagreeing on that. If you use dynamic cast, you have to have rtti enabled. Otherwise, you're not even writing C++. I'm just stressing that rtti enables bad practices. They're sometimes necessary, because you don't always have the means to correct a bad design, and that's ultimately why the language supports it (same as other "bad design" constructs like const_cast, or some uses of reinterpret_cast). It's a very practical language in that sense. But rtti is one of the few things in the language that breaks the "you don't pay for what you don't use" rule, which is why it often gets disabled in projects that don't use dynamic_cast.

[topspin]

@Kian Tangential, but true. I think if you don’t use it you only pay for larger binary size though, right?

[Kian]

@topspin Strictly speaking, I'm not sure what the actual cost is. I don't disable it unless I'm in some kind of embedded system where I can't count on the C++ runtime being, in which case it gets disabled due to lack of support (I'm experimenting with bootloaders and OSes right now, so I disable rtti and exceptions, which is painful), not for performance reasons. I want to believe that the projects that do have actually measured the impact, but it's very possible they do it due to superstition, maybe because 20 years ago the implementation of it was more expensive and they've "always done it that way".

[dcon]

@PleegWat said in Job interview questions. Really???? Are these real?:

@topspin Catching up is not enough; the two pointers need to actually land on the same element, and there are combinations of step sizes, distance to loop start, and loop length, where the two loops end up moving in sync in some fashion without ever visiting the same elements.

However I can't think of any counter-examples offhand.

Of course, my first thought is if the program got your list into this state, the fuck with determining loops - there's a nasty bug that needs to be fixed!

[dkf]

@Kian said in Job interview questions. Really???? Are these real?:

Strictly speaking, I'm not sure what the actual cost is.

Probably some descriptors somewhere in read-only memory and a pointer into them per vtable, and with making it much harder to eliminate the need to exclude the vtable pointer from the instance layout. The complexity wouldn't be too bad except C++ has a fairly complex type system that makes the decision inside the dynamic_cast somewhat complicated (and necessarily at least partially impossible to perform ahead of time). It's the vtable pointer that has to be in the instances (at least a lot of the time) that makes things really awkward, since that can disrupt memory layouts where you need to map externally-defined structures, and that's a really unfortunate capability to lose since it's vital for handling network protocols, the OS, memory mapped hardware, etc. The compiler might be smart enough to avoid the cost in the classes/structure types which definitely never hit a dynamic_cast but that's getting worryingly tricky.

What's funny about this is how so many other languages have the ability to do the equivalent of dynamic_cast and don't get themselves in a mess over it. It's only really the C++ community that works themselves up over this, though I could see Rust worrying about this too. (The majority positions fall into two camps: always have safe dynamic casting because every memory object knows its true type, or totally reject making it safe and get on with being a hacky but useful language.)

It also amuses me that GUIs are once again the canonical troublesome example.

[Gąska]

@dkf said in Job interview questions. Really???? Are these real?:

It's the vtable pointer that has to be in the instances (at least a lot of the time) that makes things really awkward, since that can disrupt memory layouts where you need to map externally-defined structures, and that's a really unfortunate capability to lose since it's vital for handling network protocols, the OS, memory mapped hardware, etc.

Doesn't vptr only gets generated for classes in inheritance hierarchy? If you don't inherit, you don't have vptr, right? And I don't think anyone sane uses inheritance for those things.

[topspin]

@dkf An implementation detail, but I’d assume each object only stores a pointer to the class’s vtable, not the whole vtable per object (which would be one less indirection but a ton of memory overhead). And then increasing the size of that vtable by some more data isn’t a big deal.

[topspin]

@Gąska even then only for polymorphic classes (having virtual methods). Simply extending structures by inheritance (instead of composition) won’t make them polymorphic.

[Groaner]

@Gąska said in Job interview questions. Really???? Are these real?:

Then the API is bad. Yes, I do realize it means almost all GUI APIs are bad. It's a sad world we live in.

If it's so bad, then why is it such a common pattern? Cargo-cultism?

Here, you need an enum to store type

StaticGeometry isn't replicated across the network, but RigidBody is, and Location might contain data about what happens to actors that enter it while the others do not.

So while they all might have the common property of receiving collisions, each of them contains divergent data, and if you're going to use an enum, that means that to roll them into a single class entails a union of all possible fields. You've also just moved the complexity of a bunch of dynamic_casts into a bunch of switch statements.

or just keep each kind separately so you don't need to dynamic_cast to get the object of correct type (note that you can still use base class for the stuff that actually is common).

The physics library I'm using (Bullet) has a single user data field of type void * for its objects, so keeping them separate isn't an option. I suppose you could link that user pointer to some sort of descriptor class that has a bunch of pointers to various object types (where one of the pointers is valid and the rest are nullptr), but that just seems like going far out of your way just to avoid dynamic_cast. And you'd have to update that class every time you created a new class, while you generally don't have to update a base class every time you add a derived class.

Another of my dependencies (Ogre) is nicer in that it creates a property map for user-defined data in each of its objects, but we don't get that luxury everywhere.

The problem isn't with dynamic_cast itself. The problem is with what made you use it.

Like the as keyword in C#, it's a very useful tool for answering the question "I have a Base. Is it a Derived?" Every model is going to get ugly once it's exposed to reality for long enough. The question is, what's the least-ugly approach?

[Gąska]

@topspin said in Job interview questions. Really???? Are these real?:

@Gąska even then only for polymorphic classes (having virtual methods). Simply extending structures by inheritance (instead of composition) won’t make them polymorphic.

And dynamic_casting those is a compile error, apparently.

[Gąska]

@Groaner said in Job interview questions. Really???? Are these real?:

@Gąska said in Job interview questions. Really???? Are these real?:

Then the API is bad. Yes, I do realize it means almost all GUI APIs are bad. It's a sad world we live in.

If it's so bad, then why is it such a common pattern? Cargo-cultism?

Pretty much. Also, laziness.

Here, you need an enum to store type

StaticGeometry isn't replicated across the network, but RigidBody is, and Location might contain data about what happens to actors that enter it while the others do not.

So they should be three separate classes altogether. Or go with ECS model and use collision component for collision, replication-over-network component for replicating over network, and trigger component for effects on entering location.

So while they all might have the common property of receiving collisions, each of them contains divergent data, and if you're going to use an enum, that means that to roll them into a single class entails a union of all possible fields.

If you didn't notice, I didn't know any of this before literally just now, long after I made that post. If you didn't notice, I've provided alternative solution that doesn't involve enums in the very same sentence.

You've also just moved the complexity of a bunch of dynamic_casts into a bunch of switch statements.

Which is arguably a bit less bad than dynamic casts. If only because you statically know all possibilities.

or just keep each kind separately so you don't need to dynamic_cast to get the object of correct type (note that you can still use base class for the stuff that actually is common).

The physics library I'm using (Bullet) has a single user data field of type void * for its objects

I refer you to what I've said about having to use 3rd party libraries.

Another of my dependencies (Ogre) is nicer in that it creates a property map for user-defined data in each of its objects, but we don't get that luxury everywhere.

See? There is a better option. Just not everybody cares enough to implement it. And library users are stuck with that laziness forever.

The problem isn't with dynamic_cast itself. The problem is with what made you use it.

Like the as keyword in C#, it's a very useful tool for answering the question "I have a Base. Is it a Derived?"

It probably won't surprise you that I have the exact same opinion of C#'s as as I have of C++'s dynamic_cast.

Every model is going to get ugly once it's exposed to reality for long enough. The question is, what's the least-ugly approach?

In your case, ECS. In other cases, it's other things. But dynamic_cast is never the least ugly. Unless you're stuck with it because someone else in dependency chain fucked it up already.

[Gąska]

@Groaner and an interesting historical fact - old Quake engines had only one entity type, and it contained all possible fields of all possible kinds of entities. Terrain had health. Pistol had explosion radius. And so on for everything. And I've heard people found that model very flexible and easy to work with - and also pretty great performance-wise (memory is far cheaper than cycles). So having one class for everything (plus an enum for type) isn't as bad an idea as it might sound. But still, in my opinion, ECS is the way to go.

[topspin]

@Gąska Can you expand that acronym? I’m sure it’s not elastic container system.

[Gąska]

@topspin close. Entity Component System. Note that it's three independent nouns, not a system of entities and components - it's an architecture that consists of entities, of components, and of systems, all semi-independent from each other.

Edit: if you've had any experience with Unity Engine, ECS is what Unity Engine is built around.

[topspin]

@Gąska That makes more sense, the acronym just didn’t ring a bell.

[pie_flavor]

@Gąska said in Job interview questions. Really???? Are these real?:

vide

[WhatYouSay]

@Groaner said in Job interview questions. Really???? Are these real?:

@cheong said in Job interview questions. Really???? Are these real?:

(Unless you set the target wage too highambitious, of course)

It's tiresome dealing with 23-year-olds who assume they're immediately entitled to a 90th+ percentile senior salary. A few friends wanted six figures or near that amount as they were starting out and they had to learn the hard way.

Blame Google. Apparently they are more than willing to do exactly this for fresh-off-the-mint graduates who don’t know enough to know when they are being mismanaged or asked to build dystopian systems of social control.

[WhatYouSay]

@Gąska said in Job interview questions. Really???? Are these real?:

@topspin close. Entity Component System. Note that it's three independent nouns, not a system of entities and components - it's an architecture that consists of entities, of components, and of systems, all semi-independent from each other.

Edit: if you've had any experience with Unity Engine, ECS is what Unity Engine is built around.

Except that the GameObject/MonoBehaviour setup isn’t really quite ECS, strictly speaking. Way too much overhead and not much cache coherence. Hence why they are actually making a shift to a more proper ECS implementation, with a chance to get used to it in their package manager.

They are indeed hoping that they’ll manage to get people onboard with everything being done by iterating native arrays of structs inside c# jobs that have no concept of the outside world. I foresee an epic shitstorm if they pull support for GameObject/MonoBehaviour and crack down on the usefulness of lambdas and closures.

[dkf]

@topspin said in Job interview questions. Really???? Are these real?:

An implementation detail, but I’d assume each object only stores a pointer to the class’s vtable, not the whole vtable per object (which would be one less indirection but a ton of memory overhead). And then increasing the size of that vtable by some more data isn’t a big deal.

Yes, I was assuming that too.

The problem is that even one pointer takes space, which is critical in some situations, and if you have dynamic_cast in the mix you've got to prove that you are safe to elide the vtable pointer. Which requires knowing that such classes never go through an operation that critically needs them, though such knowledge is very much not in keeping with how C++ compilers work…

[djls45]

@pie_flavor said in Job interview questions. Really???? Are these real?:

@Gąska said in Job interview questions. Really???? Are these real?:

vide

[pie_flavor]

@djls45 I have never heard of that word used anywhere, for anything. TIL.

[HardwareGeek]

@pie_flavor Have you ever seen the abbreviation q.v.? If so, you've seen vide without knowing it. Quod vide, "which see," meaning "refer to the section of the document describing the preceding term."

[Gąska]

@HardwareGeek I have never heard of "q.v." used anywhere, for anything. TIL.

[pie_flavor]

@HardwareGeek I haven't seen that either, no.

[Parody]

@Gąska While I've used q.v. before, I don't recall seeing vide separately.

[Gąska]

@Parody maybe it's a Polish thing. I see people using it in Polish texts from time to time.

[remi]

@Gąska said in Job interview questions. Really???? Are these real?:

Every model is going to get ugly once it's exposed to reality for long enough. The question is, what's the least-ugly approach?

In your case, ECS. In other cases, it's other things. But dynamic_cast is never the least ugly. Unless you're stuck with it because someone else in dependency chain fucked it up already.

For me, this discussion ties in quite well with a previous post where I said, essentially, "who gives a fuck about linked lists in the Real World?" I kind of agree with you in theory that dynamic_cast isn't very clean and often betrays a bad design that could be improved, but for me the main point is practicality. And in the long term, I've found many cases where it's easier to use a dynamic_cast than rewrite a lot of code, or change the whole model (if designing from scratch). Sure, it's less clean, but as long as I'm aware of it and cringes a little every time I do it (and therefore do it as little as possible), I won't really mind. There is a point where actually getting things done becomes more important than getting a perfectly pure and ideal code (and design).

Am I perpetuating bad designs? Yes, but we all do that every day in a lot of domains, not just in coding ( : Americans still don't use SI units in every day life...). Without getting too philosophical, knowing that I'm not perfect and where my flaws are is better than believing that I could ever actually be perfect.

[Gąska]

@remi said in Job interview questions. Really???? Are these real?:

@Gąska said in Job interview questions. Really???? Are these real?:

Every model is going to get ugly once it's exposed to reality for long enough. The question is, what's the least-ugly approach?

In your case, ECS. In other cases, it's other things. But dynamic_cast is never the least ugly. Unless you're stuck with it because someone else in dependency chain fucked it up already.

For me, this discussion ties in quite well with a previous post where I said, essentially, "who gives a fuck about linked lists in the Real World?" I kind of agree with you in theory that dynamic_cast isn't very clean and often betrays a bad design that could be improved, but for me the main point is practicality. And in the long term, I've found many cases where it's easier to use a dynamic_cast than rewrite a lot of code, or change the whole model (if designing from scratch).

At which point did I advocate for rewriting everything from scratch? If you're responding to my points, at least be kind enough to address those points, not random strawmen you're setting up on the way. I didn't say you should rewrite everything that's badly designed. I just said it's badly designed. I even said that using more bad design because the previous bad design forces you to do that is completely justified.

[Benjamin Hall]

@remi The perfect is too often the enemy of the good. And knowing when "good" is "good enough" is something people (including myself) struggle with. As my dissertation advisor said (paraphrased):

Your research will never be done, but there comes a time when you have to publish what you've got and move on.

Same goes for scientific models and methods. Sometimes the most exact, most "right" one isn't the one that's actually useful or tractable in the present case. dynamic_cast (if I understand correctly) is a tool. A dangerous tool, to be sure, but so is a chain saw.

[Kian]

@Benjamin-Hall said in Job interview questions. Really???? Are these real?:

dynamic_cast (if I understand correctly) is a tool. A dangerous tool, to be sure, but so is a chain saw.

To clarify, dynamic cast itself is perfectly safe, in the same sense that bandages are safe. But it would be better not to plan your tasks around the fact that you have bandages to patch yourself up after the chainsaw got away from you.

[Benjamin Hall]

@Kian said in Job interview questions. Really???? Are these real?:

@Benjamin-Hall said in Job interview questions. Really???? Are these real?:

dynamic_cast (if I understand correctly) is a tool. A dangerous tool, to be sure, but so is a chain saw.

To clarify, dynamic cast itself is perfectly safe, in the same sense that bandages are safe. But it would be better not to plan your tasks around the fact that you have bandages to patch yourself up after the chainsaw got away from you.

Except bandages only exist for the "I screwed up and got hurt" failure case. As it seems to me, dynamic_cast has uses that are really awkward at best to do otherwise (mainly because C++, but )

[Groaner]

@Gąska said in Job interview questions. Really???? Are these real?:

@Groaner and an interesting historical fact - old Quake engines had only one entity type, and it contained all possible fields of all possible kinds of entities. Terrain had health. Pistol had explosion radius. And so on for everything. And I've heard people found that model very flexible and easy to work with - and also pretty great performance-wise (memory is far cheaper than cycles). So having one class for everything (plus an enum for type) isn't as bad an idea as it might sound. But still, in my opinion, ECS is the way to go.

There are certainly advantages to putting everything in one class, as long as you can accept that you'll have to test more permutations since that one class has to support far more behavior.

Right now, my Entity class' .cpp file is about 1kLoC. This is a barebones base class for all replicated actors, be they player characters, fireballs, boulders that can be moved, etc. If I were to roll all the subclasses into it, it would probably be closer to 10k. But, that would make handling a few awkward corner cases easier and obviate the need for dynamic_cast.

[izzion]

@Groaner
But they have a trophy case full of evidence that they're amazingly exceptional, of course they're worthy of a 99th %ile salary!

[Groaner]

@WhatYouSay said in Job interview questions. Really???? Are these real?:

@Gąska said in Job interview questions. Really???? Are these real?:

@topspin close. Entity Component System. Note that it's three independent nouns, not a system of entities and components - it's an architecture that consists of entities, of components, and of systems, all semi-independent from each other.

Edit: if you've had any experience with Unity Engine, ECS is what Unity Engine is built around.

Except that the GameObject/MonoBehaviour setup isn’t really quite ECS, strictly speaking. Way too much overhead and not much cache coherence. Hence why they are actually making a shift to a more proper ECS implementation, with a chance to get used to it in their package manager.

They are indeed hoping that they’ll manage to get people onboard with everything being done by iterating native arrays of structs inside c# jobs that have no concept of the outside world. I foresee an epic shitstorm if they pull support for GameObject/MonoBehaviour and crack down on the usefulness of lambdas and closures.

Rapid deprecation/removal of GameObject/MonoBehaviour sounds like a great way to break 99% of Unity apps. At least the Ogre guys are nice enough to do a 1.x/2.x split.

I've gone on the record as having no love for Unity in the past, and while I don't see it as a good solution for serious projects, it would be bad to make a bunch of newbie/indie developers dead in the water.

[Groaner]

@Kian said in Job interview questions. Really???? Are these real?:

@Benjamin-Hall said in Job interview questions. Really???? Are these real?:

dynamic_cast (if I understand correctly) is a tool. A dangerous tool, to be sure, but so is a chain saw.

To clarify, dynamic cast itself is perfectly safe, in the same sense that bandages are safe. But it would be better not to plan your tasks around the fact that you have bandages to patch yourself up after the chainsaw got away from you.

Um, I hate to be the bearer of bad news, but if you have chainsaw wounds, bandages probably aren't gonna suffice.

[WhatYouSay]

@Groaner said in Job interview questions. Really???? Are these real?:

@WhatYouSay said in Job interview questions. Really???? Are these real?:

@Gąska said in Job interview questions. Really???? Are these real?:

@topspin close. Entity Component System. Note that it's three independent nouns, not a system of entities and components - it's an architecture that consists of entities, of components, and of systems, all semi-independent from each other.

Edit: if you've had any experience with Unity Engine, ECS is what Unity Engine is built around.

Except that the GameObject/MonoBehaviour setup isn’t really quite ECS, strictly speaking. Way too much overhead and not much cache coherence. Hence why they are actually making a shift to a more proper ECS implementation, with a chance to get used to it in their package manager.

They are indeed hoping that they’ll manage to get people onboard with everything being done by iterating native arrays of structs inside c# jobs that have no concept of the outside world. I foresee an epic shitstorm if they pull support for GameObject/MonoBehaviour and crack down on the usefulness of lambdas and closures.

Rapid deprecation/removal of GameObject/MonoBehaviour sounds like a great way to break 99% of Unity apps. At least the Ogre guys are nice enough to do a 1.x/2.x split.

I've gone on the record as having no love for Unity in the past, and while I don't see it as a good solution for serious projects, it would be bad to make a bunch of newbie/indie developers dead in the water.

If it happens that they deprecate GameObject/MonoBehaviour, it wont be rapid. As I say, they are rolling out the change in a package and it’s opt-in (and undercooked) currently. It’s not the worst way to introduce such a change, but it’s one that I’m certain would lose a lot of the old community.

All your criticisms are fair, and I have my own apart from them. They did however, eventually sunset support for Boo and UnityScript, so they are certainly not afraid to break legacy code made by past developers. That’s even apart from other things like constantly changing the physics engine from version to version, or letting older versions of Unity become incompatible with the new asset store, and WTFs like blackboxing Android SDK support in older versions keeping you trapped in specific older SDKs.

It’s certainly a productive tool but people have to go into it with their eyes wide open and understand what they’re signing themselves up for. I think not many people do that and they get burned.

[topspin]

@Benjamin-Hall said in Job interview questions. Really???? Are these real?:

@Kian said in Job interview questions. Really???? Are these real?:

@Benjamin-Hall said in Job interview questions. Really???? Are these real?:

dynamic_cast (if I understand correctly) is a tool. A dangerous tool, to be sure, but so is a chain saw.

To clarify, dynamic cast itself is perfectly safe, in the same sense that bandages are safe. But it would be better not to plan your tasks around the fact that you have bandages to patch yourself up after the chainsaw got away from you.

Except bandages only exist for the "I screwed up and got hurt" failure case. As it seems to me, dynamic_cast has uses that are really awkward at best to do otherwise (mainly because C++, but )

Well, it's no worse than using runtime reflection, and people build whole frameworks around that.

[Kian]

@WhatYouSay Well, games don't tend to require a long support life, and are mostly standalone applications, so breaking compatibility with old versions isn't that much of a problem. Either the benefits of the new tools outweigh the costs of having to upgrade some other tools/resources, or they don't. The old version will continue to be maintainable until it makes no more sense to update it, and new games start with a mostly clean slate (except for whatever you can salvage of the old one). Having no legacy baggage in your tools is also nice.

[Gąska]

@Groaner said in Job interview questions. Really???? Are these real?:

@Gąska said in Job interview questions. Really???? Are these real?:

@Groaner and an interesting historical fact - old Quake engines had only one entity type, and it contained all possible fields of all possible kinds of entities. Terrain had health. Pistol had explosion radius. And so on for everything. And I've heard people found that model very flexible and easy to work with - and also pretty great performance-wise (memory is far cheaper than cycles). So having one class for everything (plus an enum for type) isn't as bad an idea as it might sound. But still, in my opinion, ECS is the way to go.

There are certainly advantages to putting everything in one class, as long as you can accept that you'll have to test more permutations since that one class has to support far more behavior.

But it didn't. It just ignored irrelevant variables.

[dkf]

@Groaner said in Job interview questions. Really???? Are these real?:

Um, I hate to be the bearer of bad news, but if you have chainsaw wounds, bandages probably aren't gonna suffice.

You mean, I might need a whole health potion? Oh well, that's what they're there for…

[dkf]

@Kian said in Job interview questions. Really???? Are these real?:

Having no legacy baggage in your tools is also nice.

Having no legacy support requirements by having no customers is also nice.

Except it isn't.