Which programming language did you choose and why?

[Rincewind]

Did you read the entire book? I've read people say the first three chapters are good enough.

The more you do, the better. But don't just read, do the exercises, otherwise you will gain just like 20% of the benefits.

 

[Hag]

I don't know why the language would do that, it's more about what the programmer is going to do. If anything C++ teaches you to avoid bad programming the hard way.

While you are right in saying languages are just tools, programming is not easy and doing it well is actually quite difficult. There is real value in simplicity, brevity and getting shit done. When you start you don't know what pattern is useful and what functionnality is to be avoided in 99.9% of the cases. Learning with Python or Racket is great because you will roll out working code quickly, play with it, and then be able to reproduce it in other context or language. In the end I believe that good coding is independant from the language. Good coding is finding the simplest way to change your inputs into your desired output. It's finding the best path from your ideas to the end program. Some languages make it easier than the others, and are thus more suitable for beginners.

I taught myself development with C++ long ago and it took years to learn -the hard and painful way- that you could just develop and enjoy yourself without overthinking every aspect of your program. A valuable lesson I gladly share to prevent others from doing the same mistake.

 

[Rincewind]

If anything C++ teaches you to avoid bad programming the hard way.

I'd say C++ is the ultimate goldmine to pick up horrible habits. The vast multitude of ways how you can shoot yourself in the foot is actually truly impressive, especially for a beginner. But even among pros, teams usually agree on which 20-30% of the language to use, otherwise things quickly devolve into chaos. There's good reason why C++ style guides like this exist.

But maybe you're saying the same thing? I just don't think anybody should be forced to go through that crap unnecessarily, especially if there are other languages that do the job better and with much less pain.

Btw, Tundra is a quite nice example of a well-written codebase in a minimalistic sane subset of C++. If I had to touch C++ ever again, I'd pick a style resembling something like that.

 

[Urthor]

One of the cooler things about the shift to the ultra fucking expensive cloud providers, is that bad programming gets (at least with what I do) a much bigger cloud bill.

It's honestly nothing appreciable vs the paycheque, especially when the employer itself is pretty dumb and will deploy large services with very poorly configured load balancing at the cost of thousands without blinking, but I take pride in how low I keep my cloud bill.

 

[Twiglard]

Anyone here big on the Scala/Haskell train?

I went halfway, to C++. It's easier to implement a type quicksort with C++ than Haskell.

 

[PorkyThePaladin]

There is Python, and then, there is everything else.

 

[J1M]

Anyone here big on the Scala/Haskell train?

Decided I need to do some stuff in a language that doesn't look like my job, and hey the "objects and Java were all a giant mistake" guys seem to have it right.

Functional programming is a solid approach. Thinking you need a purely functional language to get the benefits is not.

 

[J1M]

If anything C++ teaches you to avoid bad programming the hard way.

I'd say C++ is the ultimate goldmine to pick up horrible habits. The vast multitude of ways how you can shoot yourself in the foot is actually truly impressive, especially for a beginner. But even among pros, teams usually agree on which 20-30% of the language to use, otherwise things quickly devolve into chaos. There's good reason why C++ style guides like this exist.

But maybe you're saying the same thing? I just don't think anybody should be forced to go through that crap unnecessarily, especially if there are other languages that do the job better and with much less pain.

Btw, Tundra is a quite nice example of a well-written codebase in a minimalistic sane subset of C++. If I had to touch C++ ever again, I'd pick a style resembling something like that.

Go is basically just one guy enforcing his C++ opinions at the compiler level. Surprisingly it hasn't come up much in this thread. Though it isn't really for games.

 

[Krice]

I couldn't get over the fact that Go compiles everything when you compile. Always. Everything. I think even the libraries are in source code format and it compiles them too. I guess if you have a super computer at Google it works, but it's just not practical with a home computer.

 

[Alpan]

He's writing the game in C++. His videos are interesting, but it'll be a millennia until he finishes the game.

It might as well be C -- of C++ features, he's only using function and operator overloading, not even templates. Anyway, Casey Muratori is more like an engine guy, he has said that he doesn't actually like designing games. So the reason the project has taken as long as it has taken is because he keeps moving the goalposts and adding more features to the engine, and he only programs like 2 hours a week anyway.

I have followed and coded along quite a few of the early episodes and I can confirm it's worth watching, especially the first 30 or so.

