Which programming language did you choose and why?

[Krice]

I think there is something important missing in new language development. You see all these "better than C++" languages and some of them look ok, but the reason they will never become popular is that they force "linux" style workflow. You know, a text editor with some kind of build system like make. However most serious development is made in IDEs and it was I believe one of the reasons why C++ became so popular, even it does kind of suck as a language. There were popular IDEs like Turbo C++ which made development so much easier. Of course there is VS Code and language extensions, but they don't fix the underlying problem with close integration with the editor and the language. You can see so clearly that language developers come from linux background when they just don't get it.

 

[Twiglard]

You see all these "better than C++" languages and some of them look ok, but the reason they will never become popular is that they force "linux" style workflow. You know, a text editor with some kind of build system like make.

No language without cross-referencing IDE support is worth the time for non-trivial projects. Otherwise just go writing 1k-line self-contained Perl projects.

Languages with GC or reference counting have no chance of competing with C++. Languages without O(1) primitive operations similarly have no chance of competing with C++. They're of a different league.

Just read Bruce Eckel's Thinking in C++ and see how every abstraction has no cost. Then read Kiczales' AMOP and compare. Ironically the latter also has live cross-referencing support since forever. Albeit implemented in a different manner.

 

[Tramboi]

Some abstractions in C++ still have cost in the sense that you can do better in assembly or with simpler idioms, but it really is a sweet spot if you don't care too much for safety (disclaimer : all my embedded professional work is C++).
But, with Common Lisp (and SBCL), you can get near-C++ performance if you need it (with verrrrry ugly Lisp code) AND a dynamic and expressive language.
So if you don't know how to write very fast C++ (which often is quite ugly compared to idiomatic hyper modern C++), I think other languages might be great choices.

tldr: if you're a performance fanatic (like I am most of the time) go for C++. If you need productivity and have to meet deadlines, maybe some nuance is in order

 

[Catacombs]

You see all these "better than C++" languages and some of them look ok, but the reason they will never become popular is that they force "linux" style workflow. You know, a text editor with some kind of build system like make.

I love using make and Emacs. So, I guess I won't make it.

 

[dippy]

Here's another one for you: https://dascript.org/
It's developed and used by Gaijin Entertainment (mainly known for War Thunder and more).
Feels like Python with static types that can be compiled to C++14 for amazing speed. It's already got online sandbox to play around with and a VS Code extension.

Something for all your guys, tortured by the stalled GC and wasted SIMD units cycles nightmares.

 

[Rincewind]

Languages with GC or reference counting have no chance of competing with C++. Languages without O(1) primitive operations similarly have no chance of competing with C++. They're of a different league.

Define "competing". If you're talking about pure raw speed, there's still better options. If you start including other criteria, C++ starts to be become quite far down the list.

Also, there's much more to programming than relatively simple number crunching in tight loops (not disagreeing manual control over memory can be useful in those situations though, but this is a quite narrow and restricted definition of what a useful program would do). Certain higher-level programming concepts, such as closures kind of necessitate automatic memory management, otherwise they can become an unmanageable mess (closures, by the way, have managed to creep into C++, although in a much simplified form, most likely because of the restrictions of manual memory management). Similarly, various functional programming techniques would become very cumbersome if you had to deal with the extra complexity of managing memory by hand.

And remember, it's abstractions all the way down. CPUs and assembly language are abstractions too. You could go and program FPGAs directly for ultimate speed instead of using some general purpose CPU. But really, what everybody is looking for is the correct effort/benefit ratio for the task at hand. C++ (or anything else), can be a good fit for that, or a horrible fit (and, I'd argue, for most programming tasks, it's a horrible one).

 

[Krice]

Some programmers like the added challenge to use some ancient text editor with a separate build system, but I hate that kind of stuff. Sometimes even installing and using the language can be much more difficult than it should be. It's often small things that make the difference. Not only between languages, but also IDEs. For years I've begged Code::Blocks developers to add the "mini version" of source code as sidebar. I think they finally did something like it, but it doesn't work like in Visual Studio where you can also see errors etc. as color dots. When you have that it makes programming much easier, especially when working with legacy source code that can have bunch of errors per file.

 

