On Friday, 21 September 2018 at 06:30:40 UTC, Walter Bright wrote:
> On 9/20/2018 10:11 PM, mate wrote:
>> Note that the build can be done at compile time because the metaprogramming capabilities of the language are not limited in terms of system calls.
>
> Back in the naive olden days, Microsoft released ActiveX, where a web page could load executable objects (!) from the internet and run them in the browser.
>
> It quickly became apparent that this was a disaster, as lots of people on the internet aren't to be trusted.
>
> CTFE on D doesn't allow making any system calls. This is on purpose.

The usual argument against this is that source code distributions already usually include some sort of build or installation script (be it in the form of "configure", or a makefile, or a Visual Studio project), which can already execute arbitrary commands.

The problem with putting it in the compiler is that it invalidates many contracts (and, thus, use cases) about what invoking the compiler can do. This means you can't bisect or reduce (as with Dustmite) the source code reliably. Reproducible builds are out too, as the produced object file is no longer purely a function of the source code and compiler version.

On Friday, 21 September 2018 at 06:34:47 UTC, Vladimir Panteleev wrote:
> The problem with putting it in the compiler is that it invalidates many contracts (and, thus, use cases) about what invoking the compiler can do. This means you can't bisect or reduce (as with Dustmite) the source code reliably.

I am not able to see the difference it makes. Normally when you bisect you build the program to test using the build system. Is not it equivalent to what the Jai compiler would do?
What cases do you have in mind?

> Reproducible builds are out too, as the produced object file is no longer purely a function of the source code and compiler version.

It depends on the developer not doing anything stupid in the build instructions, be it compiler-executed or not. Doesn’t it?

On 9/21/2018 12:19 AM, mate wrote:
> It depends on the developer not doing anything stupid
Aye, there's the rub!

On Thursday, 20 September 2018 at 23:13:38 UTC, aliak wrote:
> you can create your build recipe inside the program

But this is not a particularly good idea and is even against the times.

Everyone is moving from powerful languages like makefiles to _less_ powerful languages (like dub.json) to describe how programs are built. Why is that so?

The reasons we have dpldocs.info, dub test, dub build etc. are entirely because we use a _restricted_ DSL to build D programs. If we were all doing makefiles, it's easy to see there would be no common structure hence no automated doc generation, testing etc. Like a C project!

There is a shift from imperative to declarative for build recipes in all other modern languages and Jai has made (yet another) wrong choice.

On Friday, 21 September 2018 at 06:02:26 UTC, mate wrote:
>
> I am actually not sure if there really are no limitations to Jai’s CTFE, in its current state.

What I like with unrestricted CTFE is that it makes something that was completely safe a security problem.

On Friday, 21 September 2018 at 07:37:14 UTC, Walter Bright wrote:
> On 9/21/2018 12:19 AM, mate wrote:
>> It depends on the developer not doing anything stupid
> Aye, there's the rub!

;-)

Different sensibilities on where to put restrictions clearly lead to different designs. I am not sure myself what is best.

I agree that one would need to realize that compiling a program could potentially be harmful, and that could be a significant change in one’s habits.

On Friday, 21 September 2018 at 07:19:41 UTC, mate wrote:

>> Reproducible builds are out too, as the produced object file is no longer purely a function of the source code and compiler version.
>
> It depends on the developer not doing anything stupid in the build instructions, be it compiler-executed or not. Doesn’t it?

I realize that with build instructions written in unrestricted language it is easier to create a dependency on something else than the compiler, such as the OS. Maybe they plan to solve this problem with appropriate facilities and discipline.

With standard build systems, the produced object file can depend on some specific state of the OS too (I think there were Windows updates influencing how VisualStudio was producing object files).

On Thursday, 20 September 2018 at 23:13:38 UTC, aliak wrote:
> Alo!
>

I have been watching Jonathan Blow's Jai for a while myself. There are many interesting ideas there, and many of them are what made me like D so much in the first place. It's very important to note that the speed claims he has been making are all a matter of developer discipline. You can have an infinite loop executed at compile-time in both D and Jai. There's nothing magical Jai can do about that - the infinite loop is not going to finish faster ;) You can optimize the speed of compile-time computation just like you can optimize for run-time speed.

What your observing with D is that right now many libraries including Phobos have tried to see how much they can push the language (to make for more expressive code or faster run-time) and not as much time has been spent on optimizing compile-time. If you take a code-base written in Java-like subset of the language, I can grantee you that DMD is going to very competitive to other languages like C++, Go, Java or C#. And that's considering that there are many places that could be optimized internally in DMD. But overall most of the time spent compiling D programs is: a) crazy template / CTFE meta-programming and b) inefficient build process (no parallel compilation for non-separate compilation, no wide-spread use of incremental compilation, etc.). AFAIR, there were several projects for a caching D compiler and that can go a long way to improve things.

With а build system like reggae[0] written in the same language as the one being compiled, the line between compile-time vs run-time becomes quite blurred. If the build system part of your project compiles fast enough, ultimately it doesn't matter if it runs at compile-time vs run-time. The only important part is whether the build system is pleasant to work with - e.g. having a concise declarative syntax that covers 80% of the cases while also exposing a procedural interface for the difficult parts that don't fit in the nice model. And all nice declarative abstractions have a procedural implementations that one needs write first.

On the other hand, there are things that are much better done at compile-time, rather than run-time like traditional meta-programming. My biggest gripe with D is that currently you only have tools for declaration-level meta-programming (version, static if, static foreach, mixin template), but nothing else than plain strings for statement-level meta-programming. CTFE is great, but why re-implement the compiler in CTFE code, while the actual compiler is sitting right there compiling your whole program ;)

P.S.

Jai:
loadExecutableIcon(myIcon, exeLocation)

D:
static immutable ubyte[] icon = import("image.png).decodePng;

(In D you have read-only access to the file-system at compile-time using the -J flag.)

[0]: https://github.com/atilaneves/reggae

On Friday, 21 September 2018 at 07:58:16 UTC, mate wrote:
> Different sensibilities on where to put restrictions clearly lead to different designs. I am not sure myself what is best.

The more people you have on your team, the more you appreciate the restrictions. If you are working on a personal project alone, you are in control and have full knowledge of the entire codebase, so restrictions are a hindrance. When you are collaborating with someone you know only by name from across the globe, being able to reason what their code might or may not do is considerably helpful.

On Friday, 21 September 2018 at 07:37:14 UTC, Walter Bright wrote:
> On 9/21/2018 12:19 AM, mate wrote:
>> It depends on the developer not doing anything stupid
> Aye, there's the rub!

The evolution of programming language discussions from "sufficiently smart compiler" to "sufficiently smart programmer using a sufficiently smart compiler".