Which programming language did you choose and why?

[Azdul]

Oob [] is "undefined behaviour".
You don't build reliable software on "undefined behaviours".

There are good reasons why we have undefined behaviors in C++.

If you define what compiler should do for every user error, you're not allowing to use low level hardware implementations - which may differ between platforms. Java floating point numbers come to mind - they're not using hardware FPU on some platforms, because specification says exactly what should happen if user does something stupid.

There are also some compiler optimizations that cannot be used if you want to have consistent behavior for incorrect input or buggy code, or you cannot make reasonable assumption that array will be accessed within bounds.

The C++ philosophy is to allow programmers to use reliable high level algorithms (like those included in <algorithm>) without performance penalty, so they won't be tempted to come up with their own "better" low level solutions. Many people do not agree with that approach, and that's why Java, C#, Go, Rust were invented.

For those that want to know more - presentation from CppCon about undefined behavior in C++, and why C++ ISO committee cannot remove it:

 

[Tramboi]

Oob [] is "undefined behaviour".
You don't build reliable software on "undefined behaviours".

There are good reasons why we have undefined behaviors in C++

Let's check these
And I promise you they're not for reliability.

If you define what compiler should do for every user error, you're not allowing to use low level hardware implementations - which may differ between platforms. Java floating point numbers come to mind - they're not using hardware FPU on some platforms, because specification says exactly what should happen if user does something stupid

Having done lots of fpu determinism-related code, I can assure you that a strict IEEE754 should be very desirable by default, and could be relaxed as a pragma or an opt-in.
Have you got other examples than floating point ?

There are also some compiler optimizations that cannot be used if you want to have consistent behavior for incorrect input or buggy code, or you cannot make reasonable assumption that array will be accessed within bounds.

