-
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Which programming language did you choose and why?
- Thread starter Destroid
- Start date
- Joined
- May 30, 2021
- Messages
- 461
I chose C++ because it lets me do real men's coding while also being able to target real men's type "of modern" games.
C++ has issues with boilerplate setup, having to do header include guards, and much of STL seems like a big red herring whenever I code. Hey I wonder if the STL was meant to address the boilerplate issue?
Anyway I view it as superior to C for modern development, but inferior for older development.
Let's talk Memory Management though.
Boilerplate wise: often the need for a custom allocator or manager of heap allocated objects comes up. I don't mean a garbage collector, I mean a custom interface for tracking and removing what you no longer need on the fly.
To be resorting to heap allocation of objects is usually because passing around a pointer to an object has superior flexibility. Not in every case, but it comes up super often if you given any thought to performance
or to what happens if your vector stores non-pointers. Also you can set pointers to nullptr, references you have to set to a dummy object, which would need some indication that it's the dummy object making for annoying extra state definition.
To elaborate on choices:
You may say you can just global declare some non-heap allocated objects or create them intitially on a stack within some factory function which you then pass to a vector to hold them as pointers.
Having two buffers buys you the effect that if you erase an element it's you can avoid pointers to members changing.
This may work but it includes an extra layer of bullshit just to setup managing one group of objects (assuming templates aren't involved). This also has the inflexiblity that you must know how many objects ahead of time
you might need. And if you can know that, you probably don't need memory management at all.
Anyway the gain of not using new, and instead this extra layers of trickery, you avoid having to call delete[].
But to pull it off it's worse than having two buffers actually, because you want reusability. Meaning the buffer that stores the pointers is going to change even if the other doesn't. Else you're admitting pointers are all the same and even the object they point to never change when reused.
One wonders why not just do one big heap allocation? Well that's not memory management, that's just having memory allocated.
TL;DR There's usually a guaranteed boiler plate if you want real memory management. It's not fun. You'll need to make your own containers which probably uses templates or worse STL.
So how does a C programmer avoid that? First objects are far less important. There's no things with member functions. What you really have is just bundles of data that live somewhere. That's not to say abstraction isn't used,
it's just not a construct of the language.
All this leads to the following statement:
“C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.”
― Bjarne Stroustrup
To translate in C you deal with the issues you cause as you cause them. In C++ you can pickup some gains but you also can abstract yourself through the language to not see a fatal issue.
Well big fucking deal right? Life goes on? I guess.
Getting away from debug issues, consider if classes (abstract objects) are actually abstracting too much. What if focusing on how to setup classes takes away from actually tackling your problem directly?
The claim here is obsessing over what tools you have or don't have in object form, gets in a way of much simpler solution. "I have a this task I need a this object." That kind of problem.
From an engineering point of view it makes sense to ponder what tools are right for the job. But the job and the tool are far less risky to become synonymous when things are less abstract.
TBH C++ is dangerous because you can drink your own koolaid and enlist in an class-object ecosystem that just makes things harder to design and not a superior product that it might otherwise be.
TBF, there is a time and a place for one to take seriously their own eco-system. i give you this url for what iD did:
https://cppdepend.com/blog/?p=744
"1 – Provides a common base class with useful services.
Many classes inherit from the idClass"
Having excess ways of doing things leads to another common criticism of C++. Too many ways to do things. Apparently every facet has universal turing machine property about it.
Including the generic stuff like templates.
C++ has issues with boilerplate setup, having to do header include guards, and much of STL seems like a big red herring whenever I code. Hey I wonder if the STL was meant to address the boilerplate issue?
Anyway I view it as superior to C for modern development, but inferior for older development.
Let's talk Memory Management though.
Boilerplate wise: often the need for a custom allocator or manager of heap allocated objects comes up. I don't mean a garbage collector, I mean a custom interface for tracking and removing what you no longer need on the fly.
To be resorting to heap allocation of objects is usually because passing around a pointer to an object has superior flexibility. Not in every case, but it comes up super often if you given any thought to performance
or to what happens if your vector stores non-pointers. Also you can set pointers to nullptr, references you have to set to a dummy object, which would need some indication that it's the dummy object making for annoying extra state definition.
To elaborate on choices:
You may say you can just global declare some non-heap allocated objects or create them intitially on a stack within some factory function which you then pass to a vector to hold them as pointers.
Having two buffers buys you the effect that if you erase an element it's you can avoid pointers to members changing.
This may work but it includes an extra layer of bullshit just to setup managing one group of objects (assuming templates aren't involved). This also has the inflexiblity that you must know how many objects ahead of time
you might need. And if you can know that, you probably don't need memory management at all.
Anyway the gain of not using new, and instead this extra layers of trickery, you avoid having to call delete[].
But to pull it off it's worse than having two buffers actually, because you want reusability. Meaning the buffer that stores the pointers is going to change even if the other doesn't. Else you're admitting pointers are all the same and even the object they point to never change when reused.
One wonders why not just do one big heap allocation? Well that's not memory management, that's just having memory allocated.
TL;DR There's usually a guaranteed boiler plate if you want real memory management. It's not fun. You'll need to make your own containers which probably uses templates or worse STL.
So how does a C programmer avoid that? First objects are far less important. There's no things with member functions. What you really have is just bundles of data that live somewhere. That's not to say abstraction isn't used,
it's just not a construct of the language.
All this leads to the following statement:
“C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.”
― Bjarne Stroustrup
To translate in C you deal with the issues you cause as you cause them. In C++ you can pickup some gains but you also can abstract yourself through the language to not see a fatal issue.
Well big fucking deal right? Life goes on? I guess.
Getting away from debug issues, consider if classes (abstract objects) are actually abstracting too much. What if focusing on how to setup classes takes away from actually tackling your problem directly?
The claim here is obsessing over what tools you have or don't have in object form, gets in a way of much simpler solution. "I have a this task I need a this object." That kind of problem.
From an engineering point of view it makes sense to ponder what tools are right for the job. But the job and the tool are far less risky to become synonymous when things are less abstract.
TBH C++ is dangerous because you can drink your own koolaid and enlist in an class-object ecosystem that just makes things harder to design and not a superior product that it might otherwise be.
TBF, there is a time and a place for one to take seriously their own eco-system. i give you this url for what iD did:
https://cppdepend.com/blog/?p=744
"1 – Provides a common base class with useful services.
Many classes inherit from the idClass"
Having excess ways of doing things leads to another common criticism of C++. Too many ways to do things. Apparently every facet has universal turing machine property about it.
Including the generic stuff like templates.
Last edited:
Not much. Basic bullet point listing with no real regard for game development matters, written by someone who has probably never tried any of them. The Java paragraph doesn't make sense, and the fact that the discontinued ActionScript is included in a 2021 article sums up how little the author know about this subject.
If you really need help to choose a programming language, use Racket.
If you really need help to choose a programming language, use Racket.
Are you serious? An "article" written by someone who knows neither English, nor programming...
Plus the image on top shows a screenshot of some PHP code interacting with MySQL. What does that have to do with game programming? WTF?
Krice
Arcane
- Joined
- May 29, 2010
- Messages
- 1,649
Would be interesting to know what you are trying to do, because it sounds complicated. Memory management in C++ is not difficult, although creating error correcting allocations might be. Most of the problems you ever had with memory management can be tackled with container/ownership guideline.
- Joined
- Aug 10, 2017
- Messages
- 6,158
What? You don't consider oneangrygamer a definitive source for game development news and resource?
Rewrite
Latest Doxxer Account
- Joined
- May 25, 2021
- Messages
- 91
I love C and this is bullshit. Win98 used to BSOD from fucking userspace for funz. Any app you ran, could blue screen you.
Shit was crashing left and right and UB was raping memory like it owns the place.
Today, nothing is collapsing while on fire - but it is slow and managed and '''expressive'''. Apps run in a JIT in a JIT in a VM in a VM on a CPU with a javascript instruction. And thats not an exaggeration. But they dont bring down your phone ...mostly.
Good old times, today!:
[$TBD][1197146] High CVE-2021-30524: Use after free in TabStrip. Reported by David Erceg on 2021-04-08
-> opening and closing new tabs on Chrome can kill you!
"""People""" like this though, you know them from the interwebz flamewars, they have never written 11 lines of asm in any dialect - they are full of shit on any subject. They dont even know why oldhats compared C to an assembler. Otherwise C and assembler would never be in the same sentence.
All this language warfare has always been ultimately about convenience, builtins, libs. Its not about '''ideas''' and '''expression''' and '''powerful'''.
Its not like the LISP interpreter runs on some alien quantum hexa-state quasi-analog magic machine.
Its about the stuff that has already been written for you and how easy it is to use.
Python lists are not lists, they are hashtable objects.
Lua's tables are hashtables.
Exceptions are error codes with some extra data but hidden from you.
Callbacks, coroutines, threads and virtual methods are just functions.
Compile time generics are just code deduplication roffles!
Have you ever seen a decent C library? Oh no! How possibly could they have written it, dealt with all the complexity without inheritance and polymorphism?!
lib_do_stuff1(), lib_getx(), _private_dont_uselel()!
You shift those bits over the register limits and explode cum all over your memory ...somewhere down the line - it will be our little secret!
I love C
I also hate Rust. I'd rather write fucking Java or .Net or God forbid start reading C++ error messages but fuck Rust.
Rewrite
Latest Doxxer Account
- Joined
- May 25, 2021
- Messages
- 91
Isnt C beautiful???
ls->all_time_high = ts ? ts->max : 0;
https://github.com/redis/redis/blob/unstable/src/latency.c#L182
ls->all_time_high = ts ? ts->max : 0;
https://github.com/redis/redis/blob/unstable/src/latency.c#L182
Well, Symbolics and LMI did. They even had the GC implemented in microcode. The C runtime didn't allow pointers beyond the length of an array, since everything non-Lisp related was an afterthought on these architectures. As a tradeoff, you've had hardware tagged pointers and the like.
To be fair, maintaining polymorphism with structs of pointers is hard once beyond a single level of inheritance.
Generics don't do monomorphization. Which makes them useless for any serious abstraction or compile-time shenanigans.
You didn't mention any features from strongly-typed academic and research languages. That's where any progress has been in the recent decade. The only good idea taken from Lisp was the REPL. Macros aren't powerful enough due to not being able to reason about the nature of the subexpressions passed to it.
Rewrite
Latest Doxxer Account
- Joined
- May 25, 2021
- Messages
- 91
Wow, didnt know that.
https://www.gwern.net/docs/cs/1987-baker.pdf
Though it looks just like any other CPU and the only Lisp related shit I find is this:
"Hardware included for testing includes scan-out registers on the microcode ROM and real time observation of the micro program counter. All hardware defined registers are accessible from high level language primitives. The microcode ROM may be checksummed via the scan-out path while run. ning Lisp."
Considering the short list of primitives here:
https://ccrma.stanford.edu/courses/124/resources/Basic Lisp Primitives.htm
Its not really impressive (or interesting even) for 87 from a hardware perspective...
I actually meant that people dont even try, they just name functions differently and cleanly. Its hard work.
There is not even need for simple namespacing like "pythonic" requests.get() if you have dumb naming rq_get()
I'm not even touching super abstract bullshit like a abstract factory superclasses (heh) constructing factories.
No one will ever convince me that it improves readability, reduces complexity or has any fucking positive effect.
"They" always preach it being extendable and I dont believe it for a second. In a real codebase that already has some
complicated inheritance structure, you'd first have to grok the full chain, make sure its not fucked up and then try
not to fuck it up more. I'd rather manage global state and carry data overhead around.
Its because I have no idea about them. But in my not so humble opinion, all those academics are a laughable fucking joke.
I have zero respect for these language designers with strong opinions.
You tacked some syntatic sugar onto some abstract data types and your vm/interpreter/compiler shits out valid IR that runs
at the other end? Whoopty fucking doo. Have a medal.
They are like failed mathematicians. Craftsmen pretending to be monocled.
While the whole web runs on a language that reportedly got hacked together in 2 weeks and hipsters
started whacking "extensions" to it and voila ~> Typescript! Very advanced! Such IDEAS and POWERFUL! MUCH WOW
Whole industry is being fed by money from adtech roffles!
I need to learn Rust so I can shit on it convincingly but I dislike the syntax...
Someone ought to make a C++ variant that disallows raw mem access and extend the compiler to reason about ownership,
now that the memory can be assumed to be virgin untouched by dirty programmer hands. Better Rust lul!
Genera Lisp was close to ANSI CL. None of these two links are relevant. The term "primitive" isn't used in that sense. They're talking about cons cells in registers and so on.
That's only for shit languages without template partial specialization, typeclasses or functors. It's easy to bash OOP and other methods of abstraction by the strawman of Java or C#.
How can they be a joke if you have no idea what they do?
rusty_shackleford
Arcane
- Joined
- Jan 14, 2018
- Messages
- 50,754
(((lisp)))
By points, I mean, is it true that C++ is the language often used for big games, C# for small games, Lua for web apps (games?), Obj-C for Android games, etc?
I didn't consider the use of language and the image.
rusty_shackleford
Arcane
- Joined
- Jan 14, 2018
- Messages
- 50,754
no, it's wrong, I don't even have to read it. You use whatever language you're told to use.
If you get to pick the technologies(lead programmer, small team, working solo, etc...) you'll just end up using whatever language the game engine you're using works best with.
It's wrong. If you want to generalise, C++ is used for rendering engines most of the time, C# and Lua for scripting everything else (gameplay mechanics, AI, etc).
At least 50% of his claims are wrong and/or non-sensical. You can infer a lot from the writing style; generally it's a hastily put together, superficial article obviously lacking any personal real-world experience.
Yeah it's the kind of article that's aimed at getting clicks based on SEO*. You get this kind of articles whenever you tried googling "best X" for anything. Don't even need to know much about programming to notice.
*At least that's my guess, considering these articles often shows up above actually useful links on Google
- Joined
- Aug 10, 2017
- Messages
- 6,158
JBlow is working Jai, which, people claim, will be a better C++ for game development.
Is there an article that doesn't state what's the best language or that's not made to get clicks but states which languages are most often used for games and why? Or which game engines are often used and languages that work with them?
Sure there is. Google is your friend
Or read this thread from the beginning, there's lots of useful (but often contradictory) info.
Sure there is. Google is your friend
They also mention C++, C#, Lua, etc.
Ok, here is my take :
There is no perfect language, and usually when you start up a new game project you pick up a language you already know, just because most of them do the job. As an independent developer, you can choose whatever tools you want, so use the one you are comfortable with. I'd say the best are quick prototyping languages with extensive libraries such as Python or Racket, but whatever. As long as you have access to graphics, sound and input libraries, you're good. If you opt for a modern game engine (UE, Unity, etc.) you use the tools and languages bundled with them.
If you work in the industry, then usually you don't get to choose and simply use the same language as your teammates. It is often C++ for historical reasons, because is is kind of retro-compatible with C which used to be the big cheese, but not necessarily because of the quality of the language itself. They probably use also more-or-less known utility languages for scripting (Lua for example) that you don't have to care about unless you work for them.
Now there are some corner cases : if you want to go low level and create your own game engine, manage all the performance and resources yourself, then C or C++ are your best bet. They can be lightning fast and are real jack-of-all-trades, but at the cost of increased complexity, rigidity and many way to fuck up and have weird and difficult to find bugs.
If you want to build a complex IA, for example in RTS games, then go for some language allowing great flexibility and easy writing of algorithms, such as Racket, Common Lisp or OCaml. They are designed to allow you to write code quickly and efficiently without having to deal with overly technical matters such as memory management.
If you are into mobile games, learn Java (for Android) or Swift (for iOS).
I think Java and C# are a bit in the middle of the road as good-enough versatile general purposes languages.
All these language are well-established and field-proven, with active communities. Can't really go wrong with any of them.
There is no perfect language, and usually when you start up a new game project you pick up a language you already know, just because most of them do the job. As an independent developer, you can choose whatever tools you want, so use the one you are comfortable with. I'd say the best are quick prototyping languages with extensive libraries such as Python or Racket, but whatever. As long as you have access to graphics, sound and input libraries, you're good. If you opt for a modern game engine (UE, Unity, etc.) you use the tools and languages bundled with them.
If you work in the industry, then usually you don't get to choose and simply use the same language as your teammates. It is often C++ for historical reasons, because is is kind of retro-compatible with C which used to be the big cheese, but not necessarily because of the quality of the language itself. They probably use also more-or-less known utility languages for scripting (Lua for example) that you don't have to care about unless you work for them.
Now there are some corner cases : if you want to go low level and create your own game engine, manage all the performance and resources yourself, then C or C++ are your best bet. They can be lightning fast and are real jack-of-all-trades, but at the cost of increased complexity, rigidity and many way to fuck up and have weird and difficult to find bugs.
If you want to build a complex IA, for example in RTS games, then go for some language allowing great flexibility and easy writing of algorithms, such as Racket, Common Lisp or OCaml. They are designed to allow you to write code quickly and efficiently without having to deal with overly technical matters such as memory management.
If you are into mobile games, learn Java (for Android) or Swift (for iOS).
I think Java and C# are a bit in the middle of the road as good-enough versatile general purposes languages.
All these language are well-established and field-proven, with active communities. Can't really go wrong with any of them.
As an Amazon Associate, rpgcodex.net earns from qualifying purchases.