[Hag]

I am back to game development for the first time in years. Decided to roll with C, since I already knew it a little and I like its kind of minimalism. I am the kind of guy who doesn't like IDEs and automated stuff, I like my tools to be as light and fast as possible so I can ease my life myself. Not even using syntax coloring since I realized a few years ago it did not improve my coding quality (nor pleasure). The idea is to be forced to write clear and readable code, to discard as much boilerplate as possible, to go bare bones, learn a lot, and try to write code good enough to build on without hassle.

So far so good, but I'm only doing some basic shit. Curious to see how it will unravel when I add a few thousands lines of code.

 

[Catacombs]

So far so good, but I'm only doing some basic shit. Curious to see how it will unravel when I add a few thousands lines of code.

I'd be curious to read some source code, if you wouldn't mind sharing.

 

[Rincewind]

For people who think C is simple, easy, well-designed or minimal (it might appear so in the beginning, I'll give you that).

https://www.radford.edu/ibarland/Manifestoes/whyC++isBad.shtml

TL;DR - It's some sloppy crap that got the job done, and still kind of does, and we're mostly stuck with it because of inertia (half the world is written in C). But it doesn't make it good or desirable (same with JavaScript; you gotta use if if you develop dynamic webpages, but that still doesn't change the fact that it's shit).

Also: I used to like it when I didn't know better. So really, you need to get familiar with better languages first to realise why it's shit, then you can make an informed decision what to use.

 

[Krice]

People who talk about how bad C/C++ is don't seem to understand they are talking about bad programming, not the language. In fact most language descriptions and concepts are perfect in theory. In C/C++ case the actual problem is that the language does little to prevent bad programming and not surprisingly this is the aspect that many modern languages have. They simply prevent dumb programmers making the mistakes they would otherwise make even with that modern language.

 

[Hag]

For people who think C is simple, easy, well-designed or minimal (it might appear so in the beginning, I'll give you that).

https://www.radford.edu/ibarland/Manifestoes/whyC++isBad.shtml

TL;DR - It's some sloppy crap that got the job done, and still kind of does, and we're mostly stuck with it because of inertia (half the world is written in C). But it doesn't make it good or desirable (same with JavaScript; you gotta use if if you develop dynamic webpages, but that still doesn't change the fact that it's shit).

Also: I used to like it when I didn't know better. So really, you need to get familiar with better languages first to realise why it's shit, then you can make an informed decision what to use.

Interesting read, but while I agree on many points, I would have liked the author to give examples of good computer languages.
According to my experiences in a dozen or so languages, in the end of the day every one of them can be a sloppy nightmare and none stops you from writing bad code. C being more straightforward than most, and C++ a candy factory of everything that can possibly go wrong.

 

[Ysaye]

For people who think C is simple, easy, well-designed or minimal (it might appear so in the beginning, I'll give you that).

https://www.radford.edu/ibarland/Manifestoes/whyC++isBad.shtml

TL;DR - It's some sloppy crap that got the job done, and still kind of does, and we're mostly stuck with it because of inertia (half the world is written in C). But it doesn't make it good or desirable (same with JavaScript; you gotta use if if you develop dynamic webpages, but that still doesn't change the fact that it's shit).

Also: I used to like it when I didn't know better. So really, you need to get familiar with better languages first to realise why it's shit, then you can make an informed decision what to use.

Interesting read, but while I agree on many points, I would have liked the author to give examples of good computer languages.
According to my experiences in a dozen or so languages, in the end of the day every one of them can be a sloppy nightmare and none stops you from writing bad code. C being more straightforward than most, and C++ a candy factory of everything that can possibly go wrong.

My old CS lecturer used to say that using C++ is like using a shotgun to cut your toe-nails; quick and effective, but you have to be careful with your aim.

 

[Catacombs]

C++ is like using a shotgun to cut your toe-nails; quick and effective, but you have to be careful with your aim.

No matter where you aim, in relation to your toenail, you'll still blow the toe off

 

[Tramboi]

People who talk about how bad C/C++ is don't seem to understand they are talking about bad programming, not the language. In fact most language descriptions and concepts are perfect in theory. In C/C++ case the actual problem is that the language does little to prevent bad programming and not surprisingly this is the aspect that many modern languages have. They simply prevent dumb programmers making the mistakes they would otherwise make even with that modern language.

I think lots of brillant people precisely understand this and that's why they advocate for safer languages.
The mere fact you wrote "dumb programmers" proves that you don't know much about safety and security in programming.

 

[Rincewind]

I think lots of brillant people precisely understand this and that's why they advocate for safer languages.
The mere fact you wrote "dumb programmers" proves that you don't know much about safety and security in programming.

This.

Don't want to appear condescending to anyone here, but you really have to use different languages for prolonged periods of time, preferably on production code, and preferably in teams. That will teach you a lot about a given language. It's harder to see the advantages/disadvantages of a language if you've only ever used it in hobby projects, under no time pressure, and basically as the only maintainer of the codebase. Reading a few tutorials about the basic syntax and writing a few toy examples doesn't really teach you to feel a particular language (it's a bit like reading the rules of chess; well, it takes less than 10 minutes, still it won't make you a master).

Sure, you can use C for "everything"... like you can write a LISP in it Still, it's a bit like building a castle out of toothpicks, but sometimes it's necessary. Think of it like this: if walking barefoot is the only mode of transport that you know, then riding on a horse carriage might seem the best thing ever to you. But what if you learned teleportation and dimension jumping first? Well, then that horse carriage doesn't seem like the "ultimate upgrade" from barefoot walking anymore...

I'd say knowing C is all good and well, but that's really the walking barefoot category. Go and learn something really high-level that has GC, closures, support for functional style, and preferably a nice standard library that has nice collections. Some LISP/Scheme is preferable (that's definitely the dimension jumping category), or Scala or Kotlin if you don't mind the JVM. Use it for a while in non-trivial projects, then go back to language X (like C) and compare your experience.

If you just want a "better C", even Nim, Go, Rust or D can teach you some interesting things, but it's really best to go for the most advanced languages first for educational purposes and to expand your worldview, in my opinion.

 

[Krice]

The mere fact you wrote "dumb programmers" proves that you don't know much about safety and security in programming.

I think you are trying to sidetrack the discussion, sir. Security is a large topic and not often connected to game programming, at least the old fashion offline programming I'm representing. Bad programming in C++ context is (mostly) using "esoteric" stuff just for funsies. I never liked it, because why would you write code like that? I like simplest possible code I can read myself after months or even years. For example in C++ when done properly pointers are mostly safe, because they become more like a handle of an object than anything else, surely not anything esoteric like in C with pointer arithmetics.

 

[Tramboi]

The mere fact you wrote "dumb programmers" proves that you don't know much about safety and security in programming.

I think you are trying to sidetrack the discussion, sir.

I was not trying to
Game programming is a special case of programming.

 

[Rincewind]

Security is a large topic and not often connected to game programming, at least the old fashion offline programming I'm representing.

It depends. Security can be very much an issue for server-based games. The same issues might apply as to server based computing in general.

If we're also talking about safety of a program (i.e. random crashes because of programming errors), well, no one wants their game to crash either because of accessing already freed memory, or writing past the end of a buffer or something. Unsafe languages make it super easy for you to shoot yourself in the foot. Tools like valgrind exist for a reason, not just because some C coders are "dumb".

I've worked as a pro C dev for a while, and believe me, maintaining 1 million+ line C codebases is very far from my idea of fun. Of course, you can always try to be "careful"... but there's a limit of how well you can do that as a human in complex programs.

 

[Davaris]

Good and bad programmers really do exist.
These days they are trying to make computer languages for bad programmers, instead of good programmers, because good programmers are few in number and expensive to hire, while bad programmers are plentiful and cheap. Unfortunately all the software they make with these languages runs slow, and isn't fun to use. So SAD!

If you want software that feels good to use, you need something with immediate response time. They did studies on this in the 1980s, back when companies cared about being the best, and proved that users get addicted to software that responds below a certain number of milliseconds. They are not reaching these numbers with modern software and it feels bad using it.


If you want to see a nice C code base check out OpenBSD. You can learn a lot studying it.

IDEs are crap. Here's why. They are slow and buggy, and their features stop working if you don't use the normie workflow, which is very slow to compile. They don't work on all platforms, so if you switch to a new platform you have to learn a new IDE from scratch, so your productivity drops to beginner level.

All you need is a good text editor that works on all platforms so you will be fast no matter what. You also need a good debugger. This is much harder. RemedeyBG is a good one if you are on Windows so I hear.

Having to fiddle around with make files sucks. They should have fixed that 40 years ago. Make C build itself using C.

There are languages being built that are trying to fix the problems with C/C++: Jai, Odin, Zig. I think the C devs have noticed what they are doing and may respond.

To me a good replacement for C would be something that is simple to learn but has all the control and run time speed of C/C++. It is frictionless to program with so you are very productive, compiles instantly, its build system is internal, in the same language, and also simple. Something like that would be fun to use.

 

[Tramboi]

If you want to see a nice C code base check out OpenBSD. You can learn a lot studying it.

Sure but you have to admit the C skill in OpenBSD kernel is not representative, we're talking serious elite level. And they still have CVEs

To me a good replacement for C would be something that is simple to learn but has all the control and run time speed of C/C++. It is frictionless to program with so you are very productive, compiles instantly, its build system is internal, in the same language, and also simple. Something like that would be fun to use.

Ada did most of this in the 80es except for the fun part. That's the issue with programmers. We want fun more than correctness, in general. The users beg to differ

 

[Tramboi]

And by the way, some people argue about the need for tool-driven memory safety. Ok. It certainly is feasible to write simple code without some classes memory errors (but it takes lots and lots of time and care). Use after free are notoriously tricky in complex scenarios.
But I've yet to see confident multithread programmers in C or C++ (I'm certainly not one of them, and I use paralellism on a regular basis).

 

[Davaris]

I've seen OpenBSD devs telling just starting out C programmers to learn from their code base. Because why would you want to learn from shit programmers?

Ada was made for the military wasn't it? They designed Ada because the defense contractors were inventing their own languages as a scam, to make themselves unfireable.

Rust was designed with safety in mind. I saw a game programmer discussing it on Youtube. He tried it for 6 months and said all the friction wasn't worth the trouble of finding three bugs. I noticed the company that makes Firefox is close to bankruptcy. They fired all their Rust staff and their browser is a bloated and feels bad to use like all modern corporate software.

The fellow that is making Jai said as a game developer, he was perpetually on the edge of bankruptcy because of the friction in C++. Just 5% here or there and he would be in the gutter. He is attempting all of what I suggested.

OpenBSD detects use after free. Memory managed languages do poorly on it, while C programs written by devs who knew what they were doing run extremely well.

Check out the Data Oriented Design book for help with parallelism. It is free online.

I saw this joke advice from a C programmer on Twitter. He said, C is not that hard. You just have not be a fuck up.

 

[Tramboi]

I've seen OpenBSD devs telling just starting out C programmers to learn from their code base. Because why would you want to learn from shit programmers?

Sure, I just don't meet a lot of OpenBSD-level C programmers in the wild.

Rust was designed with safety in mind. I saw a game programmer discussing it on Youtube. He tried it for 6 months and said all the friction wasn't worth the trouble of finding three bugs.

Yet finding 3 more bugs in a browser or SSL implementation is valuable. No more heartbleed please.

OpenBSD detects use after free.

No. OpenBSD catches *some* "use after free" (or "double free") instances. It's mitigation.

Check out the Data Oriented Design book for help with parallelism. It is free online.

Thanks but the world of parallelism is much wider than this

 

[Davaris]

The Object Oriented Design book is for *games*.

Your browsers are so big and slow I don't want to use them any more. I would use something far simpler and safer, but the Internet has been broken by bloat programmers.

OpenBSD's mitigations are running all the time. Users will find the bugs faster than one programmer.

Also Rust has no spec:

C has a spec. No spec means there’s nothing keeping rustc honest. Any behavior it exhibits could change tomorrow. Some weird thing it does could be a feature or a bug. There’s no way to know until your code breaks. That they can’t slow down to pin down exactly what defines Rust is also indicative of an immature language.

https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html