On Tuesday, 16 September 2014 at 21:05:18 UTC, K.K. wrote:
On Tuesday, 16 September 2014 at 20:53:08 UTC, Cliff wrote:
Would you be willing to provide some more detail on what about
it
you didn't like (errors, missing features, etc.)? I ask
because
build systems are a particular interest of mine and I have
projects in this area which can always use more user data.
I'll try, but I haven't used it at all since maybe.. April?
One of the main things that annoyed me about it was how
sensitive
it could be. The best comparison I can give is that it reminded
me ALOT of Haxe. Both are very flimsy, and very poorly
documented. (Nothing beats a good manual as far as I'm
concerned!)
The other thing, as I briefly mentioned, was it really didn't
speed anything up, unless maybe you were working on a larger
project.
Obviously I'm not a master of any sort, but the main point I'd
take from this is it wasn't inviting.
Hope that helps a bit :3
Yep, that's useful information to me. Over the years I have
found that build systems *generally* tend to be uninviting. My
suspicion is that comes down to a few reasons:
1. Builds end up being a LOT more complicated that you would
expect as soon as you step out of a single project with a few
source files and default options
2. Build tooling is typically built and maintained by people who
end up being relatively specialist - either they are part of the
small cabal of people who know the tooling intimately, or they
have been forced into it and know just enough to get by for their
organization.
3. Most build tooling is designed to solve a particular subset of
actual build-related problems, with much less though given to how
it fits holistically into the entire developer workflow.
4. Build tooling is almost never treated like an actual product -
documentation is written for wizards, not lay-people.
As a result, the casual user is a bit SOL.
(NOTE: This is not a rant specifically aimed at DUB, but my
general observation on the state of build tooling.)
