www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Could D be used by Jonathan Blow rather jai language?

reply Jack <jckj33 gmail.com> writes:
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?
Nov 18 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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?


He knows... So, nope.
Nov 18 2020
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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?


My guess is that no language is going to be more appealing to 
Jonathan Blow himself than the one he designed personally to fit 
his own needs.

On the other hand, it's entirely possible that others who are 
interested in Jai might find D an appealing alternative, 
especially given that Jai has yet to see a single public release.
Nov 18 2020
parent Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 18 November 2020 at 16:19:02 UTC, Paul Backus wrote:

 On Wednesday, 18 November 2020 at 16:13:20 UTC, Jack wrote:

 [...]


 My guess is that no language is going to be more appealing to 
 Jonathan Blow himself than the one he designed personally to 
 fit his own needs.

 On the other hand, it's entirely possible that others who are 
 interested in Jai might find D an appealing alternative, 
 especially given that Jai has yet to see a single public 
 release.


IIRC Jai doesn't even have RAII so it's probably not even similar 
to D philosophically.
Nov 18 2020
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On Thu, Nov 19, 2020 at 2:15 AM Jack via Digitalmars-d <
digitalmars-d puremagic.com> 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?


I argued about this with him briefly before he started writing jai. He
knows about D, although he has no experience at all.
Jon is not interested in D (or any existing language); his vision includes
things that are omitted from D by-design, like AST macros and a
full-featured JIT/execution engine (including binary linkage), and I think
Jonathan sees jai more as a comprehensive solution (which solves the whole
build pipeline) rather than 'just a compiler' which takes a text file and
emits an object file.
There are distinctly different goals.
Nov 18 2020
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On Thu, Nov 19, 2020 at 2:24 AM Manu <turkeyman gmail.com> wrote:


 On Thu, Nov 19, 2020 at 2:15 AM Jack via Digitalmars-d <
 digitalmars-d puremagic.com> 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?


 I argued about this with him briefly before he started writing jai. He
 knows about D, although he has no experience at all.
 Jon is not interested in D (or any existing language); his vision includes
 things that are omitted from D by-design, like AST macros and a
 full-featured JIT/execution engine (including binary linkage), and I think
 Jonathan sees jai more as a comprehensive solution (which solves the whole
 build pipeline) rather than 'just a compiler' which takes a text file and
 emits an object file.
 There are distinctly different goals.


Also funny timing; at this _exact_ moment, I just received an email from
his company's recruiter :P .. extremely spooky coincidence!
Nov 18 2020
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
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?


It's funny, there seem to be a lot of gamedev people that *know* 
about D, but aren't interested in using it for various reasons (I 
think the primary one is probably that most/all modern game 
engines are written in C++ - except Unity, which is still C++ 
under the hood - and the toolchains are usually geared toward C++ 
as well).

John Carmack mentioned its support for functional purity in an 
article back in 2012:
https://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php

