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.
