Which programming language did you choose and why?

[Raghar]

Public static is initialized during start of the program which slow down initialization sometimes significantly.

In addition order of activation of public static stuff during initialization is up to compiler. That can change between compiler versions, and in case of JIT compilers, it can even change between two initializations.

 

[odrzut]

Pure functions and passing everything is better for understanding what happens. Also for parallel programming. But it sucks when you want to iterate quickly on your design. So you want to add a particle effect and play a sound when you kill every 10th enemy? Have fun adding 2 new parameters to every function in the callstack

Global state is better for exploratory, iterative programming (which is 90% of gamedev). Also for single-threaded efficiency in some cases. But it's hard to understand and lets you make a mess.

My ideal language would allow me to write code with no parameters using hierarchically nested global state and then hit "purify" and transpile it into pure functions style passing the minimal required data everywhere it's used.

ECS is pretty close to this and that's a big reason I like it.

 

[Krice]

Pure functions and passing everything is better for understanding what happens.

Well there is also OOP where you don't really pass that many parameters. I guess keeping that parameter purity is not practical in most cases, you'll have something as globals. In my projects it's usually classes that have only one instance, like gui class. However as someone already stated it's probably better keep them dynamic rather than static, because (in C/C++) for statics the order of initialization is random. In literature this is called "initialization order fiasco". If your classes are independent (don't depend on anything else in the construction phase) then it ok. In ideal cases this is what you should have anyway, but I guess it could result to partial construction which could also be an issue.

 

[odrzut]

OOP doesn't change much here, it doesn't really matter if you have struct GlobalState and functions or class GlobalState and methods.

 

[Twiglard]

OOP doesn't change much here, it doesn't really matter if you have struct GlobalState and functions or class GlobalState and methods.

In C++ struct is just a class with an implicit public access specifier. Equal in all other aspects.

 

[odrzut]

Yes I know. That's what I added "and functions".

 

[Krice]

OOP doesn't change much here, it doesn't really matter if you have struct GlobalState and functions or class GlobalState and methods.

It does if you think about passing parameters in functions. In a class you usually have a dramatic reduction of parameters, unless you code C/procedural style with classes, too. I mean, surprisingly many people do that, because they just don't get the idea.

 

[Krice]

In C++ struct is just a class with an implicit public access specifier. Equal in all other aspects.

You can think about the difference if you compare C struct with a class. In C++ they decided to make struct a class for some reason, but it's not the same thing at all.

 

[Burning Bridges]

Not to undermine the importance of this problem, but initialization of global variables is always done explicitly by myself before the start of the program.

A variable that you consider "global" would be for example a configuration setting that is read from a file or a object that remains the same for the entire runtime that is created once before the main loop and then never again.

Btw it is crucial to initialize all your variables in any case because C++ release builds randomly crash if not all variables were initialized. I do not know specifically why but it seems that the compilers all have problems of their own, especially with aggressive optimization flags. Debug builds are much safer in that regard. This goes for all types that are not a basic types. You may only notice this when you have a throughput of 100,000s of objects, in fact I only discovered it when I stress tested a program for entire days, but there is evidence material in the internet.

 

[odrzut]

Btw it is crucial to initialize all your variables in any case because C++ release builds randomly crash if not all variables were initialized. I do not know specifically why but it seems that the compilers all have problems of their own, especially with aggressive optimization flags. Debug builds are much safer in that regard.

That's because debug builds initialize variables to useful values (usually 0) automatically (to make it more likely to crash when you dereference a pointer to 0 because it's outside of your allowed memory instead of a pointer to a random value which is likely to be inside your allowed memory). If your code crashes early you are more likely to find the problem and fix it.

And release builds don't do that by default because initialization takes time and sometimes you don't want that cause C++ is for "real man who know what they do" so the compiler assumes you fixed all memory issues before switching to release build and it's wasted work to initialize the rest of the variables. So your code will work on random uninitialized data and one part of you code will write random stuff in the middle of an array used by another part of the program and it will seem it works for a while and then it will crash in "impossible" ways 10 hours later - good luck guessing why

You can change this behaviour in most compilers with specific flags, but really you should fix your memory issues before compiling in release. I recommend using valgrind or similar memory-checking tools for C++.