And Jonathan Blow has mentioned it at least in passing before, 
not to mention one of Ubisoft's development studios evaluating it 
(which I don't think panned out), and D code actually shipping in 
a modern AAA game (Alan Wake from Remedy Entertainment).

Manu and Ethan are the ones that are/were down in the trenches 
actually using D for gamedev, but it seems to me like the 
language is very well suited to it; potentially moreso than C++. 
C++ has almost completely dominated that space for 20+ years, 
though, so I don't think D will get big there anytime soon.
Nov 18 2020
parent Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 18 November 2020 at 16:53:44 UTC, Meta wrote:

 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?


 It's funny, there seem to be a lot of gamedev people that 
 *know* about D, but aren't interested in using it for various 
 reasons (I think the primary one is probably that most/all 
 modern game engines are written in C++ - except Unity, which is 
 still C++ under the hood - and the toolchains are usually 
 geared toward C++ as well).

 John Carmack mentioned its support for functional purity in an 
 article back in 2012:
 https://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php

 And Jonathan Blow has mentioned it at least in passing before, 
 not to mention one of Ubisoft's development studios evaluating 
 it (which I don't think panned out), and D code actually 
 shipping in a modern AAA game (Alan Wake from Remedy 
 Entertainment).

 Manu and Ethan are the ones that are/were down in the trenches 
 actually using D for gamedev, but it seems to me like the 
 language is very well suited to it; potentially moreso than 
 C++. C++ has almost completely dominated that space for 20+ 
 years, though, so I don't think D will get big there anytime 
 soon.




Want to make D attractive to game devs? Talking about what Remedy 
use is way past date.


reach out for,

https://stride3d.net/

https://waveengine.net/

https://flatredball.com/

https://www.cryengine.com/

https://www.neoaxis.com/

https://www.monogame.net/

https://jmonkeyengine.org/

https://libgdx.badlogicgames.com/

This is what D needs to actually be relevant to indie game 
studios, the language alone, or a couple of raw OpenGL/DirectX 
bindings isn't enough to be competitive with what comes in the 
box from the alternatives.
Nov 19 2020
prev sibling next sibling parent reply Guillaume Piolat <first.name guess.com> writes:
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?


I wrote an email after the first Jai video to to try D but Jon 
Blow just said:
"D is fine but it's not exactly what I'm looking for".

Blow seems to think there is a lot of native design space with 
plenty of things that would make a way better language than D.

He then went on to repeat many mistakes successfully avoided by D:
- new syntax
- lack of exceptions
- AST macros
- the SoA and AoS features can be replicated with one D template
- imperative build system
- unsafe CTFE
- "Jai will not have subtype polymorphism", let that sink in
...


Just a reminder than Blow is a bit extreme, he goes all in 
financially and almost went bankrupted for both Braid and the 
Witness.
Nov 18 2020
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 18 November 2020 at 17:23:17 UTC, Guillaume Piolat 
wrote:

 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?


 I wrote an email after the first Jai video to to try D but Jon 
 Blow just said:
 "D is fine but it's not exactly what I'm looking for".

 Blow seems to think there is a lot of native design space with 
 plenty of things that would make a way better language than D.

 He then went on to repeat many mistakes successfully avoided by 
 D:
 - new syntax
 - lack of exceptions
 - AST macros
 - the SoA and AoS features can be replicated with one D template
 - imperative build system
 - unsafe CTFE
 - "Jai will not have subtype polymorphism", let that sink in
 ...


 Just a reminder than Blow is a bit extreme, he goes all in 
 financially and almost went bankrupted for both Braid and the 
 Witness.


I don't think that those are mistakes if implemented properly.
Implementation quality is key.

Jai is already much faster than dmd is because it has a proper 
task and dependency system.
(Like SDC but more sophisticated.)

Personally I want to move dmd in a similar direction, but with 
the sprawling un-documented dependencies it's almost impossible 
to do.
Nov 18 2020
parent reply Guillaume Piolat <first.name gmail.com> writes:
On Wednesday, 18 November 2020 at 22:05:40 UTC, Stefan Koch wrote:

 On Wednesday, 18 November 2020 at 17:23:17 UTC, Guillaume 
 Piolat wrote:

 Blow seems to think there is a lot of native design space with 
 plenty of things that would make a way better language than D.

 He then went on to repeat many mistakes successfully avoided 
 by D:
 - new syntax
 - lack of exceptions
 - AST macros
 - the SoA and AoS features can be replicated with one D 
 template
 - imperative build system
 - unsafe CTFE
 - "Jai will not have subtype polymorphism", let that sink in
 ...


 I don't think that those are mistakes if implemented properly.
 Implementation quality is key.


Please let me disagree here.

Exceptions + RAII are super useful for reliable software, as 
shown in C++.

Subtype polymorphism is basically required for any type of UI.

Unrestricted CTFE? On the JaiPrimer.md page it reads:


 Download the OpenGL spec and build the most recent gl.h header 
 file
 Contact a build server and retrieve/send build data
 Talk to your Mars probe on Mars and wait for the packets to 
 come back and get a photo of what Mars looks like


That's 3 more attack vectors etc.

The list goes on and on, I think it has variable-sized integers 
too.
Nov 18 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 18, 2020 at 10:36:05PM +0000, Guillaume Piolat via Digitalmars-d
wrote:
[...]

 Unrestricted CTFE? On the JaiPrimer.md page it reads:
 

 Download the OpenGL spec and build the most recent gl.h header file
 Contact a build server and retrieve/send build data
 Talk to your Mars probe on Mars and wait for the packets to come back
 and get a photo of what Mars looks like


 
 That's 3 more attack vectors etc.


It's not just a security concern.  It also mixes diverse concerns (e.g.
build procedure vs. application logic vs. data acquisition) into one big
tangled hairball that represents a maintenance nightmare.

Build-specific logic is no longer restricted to the build scripts, now
*any* random piece of code *anywhere* in any source file can contain
build logic.  Or arbitrary network code that performs arbitrary network
operations while the code is compiling.  Y'know, like while the code is
compiling it starts editing a database on some remote server somewhere
and publishes stuff to Facebook.

And let's not mention build reproducibility, which goes right out the
window.  Good luck debugging your code, that modifies arbitrary remote
resources during compilation, and potentially "helpfully" reinstalls
your debugger for you while it's at it. Or reinstalls your entire OS,
for that matter.  You may argue, build scripts can already do this.  No
doubt -- but at least we knew where to look when things go wrong: in the
build scripts.  Now build logic can be sprinkled *anywhere* in the code.
There can be hidden "gems" slipped into the codebase by Johnny Junior
Programmer that does who knows what with the overall build logic.  Now
instead of debugging the build scripts, you're hunting for random bits
of build logic sprinkled all across the entire codebase.  It's an
undebuggable, free-for-all, wild-wild-west nightmare for maintenance.


T

-- 
The problem with the world is that everybody else is stupid.
Nov 18 2020
parent FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 19 November 2020 at 01:02:17 UTC, H. S. Teoh wrote:

 Build-specific logic is no longer restricted to the build 
 scripts, now *any* random piece of code *anywhere* in any 
 source file can contain build logic.  Or arbitrary network code 
 that performs arbitrary network operations while the code is 
 compiling.  Y'know, like while the code is compiling it starts 
 editing a database on some remote server somewhere and 
 publishes stuff to Facebook.

 And let's not mention build reproducibility, which goes right 
 out the window.  Good luck debugging your code, that modifies 
 arbitrary remote resources during compilation. [...]
 It's an undebuggable, free-for-all, wild-wild-west nightmare 
 for maintenance.


 T


Right, but if you're pulling in remote software with a package 
manager you *already* trust that that software is sane. Sure, 
with a Turing-complete build system those packages may be able to 
do arbitrary things on your systems - but if you don't check 
their code, they may be able to do arbitrary things on your 
*customers'* systems *anyway*, which is arguably worse. You 
already embrace this risk when you use packages.

I think stuff like reproducibility is better solved as 
convention. For instance, require that your package hoster get a 
clean test build for every published package, and limit network 
access during the test build.
Nov 18 2020
prev sibling next sibling parent Kagamin <spam here.lot> writes:
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?


I'd say jai provides gamedev-friendly tradeoffs, like trading 
correctness for agility, performance and features, which isn't 
good for other kinds of software.
Nov 18 2020
prev sibling next sibling parent reply elisecoen <elisecoen gmail.com> writes:
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?


I don't understand his secrecy, it makes the whole thing 
unnecessarily strange. Even fully public languages (like zig or 
nim) have a hard time getting enough recognition, what the hell 
is he trying to achieve with a compiler that was only seen by a 
handful of people? Just look at a successful project like rust 
and check out how many manhour is needed for something like that, 
it's insane. And most people don't even know rust exists.. Even 
if Jai is the most perfect language ever, it's still doomed. The 
language itself is a strange mutation of C, I don't see it 
becoming the next best thing because it doesn't actually do 
anything that is interesting enough to switch to it.
Nov 19 2020
next sibling parent starcanopy <starcanopy protonmail.com> writes:
On Thursday, 19 November 2020 at 12:47:08 UTC, elisecoen wrote:

 And most people don't even know rust exists..


How much truth is there to this? It's probably because of the 
little corner of the internet that I have carved out for myself, 
but I see discussions and posts about Rust in a lot of places--to 
a detriment, even. Further, Nim and Zig are also visible (more so 
than D).
Nov 19 2020
prev sibling next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 19 November 2020 at 12:47:08 UTC, elisecoen wrote:

 I don't understand his secrecy, it makes the whole thing 
 unnecessarily strange. Even fully public languages (like zig or 
 nim) have a hard time getting enough recognition, what the hell 
 is he trying to achieve with a compiler that was only seen by a 
 handful of people? Just look at a successful project like rust 
 and check out how many manhour is needed for something like 
 that, it's insane. And most people don't even know rust 
 exists.. Even if Jai is the most perfect language ever, it's 
 still doomed. The language itself is a strange mutation of C, I 
 don't see it becoming the next best thing because it doesn't 
 actually do anything that is interesting enough to switch to it.


The reason he doesn't release it, is because it's not done yet.
He does not want to release and unfinished or broken product.
Which is a good stance to take, both for once reputations as well 
for the users happiness.
Nov 19 2020
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 19 November 2020 at 12:47:08 UTC, elisecoen wrote:

 On Wednesday, 18 November 2020 at 16:13:20 UTC, Jack wrote:

 [...]


 I don't understand his secrecy, it makes the whole thing 
 unnecessarily strange. Even fully public languages (like zig or 
 nim) have a hard time getting enough recognition, what the hell 
 is he trying to achieve with a compiler that was only seen by a 
 handful of people? Just look at a successful project like rust 
 and check out how many manhour is needed for something like 
 that, it's insane. And most people don't even know rust 
 exists.. Even if Jai is the most perfect language ever, it's 
 still doomed. The language itself is a strange mutation of C, I 
 don't see it becoming the next best thing because it doesn't 
 actually do anything that is interesting enough to switch to it.


He is doing it for himself, he doesn't care to share it with the 
world.

Doing in-house languages is quite common in game studios.
Nov 19 2020
parent reply IGotD- <nise nise.com> writes:
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.
Nov 19 2020
parent Paulo Pinto <pjmlp progtools.org> writes:
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
Nov 19 2020
prev sibling next sibling parent reply starcanopy <starcanopy protonmail.com> writes:
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?


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.
Nov 19 2020
parent reply IGotD- <nise nise.com> writes:
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?
Nov 19 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
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).
Nov 19 2020
prev sibling parent starcanopy <starcanopy protonmail.com> writes:
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.
Nov 19 2020
prev sibling next sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
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.
Nov 19 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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?".
Nov 19 2020
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
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.
Nov 19 2020
next sibling parent reply Bruce Carneal <bcarneal gmail.com> writes:
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.
Nov 19 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Nov 19 2020
parent reply Bruce Carneal <bcarneal gmail.com> writes:
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".
Nov 19 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Nov 20 2020
parent reply Bruce Carneal <bcarneal gmail.com> writes:
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?
Nov 20 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Nov 20 2020
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 20 November 2020 at 16:12:35 UTC, Ola Fosheim Grøstad 
wrote:

 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.


