On Thursday, 19 November 2020 at 23:01:34 UTC, Ola Fosheim Grøstad wrote:
> 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.

Consider the future variant that includes monadic type variables and, pay-as-you-go, embeds the "static" compiler within the app.  Will some people still pine for Python style "typing" if the compile-time/run-time distinction is optional?

I imagine there will still be some who would so, yes, call that part of the "nearly".

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?

GC is a big NO for Jonathan. What people must try to understand is that Jonathan is not creating Jai to be a general purpose language, he has a specific goal and a specific design in mind.

Game development is very different from any other field, but of course, if you are creating a small/simple game the GC will not be such a big problem, but if you are doing anything complex, the GC is a huge problem, and people cleary do NOT understand that.

In my case for example, the reason my game engine is written is C++ is because i HAVE NO CHOICE, i fucking hate C++, but i have no choice. The first version of my engine was pure C# (using only c++ binding for some libraries) and i had a lot of problems with the GC and memory usage, the FPS was not acceptable, i had to spend months rewritting but now i at least do not have this problem anymore.

Another example is the Stride game engine (previously Xenko), which is also terribly slow if compared with Cryengine, for example. And Stride's codebase is not bad at all, it was really well written by very experienced engineers.

Jonathan is creating Jai SPECIFICALLY for game development, as he said a lot of times before, Jai is meant to be used in financial, trading or whatever systems. It is for game development.

Yes, it gives you a lot of power. Yes, is dangerous. Yes, debugging is not the best. Yes, it is NOT for begginners. It is NOT for everyone and it will never be a mainstream language, and that is fine.

On Friday, 20 November 2020 at 01:28:46 UTC, J. V. wrote:
> On Wednesday, 18 November 2020 at 16:13:20 UTC, Jack wrote:
>> [...]
>
> GC is a big NO for Jonathan. What people must try to understand is that Jonathan is not creating Jai to be a general purpose language, he has a specific goal and a specific design in mind.
>
> [...]

Correcting this part:

Jonathan is creating Jai SPECIFICALLY for game development, as he said a lot of times before, Jai is *** NOT *** meant to be used in financial, trading or whatever systems. It is for game development.

On Friday, 20 November 2020 at 01:14:45 UTC, Bruce Carneal wrote:
> Consider the future variant that includes monadic type variables and, pay-as-you-go, embeds the "static" compiler within the app.  Will some people still pine for Python style "typing" if the compile-time/run-time distinction is optional?
>
> I imagine there will still be some who would so, yes, call that part of the "nearly".

The problem is more general. If you include low level capabilities across the board then you also throw out most solid type system advantages. In fact, in the case of D it even prevents a decent GC. Even to enable a decent GC you would need more constraints than D currently has.

The only way you can have high-level programming advantages is if you isolate low level programming capabilities and encapsulate that code with guarantees that uphold the high level type system invariants.

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

That's kind of how I use D. The language for prototyping, scripting, development (web, system), teaching, competitive programming. I don't have to relearn a new language.

Life is very short...not enough time.

Modeling things in D is soo familiar and nice. The language can model CLEANLY basically anything. Phobos got lots of free gems. Dub is also great supplement.

My only issue is the ecosystem for some of those areas (embedded, cloud
SDKs) are still not as matured as I would like them to be. But that's only a matter of time. D has improved a lot since I found it.

On Friday, 20 November 2020 at 12:30:22 UTC, aberba wrote:
> That's kind of how I use D. The language for prototyping, scripting, development (web, system), teaching, competitive programming. I don't have to relearn a new language.

As programmers gain more experience learning a new language is a small challenge. What is expensive is figuring out how to use libraries and frameworks (and to find the ones you need). Also there is a heavy transition costs if you have to port your own libraries/code bases.

> My only issue is the ecosystem for some of those areas (embedded, cloud
> SDKs) are still not as matured as I would like them to be. But that's only a matter of time. D has improved a lot since I found it.

I think one key property of a language and the culture around it is to provide standards for how to write libraries so that you don't have to learn peculiarities of each library and to make them interoperate fluently.

E.g. Python had a rather strong culture on Stack Overflow with a lot of debate of what was idiomatic or not. Unfortunately, libraries like numpy/matplotlib come with their own hacky ways of doing things, and as such outliers become more widespread you get a more mishmash programming experience.

