Dub, Cargo, Go, Gradle, Maven

[H. S. Teoh]

On Thu, Feb 22, 2018 at 09:24:05AM +0000, Russel Winder via Digitalmars-d wrote:
> On Wed, 2018-02-21 at 09:30 -0800, H. S. Teoh via Digitalmars-d wrote:
[...]
> Dub, Cargo, and to a great extent Maven, give you tools to specify
> declaratively the project and nothing else. All actions are pre-defined 
> and you have to work within the convention or not at all. The tool
> allows no trust of the people working on the project to do the right
> thing.

And this is what I find frustrating about this way of implementing the
declarative approach.  It's an all-or-nothing proposition: either you
confine yourself to work within the model set down by the author, or
you're left out in the cold. There is no compromise.

IMO, the correct approach is to *empower* the user, not to force the
user to conform to a prefabricated mold.  I think this is actually
orthogonal to the whole declarative/imperative divide; I can conceive of
models where a declarative approach empowers, rather than restricts, the
user.  It all depends on what is laid down in the foundations.  A good
design ought to consist of a small number of orthogonal primitives with
obvious semantics, but the combinations of which give you maximal
expressive power.

SCons comes pretty close to this: while it has a whole bunch of very
useful built-in functionality, it also exposes the lower-level
primitives used to build those functionalities in the first place. E.g.,
scanners, generators, etc..  This is what I mean by empowering the user.
It lets you use the same tools the author used to create the
higher-level constructs, as opposed to saying "we don't support X; if
you want X, you'll just have to write it from scratch in bare Python".
Which is better than not being able to do anything at all outside of the
author's prefabricated model (e.g., dub), but still essentially
amounting to "what you want to do is not our department; here's the
escape hatch to leave the building, you're on your own".

You don't necessarily need a full-fledged programming language to work
with -- my SConscripts quite often consist of custom Environment methods
that are basically just abstractions of a bunch of calls to Depends and
Command. Very few things actually require full-out Python.


[...]
> Taking all the lessons of Dub and Reggae is clearly important, but
> then is the strategy to amend Dub and merge Reggae or start a new
> codebase? 

I think it depends on how fundamental of a change we're looking at.  So
far, I've not found a single build tool that meets my ideal of a small
number of orthogonal yet powerful primitives that, combined together,
yields maximal expressive power.  SCons comes pretty close, but it does
have its inherent limitations.


[...]
> I still find Meson constraining for anything not fitting that standard
> project model. Indeed it was the Meson developers who stated that for
> one of my projects I had to use the "drop down to Python", there was
> no other way of handling things.

So that probably means Meson is not for me.  I can't stand having to
work within arbitrarily-defined standard project models that are imposed
without any clear reason why it is absolutely indispensible.  Saying
"drop down to Python" to me is basically showing you the door and saying
"you're on your own".  At least it's better than having no door at all,
like in dub where you're either in, or out in the cold; there is no
compromise, not even an escape hatch.


> Whilst I will use Meson for Debian related builds when I can (Meson is
> approved, SCons is not) I am still an advocate for internal DSL in a
> programming language, and make sure that good build people do the most
> declarative, least complex thing.
[...]

The good thing about using a programming language as DSL is that if said
language is well-known, it alleviates the need for the user to learn yet
another DSL.  In this day and age of new DSLs popping up like dandelions
in a field, people just don't want to have to learn something new unless
they absolutely have to.  In that vein, since we're talking about builds
in D, one good idea might be to have a DSL that's essentially a subset
of D.  I.e., actually a different language, but one that happens to look
like a subset of D, with comparable semantics.  That saves us from
having to deal with Turing-completeness in a build script, yet at the
same time retain to some degree the comfort of not needing to learn Yet
Another Different Language.


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely repeat each other.