Am 20.09.2014 01:47, schrieb Max Klyga:
> 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.
>

Many of his wishes have been answered in Algol68(1973), Modula-2(1978), Cedar(1983), Ada(1983), Turbo Pascal 6.0 (1990), but the industry at large decided to go elsewhere instead.

Which in the end boils down to this:

"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. " -- Dennis Ritche on history of C.

Already in 1979 it was clear that C without syntax analysis tooling wasn't a good idea.

This of course, also had an impact in C++ and Objective-C.

--
Paulo

On Saturday, 20 September 2014 at 09:09:56 UTC, bearophile wrote:
> 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).

Yes, I was thinking of auto vectorization/masking. Handcrafted simd is nice too, but I feel it is better done in a way the backend can understand. You might also want the compiler to generate fallback paths for older cpus...

Am 20.09.2014 04:25, schrieb po:
>   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 seems to miss the point that it is possible to write general purpose
RAII templated classes, since he keeps on talking about specific implementations for each type of resources.

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

Exceptions in most programming languages that have them are a good idea.

Exceptions in C++ are a broken concept.

Having to cope with C semantics, ability to disable them and mixing code
bases is what leads to the pain of writing exception safe code in C++.


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

At the end he states having only read K&R C, with everything else being learning on the job, it seems.

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

Back when I was stil working with C++ at day job, doing a "make world" in a code base with Tools.h++ would cost a few hours.

And we were using ClearMake optimized build infrastructure.

You can have fast builds, but it requires knowledge of the whole architecture and coding for the build system, e.g. separating modules into real libraries.


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

It also surprised me. Visual Studio has the best developer experience in terms of visualizing C++ data structures.

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

I wonder if modules in C++17 will already be too late.

By then, when looking at C++ project, it might be pre-C++98, C++11, C++14, C++17 with the accumulated set of semantics, differences and
styles each standard revision brings to the table.

--
Paulo

On Saturday, 20 September 2014 at 11:11:23 UTC, Paulo Pinto wrote:
> Many of his wishes have been answered in Algol68(1973), Modula-2(1978), Cedar(1983), Ada(1983), Turbo Pascal 6.0 (1990), but the industry at large decided to go elsewhere instead.

I didn't get that impression. Seems like he wants to cover existing practices in a more time saving package, then add some neat stuff:

- automatic region allocator per object
- ctfe including executing external programs
- uda + static reflection
- debugging tools for freeing shared memory (without rc/tracing)
- go style literals + type system?
- swift style nullable

Seems he wants a streamlined nogc/nothrow version of D with a dedicated syntax for his field. D could probably be modified to fit pretty well.

On 9/19/14, 9:52 PM, bearophile wrote:
> but currently Rust
> seems to ignore several kinds of correctness, focusing only on two
> kinds

Could you tell which are those two kinds and which other correctness are ignored? Just to learn more about Rust. Thanks!

Ary Borenszweig:

> Could you tell which are those two kinds and which other correctness are ignored? Just to learn more about Rust. Thanks!

Rust does everything to be memory safe, and avoid data races outside its unsafe code zones. But in the real world there are many other sources of bugs that can wreak a program. Ada (and in a less intense way D) try to help the programmer write correct code for some of them too (and other languages are ATS, Whiley, F*, Idris, etc, cover other forms of correctness).

Bye,
bearophile

Am 21.09.2014 11:30, schrieb bearophile:
> Ary Borenszweig:
>
>> Could you tell which are those two kinds and which other correctness
>> are ignored? Just to learn more about Rust. Thanks!
>
> Rust does everything to be memory safe, and avoid data races outside its
> unsafe code zones. But in the real world there are many other sources of
> bugs that can wreak a program. Ada (and in a less intense way D) try to
> help the programmer write correct code for some of them too (and other
> languages are ATS, Whiley, F*, Idris, etc, cover other forms of
> correctness).
>
> Bye,
> bearophile

You can handle units of measure via tuples structs, since you mention F#.

Not as clean, but workable.

--
Paulo

Paulo Pinto:

>> (and other
>> languages are ATS, Whiley, F*, Idris, etc, cover other forms of
>> correctness).
>>...
> You can handle units of measure via tuples structs, since you mention F#.

Here I mentioned F*, not F#:
http://research.microsoft.com/en-us/projects/fstar/

Bye,
bearophile

Am 21.09.2014 12:47, schrieb bearophile:
> Paulo Pinto:
>
>>> (and other
>>> languages are ATS, Whiley, F*, Idris, etc, cover other forms of
>>> correctness).
>>> ...
>> You can handle units of measure via tuples structs, since you mention F#.
>
> Here I mentioned F*, not F#:
> http://research.microsoft.com/en-us/projects/fstar/
>
> Bye,
> bearophile

Sorry, should have taken more coffee.

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.

Interesting to see him not worship RAII and even bash it a bit. Most game developers sticking with C++ and evaluating other languages swear by RAII and reject every GC-language for the lack of it.