Live data from Hacker News

Be Aware of the Makefile Effect

blog.yossarian.net

251–260 of 347 posts

Re: Be Aware of the Makefile Effect

#251

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

They are simple but very often wrong . It's surprisingly hard to write Makefiles that will actually do the right thing under anything other than "build from scratch" scenarios. (No, I'm not joking. The very existence of the idea of "make clean" is the smoking gun.)

The idea that git offers a 'clean' command was revelatory to me. Your build system probably shouldn't need to know how to restore your environment to a clean state because your source control should already know what a clean state is.

That's sort essential to serving its purpose, after all.

I haven't yet run into a scenario where there was a clean task that couldn't be accomplished by using flags to git clean, usually -dfx[0]. If someone has an example of something complex enough to require a separate target in the build system, I'm all ears.

[0] git is my Makefile effect program. I do not know it well, and have not invested the time to learn it. This says something about me, got, or both.

Re: Be Aware of the Makefile Effect

#252
post #237
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…

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

I did drop the lines you're thinking of. The last line is to specify which .o files go into the executable.

Re: Be Aware of the Makefile Effect

#253
post #247

Earlier quoted context omitted.

With that attitude how would the presently accepted languages/frameworks have come about?

Probably slower and with more respect for existing tech. But hey, now we have npm, so who cares anymore? :-)

Disrespect is part of progress, respectful humans are liable to blindness of flaws. Just as part of youthful creativity is disregard for what has come before.

Re: Be Aware of the Makefile Effect

#254

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

For a start, any suite that takes >X hours on a single node, especially compounded if you have a large team of developers.

> At least as long as you're running your own code on your own hardware

Assuming you keep a consistent env/OS across all nodes you will want to run said code. Which can be difficult, even just between two users on a single node.

Not to mention the fact that a lot of (most?) code needs to (A) interoperate with other people's code and (B) at least sometimes run on other hardware.

Re: Be Aware of the Makefile Effect

#255

Earlier quoted context omitted.

They are simple but very often wrong . It's surprisingly hard to write Makefiles that will actually do the right thing under anything other than "build from scratch" scenarios. (No, I'm not joking. The very existence of the idea of "make clean" is the smoking gun.)

The idea that git offers a 'clean' command was revelatory to me. Your build system probably shouldn't need to know how to restore your environment to a clean state because your source control should already know what a clean state is . That's sort essential to serving its purpose, after all. I haven't yet run into a scenario where there was a clean task that couldn't be accomplished by using flags to git clean, usual…

The problem with `git clean` is -X vs -x. -x (lowercase) removes EVERYTHING including .env files and other untracked files. -X (uppercase) removes only ignored files, but not untracked files.

If there is a Makefile with a clean target, usually the first thing I do when I start is make it an alias for `git clean -X`.

Usually, you want to keep your untracked files (they are usually experiments, debugging hooks, or whatever).

Re: Be Aware of the Makefile Effect

#256

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…

> Just because your wooden plane glides doesn't mean it's AC an actual plane But if your wooden plane can somehow make it to Europe, collect cargo, and bring it back to your island, what you're doing is definitely not cargo culting . It might not be actual engineering, maybe you don't understand aerodynamics or how the engine works, and maybe the plane falls apart when it hits the runway on the return flight, but if…

  >> Just because your wooden plane glides doesn't mean it's AC an actual plane

  > But if your wooden plane can somehow make it to Europe, collect cargo, and bring it back to your island
Sure, but these are categorically different and not related to my point.

  > That's why copypasta doesn't count as cargo culting.
Let me quote wiki[0]

  The term cargo cult programmer may apply when anyone inexperienced with the problem at hand copies some program code from one place to another with little understanding of how it works or whether it is required.

  Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. Some examples are adding unnecessary comments to self-explanatory code, overzealous adherence to the conventions of a programming paradigm, or adding deletion code for objects that garbage collection automatically collects. 
Even in the example it gives the code will "work." You can collect garbage when the language already does that, you'll get performance hits, but your code won't break.

It "it doesn't _work_" disqualifies something from not being cargo cult programming, then there would be no cargo cult programming. Who is shipping code that doesn't compile or hits runtime errors with any form of execution? You couldn't do that for very long.

Let's take an airplane example. Say you want to copy Boeing[1]. You notice that every 747 has a coffee maker on it. So you also make a coffee maker. After all, it is connected to the electrical system and the engines. Every time you take out the coffee maker the airplane fails. So you just put in a coffee maker.

A cargo cult exists BECAUSE _something_ is "working". BECAUSE they have evidence. But it is about misunderstanding the causality. See also Feynman's "Cargo Cult Science"[2]. As dumb as people are, there's always a reason people do things. It is usually not a good reason and it is often a bad reason, but there is a reason. Even people will explain you "causal" explanations for things like astrology.

[0] https://en.wikipedia.org/wiki/Cargo_cult_programming

