Git, the D package manager

[Jacob Carlborg via Digitalmars-d]

On 2015-02-08 17:57, Andrei Alexandrescu wrote:

> Ehm. This part sounds unnecessarily a bit political - NIH syndrome,
> closemindedness of the D folks toward using anything else but D and
> make, and such.

I'm just sharing my experience since I've tried this before. I would not 
recommend using any other language than D unless it has the community's 
blessing. I'm just trying to save him the trouble.

> I do remember one action I took "against" Ruby - replacing a 109 line
> Ruby installer script with 13 lines of makefile code:
> https://github.com/D-Programming-Language/installer/pull/10/files. It
> would be difficult to construct an argument against that work.

I specially remember you saying something along the lines that it took 
me two years to consider D instead of Ruby for Orbit.

> Ruby and Python have all my respect as an outsider of their respective
> communities: they have users who enjoy them and get work done using
> them. That's always a good thing in my book.
>
> That said, I wouldn't feel easy appealing to Ruby or Python for D
> internal work for reasons that I consider entirely practical and
> non-political:
>
> * One more language for the maintainers to know and use.

Same thing with make or shell scripts.

> * One more dependency. Although scripting languages are ubiquitous
> enough, I can tell from direct experience that versioning and dependent
> packages can be quite a hassle.

Only for building the tool. The scripting language would be built-in to 
the executable.

> * Escaping into a high-level language seems as much "cheating" as
> escaping into a low-level language. If C or C++ would be needed instead
> of D for a task, it is worthwhile exploring how to make D a better
> replacement for them . This has been historically a good and important
> goal to pursue. Similarly I'd rather explore what it takes to expand D
> into high-level territory instead of escaping into a high-level language.

It's just that the syntax Ruby has, in my opinion, is better suited for 
a declarative DSL, i.e. call methods without parentheses, 
blocks/trailing delegates, top level execution of code.

-- 
/Jacob Carlborg