[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