Programming Language for Games, part 3

[Ary Borenszweig via Digitalmars-d]

On 11/1/14, 8:31 AM, bearophile wrote:
> Third part of the "A Programming Language for Games", by Jonathan Blow:
> https://www.youtube.com/watch?v=UTqZNujQOlA
>
> Discussions:
> http://www.reddit.com/r/programming/comments/2kxi89/jonathan_blow_a_programming_language_for_games/
>
>
> His language seems to disallow comparisons of different types:
>
> void main() {
>      int x = 10;
>      assert(x == 10.0); // Refused.
> }
>
>
> I like the part about compile-time tests for printf:
> http://youtu.be/UTqZNujQOlA?t=38m6s
>
> The same strategy is used to validate game data statically:
> http://youtu.be/UTqZNujQOlA?t=55m12s
>
> A screenshot for the printf case:
> http://oi57.tinypic.com/2m5b680.jpg

That is called a linter. A general linter works on an abstract syntax 
tree with possibly type annotations. His "linter" only works on 
functions. I guess he will extend it later, but he's not inventing 
anything new.

My opinion is that he knows C++ a lot and he's tired of some of its 
stuff so he's inventing a language around those. I don't think that's a 
good way to design a language.

D can run (some) stuff at compile time. Crystal can run (any) stuff at 
compile time. Rust too. Many modern languages already understood that it 
is very important to run things at compile time, be it to generate code 
or to check things.

I can understand his excitement because I got excited too when I was 
able to run stuff at compile time :-)

About the bytecode he generates: as someone said in the reddit 
discussion, having to maintain two separate language implementations 
(compiled and interpreted) can lead to small and subtle bugs. And, 
running code via an intepreter is slower than compiled code, even if the 
interpreter is really good. So I don't think the bytecode stuff is a 
really good idea.

Also, why have a dynamic array as a built-in? You can implement it 
yourself with pointers...