Comments by "TheEVEInspiration" (@TheEVEInspiration) on "Developer Voices" channel.

In the 90s I always did "transactional" programming, using C++ very strict lifetimes of objects on the stack. Things go out of scope? Fine, then deallocate automatically, no coding required. And it does not matter how deep or complex the execution pathways are. It does not have to be stack memory based, but the control of flow does control the memory claim lifetime. This simplified code a lot and memory management too as most memory use is very temporary.
5
I think the architecture will be quite difficult to do model updates on. Because each server node and client node needs to use the same code/model. I can see a full shutdown of all clients required. Then let the server nodes sync up. Validate this. Then do model/code updates in single user mode. Link up again and validate shared state. Then update clients and re-connect them. As for storing all historical transactions Model changes and game rule changes mess with historical data. Historical transactions cannot really be replayed fully after a change, if it are actions (that would require the code as it was back then, bugs included). But if it is just a log of what was decided and approved, then information is lost and it becomes increasingly harder to interpret the data due to changes over time. I kind of look at it in the same way I look at persistent memory (computers that never boot up, programs that never shut down). That I will never trust, every bug is permanently ingrained in the OS/program state and permanent. For the same reasons object databases that simply act as virtual persistent memory are not trustworthy. Overal, I think it is an interesting idea, but fear that in practice it will be too restrictive and clog up over time.
3
I hope the database can be used in client server mode and had backup/restore functionality. Else its practicality in the field will be quite limited. Even a crude client/server with just a few broad rights (like read-only) and limited number of users would go a long way.
2
Why not just use a "pure" keyword onto variables that imply some restrictions on what you can do with that reference? No need to "declare" regions then.
2
21:38 "everything is a database" Depends on how you mean it, if that is true or not. If it means all state can be persistent, then if it not true. But if it means, every state can be accessed as if it were a database, sure, there is something to be said about that. Treating state itself as something that is persistent is enormously rigid and error prone. Every now and then someone or some institution thinks they found the light and memory needs to be persistent. That might work out well for biological systems that are inaccurate and forgetful and have Neuroplasticity. But it is a terrible concept for anything else. Think of error accumulation, having bugs forever persistent in ones program state is just plain wrong. What if a developer wants to use a different algorithm, how to transition the current state to that new one? You can see the nightmare and potential for bugs developing right in front of your eyes now, don't you?
2
27:47 as long as the server still validates every client input as according to the game rules, this is ok. But there is no way around the server needing to have game knowledge, can't trust clients to send valid data according to game rules!
2
@LtdJorge IMO, you just described its crippling limitations for real applications, not its strengths. There are very few use-cases other than taking a first look at some data with the CLI tool as far as I can see from your reply. Actual applications for automation need more than that and cannot accept data of unknown structures to work with meaningfully. And also require support for other processes to access the data or the output after processing of said data. So as an explorer tool that uses SQL to open CSV files etc, sure. It will be better at that than typical RDBMS I seen, but once that is done, one still needs to use RDBMS for the real deal. Can't call it a database then, call it a data-explorer tool.
1
@AdrianBoyko These days I stick to what I need to work with, so I miss out on some neat ideas no doubt. But even if I see them, they would not be usable for me in my job. Great that people are trying to make things better however.
1
Another drawback of parallelizing re-partitioning streams instead of parallel operators is that there is a lot more memory claimed, just to avoid spillovers. And spillovers really hurt performance.
1