Be Aware of the Makefile Effect • Hacker News Board

Re: Be Aware of the Makefile Effect

#191

Post by mdaniel » Sat, Jan 11, 2025, 6:12 PM UTC

pantalaimon wrote: post #95

kragen wrote: post #92

Earlier quoted context omitted.

Yeah, I've always been mystified by the idea that writing a new Makefile is some kind of wizardly mystery. Make has its design flaws, for sure, but how hard is it really to write this? CFLAGS = -std=gnu99 -Wall all: foo clean: $(RM) foo *.o foo: foo_main.o foolib.o $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ (Except with tabs, which HN doesn't allow.) I haven't tested what I just typed above, but I'm reasonably sure that if…

Auto-generated Makefiles that CMake and Autotools produce really leave a bad impression on how complex Makefiles need to be.

Good news, you can change the output then! And for as much as you might not like its generated Makefiles, I assert that $(cmake -G Ninja) is 100,000,000x more "wtf" than -G Makefiles

I disagree about the autotools ones, I find them very sane although autotools itself can die in a rotting dumpster out back. And take m4 with it.

Re: Be Aware of the Makefile Effect

#192

Post by layer8 » Sat, Jan 11, 2025, 6:13 PM UTC

There are certainly a lot of tools that are more complicated than necessary, but Make as a tool isn’t a good example of that, IMO. With modern tooling, more often than not the complexity problem is compounded by insufficient documentation, the existing documentation being predominantly cookbook-style and not explaining the conceptual models needed to reason about how the tool works, nor providing a detailed and precise enough specification of the tool. That isn’t the case for Make, which is well-documented and not difficult to get a good grasp on, if one only takes the time to actually read the documentation.

The cookbook orientation mentioned above in turn leads to a culture that underemphasizes the importance of learning and understanding the tools that one is using, and of having thorough documentation that facilitates that. Or maybe the direction of causation is the other way around. In any case, I see the problem more in too little time being spent in creating comprehensive and up-to-date documentation on tooling (and designing the tooling to be amenable to that in the first place), and in too little resources being allocated to teaching and learning the necessary tooling.

Re: Be Aware of the Makefile Effect

#193

Post by knallfrosch » Sat, Jan 11, 2025, 6:17 PM UTC

Yeah I'm just not wasting my life (or professional time) learning Groovy, Maven, DotNET project files, DotNET 4.8, Gradle, Azure DevOps, Grafana, Prometheus, Docker, Docker compose, Kubernetes, Jenkins etc et all.

I need those things once at project setup. I copy-paste and change a bit.

Why copy-paste? It's a proven strategy with a high success rate despite little effort behind it.

I also don't want to learn templating for every little DSL I need to write one file per project with.

But if you love doing it "the right way", you're welcome to do that work for me.

Re: Be Aware of the Makefile Effect

#194

Post by aulin » Sat, Jan 11, 2025, 6:18 PM UTC

oweiler wrote: post #106

huijzer wrote: post #64

Earlier quoted context omitted.

> That leaves 50% who don’t really know much beyond a few LeetCode puzzles and have no real grasp of what they’re copying and pasting. Small nuance: I think people often don’t know because they don’t have the time to figure it out. There are only so many battles you can fight during a day. For example if I’m a C++ programmer working on a ticket, how many layers of the stack should I know? For example, should I know h…

That's why suggestions like RTFM! are stupid. I just don't have time to read every reference documentation of every tool I use.

you don't have the time because you spend it bruteforcing solutions by trial and error instead of reading the manual and doing them right the first time

Re: Be Aware of the Makefile Effect

#195

Post by mdaniel » Sat, Jan 11, 2025, 6:19 PM UTC

klysm wrote: post #87

choeger wrote: post #80

Makefiles have an even more interesting issue: They lost their main purpose. In many, many projects that I've seen, they only consist of phony targets. No dependency tracking is used whatsoever. How many Makefiles are there that just Wrap npm, pip, or some other tool like that? A Makefile is supposed to be the build system, not trigger it.