The whole discussion about "which programming language to use" is honestly pointless to me, because it indicates that people don't have anything better to do, like work on an actual problem, task, or idea. Best to keep an open mind, be pragmatic and do whatever you need to solve your problem. I will say though, this year due to some RL issues I found myself in a position to answer a similar question -- "if I wanted to exclusively focus on one language, or aspect of programming, what would it be?" and I agree more with Absinthe than Rincewind. If you're serious about programming, a language that programs the actual computer rather than a virtual machine or an interpreter will bring you the greatest benefits, compounded over time. All other choices run the risk of encountering a language issue or performance bottleneck that will require you to figure out what's going on under the hood, so you might as well start there. So I decided on C.

Note that I'm not making a financial appraisal: It's quite likely other languages pay more for less work. And if I had been thinking about the web, maybe the answer above would have been JavaScript or TypeScript (sad as that sounds). This is only a technical/philosophical perspective.

 

[Bad Sector]

I guess if you have a super computer at Google it works, but it's just not practical with a home computer.

Depends on the compiler, if the compiler is fast it is a perfectly fine approach. Though AFAIK Go's compiler isn't that fast, which is weird considering how simple the language is. In comparison, Delphi 2 has a *much* more complex language yet even with optimizations enabled can compile (and link) ~1.7M lines per second on my current PC on a single core - and Delphi 2 itself is written so that it can run even on a 386 PC, meaning it doesn't take advantage of any more recent instructions. A compiler of the same speed that could take advantage of modern multicore PCs and instructions could even compile 10M lines in half a second.

At that level of performance (or actually, even at a tenth of that really), compiling everything from scratch at every build doesn't matter at all.

Though AFAIK Delphi 2 has some performance intensive parts of it in hand written assembly, which isn't something that people tend to do nowadays (but it made sense for it since compilation speed was always a selling point for Borland's compilers).

 

[Tramboi]

Delphi generates very inefficient code though (source : joined a team to work on a major RTS title in Delphi in the past).
Though I don't know if Go code is good

 

[Rincewind]

If you're serious about programming, a language that programs the actual computer rather than a virtual machine or an interpreter will bring you the greatest benefits, compounded over time.

Programming the "actual computer" is a rabbit hole... Even assembly is not exactly what used to be these days (there's lots of magic happening behind the scenes in Intel CPUs, assembly these days is actually more or less a "high level" interface to the underlying CPU; it presents the familiar "x86 facade" to you that you can use, but the real thing at the lowest level is quite a bit different). Same with optimising C compilers, you can't rely on the ordering of instructions etc.

Depends on your goals too. Some basic understanding of how the hardware and the computer works benefits every programmer for sure, but many times you just want to work with higher level abstractions. But ultimately I think going "low level" is a dead end. Might be still necessary these days though... but how many people still code in assembly? It used to be the norm a few decades ago, now it's a lost art for 99% of programmers.

Programming (and everything else in engineering, or just in human-created inventions in general) is a history of abstractions. Nobody cares about controlling the motor of the harddrive anymore these days; you just call fread or whatever and let it do its thing, let the OS cache files into memory behind the scenes, etc. Even as a systems programmer, much of that functionality is an abstraction to you. Sure, rarely you need to go low level, but that's not the norm in general programming these days (which is definitely a good thing).

EDIT: I'm saying "these days" a bit too often these days.

 

[Bad Sector]

Delphi generates very inefficient code though (source : joined a team to work on a major RTS title in Delphi in the past).
Though I don't know if Go code is good

The code is good enough for 99.9% of the uses, as long as your architecture isn't bad you can optimize the slow parts manually (and if your architecture is bad, it'll be bad with a C++ compiler too). Some time ago i wrote a small benchmark that compared some C and Pascal compilers with a simple raytracer and for the same target CPU (32bit 386) Free Pascal and Delphi 2 produced code with about the same performance (Delphi 2 was a tiny bit faster actually). Yet for me Free Pascal's codegen had never been much of an issue, i wrote Post Apocalyptic Petra in it and works ok even with retro hardware (if anything the performance issues i had were all because of the shitty slapped together architecture i had, but the game was made for a jam without any specific performance requirements aside from running a DOS machine :-P).

AFAIK Go's codegen isn't that great either, but i do not know how it compares to Delphi 2's. According to debian benchmark game Go produces slower code than Free Pascal, but that is with explicitly enabling Free Pascal's support for AVX, etc on 64bit CPUs which often almost doubles or triples the performance (see the linked raytracer page), though in practice it rarely makes much of a difference in real programs in my experience.

