[Semi OT] Language for Game Development talk
deadalnix via Digitalmars-d
digitalmars-d at puremagic.com
Fri Sep 19 21:28:56 PDT 2014
On Friday, 19 September 2014 at 23:47:06 UTC, Max Klyga wrote:
> Jonathan Blow just recorded a talk about the needs and ideas
> for a programming language for game developer.
>
> https://www.youtube.com/watch?v=TH9VCN6UkyQ
>
> This talk mentions D quite a lot of times.
> D is mentioned as the most probable to be adopted if it were
> possible for frictionless interaction with existing codebase.
> An interesting talk if you want to look at language design from
> game developer perspective.
I haven't finished the talk yet, but already this is kind of
upsetting. The claim that he want to create a programming
language, but is unable to give concrete examples of any case he
makes so far, grossly misrepresent what exists in other languages
or flat out declare that he doesn't know.
If you are going down the road of creating a new programming
language, you'd better be sure to know what exists fairly well
and what shortcomings you are trying to overcome.
That would be true of anything, really, not simply programming
language. The fact that, without deep knowledge of what is done
in languages outside C++, he can assert of the difficulty of
writing a compiler the classroom example of Dunning Kruger.
It literally like me saying telling to general motor engineer
hey, building a really good car is easy, You screw 4 wheels to a
metal cage and done!
I'd concede that he is probably right on the fact that writing a
front end is certainly easier that a game engine (ie I mean high
end game engine with realistic physic, high quality rendering and
all the goodies). But it is pretty clear from his talk so far
that he grossly underestimate the difficulty to:
1/ Get language design right. It is a mix of technical constraint
for the coder, the compiler, and plateform/runtime constraints,
the whole thing being made extra hard as success depends on
various social dynamics amongst developers.
2/ Getting compiler right. Parsing and dumping C like code into
LLVM is one thing. Getting the whole thing to support various
advanced features, meaningful errors messages, making it fast,
making it resilient enough to wrong code so it can be useful for
tooling, generating good quality IR, getting a good quality
runtime that work on various platforms and implementing languages
specific optimization is much harder.
More information about the Digitalmars-d
mailing list