On Thursday, 19 November 2020 at 13:32:13 UTC, IGotD- wrote:
> On Thursday, 19 November 2020 at 13:25:33 UTC, starcanopy wrote:
>>
>> If I recall well, he made a video about Rust, golang, and D in the context of game development, and the crux of the issue is that each of these languages are too opinionated for him--or at least incorrectly opinionated.
>
> Can you explain what it means when a language is "opinionated". If I'm going to guess it means that Jonathan Blow doesn't like a language that he doesn't have full control over?

golang: GC, interfacing with other languages is not smooth, dynamic arrays that reallocates, a very specific concurrency model, basically useless for games. Messed up exceptions.

Rust: you are basically forced to model with tree-like structures and optimizing backpointers and other shortcuts are an issue. The syntax is peculiar. The language is essentially built around one specific feature, if that feature does not solve you problems, then it is a misfit.

Dlang: the forums are a testament to where it is opinionated, but the bigger issue is that the language is dominated by conflicting design goals (or goals that have changed over time).

On Thursday, 19 November 2020 at 13:42:38 UTC, Paulo Pinto wrote:
>
> Doing in-house languages is quite common in game studios.

That is usually scripting languages for game logic. Seldom any system languages unless you can mention one.

On Thursday, 19 November 2020 at 13:32:13 UTC, IGotD- wrote:
> On Thursday, 19 November 2020 at 13:25:33 UTC, starcanopy wrote:
>>
>> If I recall well, he made a video about Rust, golang, and D in the context of game development, and the crux of the issue is that each of these languages are too opinionated for him--or at least incorrectly opinionated.
>
> Can you explain what it means when a language is "opinionated". If I'm going to guess it means that Jonathan Blow doesn't like a language that he doesn't have full control over?

I found the video: https://www.youtube.com/watch?v=TH9VCN6UkyQ . And I was mistaken: it's not "opinionated," it's "big agenda", and it isn't the only criterion by which he judges a language. So, as an example, Rust is considered to have a "big agenda" (borrow checker), or insufficiently-tested mandate. Funnily enough, D is too similar to C++. The latter is something that appears on this very newsgroup from time-to-time: D is a nicer C++, but its differences and advantages aren't appropriately significant to warrant a change.
Aside: This video is only three years old, and my mind already distorted it. Scary stuff.

On Thursday, 19 November 2020 at 13:46:37 UTC, IGotD- wrote:
> On Thursday, 19 November 2020 at 13:42:38 UTC, Paulo Pinto wrote:
>>
>> Doing in-house languages is quite common in game studios.
>
> That is usually scripting languages for game logic. Seldom any system languages unless you can mention one.

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

On Wednesday, 18 November 2020 at 16:13:20 UTC, Jack wrote:
> So I find out jonathan Blow is devloping his own programming language, because "C++ is wild mess". I know pretty much nothing about game dev and I was wondering if D could be used in the way Jonathan Blow would like to? Anyone experienced on game dev stuff could answer this? as far I know, the jai's compiler is not ready yet.Maybe let him know about D language, assuming it fits its game needs, would be interesting?

Jonathan Blow repeatedly states in his streams that GC is simply not acceptable in a games programming language. So that is a blocker when it comes to D.

It is hard to judge without having access to Jai, but my impression is that most of what Jai has is available in D already:

1. Compile time programming
2. Fast compile times

With regards to innovations in Jai, I think the main one that stood out to me is that it has knowledge of temp memory allocators - so you can kind of allocate temp memory without worrying about it, but you have to do something to clean it all up.

Re libraries Jonathan seems to hold the view that the library should be in source form and be built along with the project, as he wants builds to be totally controlled.

Another philosophical point is that the language should not hide the gory details of computers - it should not have layers of abstraction that gives a false sense of security. Jonathan believes that many programmers don't realize how slow their programs are because they are so far removed from how the computer operates.

I certainly think a cut-down version of D could compete with Jai. That is the motivation for my Laser-D project.

On Thursday, 19 November 2020 at 14:32:36 UTC, Dibyendu Majumdar wrote:
> I certainly think a cut-down version of D could compete with Jai. That is the motivation for my Laser-D project.

Zig is kinda a cut down version too though, where the design goal is to not have language features that are non-transparent. Sadly, that also results in no overloading of functions by parameter types (IIRC).

What stands most out with D is that it is trying to be jack-of-all-trades, which often means that you end up being master-of-none. My impression is that Jai tries to turn that around and be master-of-one-but-not-for-everyone. So, clearly it will be very opinionated...

