Live data from Hacker News

Be Aware of the Makefile Effect

blog.yossarian.net

151–160 of 347 posts

Re: Be Aware of the Makefile Effect

#151

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…

(Author of the post.)

This is mentioned in footnote 1. Concretely, I don’t think this is exactly the same thing as cargo culting, because cargo culting implies a lack of understanding. It’s possible to understand a system well and still largely subsist on copy-pasting, because that’s what the system’s innate complexity incentivizes. That was the underlying point of the post.

Re: Be Aware of the Makefile Effect

#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’t worth the time or effort.

Re: Be Aware of the Makefile Effect

#153

Is it not a problem which is basically COMPLETELY SOLVED by LLMs ? The reason this happens is because Makefiles (or CI/CD pipelines / linters config, bash scripts) are more or less "complete language" on their own, that are not worth learning when you can do ... exactly what the author says (copy/pasting/modifying until it works) 99% of the time. But LLMs in general know the language so if you ask "write a minimal Ma…

Completely solved? I'd say exacerbated beyond recognition. We have tools to let us get by so much farther without understanding anything, so it probably becomes less of a problem in more cases. But it basically guarantees that all but the most curious will not understand how the system actually works. Everything becomes magical copy/pasting from the most advanced information retrieval system with LLMs.

Re: Be Aware of the Makefile Effect

#154
post #77
post #69

Earlier quoted context omitted.

I like Makefiles, but just for me. Each time I create a new personal project, I add a Makefile at the root, even if the only target is the most basic of the corresponding language. This is because I can't remember all the variations of all the languages and frameworks build "sequences". But "$ make" is easy.

You're probably using the wrong tool and should consider a simple plain shell script (or a handful of them) for your tasks. test.sh, build.sh, etc.

I disagree. Make is - at it's simplest form - exactly a "simple plain shell script" for your tasks, with some very nice bonus features like dependency resolution.

Not the parent, bit I usually start with a two line makefile and add new commands/variables/rules when necessary.

Re: Be Aware of the Makefile Effect

#155
post #153

Is it not a problem which is basically COMPLETELY SOLVED by LLMs ? The reason this happens is because Makefiles (or CI/CD pipelines / linters config, bash scripts) are more or less "complete language" on their own, that are not worth learning when you can do ... exactly what the author says (copy/pasting/modifying until it works) 99% of the time. But LLMs in general know the language so if you ask "write a minimal Ma…

Completely solved? I'd say exacerbated beyond recognition. We have tools to let us get by so much farther without understanding anything, so it probably becomes less of a problem in more cases. But it basically guarantees that all but the most curious will not understand how the system actually works. Everything becomes magical copy/pasting from the most advanced information retrieval system with LLMs.

Imagine if copy-pasting LLM output is the valuable part of human participation in software development. The act of copy-past sounds like drudgery, not problem solving. Another user phrased it best:

https://news.ycombinator.com/item?id=42646989

Re: Be Aware of the Makefile Effect

#156

Earlier quoted context omitted.

Well, yes, but aren't those runners have different configuration than the runners that are actually deployed and used by your company's CI/CD?

Wat? Our company's CI is GitLab CI, self-hosted. What other runners would we need?

The local ones, mentioned in the original comment that we've been discussing in this thread? The local runner, executing on the developer's machine.

Re: Be Aware of the Makefile Effect

#157

> However, the occurrence of the Makefile effect in a simple application suggests that the tool is too complicated for that application. I interpret it in a bit of different way. Makefile is relatively simple and unopinionated like a brick. Also makefile defines/reflects project’s structure. From simple blocks one can build any shape one want. Total freedom. Problem is, make doesn’t impose best practice and doesn’t s…

To expand the illustration:

* using out-of-source builds is a good idea

* using fully automatic dependencies is a good idea

* never committing generated files is a good idea (avoid hysteresis)

It is fundamentally very difficult to get all three of these at once; automatic dependencies often require generating files ahead of time, but generating files often involves needing to know the dependencies or at least their paths ahead of time.

These days the trend seems to be to commit "generated-in-place" files, which avoids some of the historical problems with the last (at the cost of introducing others). I don't claim this is optimal.

Re: Be Aware of the Makefile Effect

#158
post #72

Most of my simple C projects have make.sh instead that has something like: clear gcc some options -o foo && ./foo

You might benefit from make, as you wouldn't need a full rebuild every time, or have to spell out every step.

For C and C++* projects under ~100k lines I wouldnt bother with incremental builds - I have a 70k C project with a single translation unit that builds in under 1s on my machine.

* C++ requires some discipline to not explode build times, but it can be done if you dont go nuts with templates and standard headers.

Re: Be Aware of the Makefile Effect

#159
post #144

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…

I agree, and I think the key distinction is in understanding. In a cargo cult there's a lack of understanding, whereas I'll often copy and paste code/config I understand to get something done. Usually this is for something I don't do very often (configuring nginx, writing some slightly complicated shell script etc.) I could spend an hour reading docs and writing the thing from scratch but that's likely gonna be wasted time because there's a good chance Im not going to look at that thing again for a few years.

Re: Be Aware of the Makefile Effect

#160
post #125

Earlier quoted context omitted.

> I completely encourage anyone to learn as much about the tools and stack as possible, but there is only so much time. That seems like a weird way to think about this. I mean, sure, there's no time today to learn make to complete your C++ ticket or whatever. But yesterday? Last month? Last job? Basically, I think this matches the upthread contention perfectly. If you're a working C++ programmer who's failed to learn…

> I mean, sure, there's no time today to learn make to complete your C++ ticket or whatever. But yesterday? Last month? Last job? That seems like a weird way to think about this. Of course there was no time in the past to learn this stuff, if you still haven't learned it by the present moment. And even if there were, trying to figure out whether there perhaps was some free time in the past is largely pointless, as op…

To be clear: I'm not suggesting a time machine, and I'm not listing any particular set of skills everyone must have. I'm saying that excusing the lack of core job skills by citing immediate time pressure is a smell. It tells me that that someone probably won't ever learn weird stuff. And in software development, people who don't learn weird stuff end up in that 50% bucket posited upthread.
Post reply on HN