[1] Well in the past you might have wanted to lol

[2] https://calteches.library.caltech.edu/51/2/CargoCult.pdf

  > not only what you think is right about it: other causes that could possibly explain your results
His explanation explicitly acknowledges the experiment works. In fact, even the math to explain the experiment "works". But it is wrong. Related is Von Neuman's Elephant. Where Freeman Dyson had evidence that a theory explained an experiment, yet it was in fact wrong. Evidence isn't sufficient to determine causality.

Re: Be Aware of the Makefile Effect

#257

Earlier quoted context omitted.

> Just because your wooden plane glides doesn't mean it's AC an actual plane But if your wooden plane can somehow make it to Europe, collect cargo, and bring it back to your island, what you're doing is definitely not cargo culting . It might not be actual engineering, maybe you don't understand aerodynamics or how the engine works, and maybe the plane falls apart when it hits the runway on the return flight, but if…

>> Just because your wooden plane glides doesn't mean it's AC an actual plane > But if your wooden plane can somehow make it to Europe, collect cargo, and bring it back to your island Sure, but these are categorically different and not related to my point. > That's why copypasta doesn't count as cargo culting. Let me quote wiki[0] The term cargo cult programmer may apply when anyone inexperienced with the problem at…

To quote the original source that Wiki cites and is derived from:

> A style of (incompetent) programming dominated by ritual inclusion of code or program structures that serve no real purpose. A cargo cult programmer will usually explain the extra code as a way of working around some bug encountered in the past, but usually neither the bug nor the reason the code apparently avoided the bug was ever fully understood (compare {shotgun debugging}, {voodoo programming}).

This is categorically different than the kinds of copypasta that TFA is talking about, and it's different in that the copypasta in TFA does serve a purpose.

There's a world of difference between copying something whose implementation you don't understand but whose function you do understand versus copying something which you vaguely associate with a particular outcome.

https://jargon-file.org/archive/jargon-2.9.6.dos.txt

Re: Be Aware of the Makefile Effect

#258
> Complex tools are a necessity; they can’t always be avoided. However, the occurrence of the Makefile effect in a simple application suggests that the tool is too complicated for that application.

This footnote actually made me think about IDEs and the JS toolchain even more than makefiles.

If I'm writing a small project (say, 10 code files) surely an IDE where most people only know how to use 4 of the 1000 buttons is overkill, and I'd use a makefile.

Similarly surely 10 code files with 10 config dotfiles to set up a JS environment and tooling for dependencies, versioning, linting, transpiling, etc is overkill too.

- Basic javac/gcc/swiftc/whatever commands are simple, even if they can scale up through every niche via configuration options.

- Basic makefiles are simple, even if they can scale up to something like the xnu makefile tree (the most complex make system I've encountered).

- Let's not talk about JS.

I'm hesitant to use the word "lazy" to describe people who do what the author is describing - not just because I sometimes do it myself but because I believe that laziness is a derivative observation of time constraint, executive function exhaustion, and other factors. It also reminds me of the classic "I'm going to learn X, which handles/wraps Y, so that I can avoid learning Y", which is generally a bad pattern of motivation.

At its core this feels like a failure to understand (or failure of others to teach) fundamentals / first principles of the tools being used.

Re: Be Aware of the Makefile Effect

#259

Earlier quoted context omitted.

The idea that git offers a 'clean' command was revelatory to me. Your build system probably shouldn't need to know how to restore your environment to a clean state because your source control should already know what a clean state is . That's sort essential to serving its purpose, after all. I haven't yet run into a scenario where there was a clean task that couldn't be accomplished by using flags to git clean, usual…

The problem with `git clean` is -X vs -x. -x (lowercase) removes EVERYTHING including .env files and other untracked files. -X (uppercase) removes only ignored files, but not untracked files. If there is a Makefile with a clean target, usually the first thing I do when I start is make it an alias for `git clean -X`. Usually, you want to keep your untracked files (they are usually experiments, debugging hooks, or what…

You are almost certainly right that I was using -X. It's been a while since I had to deal with git.

Re: Be Aware of the Makefile Effect

#260

Earlier quoted context omitted.

>> Just because your wooden plane glides doesn't mean it's AC an actual plane > But if your wooden plane can somehow make it to Europe, collect cargo, and bring it back to your island Sure, but these are categorically different and not related to my point. > That's why copypasta doesn't count as cargo culting. Let me quote wiki[0] The term cargo cult programmer may apply when anyone inexperienced with the problem at…

To quote the original source that Wiki cites and is derived from: > A style of (incompetent) programming dominated by ritual inclusion of code or program structures that serve no real purpose. A cargo cult programmer will usually explain the extra code as a way of working around some bug encountered in the past, but usually neither the bug nor the reason the code apparently avoided the bug was ever fully understood (…

  > does serve a purpose.
I think this is where we're butting heads, because I think this is an ambiguous term.
Post reply on HN