[pjmlp]

1. Refusing to just use Assembly.

Was the reply we got in the old days, when one used C, Pascal, Basic, Amos.

Thankfully many ignored that and moved the state of art to such languages.

A few years later the reply would be,

1. Refused to use C

When devs tried to use C++ or Delphi.

State of the art in games development only advances thanks to those that manage to produce entertaining games, while ignoring such advices.

[xemdetia]

I don't really feel like this is a fair statement if you have done any game engine related development. Even 'writing from scratch' is still gluing together a whole soup of libraries and many of those libraries are C API only. Fonts? Use freetype. PNG's? use libpng. COLLADA? Audio? Audio files? Input? OpenGL/DX?

As soon as you say you are throwing out C/C++ you better have amazing alternatives that make sense for the language you are working on. Games are large enough projects with broad enough scope that if you don't have a language that works well with a bunch of external libraries you are immediately in the weeds once you end up with a problem that isn't covered by what is already available. If you find this out too late in the project (especially in a hobby/side project) this can be a death knell.

This is a constant problem in game engines or other large frameworks- once you get off the rails in a significant way all your development time is going to making that kludge work. If you are using a language that is just wrapping C API libraries often a lot of this development time is just fixing the wrappers to the actual library instead of getting anything done.

If you know the end product is 100% covered by a game engine you can save all the game engine development time and the kludge fix time all at once. I had written a whole tutorial series based on XNA for instance because it was easy to demonstrate the concepts I wanted to share, but when trying to start working on a particular topic I realized the engine's limitation and it all went to hell and I had to scrap it.

[yellowapple]

A growing number of languages are ABI-compatible with C. A small but significant subset of those languages is ABI-compatible with C++. Quite a few languages (Perl 6, Julia, Tcl w/ critcl, pretty much everything that uses libffi AFAICT) are able to do this without having to write full-blown wrappers for a whole C/C++ library (though you still need to wrap specific functions in most cases).

[ihnorton]

Julia JIT compiles C calls via LLVM, so there's no libffi performance overhead (similar to LuaJIT's CFFI, though that does not use LLVM).

[yellowapple]

Neither does Tcl's critcl AFAIK (I think it just sticks the C code in a Tcl extension and compiles it using the system compiler). My intent there was just to list cases where wrapping a whole C/C++ library is unnecessary, not to imply that Julia uses libffi :)

On that note, LLVM helps a lot here, too. Are there any LLVM-based languages that don't have some degree of C compatibility?

[ihnorton]

Parse error on my part, excuse the pedantry :) Tcl is such a weird and wonderful language, and I occasionally miss it (though I don't miss working with a GUI written in C++ wrapped around tk).

[pjmlp]

On a past life I used to be an IGDA member, attended GDCE a couple of times, and knew personally developers working in a few European game studios, until deciding boring IT work was a better way to make a living and enjoying life.

[karmadog]

Game developers used Assembly to write games when it was the best tool for the job. They then moved to C when it was feasible and then to C++ when that was feasible. For their engines, they never moved on to anything else, because there still is no better tool for the job, all things (tooling, SDKs, platform support) considered.

Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborate script bindings, but the engine remains in C/C++.

There's a lot of people leaving college that have never learned how to use C/C++ and immediately they want something they're comfortable with, which is Java/C# or Javascript or maybe even Python. These languages are not good choices for a game engine, for the reasons I mentioned. Will there never be a better language? I did not say that, but it would be an uphill battle.

[pjmlp]

Usually game developers changed language when the OS or game console's SDK release forced them to do so.

> These languages are not good choices for a game engine

I have seen these words written against C, Turbo Pascal, Modula-2, C++.

Some of the games I saw "written" in C for MS-DOS were like this all over the place:

    void my_func(void)
    {
       asm {
         /* 100% of my_func actual code */
       }
    }

Just as if C was a macro assembler.

[karmadog]

SDKs never forced anybody to move to C or C++, but the opposite is true: C/C++ compilers were either unavailable or limited.

"I have seen these words written against C, Turbo Pascal, Modula-2, C++."

So what? Those words probably had a good argument behind them, at the time.

In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.

[pjmlp]

> So what? Those words probably had a good argument behind them, at the time.

> In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.

Just like C compilers had enough money spent into their optimizers, that eventually made them competitive against Assembly, so can C#,Go,D, <whatever language> have enough work placed into them, that eventually they will become competitive against C.

People believed they could make C competitive against Assembly, just like they believe they could make C++ competitive against C.

So it is a matter if one wants to believe and lead, or don't and follow.

[karmadog]

If <whatever language> makes certain assumptions and guarantees on behavior, then no, belief is not enough. It has to be plausible. GC alone really is a big issue and all the research (of which there is a lot) has not solved fundamental issues.

There are of course languages (like Rust) that have the fundamentals to match C/C++, but then it's still a matter of adoption. C++ also still develops.

[pjmlp]

The fundamental issues is that science only advances one memorial at a time, as there is no amount of technical proofs that will change the mind of luddites.