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

231–240 of 347 posts

Re: Be Aware of the Makefile Effect

#231

Post by klibertp »

ori_b wrote: post #123
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…

Yes, sometimes things are unfixably broken, and it's impossible to build anything good. For everything else, there's MasterCard.

> For everything else, there's...

...the very definition of brokenness :D Not much of a (good) choice there...

Re: Be Aware of the Makefile Effect

#232

Post by erosivesoul »

raverbashing wrote: post #175
cle wrote: post #144

Earlier quoted context omitted.

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…

Pretty much this And of course every one of those tools has to have their own special language/syntax that makes sense nowhere else (think of all the tools beyond make, like autotools, etc) I don't care about make. I don't care learning about make beyond what's needed for my job Sure, it's a great tool, but I literally have 10 other things that deserve more of my attention than having my makefile work as needed So ye…

Honestly is this not how it should be done? There's always going to be a more elegant approach for sure. But in general, we don't want developers to keep rewriting the same code again and again. Avoiding that is part of entire design paradigms. I'd like to talk to the dev who doesn't copy-paste and writes everything from scratch.

Re: Be Aware of the Makefile Effect

#233

Post by solatic »

> Think about CI/CD setups, where users diagnose their copy-pasted CI/CD by doing print-style debugging over the network with a layer of intermediating VM orchestration. Ridiculous!

I don't think the author understands the point of "CI/CD systems". And I don't really blame them, because workload orchestration systems have been abused and marketed to the point where we call them CI/CD systems instead. Sure, if you think the point of CI/CD is to just provide a unified build and deploy it somewhere, you can write that in whatever language you like, and not need to know a bunch of YAML-fu.

But the whole point of workload orchestration systems is to configure the flow of workloads between machines as they inherently execute on different machines. The status quo is to debug over the network because, fundamentally, different machines will be connected by a network and the workload orchestration system is figuring out which machine to put it on.

If you think you can just run your CI/CD on a single server without networking or virtualization, I have some very large, parallelized testing suites to show you.

Re: Be Aware of the Makefile Effect

#234

Post by IgorPartola »

Make and Makefiles are incredibly simple when they are not autogenerated by autoconf. If they are generated by autoconf, don’t modify them, they are a build artifact. But also, ditch autoconf if you can.

In the broader sense: yes this effect is very real. You can fall to it or you can exploit it. How I exploit it: write a bit of code (or copy/paste it from somewhere). Use it in a project. Refine as needed. When starting the next project, copy that bit of code in. Modify for the second project. See if changes can be backported to the original project. Once both are running and are in sync, extract the bit of code and make it into a library. Sometimes this takes more projects to distill the thing into what a library should be. In the best case, open source the library so others can use it.

Re: Be Aware of the Makefile Effect

#235

Post by godelski »

scubbo wrote: post #207
godelski wrote: post #199

Earlier quoted context omitted.

> 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…

> a cargo cult works But...it doesn't? That's the whole definitional point of it. If action A _does_ lead to outcome B, then "if we do A, then B will happen" is not a cargo cult perspective, it's just fact.

Sorry, the quotes around "work" were implicit. I thought there was enough context to make that clear. That just because some things actually work doesn't mean it works for the reason it actually works.

This is what I meant by cargo cults working. Where there is a _belief_ in a causal connection where there is none. The Melanesia really did believe there was a causal connection between their actions would cause cargo to return. It's not just about appearance. It is about not understanding the actual causal chain and misinterpreting the causal variables.

Measurement is HARD. It is very common that if you do A then B will happen YET A is not the cause of B. Here's a trivial example: a mouse presses a button and it gets fed. In reality, the mouse presses a button and a human feeds the mouse. It is not the button. It may even be impossible for the mouse to know this. But if the human leaves, the mouse can press the button all they want and they will not get fed. I hope you can see how this can happen in far more complex ways. As the chain of events gets longer and more complex you an probably see why it is actually a really common issue. Because you have literal evidence that your actions are causal while they are not.

Re: Be Aware of the Makefile Effect

#236

