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...
