Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Be Aware of the Makefile Effect

blog.yossarian.net

Post reply on HN
Print view View original

161–170 of 347 posts

Re: Be Aware of the Makefile Effect

#161

Post by o11c »

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.

Specifically, any generated makefile that refuses to take advantage of GNU make is necessarily going to be horrible.

BSD make is ... viable I guess, but only really worth it if you're already in the ecosystem - and even then I can't guarantee you won't hit one of its silly limitations.

Re: Be Aware of the Makefile Effect

#162

Post by marcosdumay »

bboygravity wrote: post #18
donatj wrote: post #6

If I had a nickel for every time I have seen a Makefile straight up copied from other projects and modified to "work" while leaving completely unrelated unnecessary build steps and targets in place. It's a major pet peeve of mine.

How do you know what is and isn't related if nothing is documented? Trial and error? Well have fun with that :p

Hum...

You know, a makefile is documentation. That's why you should probably never copy one (except for a single line here or there). There's space for commenting a few stuff, but your target names and variables should explain most of what is going there.

Anyway, the article and most people here seem to be talking about those autotools generated files. Or hand-built ones that look the same way. But either way, it's a bad solution caused by forcing a problem to be solved by a tool that wasn't aimed at solving it. We have some older languages without the concept of a "project" that need a lot of hand-holding for compiling, but despite make being intentionally created for that hand-holding, it's clearly not the best tool for that one task.

Re: Be Aware of the Makefile Effect

#163

Post by linuxftw »

rednafi wrote: post #152

This also happens with tools you have to use but don’t get much payoff from—like internal tooling. At work, we have a shitty in-house feature flag service. It breaks all the time and is super finicky. Learning it properly doesn’t really help me, so I mostly copy and paste my way through it. Another example is jq. I use it occasionally, and ChatGPT handles the syntax pretty well. For me, learning it properly just isn’…

Makefile syntax is also well understood by ChatGPT. If you want to know a suitable way for doing some task, ChatGPT can do it. It can also explain what another Makefile is doing.

Here's an example of a (similar) prompt I used recently: "Write me a makefile that executes a script inside a docker container. I want the script to be someprefix- that calls /app/.sh inside the container."

I don't have to care about Makefile syntax anymore for the most part.

Re: Be Aware of the Makefile Effect

#164

Post by vintermann »

tempodox wrote: post #147
vintermann wrote: post #136

Earlier quoted context omitted.

If you think cmake is a good example of more complex than make, then you haven't seen automake/autoconf. The first thing I thought of. You can find tons of tons of configure scripts that check if you're running ancient versions of Unix, checks that a byte is 8 bits wide, and a ton of other pointless checks. They don't do anything with all that information, don't think for a moment that you can actually build the app…

Firstly, automake/autoconf is not `make`, but a different piece of software, and secondly, that you know all those details about it is because it is not black-box-like.

I never said it was. It's a script to generate a script to generate a makefile, more or less.

If it wasn't black box like, why do people keep blindly copying tests which check things which haven't been relevant for decades and in any case would require a ton of manual effort to actually use for something?

Re: Be Aware of the Makefile Effect

#165

Post by rednafi »

linuxftw wrote: post #163
rednafi wrote: post #152

This also happens with tools you have to use but don’t get much payoff from—like internal tooling. At work, we have a shitty in-house feature flag service. It breaks all the time and is super finicky. Learning it properly doesn’t really help me, so I mostly copy and paste my way through it. Another example is jq. I use it occasionally, and ChatGPT handles the syntax pretty well. For me, learning it properly just isn’…

Makefile syntax is also well understood by ChatGPT. If you want to know a suitable way for doing some task, ChatGPT can do it. It can also explain what another Makefile is doing. Here's an example of a (similar) prompt I used recently: "Write me a makefile that executes a script inside a docker container. I want the script to be someprefix- that calls /app/ .sh inside the container." I don't have to care about Makefi…

Exactly. I used to go for Just and Go Task as Make alternatives, but not anymore. LLMs are great with Make syntax, and Make is everywhere.