Post by godelski »

foobarchu wrote: post #210
scubbo wrote: post #207

Earlier quoted context omitted.

> a cargo cult works But...it doesn't? That's the whole definitional point of it. If action A _does_ lead to outcome B, then "if we do A, then B will happen" is not a cargo cult perspective, it's just fact.

For actual cargo cults, yes. Cargo Cult Development just used the name to invoke a comparison..when CCD is being practiced, devs are doing mystical steps because it's part of the incantation. They wouldn't keep doing them if the project then never worked. Your definition is extremely unlikely to ever be practiced, because those developers would be fired for never getting anything working, and so it's not really a hel…

  > For actual cargo cults, yes.
I'd say it is true for both. There's evidence that the actions cause the events. They correlate. It's why people start doing the actions in the first place. The exact reasoning you use, if it didn't "work" (appear to work) then the cult dies off pretty fast (and they do). Rationally irrational. It's good to be aware of because with high complexity systems it is easy to fall into these types of issues. Where you are doing A and you _believe_ are causing B, but there is no real relation.

Re: Be Aware of the Makefile Effect

#237

Post by spc476 »

kragen wrote: post #92
shusaku wrote: post #83

I always write my makefiles from scratch. At some point in the process, I will google “make automatic variables”, because they’re a pain to memorize.

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…

You can drop the last line---make already knows the incantations to compile a C file.

Re: Be Aware of the Makefile Effect

#238

Post by semi-extrinsic »

solatic wrote: post #233

> Think about CI/CD setups, where users diagnose their copy-pasted CI/CD by doing print-style debugging over the network with a layer of intermediating VM orchestration. Ridiculous! I don't think the author understands the point of "CI/CD systems". And I don't really blame them, because workload orchestration systems have been abused and marketed to the point where we call them CI/CD systems instead. Sure, if you thi…

> If you think you can just run your CI/CD on a single server without networking or virtualization, I have some very large, parallelized testing suites to show you.

Nowadays you can get a single server with 256 cores and several terabytes of memory. I would be interested to learn what kind of testing suites have actual needs beyond that.

Without virtualization though is definitely no problem. The whole docker/k8s/whatever shtick is mainly because devs think it's more fun to invent new things than to learn how to use old ones properly. At least as long as you're running your own code on your own hardware, there is not a single thing solved by virtualization that wouldn't be solved equally well (or better) with traditional tools like environment modules and Slurm.

Re: Be Aware of the Makefile Effect

#239

Post by IgorPartola »

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…

Make is one of the simplest build tools out there. Compared to something like Grunt, Webpack, etc. it’s a hammer compared to a mining drill.

The solution is to not use tools used by large corporations because they are used by large corporations. My unpopular opinion is that CI/CD is not needed in most places where it’s used. Figure out how to do your builds and deploys with the absolute fewest moving pieces even if it involves some extra steps. Then carefully consider the cost of streamlining any part of it. Buying into a large system just to do a simple thing is often times not worth it in the long run.

If you really do need CI/CD you will know because you will have a pain point. If that system is causing your developers pain, it isn’t the right fit.

Re: Be Aware of the Makefile Effect

#240

Post by TheTaytay »

dwaltrip wrote: post #230
nrclark wrote: post #177

Earlier quoted context omitted.

(not the parent) Make is - at its core - a tool for expressing and running short shell-scripts ("recipes", in Make parlance) with optional dependency relationships between each other. Why would I want to spread out my build logic across a bunch of shell scripts that I have to stitch together, when Make is a nicely integrated solution to this exact problem?

Any modern attempts to do this better than make? I often write small “infra” bash scripts in my projects, maybe I could use a tool like that.

I haven’t used them yet, but I keep seeing people touting alternatives, and in particular “just”: https://github.com/casey/just

This is primarily aimed at a “task runner” replacement rather than a “compilation with automatic file timestamp comparison replacement”

Others I stumbled across: Taskfile Mage XcFile

None of them have tempted me enough to move away from a set of bash scripts or scripts written in the language of my repo (yet).

Post reply on HN