Timeline for Why do build tools use a scripting language different than underlying programming language?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 22, 2015 at 10:46 | comment | added | biziclop | @MasonWheeler I think that is as much a problem of the people who designed the config language than XML itself. The common mistake by authors of such languages is to assume that just because something is in XML, it will automatically be human-readable. (I know I've made this mistake more times than I'm comfortable with. It's so tempting.) A well-designed and lean configuration language can work just as well over XML as in any other form. | |
| Sep 22, 2015 at 9:54 | comment | added | Mason Wheeler | @SteveJessop: I would agree with your original position, actually. The problem with XML isn't that it's verbose per se, but that it's filled with required syntactical elements that add no useful information, and thus detracts from human-readability rather than enhancing it. A lot of times a verbose programming language says stuff that a smart compiler can infer and isn't strictly necessary, but having that information around still makes the code it easier for a human to read. But XML's close tag names just turn it into messy tag soup, and a pretty-printer makes them redundant. | |
| Sep 22, 2015 at 9:46 | comment | added | Steve Jessop | @MasonWheeler: purely declarative languages will hit problems in build systems, and XML-based languages often hit problems for all tasks. XSLT is what convinced me that my original position, "a programmer spends such a tiny proportion of the time typing, that verbose languages aren't problematic for that reason" is not strictly true. So declarative XML build systems hit a double whammy. | |
| Sep 22, 2015 at 9:18 | comment | added | gbjbaanb | @MasonWheeler I totally agree - having had the nightmare that is a XAML-based declarative build script when I wanted to edit a TFS build, I quickly realised why Jenkins and its "just run a batch script" is vastly superior. And smaller. And easier to maintain (ie possible to maintain). Declarative approaches may seem ideal for 1 or 2 steps but always end up in a horror of nested declarations if you have anything more complex (ie practically everything in the real world) | |
| Sep 21, 2015 at 20:46 | comment | added | Andres F. | @supercat Sure, I do not dispute that make files are hybrid systems. Hence "more declarative/high-level", not "exclusively declarative". | |
| Sep 21, 2015 at 20:39 | comment | added | supercat | @AndresF.: Things like make files require a mixture of approaches. The desired output state is specified declaratively, but the actions necessary to achieve that state are specified imperatively. | |
| Sep 21, 2015 at 19:05 | comment | added | Mason Wheeler | Fair enough. I've always figured C is one of those "if X is the answer you're asking the wrong question" technologies, to be perfectly honest; it's just that working with XML "scripts" has been a nightmare every time I've had to dive into one. I agree that a higher-level imperative language with DSL capabilities would be ideal. | |
| Sep 21, 2015 at 19:02 | comment | added | Andres F. | @MasonWheeler There are cases where existing build tools have made me suffer, yes. None of them would have been helped by using a low-level C-like imperative language. I see something like Ruby as probably ideal: declarative and imperative enough, as needed. C would give me nightmares for this task. To me build systems are a good use case for (mostly) declarative DSLs: you care about what to do, not about how to do it (most of the time). | |
| Sep 21, 2015 at 18:57 | comment | added | Mason Wheeler | Imagine the pain and boilerplate of writing a makefile (or build.xml, or whatever) in C. Imagine the pain and mess of trying to express non-trivial conditional logic (you know, standard imperative stuff) in a declarative XML script. Oh, wait, you don't have to imagine; you've probably had to deal with it, and it was probably a mess and a half, wasn't it? Builds are one of the worst possible choices for a declarative scripting language, because serious problems quickly end up butting up against the limits of declarative-ness, and the ones that don't are simple enough to not need a build tool. | |
| Sep 21, 2015 at 18:23 | history | answered | Andres F. | CC BY-SA 3.0 |