I suspect that Jai will fit one way of modelling better than others. Quite frankly, I would not really want to use a low level language without solid RAII.

What I dislike about some of these new languages, Go, Zig, Jai etc is that they seem to insist on going backwards on some design-parameters based on "ideological opinion" rather than sensible modelling concerns. So that makes me think: "ok, why are we going back to the 1980s here?".

On Thursday, 19 November 2020 at 17:31:30 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 19 November 2020 at 14:32:36 UTC, Dibyendu Majumdar wrote:
>> I certainly think a cut-down version of D could compete with Jai. That is the motivation for my Laser-D project.
>
> Zig is kinda a cut down version too though, where the design goal is to not have language features that are non-transparent. Sadly, that also results in no overloading of functions by parameter types (IIRC).
>
> What stands most out with D is that it is trying to be jack-of-all-trades, which often means that you end up being master-of-none. My impression is that Jai tries to turn that around and be master-of-one-but-not-for-everyone. So, clearly it will be very opinionated...
>
> I suspect that Jai will fit one way of modelling better than others. Quite frankly, I would not really want to use a low level language without solid RAII.
>
> What I dislike about some of these new languages, Go, Zig, Jai etc is that they seem to insist on going backwards on some design-parameters based on "ideological opinion" rather than sensible modelling concerns. So that makes me think: "ok, why are we going back to the 1980s here?".

The whole jack of all trades thing is really a an assumption, i.e. D is just better than C++ in more than one area but people are trained to believe you can't have a multitasking language - C is fast, Python is short etc - the way we teach programmers is a complete monoculture in language design.

On Thursday, 19 November 2020 at 17:38:16 UTC, Max Haughton wrote:
> On Thursday, 19 November 2020 at 17:31:30 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 19 November 2020 at 14:32:36 UTC, Dibyendu Majumdar wrote:
>>> I certainly think a cut-down version of D could compete with Jai. That is the motivation for my Laser-D project.
>>
>> Zig is kinda a cut down version too though, where the design goal is to not have language features that are non-transparent. Sadly, that also results in no overloading of functions by parameter types (IIRC).
>>
>> What stands most out with D is that it is trying to be jack-of-all-trades, which often means that you end up being master-of-none. My impression is that Jai tries to turn that around and be master-of-one-but-not-for-everyone. So, clearly it will be very opinionated...
>>
>> I suspect that Jai will fit one way of modelling better than others. Quite frankly, I would not really want to use a low level language without solid RAII.
>>
>> What I dislike about some of these new languages, Go, Zig, Jai etc is that they seem to insist on going backwards on some design-parameters based on "ideological opinion" rather than sensible modelling concerns. So that makes me think: "ok, why are we going back to the 1980s here?".
>
> The whole jack of all trades thing is really a an assumption, i.e. D is just better than C++ in more than one area but people are trained to believe you can't have a multitasking language - C is fast, Python is short etc - the way we teach programmers is a complete monoculture in language design.

+1

I believe that future D, or a non-backward-compatible successor, will be more than competitive across the entirety of the programming landscape.  Pay-as-you-go + ridiculously good metaprogramming capabiity == master-of-nearly-all.

D may not be able to get there, better-than-Rust safety and opt-in-ultra-low-latency GC are two features, among others, where the future looks a little iffy, but D surely points the way.

Counter examples showing how it is impossible to advance D to become master-of-nearly-all are requested.  Counter examples showing how it is impossible for any language to be master-of-nearly-all are also requested.

On Thursday, 19 November 2020 at 18:20:51 UTC, Bruce Carneal wrote:
> Counter examples showing how it is impossible to advance D to become master-of-nearly-all are requested.  Counter examples showing how it is impossible for any language to be master-of-nearly-all are also requested.

No language based on static analysis can be that. You would need incompatible type systems. You need opposing constraints.

On Thursday, 19 November 2020 at 17:38:16 UTC, Max Haughton wrote:
> The whole jack of all trades thing is really a an assumption, i.e. D is just better than C++ in more than one area but people are trained to believe you can't have a multitasking language - C is fast, Python is short etc - the way we teach programmers is a complete monoculture in language design.

It isn't an assumption. The question is whether the features are worth the costs, but it is quite undeniable that features have a cost. For instance, some aspects of Python are not used by most programs in any significant way. So you can make a language that is somewhat faster covering the same ground, as long as you exclude those not-so-frequently exploited aspects of the language.