Okay but make is a shitty build system. What it does have going for it is you can nearly universally expect it to be already installed or easy to install. That makes it a good way to name commands shorter in a portable way, with some dependencies maybe thrown in. It’s used for the same reason we write shell scripts

> It’s used for the same reason we write shell scripts

Only worse since it also uses $ for its variables leading to "thing:\n\t env FRED=$$HOME/thing some-command -p $$AWS_PROFILE $(OTHER_THING) -d $$(date +%s)" level of squinting

So for those using it as a task runner from the 60s, without dependency tracking, now it's just laziness over a shell script that has "dependencies" in an imperative and shellcheck-able way

Re: Be Aware of the Makefile Effect

#196

Post by peterldowns » Sat, Jan 11, 2025, 6:27 PM UTC

themanmaran wrote: post #187

lolinder wrote: post #140

Earlier quoted context omitted.

I don't think of this as being cargo cult development. Cargo culting has more to do with mimicking practices that have worked before without understanding that they only worked within a broader context that is now missing. It's about going through motions or rituals that are actually ineffective on their own in the hopes that you'll get the results that other companies got who also happened to perform those same moti…

I would almost call this the "boilerplate effect". Where people copy the giant boilerplate projects for React, K8, Terraform, etc. and go from there. Those boilerplates are ideal for mid to large scale projects. And it's likely you'll need them someday. But in the early stages of development it's going to impart a lot of architecture decisions that really aren't necessary.

That's a great phrase. A perfect example of what you're talking about is actually built-in to the `helm` tool for creating re-usable kubernetes configs: `helm create myapp` creates the most convoluted junk I've ever seen in my life. As a new `helm` user I was extremely confused, as I had been expecting a minimal example that I could start from. Instead, I got a maximal example. Thankfully a more experienced engineer on the infra team confirmed that it was mostly unnecessary boilerplate and I could remove it.

Something to consider for anyone else building tools — boilerplate has costs!

Re: Be Aware of the Makefile Effect

#197

Post by peterldowns » Sat, Jan 11, 2025, 6:30 PM UTC

john-tells-all wrote: post #139

ratmeadow wrote: post #7

At my work I've noticed another contributing factor: tools/systems that devs need to interact with at some point, but otherwise provide little perceived value to learn day-to-day. Example is build system and CI configuration. We absolutely need these but devs don't think they should be expected to deal with them day to day. CI is perceived as a system that should be "set and forget", like yeah we need it but really I…

Strong agree. The best workflow I've seen uses CICD as a very thin wrapper around in-tree scripts or make files. If a Dev can run some/all of the "cicd" stuff locally, they can see, control, and understand it. It helps tremendously to have a sense of ownership and calm, vs "cicd is something else, la la la". (This doesn't always work. We had a team of two devs, who had thin-wrapper CICD, who pretended it was an alien…

+1. The only CI tool that I've seen really organize around this principle is Buildkite, which I've used and enjoyed. I'm currently using Github Actions and it's fine but Buildkite is literally sooooo good for the reasons you've mentioned.

Re: Be Aware of the Makefile Effect

#198

Post by nwallin » Sat, Jan 11, 2025, 6:36 PM UTC

teeray wrote: post #126

I see this often on our codebase. It was mostly written by ex-C# developers who were new to writing Go, and there’s many ham-handed C#-isms in there. At some point, someone took a guess at how something should be, then subsequent changes were done by copy-paste. Years down the road, another copy-paste job happens, and when I point out that the patterns within are not good (like, can actually be buggy), I get a confus…

Happens to us at my day job too. The codebase is primarily C++. My most recent horror story is that I was stepping through some code in an object that was statically initialized and a variable that was initialized as `static const double foo = nan;` had a value of 0 in it. This was very surprising to me.

I look at how we defined nan and it turns out that nan is a singleton that was initialized in a DLL somewhere. My variable was being initialized before the singleton nan was initialized. I asked around, and someone with access to the previous version control system (we migrated to git in 2016) discovered that this was part of the original commit to that VCS back sometime in 2003-2006 or something. We think that was probably from before our C++ compiler was updated to support C++98 and `numeric_limits` was added.

