Software disenchantment
-
@pie_flavor oh, so Diesel is more like just serializer/deserializer than the full-fledged ORMs known from other languages?
-
@dkf said in Software disenchantment:
Except… you find that users are mostly using the library to find out how many items there are in the list, usually just to see if the number of items is zero when it could also be many millions, and don't actually want to know what the items are most of the time.
If you find that users are mostly using your program or library in ways you didn't anticipate, then you failed at the design stage and need to rework things to match the actual pattern of use in a reasonable way. Which isn't necessarily a sign of a bad developer, requirements gathering is not an exact science and just developing the application could change the way users behave. A bad developer would be one that tells users "don't use the library like that" instead of fixing the design. If users want to know the size of the thing, adding a method that tells them what they want to know makes the program simpler from the perspective of the user, not more complex.
Now, it's true that there's no silver bullet; complexity can't disappear and abstractions leak. But there's quite a big gulf between "abstractions leaking" and expecting users to understand the underlying model of the application to go about their daily business. Requiring a deeper understanding of the way the application works should be reserved for users trying to do something well outside the normal tasks you planned for, when they're trying to get the most out of what's possible with the application. And you might still want to block some things and not support them even if the underlying model makes it easy to do just because it introduces potential for confusion.
-
@Gąska said in Software disenchantment:
@pie_flavor oh, so Diesel is more like just serializer/deserializer than the full-fledged ORMs known from other languages?
Yes, to the point that you can't tell the difference since stuff knows how to insert itself. Stuff doesn't mutate out from under you but you can tell it to update itself too.
-
@pie_flavor said in Software disenchantment:
@Gąska said in Software disenchantment:
@pie_flavor oh, so Diesel is more like just serializer/deserializer than the full-fledged ORMs known from other languages?
Yes, to the point that you can't tell the difference since stuff knows how to insert itself.
Do read operations on ORM objects invoke additional DB queries? If not, then you can tell the difference very damn easily.
-
@Gąska No, you'd call a function to reread info from the database. Stuff should not ever mutate out from under you.
-
@pie_flavor in other words, Diesel avoids most pitfalls of ORM by avoiding most functionality of ORM.
Which is not bad at all, if you ask me.
-
@Gąska As usual, Rust is the best at everything.
-
@pie_flavor as usual, it does so by not being everything.
-
@pie_flavor said in Software disenchantment:
I don't need to know Java's garbage collection strategy,
You say you write game code in Java?
-
@Gribnit said in Software disenchantment:
@pie_flavor said in Software disenchantment:
I don't need to know Java's garbage collection strategy,
You say you write game code in Java?
Sort of / yes / not really?
-
@pie_flavor Fair enough. I occasionally had to know what GC would probably do for business code, but generally game code goes very, very far out of its way to avoid GC.
-
@Gribnit said in Software disenchantment:
@pie_flavor Fair enough. I occasionally had to know what GC would probably do for business code, but generally game code goes very, very far out of its way to avoid GC.
If you're looking for places to improve performance, you could start by not locking everything into a single thread. Trust me, GC is no slowdown on Minecraft servers as long as you use G1.
-
@pie_flavor said in Software disenchantment:
If you're looking for places to improve performance, you could start by not locking everything into a single thread.
Threading is among the most difficult of all topics in computer programming for extremely good reasons. In particular, it has some really non-trivial failure modes where studying the pieces of the problem separately reveals nothing wrong. It's up there with networking on the list of “well that's totally not obvious”. (Networking is bad that way because it inevitably involves services you've never heard of before doing things you hadn't ever realised were a thing you needed to do. Asynchronously. For other people.)
-
@dkf said in Software disenchantment:
Threading is among the most difficult of all topics in computer programming for extremely good reasons. In particular, it has some really non-trivial failure modes where studying the pieces of the problem separately reveals nothing wrong.
I find it becomes easier to follow by remembering that computers and programming languages is general have no concept of time, and the only thing imposing an ordering between operations are synchronization primitives (locks, atomics, etc). Which is why you should never use sleep(1000) to synchronize your code
-
@Kian said in Software disenchantment:
Which is why you should never use sleep(1000) to synchronize your code
Indeed. The right way would be
constexpr int synchronizationSleepDuration = 1000; ... sleep( synchronizationSleepDuration );
-
@Kian said in Software disenchantment:
Which is why you should never use sleep(1000) to synchronize your code
Unless you're running on a RTOS, when it might actually do the thing you need rather than the thing you asked for.
-
@dkf said in Software disenchantment:
Unless you're running on a RTOS
I can't remember the details, but years ago I heard about a car accident caused by doing this. They ran out of original 2051 uCs and bought some new 'compatible' clones instead. Turns out, the code from the '80s relied on the fact that certain operation took exactly n clock cycles, and creators of the clone succeeded in reducing that number.
-
@dkf said in Software disenchantment:
@Kian said in Software disenchantment:
Which is why you should never use sleep(1000) to synchronize your code
Unless you're running on a RTOS, when it might actually do the thing you need rather than the thing you asked for.
Huh? Thing you didn't ask for is almost always not the thing you need. Care to elaborate on this?
-
@Gąska said in Software disenchantment:
Care to elaborate on this?
I've forgotten exactly what I was thinking about, but… in a RTOS a wait for a certain number of ticks can be done fairly precisely. Often the real key is that the RTOS only runs one application at a time: there's nothing else going on that might preempt you unexpectedly and cause pauses to last longer than requested. Now I've only worked with soft-realtime OSes (so interrupts were allowed) but they're really very different indeed to anything you're used to on a desktop, server or ordinary mobile OS.
And the reason
sleep(1000)would synchronize? You can work out exactly how many clock ticks you want to wait, and you can do that for all the communicating parts of your system (typically running on different processors). Then you've just got to synchronize the clocks (a tricky hardware problem, but one that is actually possible).
