shake VS sd

Another interesting implementation is Shake: https://shakebuild.com/

It is technically a Haskell DSL, but supports Ninja files, time estimates and has tools for linting and profiling.

They explicitly refer to Shake build system and Build Systems a la Carte paper.

The one paper that gave me hope about build systems was Build systems à la carte: Theory and practice, by Andrey Mokhov, Neil Mitchell, and Simon Peyton Jones. Among other things, it describes the theoretical underpinnings of the Shake build system. To be honest I believe any build system that ignores the maths described in this paper can safely be ignored. (You may however ignore the paper itself if the maths checks out. See Daniel J. Bernstein's redo, which matches Shake very closely.)

Yeah, they don't have to be terrible. I haven't used it, but people in my circles tend to really like Shake, which uses a Haskell embedded DSL to describe builds.

You could try Shake. It's a sane build system written by a former co-worker of mine. https://shakebuild.com/

Shake does require compilation as it's essentially just a Haskell library providing a DSL and it works just fine, I guess in gradle's case it's a thing about Java-typical overengineering and complete blindness to resource usage. Shake's underlying engine can actually go head-to-head with ninja itself when building ninja files.

Did you look at shake: https://shakebuild.com/ ?

https://shakebuild.com/ agrees with you:

> Large build systems written using Shake tend to be significantly simpler, while also running faster. If your project can use a canned build system (e.g. Visual Studio, cabal) do that; if your project is very simple use a Makefile; otherwise use Shake.

For what it's worth, if I remember right, Shake has some support for interpreting Makefiles, too.

> [...] the way more complicated syntax of Shake [...]

For context, Shake uses Haskell syntax, because your 'Shakefile' is just a normal Haskell program that happens to use Shake as a library and then compiles to a bespoke build system.

View on GitHub

I'll throw in sd as a nice sed/find-and-replace tool. Using fd + xargs + sd is a pretty good workflow if a shell glob isn't good enough to target the files you want. https://github.com/chmln/sd

I wanted to like sd but it doesn't support my main use case of recursive search/replace. Imagine every time you wanted to grep some files you had to build a find+xargs+rg pipeline... it just takes me out of the flow too much. I'm glad people are posting other options here, I'm looking forward to trying them.

https://github.com/chmln/sd/issues/62

sd

https://github.com/chmln/sd ftw (sed rebuilt in rust, much easier imho) ;-)

sd is a more intuitive alternative to sed, focussing on making find and replace easier - which is all I ever used sed for.

https://github.com/chmln/sd

If it's in multiple files? To be honest, I'd just use a terminal and sed (or sd if you want something with a more friendly interface).

I love the idea and I'll try it out, but a heads up in case the author is around: the name sd clashes with another tool [0], which works as an alternative to sed.

I use that one pretty often, so maybe my first managed script will be one which symlinks binaries :)

[0] https://github.com/chmln/sd

sd is a find-and-replace CLI, and you can use it as a replacement for sed and awk. It is way more user-friendly and modern. It is also magnitudes faster than sed.

Even if sed and grep are available their weird syntax is enough to make people write modern replacements.

I don't care if they're not 100% feature complete, the fact I can remember how to use them for my simple everday tasks (searching, finding/replacing across many files) without needing to consult a manpage or search online for answers is enough.

Modern sed:

https://github.com/chmln/sd

Modern grep:

https://github.com/ggreer/the_silver_searcher