As for initialization order - I prefer to specify dependencies rather than the exact order. I wonder why dependency injection is so unpopular in C++ world.

 

[Burning Bridges]

odrzut very well explained

I initialize every pointer to nullptr and also always check for if(!pointer==nullptr)

Otherwise you never know what will happen. There seem to be situations where a program runs and loads 19 documents perfectly and then crash at the 20th, and it would be impossible to catch an error. And in my case they were all related to initializations.

 

[odrzut]

Nah initialization is the easy part. There's also race conditions and problems with freeing memory that is still referenced from other places. Basically manual memory management sucks and each time C++ was changed to add more options to deal with that it just got more complicated and still sucks

It was especially funny when they added smart pointers that broke STL containers

As far as I understand most games right now skip all of that and just allocate object pools upfront and implement their own garbage collection on these pools and instead of pointers pass around indexes into these pools.

 

[Raghar]

What about triangle dependency initialization? Is this also easy part?

 

[Burning Bridges]

Nah initialization is the easy part. There's also race conditions and problems with freeing memory that is still referenced from other places. Basically manual memory management sucks and each time C++ was changed to add more options to deal with that it just got more complicated and still sucks

It was especially funny when they added smart pointers that broke STL containers

As far as I understand most games right now skip all of that and just allocate object pools upfront and implement their own garbage collection on these pools and instead of pointers pass around indexes into these pools.

There are many solutions for the memory problem.

I for example use Qt and all you have to do is include a Q_OBJECT macro and assign a parent. The parent will then take care of reference counting and such.

What you describe sounds like a database for objects. Everyone can implement something like that by storing objects in a Map but if you have lots of objects and access them via the key it's horribly inefficient vs a direct memory pointer. I would be curious how efficient thes pools are with dereferencing the indexes. In fact it sounds like it is making the advantages of C++ obsolete, which is direct memory access.

 

[odrzut]

What about triangle dependency initialization? Is this also easy part?

Well if you have a cycle you gotta break it anyways.

I would be curious how efficient these pools are with dereferencing the indexes. In fact it sounds like it is making the advantages of C++ obsolete, which is direct memory access.

They use arrays not maps, and you're right it's very database-y. It works especially well with ECS and it's usually faster than traditional OOP object graphs, because you have better cache locality. Indexing array that's in cache already is ~1 additional instruction. Dereferencing a pointer to memory that isn't in cache takes ~100 instructions more.

More about these patterns:
https://floooh.github.io/2018/06/17/handles-vs-pointers.html
https://en.wikipedia.org/wiki/Entity_component_system#Characteristics

 

[underground nymph]

Can anybody point me to some article explaining for a newb which languages are currently in use throughout the world and what they are mainly used for?

 

[PorkyThePaladin]

Article? No, too lazy to google it, much like you.

But as a short summary:

Python - the most popular general use language in the world by far, everyone uses it from scientists to mathematicians to scripters to automators, etc. Pros: extremely elegant to work with, tons of libraries for just about anything you might need, excellent frameworks for important stuff. It's just a fun language all around, and very high level, so you can code most stuff without having to delve into low level computer details, and can just focus on your business logic. Cons: since it's interpreted, it's a bit slower than compiled languages like C++. But in most areas, this doesn't matter, since modern hardware is so fast and you only need high speed in niche fields like cutting edge 3D game programming or operating systems. Don't let detractors tell you that Python is slow since some of the highest traffic websites in the world like Instagram run on Python to a large degree, and the Godot game engine uses a Python-like scripting language.

JavaScript - the other super popular language right now, but JS is like the exact opposite of Python, a highly ugly and messed up language to work with. It's popularity is explained simply by necessity: it is the main and pretty much the only scripting language that runs in browsers clientside, so ever since websites have been getting more and more complex and dynamic in 2000s, JS became the language of choice for web development in the absence of viable competition. The bare-bones language is a horror to work with, but they have come up with a lot of higher level frameworks for it over the years, that hide its ugliness to a large degree.

Java - this is still the main language used in heavy duty business applications, although C# has been cutting into its market share for a while. It's very heavy, and although the people in charge have been streamlining it by borrowing convenience features from other languages for decades now, it's still a lot less fun to work with than something like Python/Ruby. Corporations love it due to history (they have a ton of legacy software in Java), tons of libraries, and certain features that make it more idiot-proof than Python for larger projects, like forced typing.

