3 ms·

> Tup's main problem is it's unusual, and it doesn't have a library of build rules. But it's fast! To be honest, the only time I haven't felt like an army of b

> Tup's main problem is it's unusual, and it doesn't have a library of build rules. But it's fast! To be honest, the only time I haven't felt like an army of build rules isn't a weight I have to carry uphill is when I use Lein (which is more of a build project tool as opposed to something as elemental as tup). Systems like SBT and Ant end up with things that feel to me like a complete and total reliance on hand-tooled plugins as opposed to a reliance on executing pre-existing executables. Gulp is the same way; even though there are perfectly serviceable and stream-like executables on every OS ready for use, Gulp insists you write more javascript to glue things into its awkward model. Maybe that's not the end of the world (as opposed to yet another make-like DSL), but in cases with truly and almost comically incomprehensible codebases like SBT (oh SBT team, every time you "simplify" your codebase you totally miss the point we don't care about your abstractions and just need to write command extensions) or Gulp (oh Gulp team, please make Gulp more like Storm/Trident or Hakyll's buidler arrows so it does more than just compile javascript and sass) then you're totally out of luck. And when we consider GNU Automake and Autoconf that do have a ton of prebuilt rules, we see an even more dire situation: where the language describing the rules is more complicated than the underlying concepts they service.

moron4hire 10y ago
The one thing I like about Gulp is that it makes it easy to make a project out of your build process, to basically enforce your own convention over configuration. I have a single, canonical build process for all of my projects and it gets installed through NPM like every other dependency. The individual gulpfiles for my projects end up being very simple and readable. It has the side effect of drastically cleaning up my package.json file, too. The only other thing I like about Gulp is that it works without too much hassle on Windows and *Nix. Other than that, it's dung. Though it's certainly better than Grunt, it's not objectively good. That seems to be a problem with a lot of things these days, "relative better than the alternatives, not something you'd actually want on its own merits."
- KirinDave 10y ago
  Recently I had a local Gulp expert who had written a plugin try and help me with a simple problem: I produce a .json of load balancers from a CF stack. We need to run a command on every entry in the map to annotate it with extra information from another AWS call. It's a tricky problem not amenable to usual shell scripting (unless you use a shell with a native notion of maps and json). For the life of us, we could not find a way to make Gulp do this without essentially writing a solid block of Javascript that just does exactly what we wanted (in which case, why use anything but the shell script approach?). I understand that stream rejoining is a complex problem, but Gulp seems ideologically opposed to a more generic approach here. They get mad when people try to inject non-file based values into the system, and actively close off alternatives and shame them on their github issues. Gulp is a complete mess, in my opinion.
  - qwertyuiop924 10y ago
    Totally. Brocoli and Brunch are a bit better, but they all have the same fundamental problem: they require you to write plugins for things. The plugin model doesn't work here because writing plugins is so difficult, and you don't want to write this crap: you just want your project to build. In addition, all of the things you want to use in a build process expose a perfectly good shell interface, which probably streams, and doesn't require anybody to write hundred-line projects to integrate into the build system. Which just begs the question: Why aren't we using shell, and make, or npm run?
    - KirinDave 10y ago
      Aside, I had a similar question when I learned PowerShell. It made me question even why I was writing so many script executables. If we rely are devoted to using reusable and small components then a shell that can directly wrap our standard libraries (and has a type system rich enough to express maps and tree types) is indispensable to truly reusable software. Then what a make system should be is a clear and smart way to express dependencies and workloads.
      - qwertyuiop924 10y ago
deleted 10y ago
[deleted]

moron4hire 10y ago

The one thing I like about Gulp is that it makes it easy to make a project out of your build process, to basically enforce your own convention over configuration. I have a single, canonical build process for all of my projects and it gets installed through NPM like every other dependency. The individual gulpfiles for my projects end up being very simple and readable. It has the side effect of drastically cleaning up my package.json file, too. The only other thing I like about Gulp is that it works without too much hassle on Windows and *Nix. Other than that, it's dung. Though it's certainly better than Grunt, it's not objectively good. That seems to be a problem with a lot of things these days, "relative better than the alternatives, not something you'd actually want on its own merits."

KirinDave 10y ago
Recently I had a local Gulp expert who had written a plugin try and help me with a simple problem: I produce a .json of load balancers from a CF stack. We need to run a command on every entry in the map to annotate it with extra information from another AWS call. It's a tricky problem not amenable to usual shell scripting (unless you use a shell with a native notion of maps and json). For the life of us, we could not find a way to make Gulp do this without essentially writing a solid block of Javascript that just does exactly what we wanted (in which case, why use anything but the shell script approach?). I understand that stream rejoining is a complex problem, but Gulp seems ideologically opposed to a more generic approach here. They get mad when people try to inject non-file based values into the system, and actively close off alternatives and shame them on their github issues. Gulp is a complete mess, in my opinion.
- qwertyuiop924 10y ago
  Totally. Brocoli and Brunch are a bit better, but they all have the same fundamental problem: they require you to write plugins for things. The plugin model doesn't work here because writing plugins is so difficult, and you don't want to write this crap: you just want your project to build. In addition, all of the things you want to use in a build process expose a perfectly good shell interface, which probably streams, and doesn't require anybody to write hundred-line projects to integrate into the build system. Which just begs the question: Why aren't we using shell, and make, or npm run?
  - KirinDave 10y ago
    Aside, I had a similar question when I learned PowerShell. It made me question even why I was writing so many script executables. If we rely are devoted to using reusable and small components then a shell that can directly wrap our standard libraries (and has a type system rich enough to express maps and tree types) is indispensable to truly reusable software. Then what a make system should be is a clear and smart way to express dependencies and workloads.
    - qwertyuiop924 10y ago

deleted 10y ago

[deleted]