Personally i think that above a few "obvious" optimizations there are diminishing results and compile times aren't worth it, you can just write better code if needed for the 0.1% cases where you actually need it without having the rest 99.9% of your code "pay" for it with horrible build times and -most insidiously- compiler bugs and/or complexity that come from how a language's quirks affect optimization (see C undefined behavior as an example).

Programming the "actual computer" is a rabbit hole... Even assembly is not exactly what used to be these days (there's lots of magic happening behind the scenes in Intel CPUs, assembly these days is actually more or less a "high level" interface to the underlying CPU; it presents the familiar "x86 facade" to you that you can use, but the real thing at the lowest level is quite a bit different).

Converting x86 assembly to microcodes was a thing even in the mid-90s anyway but that was never really relevant since what you use to program the chip isn't those microcodes but the x86 instruction set - the microcodes are just an implementation detail, the chip itself is programmed in x86. It isn't like in older much simpler chips you work with the semiconductors directly anyway.

 

[Rincewind]

Converting x86 assembly to microcodes was a thing even in the mid-90s anyway but that was never really relevant since what you use to program the chip isn't those microcodes but the x86 instruction set - the microcodes are just an implementation detail, the chip itself is programmed in x86. It isn't like in older much simpler chips you work with the semiconductors directly anyway.

True, I was just trying to illustrate the point that you can't go "all the way down" when you want to hit the bare metal. But good points.

It's similar to the story I bring up with people who want to write every single line of code themselves and never use libraries. "Ok, but you're still using the OS, so why don't you write your own OS, so that you have more control? Better yet, why not design your own CPU? Or why even stop there, why don't you go mine your own silicon? Of course, that's not ultimate enough, you're still using tools built by others for the mining... But what if... " etc It never ends, and ultimately you'll have to rely on others at some point.

 

[Joined on the 4th of July]

Converting x86 assembly to microcodes was a thing even in the mid-90s anyway but that was never really relevant since what you use to program the chip isn't those microcodes but the x86 instruction set - the microcodes are just an implementation detail, the chip itself is programmed in x86. It isn't like in older much simpler chips you work with the semiconductors directly anyway.

True, I was just trying to illustrate the point that you can't go "all the way down" when you want to hit the bare metal. But good points.

It's similar to the story I bring up with people who want to write every single line of code themselves and never use libraries. "Ok, but you're still using the OS, so why don't you write your own OS, so that you have more control? Better yet, why not design your own CPU? Or why even stop there, why don't you go mine your own silicon? Of course, that's not ultimate enough, you're still using tools built by others for the mining... But what if... " etc It never ends, and ultimately you'll have to rely on others at some point.

You can't even control electrons one by one with C, so why even bother? Why not just do your coding by doing shitposts on Codex and use GPT-4 to convert those to executable programs. (It's gonna be like Siege of Dragonspear, but even better.) Maybe some abstraction levels are just about right for many people?

 

[Tramboi]

Delphi generates very inefficient code though (source : joined a team to work on a major RTS title in Delphi in the past).
Though I don't know if Go code is good

The code is good enough for 99.9% of the uses, as long as your architecture isn't bad you can optimize the slow parts manually (and if your architecture is bad, it'll be bad with a C++ compiler too).

Seriously no, Delphi was unable to generate half-decent x87 FPU code and was very bad at inlining. Just porting the code to a C++ compiler was a huge gain (and then doing SIMD).
So I'd agree it's enough provided you don't need to crunch numbers.
And compilation was VERY fast, this was pleasant.

 

[Alpan]

True, I was just trying to illustrate the point that you can't go "all the way down" when you want to hit the bare metal.

Well, no one in this thread is advocating going all the way down. The point is not that all abstraction is bad, or to just keep going down the rabbit hole just because it's there. I think there's a sweet spot, and the case of higher abstraction isn't as strong or a no-brainer as it might appear: Given the size of the software industry and the shitty state of modern software, it is trivial to see that productivity per programmer is at an all-time low.

I do think, given that inline assembly is a thing in C, "inline C" should have been a thing in higher-level languages. But for whatever reason, there is no such thing.

 

[Rincewind]

I think there's a sweet spot, and the case of higher abstraction isn't as strong or a no-brainer as it might appear: Given the size of the software industry and the shitty state of modern software, it is trivial to see that productivity per programmer is at an all-time low.