So of course I moved this over so that accessing our special nan singleton is just a static constexpr call to `std::numeric_limits::quiet_NaN()`. But our special nan singleton is used all over the place in our codebase. So of course I have to check to see nobody's doing something weird with it.

Of course they are.

There are about a hundred lines of code that boil down to `if (foo == special_nan_singleton) { /* ...handle nan / }` which of course...isn't how nan works. This is a no-op and the compiler just straight up compiles it out of binary. This happens a lot*. Including fundamental infrastructure, like the special JSON serializer somebody reinvented.

Re: Be Aware of the Makefile Effect

#199

Post by godelski » Sat, Jan 11, 2025, 6:37 PM UTC

lolinder wrote: post #140

Scubabear68 wrote: post #127

The best term for this is Cargo Cult Development. Cargo Cults arose in the Pacific during World War II, where native islanders would see miraculous planes bringing food, alcohol and goods to the islands and then vanishing into the blue. The islanders copied what they saw the soldiers doing, praying that their bamboo planes and coconut gadgets would impress the gods and restart the flow of cargo to the area. The issue…

I don't think of this as being cargo cult development. Cargo culting has more to do with mimicking practices that have worked before without understanding that they only worked within a broader context that is now missing. It's about going through motions or rituals that are actually ineffective on their own in the hopes that you'll get the results that other companies got who also happened to perform those same moti…

  > only worked within a broader context that is now missing

  > because the thing being copied—the code—actually is effectual in its own right.

I don't understand how the second disproves the former.

In fact, a cargo cult works because there's the appearance of a casual linkage. It appears things work. But as we know with code, just because it compiles and runs doesn't mean "it works". It's not a binary thing. Personal I find that belief is at the root of a lot of cargo cult development. Where many programmers glue things together say "it works" because they passed some test cases but in reality code shouldn't be a Lovecraftian monster made of spaghetti and duct tape. Just because your wooden plane glides doesn't mean it's AC an actual plane

Re: Be Aware of the Makefile Effect

#200

Post by pdimitar » Sat, Jan 11, 2025, 6:38 PM UTC

kragen wrote: post #173

pdimitar wrote: post #115

Earlier quoted context omitted.

Yes, and I should overrule half the business decisions of the company while I am at it. Oh, and I'll push back on "we need the next feature next week" and I'll calmly respond "we need to do excellent engineering practices in this company". And everybody will clap and will listen to me, and I will get promoted. ...Get real, dude. Your comments come across a bit tone-deaf. I am glad you are in a privileged position but…

I know a lot of people have terrible jobs at profoundly dysfunctional companies. I've had those too. That situation doesn't improve unless you, as they say, have the serenity to accept the things you cannot change, the courage to change the things you can, and the wisdom to know the difference. Not everyone has a position where they have the autonomy to spend a lot of effort on paying down technical debt, but some pe…

The serenity in question boils down to "I'll never make enough money to live peacefully and being able to take a two years sabbatical so let's just accept I'll be on the hamster wheel for life and I can never do anything about it".

No. I'll let my body wither and get spent before my spirit breaks. I refuse to just "accept" things. There's always something you can do.

BTW is that not what HN usually preaches? "Change your job to a better one" and all that generic motivational drivel [that's severely disconnected from reality]? Not throwing shade at you here in particular, just being a bit snarky for a minute. :)

RE: your final point, I lost the desire to keep view of both my personal and my company's incentive systems. Most "incentive systems" are basically "fall in line or GTFO".

Before you ask, I am working super hard to change my bubble and get a bit closer to yours. To say it's not easy would be so understated so as to compare the description of a lightning hit on you and you enduring the said lightning hit. But as said above, I am never giving up.

But... it's extremely difficult, man. Locality and your own marketing matter a lot, and when you have been focused on technical skills all your life and marketing is as foreign to you as are the musical notes of an alien civilization... it's difficult.