Hacker News Reader

Comment by petr25102018 | Hacker News Reader

petr25102018

The older standard tools, because they can be easily put in CI pipelines and shared as scripts with coworkers.

For example, in my personal and professional life I use Make everywhere. The book mentions alternatives, but the examples are built on the time-tested tools.

I focused on things that don't require install (if given the option) or the ones that you are more likely to encounter at work. It is a tradeoff and I can see how the reverse would be appealing too.

View on HN

<3 GNU Make

Make is a powerful self-documentable tool. It can hide tons of complicated dependencies implementation details behind a simple and universal CLI.

If you want to use make, power to you, it’s definitely a useful tool. (What I’m trying to say is I’m bashing make, not you.)

That being said, I absolutely hate make, there are so many footguns and weird quirks and implicit behavior that always end up biting me.

I find that 90% of the time what I actually want is a command runner like Just (https://github.com/casey/just) and have the make file contain the absolute sheer minimum required to build code.

While we’re at it, CMake is another build tool with the same problems as make - powerful, with an ugly syntax, unintuitive semantics, hidden dragons, and a manual that’s torturous to read.

I agree too, Just (and others) are better as a pure entry point. But when you come to projects that already have Makefiles, or you know you have just one less thing to install in a container... you use Make.

In the era of micro services and ephemeral computing runtime, the baseline default environment will save us from unnecessary complexity.

For example, in CI pipelines, I can use my own plain. Makefile to replace different yaml tasks across different languages, from shell scripts to python scripts to npm scripts.

These days people have a tendency to grab a latest and shiniest tools when the existing ones are hard to use. Because it takes more effort to understand them than install new ones.

With LLM, we might have a chance to explore the capabilities and deeper ideas in them. If I have enough LLM budget (time and money wise), I might spend more on using awk to build super agents. GNU manuals are perfect context for these kinds of usages.

A compelling idea, but cmake writing endif(), find_package() being the equivalent of ‘from package import *’, and CXX automatically getting re-named to CMAKE_CXX_COMPILER is just bad design. There’s no deeper idea to explore. The system is just ugly and confusing.

I’ve been reading through https://cliutils.gitlab.io/modern-cmake/README.html to try and get my head around CMake best practices and the book is just line after line of “Don’t do it the old way or the obvious way, because you will end up accidentally doing the wrong thing due to A Hidden Footgun.” That’s bad design*!

We can use LLM to read and write cmake as well. They are all Turing machines anyway.

Reply on news.ycombinator.com