Re: Be Aware of the Makefile Effect

#166

Post by remus »

kragen wrote: post #99
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…

If you spend 80% of your time (and mental energy) applying the knowledge you already have and 20% learning new things, you will very quickly be able to win more battles per day than someone who spends 1% of their time learning new things. Specifically for the examples at hand: - at 20%, you will be able to write a Makefile from scratch within the first day of picking up the manual, rather than two or three weeks if y…

You make it sound easy, but I think it's hard to know where to invest your learning time. For example, I could put some energy into getting better at shell scripting but realistically I don't write enough of it that it'll stick so for me I don't think it'd be a good use of time.

Perhaps in learning more shell scripting I have a breakthrough and realise I can do lots of things I couldn't before and overnight can do 10% more, but again it's not obvious in advance that this will happen.

Re: Be Aware of the Makefile Effect

#167

Post by kragen »

silver_silver wrote: post #109
kragen wrote: post #101

Earlier quoted context omitted.

Steam engines predate the understanding of not just the crystalline structure of steel but even the basics of thermodynamics by quite a few decades.

Yes and they’re far less efficient and require far more maintenance than an equivalent electric or even diesel engine, where equivalent power is even possible

Steam engines currently power most of the world's electrical grid. The main reason for this is that, completely contrary to what you said, they are more efficient and more reliable than diesel engines. (Electric motors of course are not a heat engine at all and so are not comparable.)

Steam engines used to be very inefficient, in part because the underlying thermodynamic principles were not understood, but also because learning to build safe ones (largely a question of metallurgy) took a long time. Does that mean that designing them before those principles were known was "not engineering"? That seems like obvious nonsense to me.

Re: Be Aware of the Makefile Effect

#168

Post by kragen »

icameron wrote: post #133
kragen wrote: post #99

Earlier quoted context omitted.

If you spend 80% of your time (and mental energy) applying the knowledge you already have and 20% learning new things, you will very quickly be able to win more battles per day than someone who spends 1% of their time learning new things. Specifically for the examples at hand: - at 20%, you will be able to write a Makefile from scratch within the first day of picking up the manual, rather than two or three weeks if y…

That’s an insightful comment, but there is a whole universe of programmers who never have to directly work in C/C++ and are productive in safe languages that can’t segfault usually. Admittedly we are a little jealous of those elite bitcrashers who unlock the unbridled power of the computer with C++… but yeah a lot of day jobs pay the bills with C#, JavaScript, or Python and are considered programmers by the rest of t…

Yeah, I write most things in Python or JavaScript because it's much more practical.

Re: Be Aware of the Makefile Effect

#169

Post by dave333 »

The traditional Unix man page or list of options output with --help is often a firehose of details that most devs will never use. Sometimes there are a few examples shown of common use cases which is a good place to start learning the tool.

Re: Be Aware of the Makefile Effect

#170

Post by sgarland »

cle wrote: post #144
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…

For me, there are many cases where I copy-paste stuff I've written in the past b/c some tool is a pain-in-the-ass and I can't afford the mental context switch. I usually do understand what's happening under the hood, but it's still cognitively heavy to switch into that "mode" so I avoid it when possible. Tools that fall into this category are usually ops-y things with enormous complexity but are not "core" to the pro…

It’s always hoped (but rarely shown to be true) that by making templates, teams will put thought into their K8s deployments etc. instead of just copy/pasting. Alas, no – even when the only things the devs have to do is add resource requests and limits, those are invariably copy/pasted. If the app gets OOMkilled, they bump up memory limit until it doesn’t. If it’s never OOMkilled, it’s probably never touched, even if it’s heavily over-provisioned (though that would only matter for the request, of course).

This has spawned a cottage industry of right-sizing tooling, which does what a dev team could and should have done to begin with: profiling their code to see resource requirements.

At this point, I feel like continuing to make things easier is detrimental. I certainly don’t think devs need to know how to administer K8s, but I do firmly believe one should know how to profile one’s code, and to make reasonable decisions based on that effort.

Post reply on HN