I disagree, but it's a matter of what you value more: productivity (your time) or ultimate program performance. I'd say for the majority of programming tasks performance is not really a concern with modern hardware, and C is very far from the sweet spot in terms of productivity for general purpose programs. Most people are willing to sacrifice some performance and/or memory footprint for increased productivity. Write anything non-trivial in a high-level language like Scala, Haskell, LISP etc, preferably using functional idioms, then measure how long it takes to do the same thing in C. Generally it will take a lot longer and although it's probably faster, it's usually not worth it (then if you factor in maintenance, fixing bugs, etc, it's really not worth it).

I've done benchmarks a while ago with some simple raytracer I wrote, basically the dead simple naive Java/JavaScript implementation had about the 60% performance of the unoptimised C code, so it's not as slow as most people would think. I'd say for the majority of people that's a non-issue. Of course, if you're willing to spend the time to use vectorisation in C, you can perhaps get a 2-3x speed bump if you're clever. And that's for heavy numerical code. For non numerical code, writing everything in C is most of the time a pointless exercise (ok, there's always special cases/requirements, e.g. if you care about startup time a lot, or smallest possible memory footprint, etc).

Well, and the Python implementation had about 0.3% (!) the performance of the C code, but you don't use core Python for number crunching... I didn't write it in LISP, but optimising LISP compilers often approach or sometimes even surpass the performance of the equivalent C code, believe it or not (although it's really hard to compare, you come up with radically different solutions in LISP than in C).

The sensible approach is to write number-crunching stuff in C or something low-level, then the rest in something much nicer. Some commercial examples that do heavy number crunching is Adobe Lightroom (C++ image manipulation code and some OS interfacing, everything else including the GUI in Lua) and Bitwig Studio (DSP in C++, the GUI and everything else in some heavily restricted subset of Java).

So hence I'm saying, if you're not doing numerically heavy stuff, probably learning C should come second nowadays.

 

[Twiglard]

given that inline assembly is a thing in C, "inline C" should have been a thing in higher-level languages.

That necessitates a sane memory layout, something retarded interpreters aren't exactly known for. See Python's or Perl's FFI cancer.

It's similar to the story I bring up with people who want to write every single line of code themselves and never use libraries.

It's a good exercise for the beginner and intermediate programmer necessitating understanding of the basic principles underlying the basic algorithms and data structures. NIH wastes a lot of time, but it brings an understanding.

optimising LISP compilers often approach or sometimes even surpass the performance of the equivalent C code

No, Lisp doesn't work faster than native. That CL-PPCRE example couldn't be reproduced.

 

[Alpan]

The sensible approach is to write number-crunching stuff in C or something low-level, then the rest in something much nicer. Some commercial examples that do heavy number crunching is Adobe Lightroom (C++ image manipulation code and some OS interfacing, everything else including the GUI in Lua) and Bitwig Studio (DSP in C++, the GUI and everything else in some heavily restricted subset of Java).

I see your points, but I would suggest that this example proves my point more than yours: What makes these programs *are* the hard, performance-sensitive parts they contain. If you acknowledge that you can't use Python, Java, or JavaScript for performance-sensitive work, but that you can (but shouldn't) use C for stuff like GUI, this is the same as saying these languages aren't as powerful as C. Keep in mind that I did not say other languages aren't worth learning, only that C would provide a programmer with the most programming power over time.

There is nothing wrong with sticking with something like Lua or LuaJIT if all you foresee to be doing is GUI or scripting work.

 

[Rincewind]

I see your points, but I would suggest that this example proves my point more than yours: What makes these programs *are* the hard, performance-sensitive parts they contain. If you acknowledge that you can't use Python, Java, or JavaScript for performance-sensitive work, but that you can (but shouldn't) use C for stuff like GUI, this is the same as saying these languages aren't as powerful as C. Keep in mind that I did not say other languages aren't worth learning, only that C would provide a programmer with the most programming power over time.

Well, you surely can use Java for that, the question is whether going from say 50-60% to 100% is worth the extra time for you or not. Sometimes it is, sometimes it isn't. Like in any engineering discipline, there are many parameters of a finished product, and performance is just one of the many (you can't pretend achieving ultimate performance has zero cost).

