D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Jacob Carlborg]

On 2018-03-30 08:53, Dmitry Olshansky wrote:

> With the frame of mind prevalent in our Industry I really want to have 
> compiler includibg codegen as a bunch of library components.
> 
> Then there is no problem innovating while people argue over things 
> “allowed” for a compiler, or a linker, or a build tool. None of these 
> actually have to be apps talking via files.
> 
> If I look closely every program I see is a graph database, with nodes 
> sometimes being code, types, sometimes data, other meta-data such as ABI 
> attributes or conditional compilation flags, documentation, external 
> tools, specs and databases are also part of this. Code that produces 
> code is also part of such graph, and CTFE/macroses would just be finer 
> grained approach.
> 
> Why process graphs piece-wise in a frentic dance of command-line tools 
> that try to fit all to a tree of files (multiple ones, in many location, 
> and part in some CMS) and then have editors/IDEs integrate? Was easier I 
> believe + inertia, easy != simple though.

I completely agree. I was quite surprised when I started to use libclang 
and the only way to pass options to the library (which are usually 
command line flags) was to pass it as an array of command line options. 
This is the C API, the C++ API is more advanced.

-- 
/Jacob Carlborg