Designing both language and a culture for evolving the eco system certainly isn't easy. You probably need a well funded foundation to build a solid widespread ecosystem that other programmers mimic. A big standard library is one way to do that, but then that design has to be really solid, so you need some very skilled coordinators and funding.

On Friday, 20 November 2020 at 09:51:43 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 20 November 2020 at 01:14:45 UTC, Bruce Carneal wrote:
>> Consider the future variant that includes monadic type variables and, pay-as-you-go, embeds the "static" compiler within the app.  Will some people still pine for Python style "typing" if the compile-time/run-time distinction is optional?
>>
>> I imagine there will still be some who would so, yes, call that part of the "nearly".
>
> The problem is more general. If you include low level capabilities across the board then you also throw out most solid type system advantages. In fact, in the case of D it even prevents a decent GC. Even to enable a decent GC you would need more constraints than D currently has.
>
> The only way you can have high-level programming advantages is if you isolate low level programming capabilities and encapsulate that code with guarantees that uphold the high level type system invariants.

Constraints are key.  The question is when they are applied and by whom.  Does the language designer choose the constraints ahead of time or does the programmer opt-in/out of full capability at need?

On Friday, 20 November 2020 at 15:53:42 UTC, Bruce Carneal wrote:
> Constraints are key.  The question is when they are applied and by whom.  Does the language designer choose the constraints ahead of time or does the programmer opt-in/out of full capability at need?

The challenge is that opt-in/out is a source of serious bugs. Also very difficult to prove that the overall system is sound if you have many options that you can turn on/off.

Another problem is that even if you can make it work for single threaded it might break down when you add concurrency, for instance, you can create a parallel high level language that provably cannot deadlock. With low level multi-threading that is basically off the table.

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?

So, outside of Manu, I may very well be the only person that has spoken to Jonathan at length about D and Jai. He has in fact been an audience member for one of my D talks.

He's a pure engineer. And his coding style is still very heavily entrenched in the C way of doing things. End result is that he's writing a language to fill a gap that he sees. It's a better C (fancy that), with some features that we'd have to write library solutions for to get equivalent code.

I've shipped D code in a console game, but there's still things that need to be done before we can move D in to widespread adoption. Others are way more actively working on these things than I am. I wouldn't expect Jonathan to switch gears on this. And you know what? That's healthy. One of the things I pointed out in my DConf 2017 talk was that his perspective is "I just want to write code" and whenever I try to do heavy compile time code in D (be it templates or CTFE) I'm constantly battling the compiler and the language to get it to do what I want it to do. We've still got a ways to go to hit that painless level of language use, and there's someone out there that's actively trying to achieve that with their own language. It's a goal we should strive for.

(That's a sneaky way of saying "type functions when?")

On Fri, Nov 20, 2020 at 06:22:47PM +0000, Ethan via Digitalmars-d wrote: [...]
> [...] whenever I try to do heavy compile time code in D (be it templates or CTFE) I'm constantly battling the compiler and the language to get it to do what I want it to do.

In spite of our enthusiasm (including my own) and our advertising D's compile-time capabilities (templates/CTFE) as a major selling point, I still reach for two-stage manual D code generation (i.e., write helper program that prints D code) once my code passes a certain level of complexity.  IME, darling D projects that heavily utilize CTFE and templates like vibe.d's Diet templates, std.regex, etc., are painfully slow to compile and use, despite their coolness factor.

I wouldn't reinvent my own diet templates or std.regex, of course, but if I'm faced with a task that needs code generation on that level of complexity or higher, I find it much more conducive to write a helper program that spits out D code that's then compiled into the main executable, rather than fight with superlinearly-growing compile times, the compiler running out of RAM, and difficulty of debugging.

We have a ways to go indeed.


[...]
> (That's a sneaky way of saying "type functions when?")

There seems to be some resistance to the idea by Walter and Andrei. Which is usually a bad sign for acceptance.  I suggested recognizing certain template patterns and internally switching to a type function implementation underneath, i.e., retain the current template semantics and optimize the implementation, but Stefan didn't like that idea. So I dunno.

Do you have a concrete example of where type functions would do much better than templates, that might serve as a good motivating example of why type functions would be a good idea?


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.