The challenge is to provide as much readily accessible power as 
you can safely and correctly.  It is a language design error to 
promise something that you can not check automatically/correctly 
in the compiler.  If a language has such errors it needs an 
upgrade.

I also consider it an language design error to have defaulted to 
unsafe modes.  Things should default to safe/correct with opt-out 
capability to fast/dangerous. (I support  safe as default, for 
example, just not the extern(C) == safe nonsense)


 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.


If "it", whatever that is, precludes safe parallelism in 
libraries or language extensions then "it" should be removed from 
the language.

Again, defaults really matter here.  If the right way is the 
default way then leaving the "wrong" way escape hatch costs less, 
in my view, than forcing two or more languages.
Nov 20 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 21 November 2020 at 01:52:36 UTC, Bruce Carneal 
wrote:

 If "it", whatever that is, precludes safe parallelism in 
 libraries or language extensions then "it" should be removed 
 from the language.

 Again, defaults really matter here.  If the right way is the 
 default way then leaving the "wrong" way escape hatch costs 
 less, in my view, than forcing two or more languages.


Well,  safe just means memory safe, not sure if it is meant to 
also cover multi threading safety?

The guarantees are not very clear to me.

It is also not clear what happens if you allocated something as 
shared, cast away shared and the call free(). Are you allowed to 
have two separate heaps?

