Jai compiles 80,000 lines of code in under a second

Nick Sabalausky (Abscissa) SeeWebsiteToContactMe at semitwist.com
Fri Sep 21 02:44:57 UTC 2018


On 09/20/2018 07:13 PM, aliak wrote:
> 
> On a related note: He also mentions some really cool compilation 
> features like having compiler hooks that tell you when compilation is 
> done, when executable and where it will be written so you can create 
> your build recipe inside the program itself. Also allows you do do 
> things like:
> 
> whenCompilationFinishes(exeLocation) => loadExecutableIcon(myIcon, 
> exeLocation)
> 
> During the build!
> 
> Your source knows how to build itself as a concept is awesome! There's 
> actually a D runner [1] that kind of allows for source files to set 
> stuff up.
> 
> [0] https://www.youtube.com/watch?v=uZgbKrDEzAs
> [1] https://github.com/marler8997/rund

Just watched that part of the video. It sounds like it really just boils 
down to these three things:

1. He did away with C/C++'s awful header system, just like every other 
language out there.

(It's a good thing, but it's also a bare minimum expectation in ANY 
language that isn't C or C++. Yawn.)

2. He created a standard (and presumably mandatory) build tool to go 
along with his language, but is avoiding *calling* it a build 
tool...even though it's clearly just a build tool that happens to be 
built into the compiler.

(I've already used a language that did that: Haxe. There are definitely 
some nice things about it, but the problem is: What happens when the 
official buildsystem doesn't fit your needs? Your pretty much SOL. Just 
imagine if DUB was the ONLY way to compile D and you get the picture of 
why this isn't as great as it sounds. And even if his compiler DOES let 
you opt-out of the official built-in buildsystem, it's ultimately still 
just yet another buildsystem, nothing inherently special or new except 
for...)

3. You can embed your buildscript into one of your project's existing 
source files, instead of putting it in a dedicated buildscript file.

(We can do that in D too, by utilizing version identifiers, but we don't 
because its messy and mostly pointless. Just like you wouldn't put your 
graphics code in an XML-parsing module, or your JSON serializer in an 
audio-mixing module. They each get their own file or dir. Basic 
separation of concerns. For one-file scripts, this IS actually really, 
really nice though, which is why I like both rund and DUB's embedded 
dub.sdl. But aside from one-file scripts, there's not much point to 
avoiding basic separation-of-concerns.)


More information about the Digitalmars-d mailing list