Jai Language Primer

Post by pandaman » Sat, Feb 13, 2016, 10:27 PM UTC

CyberDildonics wrote: post #100

pandaman wrote: post #99

Earlier quoted context omitted.

>If you need to grow or shrink it use a vector. Thank you for the advise but what if I want to shrink one array that takes 200 MB of memory by 10MB and give it to another array that takes 50 MB of memory on a system with only 256 MB of memory? > If you need different types of memory or aligned memory, make an allocator and use that. std::array does not have allocators. >I'm not exactly sure why you think these things…

I've lost track of your point all together, are you still trying to say there is utility in raw arrays? You can't possibly think memory allocation problems that are solved by custom allocators can be dismissed because std::array doesn't take an allocator when that it integral to the entire reason it exists. Are you trying to say that not only do you want aligned static memory but that there is nothing that exists tha…

Here is a digest of the thread you had been replying to: gregstula said that std::array is better than what games use (imagining games use plain C arrays). I corrected them, saying that games use explicitly mapped memory and pointed at issues with std::array that prevents its usage in games. I never advocated use of raw arrays in this thread though they have utility since they are easily substituted with pointers if/when you decide that you care about the underlying memory and this is why I've never seen std::array in a game code. Note that I have not seen every game in existence, only few dozen AAA titles or so. I know people write indie/mobile/social games with stl, python and what-not but I am not really interested in that kind of game programming.

Post by BSVino » Sat, Feb 13, 2016, 11:53 PM UTC

gregstula wrote: post #10

> Abstractions like RAII, constructors and destructors, polymorphism, and exceptions were invented with the intention of solving problems that game programmers don’t have This is the only part of the Jai philosophy I struggle to understand. How is an explicit delete keyword better than deterministic destruction? From my perspective, the former method reintroduces the problem the latter method solves. Also, polymorphi…

Hey there. I wrote the Jai Primer. Ideas there are my best interpretation of Blows ideas, which I generally agree with, but bear in mind they're not his.

To quote Joe Armstrong: You wanted a banana but you got the gorilla holding the banana and the whole jungle. You wanted a way to delete memory automatically, which sounds great but in practice most language's approaches to solving this problem come with a host of other problems that at scale make the given solution not worth it. RAII solves a big problem but it introduces a bunch of tiny problems like big mysterious constructors that implicitly do a lot of work and deconstructors that don't map to any particular line of code other than an ending brace. It's tough to examine in a debugger, it's tougher to reason about when it gets to nontrivial scale, etc etc. But human brains naturally weight a lot of small pains to be less bad than one big pain, so the solution looks legit.

Polymorphism is a way of modeling the world that runs along the lines of the categorizations that people tend to make, so it feels natural to create deep class hierarchies. But in practice it doesn't match the problem that you need to solve when you make games - you have data in state A and you need to get it into state B. Example: to do a physics integration on each simulated body, the CPU wants to do a for loop over a list of position vectors. But those vectors have been scattered all over memory by the class hierarchy. So that's one problem, you also get problems like needing RTTI and casting and yadeya. Class structures have largely fallen out of vogue in game development in favor of component systems, which is a pretty good step forward.

Re: Jai Language Primer

Re: Jai Language Primer