It is unclear if D programmers follow the same principles or just 
rely on testing with the current runtime. If it is the latter 
then it will be difficult to get clean nonbreaking  semantics.
Nov 20 2020
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Saturday, 21 November 2020 at 02:42:13 UTC, Ola Fosheim 
Grostad wrote:

 On Saturday, 21 November 2020 at 01:52:36 UTC, Bruce Carneal 
 wrote:

 If "it", whatever that is, precludes safe parallelism in 
 libraries or language extensions then "it" should be removed 
 from the language.

 Again, defaults really matter here.  If the right way is the 
 default way then leaving the "wrong" way escape hatch costs 
 less, in my view, than forcing two or more languages.


 Well,  safe just means memory safe, not sure if it is meant to 
 also cover multi threading safety?

 The guarantees are not very clear to me.


I've only read about  safe referring to the memory safety that 
you noted.


 It is also not clear what happens if you allocated something as 
 shared, cast away shared and the call free(). Are you allowed 
 to have two separate heaps?


I don't have a comprehensive understanding of where D is at and 
where it is headed wrt memory safety models.  The  live stuff 
looks a little "iffy".  Hopefully Walter's upcoming talk will 
help.


 It is unclear if D programmers follow the same principles or 
 just rely on testing with the current runtime. If it is the 
 latter then it will be difficult to get clean nonbreaking  
 semantics.