Lots of people STRONGLY disagree on this.
I've been doing high performance code for decades and I want a safe default, then add optimizations later.
Signed overflow as undefined, having no array bound checking, "(int32_t)v << 32" come to mind immediately.
These people just want to look good in benchmarks. They shouldn't drive planes. Not even the internet.
Rust just does it much better. 0 cost abstractions, safety by default (apart for a few items) and the ability to write unsafe code when you can prove its correctness (or you're adventurous).
Caveat : I don't have 20+ years of Rust experience.

The C++ philosophy is to allow programmers to use reliable high level algorithms (like those included in <algorithm>) without performance penalty, so they won't be tempted to come up with their own "better" low level solutions. Many people do not agree with that approach, and that's why Java, C#, Go, Rust were invented.

This is desirable indeed. Composability is good. Yet we have std::list::sort
And what's bundled in algorithm is only a tiny subset of what you'll need in a big program.
I don't really see how Rust does it in a worse way than C++.

For those that want to know more - presentation from CppCon about undefined behavior in C++, and why C++ ISO committee cannot remove it:

Of course they cannot remove it without hindering everything's performance in the wild.
But they're not even trying. Tey they break things when it suits them (std::function allocator disappearing in c++17/c++20 for instance).
Btw the video says the std library should use ssize_t everywhere and not size_t. I disagree with this, but you can't defend the video and C++ on this topic for instance


Edit/PS: I was young and reckless too, but now I'm convinced you can't trust programmers with C and C++ for important/reliable/safe code.

 

[Twiglard]

Btw the video says the std library should use ssize_t everywhere and not size_t.

Just use unsigned unless the thing could possibly use more than 2^31 elements.

 

[Tramboi]

Just use unsigned unless the thing could possibly use more than 2^31 elements.

But then you've got interop trouble with the standard library and size_t -> unsigned casts, with the aforementionned warnings.
You can never win with this language

 

[Azdul]

Have you got other examples than floating point ?

At some point designers decided that java.util.Vector and POSIX putc / getc should be thread safe - because data races lead to random bugs, performance is not everything and after all computers are getting faster all the time.

Generics are another case when making something idiot-proof severely underestimated how creative idiots can be. Once they've released generics with type erasure, they can't put that genie back in the bottle.

Rust is still too young to provide similar stories, but I see a lot of potential in 'fearless concurrency' design.

 

[Tramboi]

Have you got other examples than floating point ?

At some point designers decided that java.util.Vector and POSIX putc / getc should be thread safe - because data races lead to random bugs, performance is not everything and after all computers are getting faster all the time.

And C++11 decided that suddenly, static at function scopes were thread-safe too.
putc and getc is IO, and slow IO at that, so correctness is more important than performance.
I agree that thread-safety is useless for the default containers because you don't build parallel programs from this.
Rust borrow checker is helpful for this, though. As you note later

Rust is still too young to provide similar stories, but I see a lot of potential in 'fearless concurrency' design.

Yes, designing correct programs with parallelism is an open problem. No type system that we know of is sufficient for this. We need good design, proofs, testing is hard and refactoring is scary.
Rust is a nice step in this direction.

 

[Rincewind]

Yes, designing correct programs with parallelism is an open problem. No type system that we know of is sufficient for this. We need good design, proofs, testing is hard and refactoring is scary.

Dunno, there are various ways to do that, and they don't necessarily have that much to do with the type system. E.g. if data sharing is impossible between threads (e.g. no pointers, no shared heap) and threads can only communicate only via messaging (where the messages are always copied and contain no references), then you can rule out a large set of problems. And this is basically what actor systems do in languages like Erlang. Of course, you might suddenly just have introduce other problems, like how to work on large datasets concurrently in an efficient manner. But then, you might lose "absolute performance", but you gain scalability and correctness. Scalability is rarely about getting the absolute "best" performance on a single node, there might be "inefficiencies", but the system scales up nicely.

Then a large number of problems just cannot be parallelised easily or meaningfully. So instead or partitioning a single problem into N parallel substasks, you might call it a day and don't even bother; you can just write a single threaded implementation instead and execute N tasks as separate programs/processes, etc.

What my point is, you don't really have to solve the parallelisation problem in general for all existing things to be able to write useful programs. There are things that are easy to parallelise and you get it almost for free (e.g. ray tracers), there's also some well defined problems that we already have best practices for (e.g. loading stuff in a background thread while the main thread is rendering the UI or whatever), and probably that's good enough?

I've read about software transactional memory (STM) in Clojure, but I've never used the language myself. I'd be curious how that would stack up against other solutions.

 

[Rincewind]

Then there are guys like that swedish fat boy (when I see his face I want to punch it so hard his funny hat flies off and then I want to trample that hat to the ground) who coded Minecraft with crappiest language ever Java. Now he never has to work again and is probably getting his balls sucked dry by a russian escort lady while we talk about programming languages.

You could've just said that you're jealous

 

[Burning Bridges]

Then a large number of problems just cannot be parallelised easily or meaningfully. So instead or partitioning a single problem into N parallel substasks, you might call it a day and don't even bother; you can just write a single threaded implementation instead and execute N tasks as separate programs/processes, etc.

This is how we already do it actually. Instead of re-implementing our software to use 4 or more cores we just open 4 datasets at once and let them run at the same time

I am kidding of course but the problem is indeed very hard. You cannot simply split most problems for multi CPUs and the payoff is not clear. Because it's such a can of worms people usually just stick with what they have und understand and allow for a bit more time. Normally there is no real need and real scientific calculations are already parallelized and run on completely different hardware.

 

[Gastrick]

I chose C# because that's Unity uses. Unfortunately the C++ in Unreal is done with wires and boxes or at least the tutorials expect you to program that way. C# works well still in unity because you are able to destruct objects through the Unity GUI. The worst part about the language is that the functions are longer than 9 letters where you get monsters like "Image.alphaHitTestMinimumThreshold". They really didn't make these with real text-editors in mind like Vim and Emacs.

 

[Catacombs]

They really didn't make these with real text-editors in mind like Vim and Emacs.

 

[Twiglard]

They really didn't make these with real text-editors in mind like Vim and Emacs.

Say what you want, but Emacs now has semantic analysis and clangd. No way I'm going back to it though. CUA good enough for me.

 

[Catacombs]

They really didn't make these with real text-editors in mind like Vim and Emacs.

Say what you want, but Emacs now has semantic analysis and clangd. No way I'm going back to it though. CUA good enough for me.

The smug wasn't meant to be negative. Real men use Emacs/vim.

 

[Gastrick]

Catacombs
Yeah, this'll apply to vim as well but emacs is the best because you can modify it to do pretty much anything. It's also more efficient to use because the shortcut keys make it so that you don't need to use your mouse or the arrow keys. They definitely earned their titles as the most prestigious text-editors.
Twiglard
Interesting to hear about clangd, I'll have to install it. What does semantic analysis do? Googling it didn't find any good explanations.

 

[Twiglard]

What does semantic analysis do? Googling it didn't find any good explanations.

Things like understanding where an identifier is used based on more than regular expressions, cross-referencing usages and identifier origin.

clangd is for warnings and CLion has a good implementation. Qt Creator has an extremely shitty and slow one though.

 

[Gastrick]

What does semantic analysis do? Googling it didn't find any good explanations.

Things like understanding where an identifier is used based on more than regular expressions, cross-referencing usages and identifier origin.

clangd is for warnings and CLion has a good implementation. Qt Creator has an extremely shitty and slow one though.

I see.

 

[Krice]

I still believe game devs should stop thinking about some details of a language and also stop comparing them to another one. Programming language is just another roadblock you have to get over somehow and the best way to do it is keep things simple. If you have to focus on language features it just shows you don't know what the point is. That's why so few people get anything remarkable done in game design.

 

[Twiglard]

I still believe game devs should stop thinking about some details of a language and also stop comparing them to another one. Programming language is just another roadblock you have to get over somehow and the best way to do it is keep things simple.

Sure, until you start using partial template specialization. Then you don't want to go back.

That's why so few people get anything remarkable done in game design.

Also, automatic memory management is useless in gamedev. You just can't go wrong with C++.

 

[Tramboi]

Also, automatic memory management is useless in gamedev. You just can't go wrong with C++.

Game scripting should be as HLE as it can. Because you won't have only programmers meddling with this.
Edit: In a big game engine of course, you can do Elite on a BBC Micro with magic nd love

 

[Catacombs]

Yeah, this'll apply to vim as well but emacs is the best because you can modify it to do pretty much anything. It's also more efficient to use because the shortcut keys make it so that you don't need to use your mouse or the arrow keys. They definitely earned their titles as the most prestigious text-editors.

I agree. I switched from vim to Emacs for all my text editing needs years and years ago, and I still love it.

 

[PrettyDeadman]

Does anyone really use vanilla emacs anymore? I am pretty sure evilmode is default for both space emacs and doom emacs anyway, so its basically vim in terms of hotkeys and stuff.

 

[Catacombs]

Does anyone really use vanilla emacs anymore?

Yes. I moved from vim to Doom Emacs and used that for a while. Over time, I couldn't get certain things working and much of the help online deals with vanilla. I eventually nuked Doom and built my current configuration from scratch. The experience was a little painful -- understandin hooks, elisp syntax, mysterious error messages -- but I got much more out of it and don't have to worry about someone else injecting buggy code into my build.

Doom and Spacemacs are perfect for vim people who want to dive into Emacs and not deal with the entire configuration.

I am pretty sure evilmode is default for both space emacs and doom emacs anyway, so its basically vim in terms of hotkeys and stuff.

You're correct. In Doom, though, you can switch to vanilla keybindings. But, most of the configuration is built around evil, so there might be some clashes.

 

[Twiglard]

Also, automatic memory management is useless in gamedev. You just can't go wrong with C++.

Game scripting should be as HLE as it can. Because you won't have only programmers meddling with this.
Edit: In a big game engine of course, you can do Elite on a BBC Micro with magic nd love

To emit a frame every 16 ms, you need either refcounting, manual memory management, or JVM. Refcounting isn't suitable for implementing the core code.

Game "engines" are decline, leading to cookie-cutter games and loss of real talent. They're glorified asset import pipelines and game editors but people treat them like as the holy grail.

 

[Tramboi]

Game "engines" are decline, leading to cookie-cutter games and loss of real talent. They're glorified asset import pipelines and game editors but people treat them like as the holy grail.

Id tech 1, SCUMM or ZMachine+ZIL for instance. Glorified asset import pipelines and game editors, too.
I've been a low level tech programmer in gaming for decades and the goal is to give less proficient user abstractions to leverage your fast code and their creativity without them being ASM experts.
Another recent public example from a company nobody (sane) will dispute technical prowess : Naughty Dog having Scheme scripting.

 

[Twiglard]

Id tech 1, SCUMM or ZMachine+ZIL for instance. Glorified asset import pipelines and game editors, too.

The difference is that id did its own tech, unlike modern studios that can't even comprehend the inner workings anything more complex than Wolf3D. It's not that you have to use your own codebase, but being fundamentally incapable is what leads to cookie-cutter 3rd person action-adventure games.

I've been a low level tech programmer in gaming for decades and the goal is to give less proficient user abstractions to leverage your fast code and their creativity without them being ASM experts.

Interesting, you still have use for inline asm? What I read nowadays is mostly intrinsics.

Another recent public example from a company novody will dispute technical prowess : Naughty Dog having Scheme scripting.

GOAL is different than R[567]RS though. Another good dev company is Factorio. I can tell from their dev posts, even though they haven't shared any code.