C# - Microsoft's clone of Java, it's even more idiot-proof with lots of convenience features for lesser programmers, optional graphical interfaces for programming, full fledged IDEs and in-built peripheral frameworks. In it's defense though, because of it's relations and easy interfacing with C/C++, it's much better for performance than Java or Python, so this is now the primary language for game development. Unity for example has C# as its scripting language.

The 4 above are the main modern programming languages. Everything else is much more niche or has died out or is in the process of dying out. Ruby for example was quite popular at one time, similar to Python, but basically lost out to Python over the years. C/C++ are super fast but you won't see them outside of very niche areas, because of how difficult they are to work with and how much they lower productivity. FORTRAN and Cobol are ancient and only exist as legacy software. PERL is limited to scripting. LISP and such are very neat languages that never caught on in the real world at scale...

 

[Ysaye]

Generally agree with the above; in my day job I find most scientific and analytic computing stuff is becoming more and more Python focussed, with only the most computationally taxing things being called in stuff built with lower order languages; most "Bigdata" mining stuff I am involved in uses Python.

 

[underground nymph]

No, too lazy to google it, much like you.

Why googling when I have Codex

 

[Jasede]

Life as a mediocre developer:

1% stand-ups
2% writing code
2% writing tests and documentation
15% Google
30% thinking about software architecture
50% playing roguelikes

 

[kepler]

C/C++ are super fast but you won't see them outside of very niche areas

In a context of a game development this is simply not true. First of all C != C++. Second, C++ is still dominant in game dev.

 

[daivin]

C++ is dominant in game engine development, less in game dev (i would say C# for using C++ engine API).

 

[kepler]

C++ is dominant in game engine development, less in game dev (i would say C# for using C++ engine API).

I still would say that UE + big in house engines (and tools, editors, whatever) dwarfs Unity + indie in house engines. There is just more C++ in games then anything else.

Placing C++ in a footnote, next to FORTRAN and Cobol in a game dev thread is just some biased BS.

 

[shywn]

PERL is limited to scripting.

Hmm? So is Python, Ruby, JavaScript.

The thing is, there are a lot of non-compiled languages ("scripting languages") around. They're exceptionally convenient for coding in general but they are often looked down upon because they're a fair bit slower and memory-hungrier than compiled languages; and because your code is visible to all with them.

I honestly can't imagine using a compiled language when a scripting language is enough for the task. But I only write for myself, and not for others.

 

[Rincewind]

I honestly can't imagine using a compiled language when a scripting language is enough for the task.

The old compiled vs scripted fallacy... What if the compiled version of your "script" compiles under 100ms? But it gives you type safety, 50-1000x times the execution speed, and a better designed language overall? If it's not a LISP so you can play with the code freely at runtime, while it's running, probably your scripted language is shit.

Not a hypothetical example; Nim has largely replaced Python for me for small scripts, I can't tolerate that hack of a language anymore. The only value I still see in Python as a tool is the vast, vast amount of useful libraries written for it, and only for that reason when I need a specific library to hack something quickly together I still reach for it.

Btw, Porky's summary is highly debatable, sounds like it's coming from someone who hasn't used high-level languages in a professional capacity and is out of touch with current trends. For the record, I've learned assembly and C/C++ as a kid, then used C/C++, Python, JavaScript, TypeScript, PHP, Ruby, Java, C#, Scala and Kotlin professionally in the last 20 years, and the "suckiness" of Java is grossly overplayed by people who don't quite get its benefits; it's basically an uninformed meme at this point.

JavaScript is rubbish, but very few people still use it directly for anything substantial. E.g. at work the frontend guys use TypeScript, which is a much nicer core language and it transpiles to JavaScript.

But then, who cares about "popularity"? It's like asking what is the most popular movie or book or game genre. Action movies, romance novels, and hidden-object mobile games. Huh, so what? Means nothing if you're a spy movie and adventure game fan and like reading classic literature. In the real world, you won't pick a language based on popularity alone, you pick a niche/industry first, *then* you learn whatever is needed in that industry to do the job well. The most popular languages *per industry* vary wildly.