As you note, some language advances may not be practical for D 
but others could be built atop extant automated/correct checking 
and some could be independent, never-existed-before, capabilities 
where backward compatibility is not a concern: type functions, 
monadic type variables, new memory guarantees, arbitrarily 
prolonged "compile time", ...
Nov 20 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 21 November 2020 at 05:51:53 UTC, Bruce Carneal 
wrote:

 I don't have a comprehensive understanding of where D is at and 
 where it is headed wrt memory safety models.  The  live stuff 
 looks a little "iffy".  Hopefully Walter's upcoming talk will 
 help.


Yes, it will be interesting to see where D is headed.

Right now I think maybe automatic reference counting for dynamic 
arrays and class objects would go a long way, but...

The more I think about it, the more it makes sense to add Actor 
as a compiler construct and let that represent one thread (heavy 
or light). Then that Actor can have its own collection strategy 
and provide its own allocator in TLS. So for instance if most 
objects in that Actor is 100 bytes then it can have a separate 
heap for those. This can be profiled. Or if the Actor is short 
lived with low memory usage, just use a bump-allocator.


 As you note, some language advances may not be practical for D 
 but others could be built atop extant automated/correct 
 checking and some could be independent, never-existed-before, 
 capabilities where backward compatibility is not a concern: 
 type functions, monadic type variables, new memory guarantees, 
 arbitrarily prolonged "compile time", ...



I do at least hope that there will be clean guarantees for shared 
and nonshared memory, so that you can keep them on separate heaps 
and avoid atomics in allocators etc.

There is a need to list the language constraints that are needed 
to get semantic/runtime improvements. Some kind of matrix, 
perhaps.
Nov 21 2020
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Nov 19 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
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.
Nov 20 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Nov 20 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 20 November 2020 at 12:57:24 UTC, Ola Fosheim Grøstad 
wrote:

 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.


You're basically saying the same thing....for the most part. 
However, I see most people think that's all it entails when they 
write D code like Java code. Every language has its own idiomatic 
way of doing things and its own tricks.
Nov 20 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 20 November 2020 at 20:22:14 UTC, aberba wrote:

 they write D code like Java code. Every language has its own 
 idiomatic way of doing things and its own tricks.