But yeah, if you need raw numerical speed and control over memory layout, well, you have to suck it up and use something like C (for example, I use Nim these days; C speeds are perfectly achievable and I don't really want to touch C anymore).

Powerful is a matter of definition, to me Haskell/Scala/LISP are powerful as in "power of expressivity" of the language. These languages allow me to think "different thoughts", at higher abstraction levels, hence they're more powerful in my view. I wouldn't really call C powerful, in comparison to pretty much everything else it's quite pedestrian. Sure, it's just capable of utilising all (or most) features of the hardware and you can control the memory layout, but that's about it. I still maintain my view that it's a sort of a high-level cross-platform assembler

But I get your points.

 

[Rincewind]

There is nothing wrong with sticking with something like Lua or LuaJIT if all you foresee to be doing is GUI or scripting work.

Umm, quite the opposite:

• Game AI is usually written in Lua, for example. Speed of iteration and hot reloading usually beats all negligible performance benefits.
• Python and NumPy or similar libraries are quite popular in scientific circles. Julia too.
• Data scientists use Spark a lot, which is written in Scala.
• Scala (and probably LISP still) are quite popular in AI researcher circles. Also in the financial sector.
• Python is nowadays quite universally used for sysadmin/devops stuff.
• Kotlin is used for most Android mobile apps, and Objective C / Swift for iOS most apps.
• 99% of the backends of all web apps are written in some high level language like Java, C#, Kotlin, Scala, Haskell, LISP, whatever.
  
• Even the awful high-frequency trader people tend to prefer Java nowadays over C++ (it's just less hassle and fast enough even for soft-realtime with some specialised GCs).
• etc.

I'd say pick C/C++ if you want to be a firmware developer, work on video/audio codecs, device drivers, OS kernels, or some highly specialised numerically intensive software, like game engines or raytracers on commodity hardware (I say commodity hardware because for really serious scientific number crunching on supercomputers Fortran still beats C). But these areas are very very small niches compared to the totality of software development.

 

[Bad Sector]

Seriously no, Delphi was unable to generate half-decent x87 FPU code and was very bad at inlining. Just porting the code to a C++ compiler was a huge gain (and then doing SIMD).
So I'd agree it's enough provided you don't need to crunch numbers.

I'm mostly certain that rewriting the code had you make adjustments to how it did things which affected the engine's performance and is the main reason why C++ was faster. I do not disagree that Delphi's codegen isn't that great, where i disagree is that it matters to the point where you have to use another language unless a *very* large percentage of your application's runtime is spent on a tight loop doing number crunching - but games spend a lot of time on non-number crunching stuff. To give you an idea, i just did a quick test with an older engine of mine written in C with two versions, one compiled at maximum optimization using GCC 10.2.0 (which i happen to have installed) and another compiled with whatever debugging options (ie. most basic optimizations) using Borland C++ 5.0 (note that in the raytracing benchmark i linked previously BCC produced executables between 4 to 5 times slower than GCC 8) and then loaded a particularly heavy map that hits the CPU hard. The difference between the two was... just 0.1ms per frame with BCC being the slower. In practice both were hovering around 110fps so to an end user it'd make zero difference.

TBH if i hadn't used a lot of language features that are not available in Delphi 2, i'd try to make a port of Post Apocalyptic Petra to it and see how its performance compares, but i'd need to rewrite a lot of stuff just for the sake of a benchmark. However while i'm not using it much anymore, i've used Delphi 2 since the 90s (it was actually the first language i used on Windows) and i'm 100% certain that it is more than adequate of making an RTS (or RPG or whatever other game).

 

[Alpan]

Umm, quite the opposite:

I'm aware of most of those use cases you list, I was just responding to your original post. Though, I'm not sure why you said "quite the opposite"; you're not actually contradicting me, and at any rate I haven't said anything you could contradict...

Powerful is a matter of definition, to me Haskell/Scala/LISP are powerful as in "power of expressivity" of the language. These languages allow me to think "different thoughts", at higher abstraction levels, hence they're more powerful in my view. I wouldn't really call C powerful, in comparison to pretty much everything else it's quite pedestrian. Sure, it's just capable of utilising all (or most) features of the hardware and you can control the memory layout, but that's about it. I still maintain my view that it's a sort of a high-level cross-platform assembler.

Well, the CPU is the CPU. It doesn't care about the elegance of your thoughts or how your statements look in your editor or whether you expressed 10 lines of code with 1. Also, I reiterate, none of that has resulted in a measurable quality increase in software, it anything it has declined.

There is something to be said for programmer ergonomics and comfort, but, again, there is absolutely no evidence that higher-level languages have produced anything of value in this respect. We should have seen an order of magnitude change in quality software with all the technological developments, but there is no positive change in quality. What they have done is lower the barrier to entry to programming, but, for the last time, it doesn't follow naturally that this is a good thing.

But yeah, there is no doubt that C is not a very expressive language, and the total lack of metaprogramming is a big deficit to be sure. This is more a limitation of the language specification, and also the reason why there are like a thousand different language projects aiming to replace C now that LLVM has gained widespread use as a back-end, though it remains to be seen if they will amount to anything.

Anyway, that's all from me in this thread. Thanks for the exchange.