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.

On 9/19/14, 4:47 PM, 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.

Awesome, thanks. More evidence that we're putting our chips on seamless C++ compatibility.

Andrei

Max Klyga:

> https://www.youtube.com/watch?v=TH9VCN6UkyQ

I like the focus on correctness of the Rust language (but currently Rust seems to ignore several kinds of correctness, focusing only on two kinds), but I understand that the needs of creating a modern browser (that is a long lived project, where like in a kernel the correctness is very important, and the speed of writing code is not important) are different from the needs of creating a modern video game. So he chooses differently than Rust.

It's a long talk. He doesn't like exceptions, not GCs. Several of the things he says are already present in D, but he is looking for a language that is simpler than D.

He suggests code like this (the syntax is not so important) in his new language:


--------------------------
struct Mesh {
    Vector3 []! positions;
    int []! indices;        @joint positions
    Vector2 []! uvs;         @joint positions
}

mesh.positions.reserve(num_vertices);
mesh.indices.reserve(num_indices);
mesh.uvs.reserve(num_vertices);
--------------------------

"int []" seems like a D dynamic array, it contains the pointer to the data and its length.

The "!" means the memory of this array is owned by the Mesh stuct. So when the Mesh instantiation goes out of scope, all the memory it owns gets deallocated.

The "@joint" annotation means that the memory of "indices" array is allocated in the same chunk of memory used to allocate "positions". The same happens for "uvs" array. So when you create a Mesh you allocate only one chunk of memory for its owned dynamic arrays.

"mesh.positions.reserve" allocates memory for the positions array of the instance "mesh", but the compiler sees the (optional) "@joint" annotation, and merges the three allocations into a single one and then slices the memory for the three arrays (i think the compiler raises a compilation error if it can't merge them well).


He also likes an explicit simple syntax for nullable pointers. I think the compiler enforces the presence of the null test for nullable pointers (perhaps as in the Whiley language):

--------------------------
void do_something(Entity ?a) {
    if (a) {
        a.x = 0;
    }
}
--------------------------

Bye,
bearophile

 He actually talks about Andre around 40' ;0

As a fellow game dev:

I don't agree with him about RAII, I find it useful

He kind of has a point about exceptions, I'm not big on them


I get the impression his C++ knowledge is about the level of C++ with classes, ie very low.

He claims using std:: inherently causes slow compilation, my experience says otherwise.

He goes on about "freeing free'd memory", this is never something that would happen in modern C++, so he is basically proposing an inferior language design.


 At one point he says you can't see the contents of std::vector in a debugger. What? This is trivial and has worked in every version of Visual Studio for the last 5+ years.

 I do agree the build systems used with C++ are idiotic

IMO, C++'s complexity is largely because of the stupid headers and all the mind numbing crap associated with it. That and the lack of any reflection.

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.

OK so I'm 1h in now. The guy is explaining slices in a languages that look like C or C++. But discarded D at the beginning because it is too close to C/C++.

Also I love how he keeps mentioning that adding debug support is easy.

His ! stuff looks interesting, but I guess this is already being discussed in D with uniqueness.

I also love the passage where he mention that you have strings everywhere, and you duplicate them and so on, and that you can a system to unique them and manage memory, but that would be crazy complicated. The obvious question that come to mind: what does he think a compiler does ?

OK now using pointer and value type via dot.

1h20 he is on nullable vs non nullable. According to him this is not an issue, but stats say otherwise. Still want to look into it. Not sure what is his point on that one.

He then goes on concurrency and make some very good points here but he doesn't look like he has anything to propose :(

1h25 annotate, serialize, introspect.

1h25 good point about build. All build system I've used so far sucks. But no solution.

At the end, I kind of agree on the problems, but the solution he mention already exists, and when they do not (or I think they do not) he don't have anything to propose.

1h30 now he is talking about CTFE and code generation...

What I take out of this, is that something like unique/isolated or whatever is key, and the memory mapping optimization is nice but probably realizable in D using code generation. But creating a new language instead of participating in existing ones seem very misguided and he does seems to realize how hard it is to create a language.

He also proposes of removing most or all implicit type conversions in his language, like bool->int.

D allows code like:

bool foo() { return true; }
void bar(int x) {}
void main() {
    bar(foo());
}


In past, removing implicit conversions from D forced you to write:

bar(cast(int)foo());

That is not much safer than having implicit conversions because cast() is a sharp powerful tool. In D programs the usage of cast() should be minimized as much as possible.

But if we keep disallowing implicit conversions, but we introduce a second kind of static cast that only work if the conversion is lossless, then we have code like (currently this is allowed in D because the int() syntax rides on the implicit conversions. So the semantic is a little different):

bar(int(foo()));

You also need suffixes to express most types with literals (like 10u8 for an ubyte, or 'c'd for a dchar), to code in a more handy way.

Perhaps this new situation (no implicit conversions, plus two kinds of casts, and few extra literals) is safer than the current D situation (and I think no C code gains a new working meaning in this new situation).

Bye,
bearophile

On Saturday, 20 September 2014 at 08:38:49 UTC, bearophile wrote:
> Perhaps this new situation (no implicit conversions, plus two kinds of casts, and few extra literals) is safer than the current D situation (and I think no C code gains a new working meaning in this new situation).

He want go-semantics. It also means that literals are untyped until bound, so you can do high precision calculations at compile time.

I would also like to see these explicit conversions (and find hacks like "alias this" somewhat annoying).

I also think arithmetics on ubytes should be done as ubytes etc to allow SIMD vectorization.

Go semantics is described well here:

http://blog.golang.org/constants

On Saturday, 20 September 2014 at 08:46:34 UTC, Ola Fosheim Grostad wrote:
> I also think arithmetics on ubytes should be done as ubytes etc to allow SIMD vectorization.

Array operations do use SIMD. The code for this is in druntime.

https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d

Brian Schott:

> Array operations do use SIMD.

Array ops aren't used often in most normal D code. Most usages of SIMD should come from auto-vectorization and core.simd (but perhaps core.simd design was not discussed and improved enough, and the implicit upcasting semantics of C could hurt auto-vectorization).

Bye,
bearophile