Right, but it is important to keep in mind that those idioms are 
cultural constructs, so if the language is flexible like D, you 
need to be smart on a cultural level to establish "code interface 
norms". This is where having gc, nogc, betterC etc can become a 
serious problem.
Nov 20 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 20 November 2020 at 22:29:39 UTC, Ola Fosheim Grostad 
wrote:

 On Friday, 20 November 2020 at 20:22:14 UTC, aberba wrote:

 they write D code like Java code. Every language has its own 
 idiomatic way of doing things and its own tricks.


 Right, but it is important to keep in mind that those idioms 
 are cultural constructs, so if the language is flexible like D, 
 you need to be smart on a cultural level to establish "code 
 interface norms". This is where having gc, nogc, betterC etc 
 can become a serious problem.


My point is the GC-nogc computer is never an issue for me. Its 
just makes D useful for many other domains that I'm interested in.

So you'll have to look at the kind of software you write.
Nov 21 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 21 November 2020 at 11:06:45 UTC, aberba wrote:

 My point is the GC-nogc computer is never an issue for me. Its 
 just makes D useful for many other domains that I'm interested 
 in.

 So you'll have to look at the kind of software you write.


Well, if nogc is going to be an alternative to C++/Rust then 
something has to be done as interfacing implies a  of risk 
confusing gc memory with nongc memory. Most interesting code is 
building a graph of some sort.

Basically, it should be easy to write a library that is both 
nongc and gc at the same time.

It implies that owning pointers basically has to be templated, 
with a retention mechanism for nogc code.
Nov 21 2020
prev sibling next sibling parent reply J. V. <jv jv.com> writes:
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 

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.
Nov 19 2020
parent J. V. <jv jv.com> writes:
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.
Nov 19 2020
prev sibling parent reply Ethan <gooberman gmail.com> writes:
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?")
Nov 20 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Nov 20 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 20 November 2020 at 18:44:33 UTC, H. S. Teoh wrote:

 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.


If this is the only issue, then it can be fixed with caching?
Nov 20 2020
prev sibling parent reply Ethan <gooberman gmail.com> writes:
On Friday, 20 November 2020 at 18:44:33 UTC, H. S. Teoh wrote:

 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?


I can rewrite Binderoo with type functions, which essentially 
take one type (user or function types) and transform it in to 
something else.

But higher level. It will fundamentally change the way you 
approach metaprogramming. Even now, we have that thing that 
Andrei will say about C++. Where D is multiple languages under 

in to DbI and it's a different language you need to learn. So I 
put it this way.

"Can you write a function?"
"Yes."
"Then you can do hardcore metaprogramming."

It's going to be a paradigm shift to get it in to a language like 
this.
Nov 20 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 20, 2020 at 09:20:19PM +0000, Ethan via Digitalmars-d wrote:
[...]

 "Can you write a function?"
 "Yes."
 "Then you can do hardcore metaprogramming."
 
 It's going to be a paradigm shift to get it in to a language like
 this.


+1, I like that.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??
Nov 20 2020
parent reply Ethan <gooberman gmail.com> writes:
On Friday, 20 November 2020 at 22:09:14 UTC, H. S. Teoh wrote:

 +1, I like that.


Separately. Programmers that have no interest in D that I've 
spoken to, when I say "first class types are being pursued" they 
immediately have interest.

This isn't the thread for it. But there's _SERIOUSLY_ a big win 
to getting that in as a feature.
Nov 20 2020
parent Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 20 November 2020 at 23:19:50 UTC, Ethan wrote:

 On Friday, 20 November 2020 at 22:09:14 UTC, H. S. Teoh wrote:

 +1, I like that.


 Separately. Programmers that have no interest in D that I've 
 spoken to, when I say "first class types are being pursued" 
 they immediately have interest.

 This isn't the thread for it. But there's _SERIOUSLY_ a big win 
 to getting that in as a feature.


+1

Templates are great when used declaratively, as simple patterns 
that get filled in (aka templates).  They can be pressed in to 
service as "functions" but it's a bad fit.  Type functions would 
help, a lot, but there's more.
Nov 20 2020